MS14-060 Microsoft Windows OLE Package Manager Code Execution

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.

Unknownsinn3r juan vazquez

Windows

x86