Metasploitable Guide Part 4 : Exploiting Distributed C Compiler and Bruteforcing PostgreSQL

Posted: November 27, 2011 in Guides
Tags: , , , ,

In the last edition of this guide we bruteforced MySQL, exploited Apache Tomcat 5.5 and the TikiWiki 1.9.5 web application. We obtained two additional shells and the MySQL dbms admin credentials. At the end of the last guide I said there was one more vulnerable service installed on this machine, however that our initial nmap scan did not detect it.

I suggested that we look through the system and pointed out a netstat output from an ssh session with the system. Hopefully you discovered the application I was talking about, however if you didn’t here we go. The line I was referring to in netstat was this.

tcp6       0      0 :::3632                 :::*                    LISTEN      -

There is something listening on port 3632, we’re not sure what yet — however we know it’s something. If we do some research on what normally runs on port 3632, we will discover it is the distributed compiler. Further examination of the target system will find the following related files

  • /usr/share/doc/distcc : which contains all the associated documentation
  • /usr/bin/distcc : executable
  • /etc/distcc : presumably contains config files but there is nothing there
  • /var/lib/distcc : does contain configuration files, as well as available compilers

A simple distcc at the prompt will give us the distribute compiler banner

distcc 2.18.3 i486-pc-linux-gnu (protocols 1 and 2) (default port 3632)
  built May  1 2007 10:25:30

Which tells us the version of the software. A simple google search will provide us with CVE-2004-2867.

Exploiting the Distributed C Compiler

Now that we have the necessary information about our vulnerable service we can utilize the Metasploit Framework to exploit it. So again we search for our CVE, and we’re not presented with anything…Well that’s inconvenient, let’s try searching for distcc.

Ahh victory 🙂

You’ll notice I configured RHOST to be 192.168.0.10 — even though the service was bound only to ipv6 this works because it was bound to all interfaces, if this was bound specifically to one interface, and our target had multiple interfaces we would have had to configure it for an ipv6 address.

And there’s our last shell.

Obtaining Postgres Credentials

The next step is to obtain the credentials from Postgres SQL. So we’re going to load up our brute-force module, and run it against the database.

We’ll be informed that the dbms admin is postgres with password postgres and the current database is template1.

Stay Tuned…

Next time we’re going to discuss profiling certain local vulnerabilities on the Metasploitable system including local escalation, as well as utilizing some other automated tools with the Metasploit Framework. We will set up our compromised Metasploit server so that it will aid us in gaining access to other machines that access it (in the event this were an actual system on a network somewhere).

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s