Shulou(Shulou.com)05/31 Report--

How to carry out CVE-2015-1641 Office type confusion vulnerabilities and shellcode analysis, in view of this problem, this article introduces the corresponding analysis and solutions in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

0x1 experimental environment: Win7_32 bit, Office2007

0x2 tools: Windbg,OD, velvet sword, UltraEdit,oletools

0x3 vulnerability description: word parses the displacedByCustomXML attributes of docx documents without validating the customXML object, and can pass in other tag objects for processing, causing type confusion by embedding the constructed RTF file in word, in which carefully constructed tags and corresponding attribute values are parsed by displacedByCustomXML and subsequent functions will cause arbitrary memory writing.

0x4 sample hash value: 8bb066160763ba4a0b65ae86d3cfedff8102e2eacbf4e83812ea76ea5ab61a31

Download link: https://github.com/houjingyi233/... 76ea5ab61a31.bin.gz

0x5: analysis record:

Before the analysis, take a snapshot of the virtual machine, get the RTF sample and analyze it using the rtfobj.pyc script in the oletools tool. Here, name the file aa.doc, in the cmd command mode, go to the directory where rtfobj.pyc is located, and put the aa.doc in that directory, then execute the command "rtfobj.pyc aa.doc". The analysis results are as follows: there are four files, and the one with id of 0 is "otkloadr.wRAssembly.1", which is used to load the OTKLOADR.DLL module. Its function will be analyzed later:

Separate and save the other three OLE objects according to their respective id with the command "rtfobj.pyc-s [id] aa.doc". Two of them are ".doc" files. Now that the samples have been separated, double-click execution will not be dangerous.

After changing the suffix of "aa.doc_object_0002042c.doc" with an id of 2 to ".docx", opening the word will cause a collapse, and it can be predicted that the vulnerability will be triggered in this OLE:

In the process of analyzing this sample, because I was not familiar with the construction of RTF files, I was blocked for a long time when I constructed the samples. I just couldn't create crash. Later, I put the problem on the Kanxue Forum, and the predecessors solved it at once. In fact, the structure of RTF files is not complex: open the original rtf samples in text and search for the "objdata" string. You can find the content of the corresponding id after rtfobj.py extraction, and manually extract the content of the corresponding id and save it as a legitimate rtf file. As mentioned earlier, this RTF sample consists of four OLE objects. Open the original sample with notepad++, then search for the "objdata" string, and find that there are four such strings, namely, the four OLE. The id of the OLE that triggered the vulnerability is 2, that is, the third OLE in the original sample, which looks like this:

When extracting and copying OEL, be sure to match the parentheses in pairs, copy out the OLE, that is, the part from the beginning of it to the beginning of the next OLE, then create a new text document and change the suffix to ".rtf" format, then write "{\ rtf}" in this document first, and then paste OLE into it:

Then open the RTF file with word, and you will collapse; you have failed several times in between, but it turns out that there are too many parentheses when you copy the OLE.

Next, to locate the location of the vulnerability trigger, first open Windbg, then open Winword.exe, and then run the vulnerable OLE file after attaching Winword.exe with the debugger. The program has an exception at the address of "0x67C39d30", resulting in collapse because [ECX] refers to an address that does not exist.

Where does this pointer [7C38BD50] point to? First extract the vulnerable OLE and find the following code in the resource organization file "document.xml" of the decompressed directory: the value of the above ECX is embedded into the attribute value of the element of the smarttTag tag

MartTag tag is a smart tag that can automatically identify the name, address, etc., the displacedByCumtomXml attribute means that it should be replaced here with another customxml tag, "next" represents the latter, and "prev" represents the former one; the sample author constructed 0x7C38BD50 Magi word in the element of smartTag without verifying the customXML object when parsing the customXML document processing displacedByCustomXML attributes, so it can be imported into the smartTag tag object.

When the OLE that triggered the vulnerability is loaded separately, it is indexed to an address that does not exist, because the address is in "MSVCR71.DLL", and this DLL is introduced through the first OLE object "otkloadr.wRAssembly.1". Add the first OLE object: {\ object\ objocx {\ *\ objdata0105000002000000160000006f746b6c6f6164722e5752417373656d626c792e3100000000000000000001000000410105000000000000}} in front of the OLE that triggered the vulnerability, and then reload the merged RTF run. Through the conditional breakpoint under windbg, first record the address of the module where "0x7C38BD50" is located when the crash occurs, and then use it to set the conditional breakpoint:

Conditional breakpoint:

Bp wwlibaked DllGetClassObject0x50e6 ".if (ecx=7c38BD50) {} .else {gc}"

0x7C38BD50 is the element value of the smartTag tag, and 0xFFFFE696 (decimal 4294960790) is the value of moveFromRangeStart, which is then calculated to get an address 0x7C38BD74. The calculation process is as follows:

Then the element value of the second smartTag,smartTag tag is 0x7C38BD68. The value of moveFromRangeStart is 0x7C376FC3 (decimal is 2084007875), and the calculated address is 0x7C38A428. Finally, the 0x7C376FC3 is overwritten to the address 0x7C38A428 through the memcpy function. As can be seen in the debugger, 0x7C38A428 is a virtual table pointer:

Before 7C38A428 is overwritten, it points to kernel32 percent FlsGetValue:

The overwritten 0x7c38a428 points to the location of the code that the attacker wants to execute:

The next execution will first go through a large area of "ret" with the address "7C342404", then enter the ROP chain, and then shellcode.

After decompressing the OLE with id 1, you can see the data block used for heap spray in the "activeX1.bin" of the decompression directory: the ROP chain is on the nop instruction, and a large number of ret-sled with the address 0x7c342404 will be used before heapspary.

Load the heap data of "activeXL.bin" through XML:

Before the heap spray data sees the ROP chain, there are a large number of "ret sled". You can enter the shellcode through this address: after entering the MSVCR71.dll, use the "uf 7C342304" command to check the address of the module that it is located in: MSVCR71 declare calloclocation0xb1, and break it there; then use the "bd" command to disable the previous conditional breakpoint, and F10 can come to the address 0x7C342404 after execution. As shown in the following figure, when the program is cut off at "0x7C342404", you can see the heap spray data by entering Virtual to "ESP" through the "Memory" window. If you cannot enter the heap spray data, there are two solutions: you can set the memory of the virtual machine to 2G, or you can find the position of the rop chain in the heap, and then change the top value of the stack to the starting position of the ROP chain when you execute "ret" to jump into the heap spray data.

After executing the "ret" at "0x7C342404", you can then follow the ROP chain, and F10 steps through: then enter the shellcode through NOP.

The analysis of shellcode in Windbg has not been able to follow smoothly, so in OD, the breakpoint is still in "0x7C342404": after opening OD and Winword.exe, attach Winword.exe with OD, and then drag the complete sample into word, you can drop the breakpoint, because shellcode is the last execution, before it is necessary to heap spray, and then trigger vulnerabilities, the time is too late. When the program is broken in the "0x7C342404" place, it is found that the ROP chain cannot be followed for a long time. At this time, with the help of the analysis results of the previous Windbg, it is found that the first position of the ROP chain is "0x7C3651EB", and then the breakpoint at the "0x7C342404" is disabled. Then F9 executes, and you can come to the beginning of the ROP chain.

DEP protection after closing the starting address 0x090008b4 in the ROP chain by calling VirtualProtect:

Then execute the "nop+shellcode" at the address 0x090008b4:

First get the kernel32.dll base address:

Then compare the hash value of API to get the desired API function, which has the advantage of reducing the size of the shellcode:

Then use VirtualAlloc to allocate executable memory space in preparation for shellcode execution:

Then get the handle of the open sample file by calling GetFileSize to traverse the open file handle in the process:

CreateFileMapping creates the shared file data for this file:

MapViewOfFile to get the memory address of shared data:

Determine if several flag bits are "{\ rt,0xfefefefe,0xfe,0xffffffff", and copy the shellcode to the executable memory space allocated by VirtualAlloc:

However, in the later analysis, many times of debugging did not follow the location of the real shellcode, so I tried to use Windbg to analyze. According to the analysis of the previous stage, the shellcoed of the first stage first judged whether several flag strings were "{\ rt,0xfefefefe,0xfe,0xffffffff". If so, it copied the real shellcode to the executable memory space allocated by VirtualAlloc, as shown in the above figure: if it goes well, it will execute the instruction at the address of "0x090009F9" (offset 0x09F9).

Then turn off OD, open Windbg and Winword.exe, attach Winword.exe with Windbg, first break at the position of "0x7C342404", that is, "ret" chain, then attach the original sample to Winword.exe, then come to "ret" after execution, then break at the beginning of "0x7C3651EB", that is, ROP chain, and disable the previous breakpoint with "bd 0". After execution, you come to the beginning of the ROP chain. According to the above analysis, the real shellcode will start execution at the offset "0x09F9". Delete the previous breakpoint with "bc 0" and "bc 1", and then break it under "0x090009F9". After execution, you can successfully come to the second stage of shellcode:

Then copy the data of the following 4KB, that is, the second part shellcode, to the memory with executable permission requested by the function VirtualAlloc, and then jump to execute.

The shellcode is then decrypted at the offset 0x2e of this part of the shellcode, and the size of the decryption is 0x3CC bytes:

Then the starting position of the payload is obtained according to the flag string "0xBABABABABA", and then the xor 0xCAFEBABE decodes the payload with the termination flag 0xBBBBBBBB:

Then create the file and release the payload:

You can see the path and the created file "svchost.exe" in the UE editor based on the API parameter:

Then execute "svchost.exe" with the WinExec function:

After the WinExec function is executed, you can see the released malicious program in the monitoring software (tindery sword). Its main function is to steal information:

After the malicious payload is executed, XOR operations are performed on some of the data in the sample in order to make it look like a normal word. This machine code begins with "0xBB" and ends with "0xBCBC".

The word you see after rewriting is a blank document that opens normally:

The word document where the original sample is located:

This is the answer to the question on how to carry out CVE-2015-1641 Office type confusion vulnerabilities and shellcode analysis. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.