Metasploitable 2 Walkthrough: Part VIII

Exploiting Port 3632 – DistCC

DistCCd is the server for the DistCC distributed compiler. It accepts and runs compilation jobs for network clients. Metasploit has a module to exploit this service.

Exploiting DistCC with MSF

This is another low privileged account.

Exploiting Port 5432 – PostgreSQL

One of the first pieces of information you will need, even before running a brute-force attack on a PostgreSQL login, is a database name.

Fortunately, the way that PostgreSQL works is by shipping with a default database called template1 that is the template database from which all other databases are created. This means that you can (probably) always find a database named template1 in any PostgreSQL database.

There is also a template0 database, which contains no local settings and is even more basic than template1, so there should always be at least these two known databases in any PostgreSQL service.

Brute forcing PostgreSQL using Metasploit

There are several Metasploit modules to be used against PostgreSQL, but you should start with the one that might give you access to the database.

The procedure is exactly the same as for the previous services:

  • Load module
  • Check default options
  • Select user and password files, or other creds
  • Run module

The Metasploit PostgreSQL login module

Try to run the module with the default settings, adjusting only the IP of the target machine

Running the PostgreSQL login module with default settings

Another option is to use the credentials previously found and stored in the workspace

Running the PostgreSQL login module with custom settings

In this case, the result is exactly the same.

Now that you have login credentials for the PostgreSQL server, use them to do admin stuff like running arbitrary SQL statements with Postgres.

NOTE: Brute forcing the service using Hydra is exactly the same as it was done for previous services

Exploiting PostgreSQL using Metasploit

Load the auxiliary admin module to run the SQL commands

The Metasploit PostgreSQL admin module

As you can see, the default options are almost perfect. Try to get the names of the existing databases:

Running the Metasploit PostgreSQL admin module

Postgres implements its databases differently from MySQL, so to list all the databases, you need a different command then "SHOW DATABASES". For PostgreSQL, you can use the pg_database database.

The following SQL command gets names of databases from pg_database:

select datname from pg_database;

the following also works:

select pg_database.datname from pg_database;

Running the Metasploit PostgreSQL admin module with proper command

Getting the /etc/passwd using PostgreSQL

With MySQL, you were able to obtain files on the remote machine using the SQL statement select load_file(\'/etc/passwd\'). However, the load_file function isn't available in PostgreSQL.

PostgreSQL implements it as load:

load \'/etc/passwd\'

Trying to read the /etc/passwd with postgres

This has a problem; invalid ELF header. (Like it is trying to load a binary file...?). So, this module doesn't allow you to load files as easily as, say, MySQL. Maybe you can try a different module.

The Metasploit PostgreSQL readfile module

Again, almost perfect default options.

Reading the /etc/passwd with postgres

It works perfectly, with an important bonus. Take a look at the end of the module output:

MSF readfile module output

The contents of the /etc/password were saved inside the workspace for later use. You can see it with the loot command:

The MSF loot command

Delivering a payload with PostgreSQL

To deliver a payload, use the payload module associated with PostgreSQL.

Delivering a payload with postgres

Dumping the PostgreSQL database

To dump the contents of a PostgreSQL database, use the pg_dump command.

You can check all the flags with man pg_dump, but the basic ones you will need are:

  • Username
  • Password (does not accept password typed as an argument on command line, apparently?)
  • Database (one of the three above, postgres, template0, or template1)
  • Table (you can use wildcards to match table names)
  • A file to capture all the output

Dumping the database with pgdump

Like mysqldump, pg_dump will output the SQL commands required to exactly replicate the database and tables selected.

However, unlike mysqldump, postgres implements an additional layer, implemented within SQL itself, that enables a lot of additional functionality. This implements all sorts of different databases and tables for PostgreSQL user management and function definitions.

While this represents a huge attack surface that would make malicious code difficult to find, this PostgreSQL database does not appear to be used for anything. The port is open and the server is listening, but there is no purpose. (Other than to provide Metasploitable users another route into the machine.)

That means that --table='*' will dump out a lot of superfluous stuff.

No comments: