INSIGHTS, NEWS & DISCOVERIES
FROM IOACTIVE RESEARCHERS

Tuesday, January 17, 2012

A free Windows Vulnerability for the NSA

Some months ago at Black Hat USA 2011 I presented this interesting issue in the workshop “Easy and Quick Vulnerability Hunting in Windows,” and now I’m sharing it with all people a more detailed explanation in this blog post.

In Windows 7 or Windows 2008, in the folder C:\Windows\Installer\ there are many installer files (from already installed applications) with what appear to be random names. When run, some of these installer files (like Microsoft Office Publisher MUI (English) 2007) will automatically elevate privileges and try to install when any Windows user executes them. Since the applications are already installed, there's no problem, at least in theory.
However, an interesting issue arises during the installation process when running this kind of installer: a temporary file is created in C:\Users\username\AppData\Local\Temp\, which is the temporary folder for the current user. The created file is named Hx????.tmp (where ???? seem to be random hex numbers), and it seems to be a COM DLL from Microsoft Help Data Services Module, in which its original name is HXDS.dll. This DLL is later loaded by msiexec.exe process running under the System account that is launched by the Windows installer service during the installation process.
When the DLL file is loaded, the code in the DLL file runs as the System user with full privileges. At first sight this seems to be an elevation of privileges vulnerability since the folder where the DLL file is created is controlled by the current user, and the DLL is then loaded and run under the System account, meaning any user could run code as the System user by replacing the DLL file with a specially-crafted one before the DLL is loaded and executed.
Analysis reveals that the issue is not easily exploitable since the msiexec.exe process generates an MD5 hash of the DLL file and compares it with a known-good MD5 hash value that is read from a file located in C:\Windows\Installer\, which is only readable and writable by System and Administrators accounts.
In order to exploit this issue, an attacker needs to replace the DLL file with a modified DLL file that contains exploit code that can match the valid MD5 hash. The attacker DLL will then be run under the System account, allowing privilege elevation and operating system compromise. The problem is that this is not a simple attack—it’s an attack to the MD5 hashing algorithm referred to as a second-preimage attack for which there are no practical attacks that I know of, so it’s impossible for a regular attacker to generate a file with the same MD5 hash as the existing DLL file.
The reason for the title of this post comes from the fact that intelligence agencies, which are known for their cracking technologies and power, probably could perform this attack and build a local elevation of privileges 0day exploit for Windows.
I don’t know why Microsoft continues using MD5; it has been banned by Microsoft SDL since 2005 and it seems there has been some component oversight or these components have been built without following SDL guidance. Who knows on what other functionality MD5 continues to be used by Microsoft, allowing abuse by intelligence agencies.
Note: When installing some Windows updates, the Windows Installer service also creates the same DLL file in the C:\windows\temp folder, possibly allowing the same attack.
The following YouTube links provide more technical details and video demonstrations about this vulnerability.
References.

8 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. It's not impossible to generate two files with the same MD5. Check this website for more information -> http://www.mscs.dal.ca/~selinger/md5collision/

    ReplyDelete
    Replies
    1. Ahmed, collision attack is not the same as 2nd pre-image attack, see http://tools.ietf.org/html/rfc4270k

      Delete
    2. My response was to this part " it’s impossible for a regular attacker to generate a file with the same MD5 hash as the existing DLL file. "

      Delete
    3. Ahmed, ...same MD5 hash as the existing DLL file... it means that you have to generate the same hash as an existing file, that's is not collision attack is 2nd pre-image attack.
      http://tools.ietf.org/html/rfc4270

      Delete
  3. Isn't the DLL signed by Microsoft using Authenticode or some digital signature?

    ReplyDelete
  4. I don't remember if the DLL is signed by Microsoft, anyways there are no signature checks only one check present for the MD5 hash

    ReplyDelete