There's a party in OLE, and you are invited


At Black Hat USA 2015, Haifei Li & Bing Sun presented their talk Attacking Interoperability: An OLE Edition in which they talk about the attack surface of OLE, especially when used in Office documents. It reminded me of the sheer number of ActiveX related vulnerabilities reported in Internet Explorer in the past (eg, research performed by the likes of Will Dormann of CERT/CC).

Since then Microsoft has added a lot of mitigations to Internet Explorer, including Per-Site/Per-User ActiveX & Enhanced Protected Mode. These mitigations are not implemented in Office - as was pointed out by Li & Sun. Their paper enticed my curiosity so I decided to perform some OLE tests myself. In this blog, I'll focus on the low hanging fruit of OLE vulnerabilities: DLL side loading (aka binary planting or DLL hijacking).

Low hanging fruit

DLL side loading occurs when Office searches for a DLL in the same directory containing the Office document. The attacker places a specially crafted DLL and Office document in the same directory (share) and then waits for, or entices a victim to open the document. Opening this document will result in malicious code to be executed with the privileges of the victim.

OLE objects are loaded by their CLSID (or ProgID). DLL side loading can occur even though the loaded object is not an OLE object. In order for Office to determine if an object is in fact an OLE object, it must first load the (COM) object in memory. The object is then queried to see if it is an OLE object. When the object is loaded, initialization code will be executed.

Tools of the trade

A simple tool was created to find DLL side loading and other OLE issues. The following approach was taken:

  • Enumerate all CLSIDs under HKEY_CLASSES_ROOT\CLSID with an InprocServer32 key.
  • Iterate through found CSLIDs & create a PowerPoint file for each CLSID.
  • Open PowerPoint files.
  • While opening the PowerPoint, run Process Monitor, look for DLLs loaded from the current working directory.
  • Manually test if the found DLL can be used to execute arbitrary code.

A week of side loading

Running these tests on several systems ranging from Windows Vista to Windows 10, and Office 2007 to Office 2016 has so far resulted in 15 different DLL side loadings issues, exploitable via 24 unique CLSIDs. Microsoft released MS15-132 that addresses 5 of the issues reported to them. Starting this Wednesday, we'll publish a new (patched) issue every working day. On Christmas day we'll also release a Metasploit module. The information will be disclosed on our website and Twitter.

Proof of concept


Vragen of feedback?