jbremer
commented
8 years ago Interesting, thanks! Will investigate further soon. Seems that the cause is the logging of RegEnumValueA, but will have to see which parameter :)
Open jjo-sec opened 8 years ago
jbremer
commented
8 years ago Interesting, thanks! Will investigate further soon. Seems that the cause is the logging of RegEnumValueA, but will have to see which parameter :)
knifeyspoony
commented
8 years ago Hey, I'm seeing this issue with PDFs as well, which leads me to believe that it might be a bug in the logging facilities.
knifeyspoony
commented
8 years ago From my limited debugging capability with the monitor, it looks like the crash is due to the parameter
LPTSTR lpValueName regkey_r
When I disabled it, it crashed later at RegEnumKeyExA, presumably when trying to log the same parameter.
Looking at report.json, the regkey field contains unicode characters at the end. (in this case \uFFB4). I'll try to see why this causes a crash, but hopefully this helps you @jbremer !
knifeyspoony
commented
8 years ago It looks like this happens when trying to encode ascii as UTF-8, but a non-ascii character is encountered.
If you have a signed char* above 0x7F, it gets sign extended. For example:
A char* buffer starts with the value 0x81, and then has some other bytes.. So utf8_bytecnt_ascii will pass 0xFFFFFF81 to utf8_length, which expects an uint32_t. This is then passed along to utf8_encode, which checks 0xFFFFFF81 and returns -1. Now, this becomes a problem when you try to actually write the encoded string to the utf8string buffer.
The utf8string holds the length in the first 4 bytes, and the buffer follows. When the first character is "written", using utf8_encode, the pos variable is incremented by the number of bytes written (-1). Now when the NEXT byte is written, it's actually overwriting the length value in the utf8string buffer!! This kills the dll down the road when the string is checked ;)
I guess a solution would be to force the character to be unsigned, or, escape non ascii characters when encoding what we think is an ascii string.
jbremer
commented
8 years ago I've pushed a new version of monitor including a fix for the bug as reported by @knifeyspoony. Thanks a lot for that! @arbor-jjones Could you please verify if your bug is still present with the latest monitor?
jjo-sec
commented
8 years ago I am still seeing crashes with injection both enabled and disabled on both win7 and winxp. The exception causing the crash with injection has changed and hopefully will match the exception that happens without injection. The documents are similar to what is blogged here in that they have mangled RTF headers and exploit the same vulnerability, but their shellcode is obfuscated and they are being used in targeted attacks : http://www.sekoia.fr/blog/ms-office-exploit-analysis-cve-2015-1641/
New exception:
stacktrace:
DllSetProperty+0x1e162 msxml6+0xe22e7 @ 0x715322e7
DllRegisterServer+0x99b94 DllSetProperty-0x5054 msxml6+0xbf131 @ 0x7150f131
DllRegisterServer+0x41f32 DllSetProperty-0x5ccb6 msxml6+0x674cf @ 0x714b74cf
DllRegisterServer+0x44b76 DllSetProperty-0x5a072 msxml6+0x6a113 @ 0x714ba113
DllRegisterServer+0x42b1e DllSetProperty-0x5c0ca msxml6+0x680bb @ 0x714b80bb
_MsoFreeCvsList@4+0x58d94 _MsoFHideTaiwan@0-0x13183 mso+0x25d04e @ 0x666ad04e
_MsoFreeCvsList@4+0x58622 _MsoFHideTaiwan@0-0x138f5 mso+0x25c8dc @ 0x666ac8dc
_MsoFreeCvsList@4+0x6728 _MsoFHideTaiwan@0-0x657ef mso+0x20a9e2 @ 0x6665a9e2
_MsoFreeCvsList@4+0x6538 _MsoFHideTaiwan@0-0x659df mso+0x20a7f2 @ 0x6665a7f2
_GetAllocCounters@0+0x2229e DllGetLCID-0x1d4990 wwlib+0x39066 @ 0x68a09066
_GetAllocCounters@0+0x21ba4 DllGetLCID-0x1d508a wwlib+0x3896c @ 0x68a0896c
_GetAllocCounters@0+0x1e62d DllGetLCID-0x1d8601 wwlib+0x353f5 @ 0x68a053f5
_GetAllocCounters@0+0x1e2b3 DllGetLCID-0x1d897b wwlib+0x3507b @ 0x68a0507b
_GetAllocCounters@0+0x1c43b DllGetLCID-0x1da7f3 wwlib+0x33203 @ 0x68a03203
_GetAllocCounters@0+0x1bc92 DllGetLCID-0x1daf9c wwlib+0x32a5a @ 0x68a02a5a
_GetAllocCounters@0+0x1552f DllGetLCID-0x1e16ff wwlib+0x2c2f7 @ 0x689fc2f7
_GetAllocCounters@0+0x2077 DllGetLCID-0x1f4bb7 wwlib+0x18e3f @ 0x689e8e3f
DllGetClassObject+0x29ea _GetAllocCounters@0-0xee02 wwlib+0x7fc6 @ 0x689d7fc6
FMain+0x245 DllGetClassObject-0x2a0 wwlib+0x533c @ 0x689d533c
wdCommandDispatch-0x964 winword+0x1602 @ 0x2fa01602
wdCommandDispatch-0x9cc winword+0x159a @ 0x2fa0159a
BaseThreadInitThunk+0x12 SetUnhandledExceptionFilter-0xbc kernel32+0x53c45 @ 0x761b3c45
RtlInitializeExceptionChain+0xef RtlFreeSid-0x117 ntdll+0x637f5 @ 0x775a37f5
RtlInitializeExceptionChain+0xc2 RtlFreeSid-0x144 ntdll+0x637c8 @ 0x775a37c8
exception.instruction_r: c9 c2 10 00 89 45 c0 eb ed 64 a1 18 00 00 00 8b
exception.instruction: leave
exception.exception_code: 0xe0000002
exception.symbol: RaiseException+0x54 BaseReleaseProcessDllPath-0x100 kernelbase+0xb760
exception.address: 0x7571b760
registers.esp: 1461412
registers.edi: 146382008
registers.eax: 1461412
registers.ebp: 1461492
registers.edx: 0
registers.ebx: 146381808
registers.esi: 146381820
registers.ecx: 1 @arbor-jjones I'm not sure if I can help with that one. According to https://msdn.microsoft.com/en-us/library/het71c37.aspx this error code is defined as follows, which would make me believe that your version of Office doesn't support this particular file. Of course if you can open the file without Cuckoo / injection running than something else is going wrong. Given the mangling as explained in the blogpost I wouldn't be surprised if something went wrong.
#define STATUS_FILE_BAD_FORMAT 0xE0000002That's definitely an odd error, but it seems to only occur when WinWord is launched using inject-x86 - with or without injection specified.
I verified that manually opening the documents in a cuckoo VM directly with winword or launching inside of a Sandboxie sandbox and the exploitation happens successfully.
I did manual testing in Win7x86/WinXP with Office 2010 / 2013 (do not have access to any Office version below that, so cannot tell if this is something that only occurs in newer office versions) where I manually ran inject-x86.exe with the path to word and injection disabled via the CLI option and then opened the document inside word and experienced the same crashes that I see when Cuckoo runs with injection.
Example file that worked in Cuckoo 1.X (where winword was launched via createprocess), but I see crashes in 2.X:
https://malwr.com/analysis/ZGM1OTdjMTZhODlkNDYxNjliYTg1ZDU4OGU1YzBjZjU/#
There should be a dropped dll that gets run via rundll32 and a dropped decoy doc if the exploitation is successful like it is when run not with inject-x86 / cuckoo.
jbremer
commented
8 years ago Do you have any idea whether the issues from this thread are still present? I believe quite a few of them should be resolved by now. @arbor-jjones
jjo-sec
commented
8 years ago When run without injection all appears to function correctly now, but still see premature crashes instead of finishing the payload execution / respawn decoy doc when run with injection.
I tried changing the mode to exploit and office using the latest commits in both monitor and cuckoo, but still am not able to achieve full execution of the exploit and subsequent dropped payload.
jbremer
commented
8 years ago Oke thanks :-) To be continued soon then ;-)
VM: Win7SP1 x32, Office 2013 (also occurs in Office 2010 in Win7 and WinXP)
One Example: This is actually an rtf file that should be named as .doc ( I can share more samples privately if needed ): https://malwr.com/analysis/OTdkMGNiMjI4NjcxNDVhZjg5NzUzZGFiNjBmOTlmMzY/
These documents exploit CVE-2015-1641, so it is possible that something to do with the way the exploit works is causing this issue. The shellcode has some standard obfuscation and then walks the PEB and loaded DLLs to find what it is looking for.
I have managed to trace the crash issue down to inject-x86.exe - If i manually run inject-x86.exe --free --app and then open the doc, it crashes during the exploitation process. If i manually type in cmd prompt and open the doc, the exploitation process succeeds. The documents worked when using Cuckoo 1.X's method of CreateProcessA vs calling inject.exe's shellcode injection to spawn.
Exception seen when injected, possible false flag: