Remote Microsoft Office DLL (MS15-132) Hijacking through a browser

Remote Microsoft Office DLL (MS15-132) Hijacking through a browser

A few weeks ago, the security researcher Parvez Anwar posted a large number of Microsoft Office DLL hijacking vulnerabilities on his personal Twitter [1]. A few weeks later, Microsoft announced the MS15-132 patch, fixed the vulnerability, and handled a large number of similar bugs published by Google's Security Research [2] in different forms [3.
Ghost file trigger vulnerability.
If you want to learn more about this vulnerability, refer to the awesome topic "Attacking Interoperability: an OLE Edition "[4]. In addition, Dominic Wang of NCC Group has a blog related to "Understanding Microsoft Word OLE Exploit Primitives: Exploiting CVE-2015-1642 Microsoft Office CTaskSymbol Use-After-Free Vulnerability" [5], this section describes how Microsoft Office processes embedded ActiveX controls.
The following describes how these vulnerabilities are generated.
When you load a document embedded with an OLE object, where the OLE object is specified by CLSID or ProgID, Windows will search for these specified IDs in its registry, then try to load the First-off DLL and call the relevant code to create the instance requested by this object.
Once the DLL is loaded into the address space of the Office, the Office will determine whether the loaded object is compatible with the document (or, in fact, it is not an OLE object ).
If the DLL required by the specified address does not exist, Windows will "Search for DLL" [6] at the pre-specified address. This includes the current directory.
In this 0-day vulnerability, these specific CLSID (embedded in the Office documentation) will cause these DLL "elsext. dll, api-ms-win-core-winrt-l1-1-0.dll, OCIW32.DLL or oci. dll is loaded from the current directory. If attackers place one of the above DLL files in the same directory, the embedded object file will also load the DLL from the same directory, the Code Constructed by attackers will be executed by the Office.
Now let's discuss this vulnerability in the context of existing knowledge. Traditional DLL hijacking requires users to start malicious files from network sharing such as SMB or WebDAV. This is because when the file is started from remote sharing, the files in the current directory will become shared when the file is started. Attackers can obviously control this, so they can easily implant malicious DLL in the same directory as the document. This article describes how attackers can remotely exploit these vulnerabilities in Office and Firefox without using SMB or WebDAV.
Release temporary Office files
To remotely exploit this vulnerability, we have adopted some existing solutions. The first method is to use Microsoft Office to release temporary files. These problems have been potentially exploited, and Haifei Li has also discovered this problem. This technique is very useful. Attackers can easily embed their payload into the RTF file by using ActiveX controls. When the RTF file is opened, the attacker's payload will be released to the user's % TEMP % folder and keep its original name (unless a file of the same name exists in the % TEMP % folder, in this case, the suffix of the file will append a number, such as (2 ).).
In our vulnerability exploitation, we will also use Microsoft's issue to embed our payload and oci. dll. This is easy to implement. You only need to implant malicious DLL files and save them. in the format of rtf, and then re-open this document. The oci is displayed in the % TEMP % directory of the current user. the dll file has been written.
Firefox Temporary Folder
The second useful technique is that when we select "open with" in the Firefox download dialog box, Mozilla Firefox uses the % TEMP % directory of the current user as its default download directory.
When you use Firefox to download an object, you can choose either of the following: "save as" or "open ".

When "open with" is selected, Firefox downloads the file to the user's % TEMP % directory before opening the file with the specified program. At this time, the current working directory of the Startup Program is changed to the user's % TEMP % directory. Check the location of these files.

We can use this feature of the browser to construct an embedded "package" ActiveX control and an RTF file containing vulnerable objects, where the "package" control is in front and the vulnerability object is in the back. When you use the Firefox browser (Select the "open with" (Microsoft Word) option) to download the RTF file from the attacker's web server, two things will happen:
First, oci. dll will be released to the user's % TEMP % folder.
Second, this vulnerability causes Word to try to load the oci. dll file from the current directory.
Because the current directory is % TEMP %, the attacker's payload will be executed through Word.

Demo
The demo Video below shows how to use Firefox to remotely execute code.
Microsoft Edge and Google Chrome
Microsoft Edge and Google Chrome both use the user's "Downloads" directory to store the downloaded files, and do not prompt before the download. This feature may also be exploited by attackers to use the "auto-download" attack method. In addition to the constructed documents, attackers can also force users' browsers to download the DLL provided by attackers. When this document is opened, the DLL will be loaded from the "Downloads" Directory (DLL is downloaded to this directory using the "auto-download" method ).
The following example shows how to forcibly download the DLL file by using the method.
Var iframe = document. createElement ('iframe ');
Iframe. src = 'oss. dll ';
Iframe. id = "dllframe ";
Iframe. width = 0; iframe. height = 0;

Iframe. style. visibility = "hidden ";
Document. body. appendChild (iframe );
Function dropDoc (){
Window. location = "exploit.docx ";
}
Aaa = setTimeout (FIG, 3000 );
Haifei Li has recently recorded this technology [8].
Note: whether Google Chrome or Microsoft Edge, if the downloaded file (such as the attacker's DLL file) is at risk, the browser will issue a warning. In the Edge browser, a warning message is only displayed before the next file is downloaded, but this file is not blocked. The browser will send a brief warning when the exported POC file is released directly to the .docx file. The prompt information will be overwritten by the "open" dialog box.

Figure 1 Chrome warning

Figure 2 Edge warning

Figure 3 Edge "open" dialog box
Measures
Microsoft has released a MS15-132 vulnerability patch to handle the DLL hijacking vulnerability described in this article. However, this patch cannot solve all the problems that have been disclosed. More importantly, the attack features exposed by OLE, especially for such vulnerabilities, we can expect more vulnerabilities to be discovered or even exploited.
In fact, we contacted Mozilla and hoped to change the existing practice to fix the % TEMP % file sharing. In their reply, they said that this was a Microsoft/Office bug and not a Firefox issue.
Google Chrome prompts you before downloading files through configuration and selects "Settings> Show Advanced> Ask where to save each file before downloading ".