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

Today, I will talk to you about the latest technical analysis of the special processing logic using the Office formula editor, which may not be well understood by many people. in order to make you understand better, the editor has summarized the following content for you. I hope you can get something according to this article.

Background

On August 24, 2018, the threat Intelligence Center captured a phishing document specially designed for Ukrainian users: the document is in RTF file format and has detailed contents. After analysis, it is confirmed that this is the first vulnerability exploit sample specially designed for the special processing logic of Office formula editor to bypass antivirus software, and the vulnerability involved is CVE-2017-11882.

As the Payload triggered by the vulnerability has become invalid, the threat Intelligence Center makes a detailed analysis of the special kill-free technology used by the samples in this paper, and reminds all antivirus software manufacturers to do a good job in testing this utilization mode. As the kill-free technology has appeared in the samples used in the field, a large number of actual attack samples may use this kill-free method to escape killing soft detection, forming a new threat.

Document content

Google content translation

The effect of exemption from killing and the characteristics of samples

The results of checking and killing the captured samples on VirusTotal are as follows. When uploaded for the first time, only four killing softwares can be checked and killed, and only two killing softwares can correctly identify vulnerabilities, and almost all killing soft killers can be avoided if slightly modified:

Sample characteristics-Special Formula object OLE

The special sample captured is not a CompoundFile Binary Format (compound binary document) stream after the header of the RTF control word "\ objdata". It is directly followed by the data (MTEF data) of the formula object, and not even the header data (Equation Native Header) of the formula object:

And such a "malformed" CVE-2017-11882 vulnerability exploitation document can successfully trigger vulnerability exploitation.

Let's first review the ways to exploit vulnerabilities in the Office formula editor in normal RTF documents, taking CVE-2017-11882 as an example:

First, an objdata is inserted into the RTF document, immediately after the RTF control word "\ objdata", followed by a 4-byte version ID, format_id (embed stands for embedded), OLE stream name (Equation.3), and so on:

Header:

01050000 / / version02000000 / / format_id (embed) 0b0000004571756174696f6e2e3300 / / "Equation.3" could be anything0000000000000000410f0000 / / data length

The header of "\ objdata" is followed by the OLE object stream, and you can see its special CompoundFile Binary Format (compound binary document) logo: D0 CF 11 E0...

The OLE object stream that follows is a composite binary file (Compound File Binary Format), which you can see through parsing to be an Office Formula 3.0 editor object, RootEntry with a formula editor CLSID {0002CE02-0000-0000-C000-00000046}:

The included Office Formula 3.0 editor object consists of formula headers + formula data:

360 threat Intelligence Center makes a detailed analysis of this special vulnerability exploitation technology, and the whole analysis process is as follows.

The flow of Office processing\ objdata objects in RTF

With the question of why Office can correctly handle embedded non-OLE objects (and the object is a formula object without a formula header), we analyze in detail the process of Office processing\ objdata objects embedded in RTF documents, which can be represented by the following flowchart:

From the perspective of the whole process, when WINWORD.EXE loads the RTF file and parses the RTF file format, the function ole32 convert OleConvertOleSTREAMToIStorage is called to transform the specified object from the OLE 1 storage model to the OLE 2 structured storage object. The ole32ConvertOLESTREAMTOIStorage called internally is responsible for parsing and converting OLE 1 objects into OLE 2 storage objects from the RTF file. Finally, the ole32 conversion GenericObjectToIStorage function is responsible for transferring the OLE 2 storage objects to the EquEdt32.exe process through the clipboard:

First, the ole32SecretwConvertOLESTREAMTOIStorage function hands over the specific transaction to Ole32SecretOLESTREAMToGenericObject:

Ole32! The OLESTREAMToGenericObject function completes the reading and conversion of OLE1 objects, and internally calls OLE1StreamToUL and OLE1StmToString (also called OLE1StreamToUL function) to read OLE1 objects Version, format_id, ClassName (Prog ID), static object, linked nor an embedde, topic, Item, NativeData and other information, that is, to deal with the header part of\ objdata:

You can also view the corresponding\ objdata through oletools's rtfobj tool to get the same information:

It further determines whether format_id is FMTID_EMBED (linked nor embedde), and then calls the wCLSIDFromOle1Class function to read the CLSID of the Ole1 object:

The wCLSIDFromOle1Class function determines whether the passed szProgID is an object with the name "OLE2Link". If so, it returns CLSID_StdOleLink, otherwise it is handed over to the proxy function CLSIDFromOle1Class to convert the stream name of Ole1 to the corresponding CLSID (that is, to convert the stream name Equation.3 to the corresponding clsid):

CLSIDFromOle1Class is handed over to the proxy function wCLSIDFromOle1Class to handle:

The wCLSIDFromOle1Class function will open the registry HKEY_CLASSES_ROOT\ [szProgID] (HKEY_CLASSES_ROOT\ Equation.3 here) to query its CLSID. If the query is successful, call the wGUIDFromString function to get the GUID return:

If the CLSID cannot be queried through the stream name, call the Ole10_CLSIDFromString function to traverse the built-in Object name in the OLE32, and return its CLSID if the same is found:

Ole32! The GenericObjectToIStorage function registers the clipboard based on the returned CLSID and writes the OLE 2 data to the clipboard:

Then WINWORD.EXE will call the ole32 Ole1Class load function to load the object corresponding to the CLSID, and finally locate the function Ole 32CoIsOle1Class. This function determines whether the Ole is a valid Ole1Class object, and if it is not a valid Ole1Class object, it returns directly. If it is a valid Clipboard object, it calls the API to process the clipboard data. The following is the process of loading the formula object:

In particular, WINWORD.EXE parses the CFB file to write the stream object of the CFB file to the clipboard before calling the ole32OleLoad function, and overwrites the Clsidy value of the Embedded object data block (that is, the block corresponding to d0cf11e0a1b11ae10) over the Clsid obtained through ProgID, that is, the clsid in the Embedded object data block:

The special logic of the formula editor (Equation) for dealing with formula data

Finally, Office passes the formula object data to Equation for processing:

The EquEdt32.exe process can handle two kinds of streams, namely Equation Native and 01Ole10Native streams. Equation Native is a more common stream format, which usually starts with 0x1C. The 01Ole10Native stream is used only if EquEdt32.exe fails to open the Equation Native stream:

Then the stream content is read according to the open stream. If it is a 01Ole10Native stream, the 4-byte stream size is read first, if not, the 0x1C byte size of the EquationNative header is read, and then the stream 01Ole10Native size is parsed from the EquationNative header. Finally, memory is allocated to read the 01Ole10Native stream data:

As you can see, during the processing of the kill-free sample captured this time, due to the failure of reading Equation Native, Equation directly processes the additional formula data by reading the 01Ole10Native stream size (03010103 … ):

Then, call the IStream::Read (coml2 exposed CExposedStreamParade read) function again to read the stream data:

Finally, the stream data is passed into the sub_42F8FF function to achieve specific 01Ole10Native stream processing, and the vulnerability is triggered successfully:

Summarize the principle of immunity from killing

Reviewing the process of Office processing the\ objdata object in RTF, we can summarize the process by which the kill-free sample triggers the Equation vulnerability:

1. Attackers attach data in non-CFB format (01Ole10Native stream with only formula data) to\ objdata, forcing Office to find the corresponding clsid through the stream name (Equation.3) in\ objdataheader and transfer to the processing flow.

2. Because the 01Ole10Native stream of the formula object (030101) is attached. Part of the data), so the EquEdt32.exe process failed to open the EquationNative stream and instead directly processed the 01Ole10Native stream with the data length specified in\ objdata header, triggering a vulnerability exploit.

Because the kill-free sample\ objdata is accompanied by data in non-CFB format (D0 CF 11... Normally, the CFB data must be carried, and the clsid obtained from the CFB data should be used to find the program (such as Equation) that handles the object, which directly leads to bypassing most of the detection logic that kills software. And the subsequent formula data does not have the characteristics such as the head of the formula object, which also makes part of the sample kill soft and catch blind, which is the main reason why the sample bypasses the anti-soft detection.

After reading the above, do you have any further understanding of the latest technical analysis of special processing logic using the Office formula editor? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.