Lame Writeup w/o Metasploit
Reconnaissance
First thing first, we run a quick initial nmap scan to see which ports are open and which services are running on those ports.
-sC: run default nmap scripts
-sV: detect service version
-O: detect OS
-oA: output all formats and store in file nmap/initial
We get back the following result showing that these ports are open:
Port 21: running File Transfer Protocol (FTP) version 2.3.4. This allows anonymous login so we should keep that in mind.
Port 22: running OpenSSH version 4.7p1.
Ports 139 and 445: are running Samba v3.0.20-Debian.
Before we start investigating these ports, let’s run more comprehensive nmap scans in the background to make sure we cover all bases.
Let’s run an nmap scan that covers all ports.
We get back the following result.
We have a new port that did not show up in the initial scan.
Port 3632: running the distributed compiler daemon distcc version 1.
Similarly, we run an nmap scan with the -sU flag enabled to run a UDP scan.
We get back the following result. As can be seen, all ports are either filtered or closed.
Our initial recon shows that we potentially have four different points of entry to this machine.
Enumeration
Let’s enumerate more to determine if any of these services are either misconfigured or running vulnerable versions.
Port 21 vsftpd v2.3.4
A quick google search shows us that this version is famously vulnerable to a backdoor command execution that is triggered by entering a string that contains the characters “:)” as the username. When the backdoor is triggered, the target machine opens a shell on port 6200. This exploit is simple enough to exploit manually but we’re trying to move to more automation so let’s see if there is an nmap script that already checks for that.
Execute the script on port 21 of the target machine.
The script output shows that we’re not vulnerable to this vulnerability. Let’s move on to our second point of entry.
Port 22 OpenSSH v4.7p1
After a quick google search, nothing major pops up. Nmap contains multiple scripts that can brute force credentials amongst other things.
This might take a while and could potentially lead us nowhere so we’ll put this on the back burner and get back to it later if the other points of entry don’t pan out.
Ports 139 and 445 Samba v3.0.20-Debian
I have high hopes to gain at least an initial foothold using these ports.
Let’s use smbclient to access the SMB server.
-L: lists what services are available on a server
Anonymous login is allowed.
Let’s view the permissions on the share drives.
-H: IP of host
We get back the following result. Interesting! We have READ/WRITE access on the tmp folder.
Let’s go back to our google friend to see if this version of Samba is vulnerable. It seems to have had its fair share of vulnerabilities. We’re looking for a code execution vulnerability that would ideally give us Admin access. After going through all the code execution vulnerabilities, the simplest one that won’t require me to use Metasploit is CVE-2007–2447.
The issue seems to be with the username field. If we send shell metacharacters into the username we exploit a vulnerability which allows us to execute arbitrary commands. Although the exploit available on exploitdb uses Metasploit, reading through the code tells us that all the script is doing is running the following command, where “payload.encoded” would be a reverse shell sent back to our attack machine.
Before we exploit this, let’s look at our last point of entry.
Port 3632 distcc v1
Googling “distcc v1” reveals that this service is vulnerable to a remote code execution and there’s an nmap script that can verify that.
The result shows us that it’s vulnerable!
So we have two potential ways to exploit this machine.
Exploitation #1: Samba
Add a listener on attack machine.
Log into the smb client.
As mentioned in the previous section, we’ll send shell metacharacters into the username with a reverse shell payload.
The shell connects back to our attack machine and we have root! In this scenario, we didn’t need to escalate privileges.
Grab the user flag.
Grab the root flag.
Exploitation #2: Distcc
In the previous section, we saw that this service is vulnerable to CVE 2004–2687 and there’s an nmap script that can be used to exploit this vulnerability and run arbitrary commands on the target machine.
First, start a listener on the attack machine.
Then, use the nmap script to send a reverse shell back to the attack machine.
The shell connects back to our attack machine and we have a non privileged shell!
We’ll need to escalate privileges. Google the OS version — Linux 2.6.24 to see if it is vulnerable to any exploits. I tried CVE 2016–5195 and CVE 2008–0600, but they didn’t work.
Let’s try CVE 2009–1185. Download the exploit from searchsploit.
Start up a server on your attack machine.
In the target machine download the exploit file.
Compile the exploit.
To run it, let’s look at the usage instructions.
We need to do two things:
Figure out the PID of the udevd netlink socket
Create a run file in /tmp and add a reverse shell to it. Since any payload in that file will run as root, we’ll get a privileged reverse shell.
To get the PID of the udevd process, run the following command.
Similarly, you can get it through this file as mentioned in the instructions.
Next, create a run file in /tmp and add a reverse shell to it.
Confirm that the reverse shell was added correctly.
Set up a listener on your attack machine to receive the reverse shell.
Run the exploit on the attack machine. As mentioned in the instructions, the exploit takes the PID of the udevd netlink socket as an argument.
We have root!
We solved this machine in two different ways!
Lessons Learned
Always run a full port scan! We wouldn’t have discovered the vulnerable distributed compiler daemon distcc running on port 3632 if we only ran the initial scan. This gave us an initial foothold on the machine where we were eventually able to escalate privileges to root.
Always update and patch your software! In both exploitation methods, we leveraged publicly disclosed vulnerabilities that have security updates and patches available.
Samba ports should not be exposed! Use a firewall to deny access to these services from outside your network. Moreover, restrict access to your server to valid users only and disable WRITE access if not necessary.
Last updated