MS14-060 Microsoft Windows OLE Package Manager Code Execution

Description

This module exploits a vulnerability found in Windows Object Linking and Embedding (OLE) allowing arbitrary code execution, publicly known as "Sandworm". Platforms such as Windows Vista SP2 all the way to Windows 8, Windows Server 2008 and 2012 are known to be vulnerable. However, based on our testing, the most reliable setup is on Windows platforms running Office 2013 and Office 2010 SP2. And please keep in mind that some other setups such as using Office 2010 SP1 might be less stable, and sometimes may end up with a crash due to a failure in the CPackage::CreateTempFileName function.

This module will generate three files: an INF, a GIF, and a PPSX file. You are required to set up a SMB or Samba 3 server and host the INF and GIF there. Systems such as Ubuntu or an older version of Windows (such as XP) work best for this because they require little configuration to get going. The PPSX file is what you should send to your target.

In detail, the vulnerability has to do with how the Object Packager 2 component (packager.dll) handles an INF file that contains malicious registry changes, which may be leveraged for code execution. First of all, Packager does not load the INF file directly. As an attacker, you can trick it to load your INF anyway by embedding the file path as a remote share in an OLE object. The packager will then treat it as a type of media file, and load it with the packager!CPackage::OLE2MPlayerReadFromStream function, which will download it with a CopyFileW call, save it in a temp folder, and pass that information for later. The exploit will do this loading process twice: first for a fake gif file that's actually the payload, and the second for the INF file.

The packager will also look at each OLE object's XML Presentation Command, specifically the type and cmd property. In the exploit, "verb" media command type is used, and this triggers the packager!CPackage::DoVerb function. Also, "-3" is used as the fake gif file's cmd property, and "3" is used for the INF. When the cmd is "-3", DoVerb will bail. But when "3" is used (again, for the INF file), it will cause the packager to try to find appropriate handler for it, which will end up with C:\Windows\System32\infDefaultInstall.exe, and that will install/run the malicious INF file, and finally give us arbitrary code execution.