Many database servers helpfully provide version number, platform, and other salient details to just about anyone who asks, authenticated or not, which makes fingerprinting these applications a snap. However, Postgres is a little more coquettish about revealing such personal information about itself to just anyone. The best way to determine Postgres' version is to log in and just ask with a "select version()" query, but what if you don't (yet) have credentials?

Lucky for unauthenticated types, it turns out that Postgres is pretty forthcoming in its authentication failure messages. Take this example response to a failed login attempt:

0000   45 00 00 00 61 53 46 41 54 41 4c 00 43 32 38 30  E...aSFATAL.C280
0010   30 30 00 4d 70 61 73 73 77 6f 72 64 20 61 75 74  00.Mpassword aut
0020   68 65 6e 74 69 63 61 74 69 6f 6e 20 66 61 69 6c  hentication fail
0030   65 64 20 66 6f 72 20 75 73 65 72 20 22 70 6f 73  ed for user "pos
0040   74 67 72 65 73 22 00 46 61 75 74 68 2e 63 00 4c  tgres".Fauth.c.L
0050   32 37 33 00 52 61 75 74 68 5f 66 61 69 6c 65 64  273.Rauth_failed
0060   00 00                                            ..

This tells us that an error (E) was encountered related to the source file (F) auth.c, on line (L) 273, in the routine (R) auth_failed. From here, it's pretty easy to guess what happens when Postgres has a new release -- usually, things like line counts tend to change. That means we can use this error code as a handy fingerprint for pretty much every minor version release of Postgres: The above comes from version 8.4.2, but on 8.4.1, the line number is 258, it's 1017 in 8.3.9, et cetera. These differences go back at least as far as Postgres 7.4.

Metasploit (as of this morning) now supports Postgres enumeration using this technique. Check it out with a quick update. The module looks something like this:

msf auxiliary(postgres_version) > set verbose true
verbose => true
msf auxiliary(postgres_version) > run
 
[*] 192.168.145.50:5432 Postgres - Trying username:'postgres' with password:'?dsx)S' against 192.168.145.50:5432 on database 'template1'
[+] 192.168.145.50:5432 Postgres - Version 8.4.2 (Pre-Auth)
[*] 192.168.145.50:5432 Postgres - Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

As mentioned at the top, if you do happen to have login credentials, you can always use those instead:

msf auxiliary(postgres_version) > set username scott
username => scott
msf auxiliary(postgres_version) > set password tiger
password => tiger
msf auxiliary(postgres_version) > run
 
[*] 192.168.145.50:5432 Postgres - Trying username:'scott' with password:'tiger' against 192.168.145.50:5432 on database 'template1'
[*] 192.168.145.50:5432 Postgres - querying with 'select version()'
[+] 192.168.145.50:5432 Postgres - Command complete.
[+] 192.168.145.50:5432 Postgres - Logged in to 'template1' with 'scott':'tiger'
[+] 192.168.145.50:5432 Postgres - Version 8.4.2 (Post-Auth)
[*] 192.168.145.50:5432 Postgres - Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We've collected a few signatures so far; we can reliably identify pretty much all of the straight Linux builds of Postgres from 7.4.26 through 8.4.2, as well as the latest Windows build. So, in the event you run into a version/platform combination of Postgres that we haven't accounted for yet, the module will display and log the relevant signature data for an easy copy-paste. Feel free to let us know about it so we can package it up. In the meantime, I'm off to hunt down some more Postgres installs.