DLL planting, also known as DLL side loading, is a popular attack technique today. If we take a look at the list of advisories Microsoft has recently published, it is clear that a large number of vulnerabilities encompass DLL planting. We have seen many targeted attacks that abuse Windows OLE in many ways. At BlackHat USA 2015, an Intel Security team presented the paper “Attacking Interoperability: an OLE Edition,” which covered various attack techniques and attack surfaces of OLE. In this paper, my colleagues Bing Sun and Haifei Li showcased many interesting vulnerabilities in OLE.
Recently we informed Microsoft of a vulnerability that can be exploited by attackers to perform a DLL side-loading attack. In this case, the vulnerable COM class object ID (CLSID) is {f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}. This CLSID can be found in the registry at HKEY_CLASSES_ROOTCLSID{f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}. This CLSID’s InprocServer32 key points to the file invagent.dll. A quick Google search reveals this DLL is a part of Windows and is covered by the update KB2976978.
During our research we found that it is possible to load and initialize this COM object with specially crafted Office document. As proof of concept, we created a Word document with an embedded external OLE object. Opening our Word doc in Office, we see this:
Later we simply patched and changed the CLSID to {f4ba59cc-2506-45ae-84c8-78ea8d7f9b3e}.
Now if we double-click the embedded icon, Office tries to load the OLE object and associated DLLs into the process. One of the DLLs Office tries to load is api-ms-win-core-winrt-l1-1-0.dll. We noticed that if we placed a DLL named api-ms-win-core-winrt-l1-1-0.dll in the same location as the crafted doc, Office simply loads the DLL from the current working directory, allowing us to execute arbitrary code through a planted fake DLL. In Process Monitor, below, we can see that the DLL is loaded from the current working directory.
To prove our point, we compiled a fake api-ms-win-core-winrt-l1-1-0.dll in which DLLMain() executes calc.exe and was placed that DLL in the same folder with the crafted Word doc. As we see in the following screen, as soon as we click on the embedded doc icon, calc.exe pops up.
This same attack can also be performed with a specially crafted rich text format (RTF) document. What’s interesting about an RTF attack is that no user interaction (such as a mouse click) is required to achieve code execution.
The next screen shows the stack trace of the vulnerable LoadLibraryEx() call. As we can see the OLE initialization process started from a call to ole32!OleLoad() -> ole32!CoCreateInstance() and goes on from there.
The next screen shows the disassembly of the vulnerable function invagent!AeInvProvider::AeInvProvider(), in which the insecure library load happens.
Microsoft pushed out a fix for this bug in January, as part of MS16-007 (https://support.microsoft.com/en-us/kb/2952664). As a fix, the dwFlags parameter of the LoadLibraryEx() function was set to 0x800. With this value, only the %windows%system32 path is searched for the DLLs. The following screen shows the patched function after installing this fix.
Disclosure time line:
January 8: Intel Security reports the issue to Microsoft.
January 9: Automated response from Microsoft.
February 27: Microsoft confirms the issue and informs us a fix was part of Security Bulletin MS16-007 (January’s Patch Tuesday update).
April 21: Microsoft publicly acknowledges our report.
The post CVE-2016-0018: DLL Planting Leads to a Remote Code Execution Vulnerability appeared first on McAfee.