March 21, 2005

Using Image File Execution options as an Attack Vector on Windows

Today I was discussing a previous entry I wrote on why using CreateProcess is better than ShellExecute when I was informed by tenfour that I am missing a critical piece of the puzzle. That even with CreateProcess, you can EASILY redirect an executable and use misdirection threats just as you could with shell file extensions. In other words, you can't actually trust where an executable is starting up from, and if its the right executable in the first place.

I will leave the actual usage of this attack vector up to the reader, as I really don't wish to provide working code for the script kiddies out there. On top of that, for this vector to be exploited you must have Administrator privileges already. Yet another reason why you should run as a normal user on your system.

Anyways, the trick for redirecting a process loading is to attach it to the Image File Execution options within the Windows registry. By simply mapping the executable name to a different debugger source, you can actually load something else entirely.

Let me give you a proof of concept:

  1. Start the Registry Editor: Click Start, click Run, and then type regedt32.
  2. Locate the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
  3. To this hive, add the SOURCE exe as a key. Lets use notepad.exe: (Right click and select New, and then Key (Add the key and name it notepad.exe)
  4. To the notepad.exe key, add a new REG_SZ (string) value called Debugger, and point it to c:\windows\system32\cmd.exe
  5. Start up notepad (Click Start, click Run, and then type notepad)
  6. Notice that a new cmd window opened instead

Now to be fair, this isn't going to elevate your privileges or expose you to any more risk relating to malicious code that couldn't already be executed on your account. But with that said, this has the potential of SERIOUS effects for social engineering hacks and hostile code start points. As an example, spyware doesn't have to worry about trying to hide and start execution in the Run/RunOnce keys when they could simply tag to a common exe that starts up, and on startup spawn the real executable after doing its bidding. I will leave that to the reader to think about.

This is one of the reasons I control application startup behavior in the kernel using a digital fingerprint (an MD5 checksum actually). You don't have to worry about the reparse point of the startup location, and you can simply STOP the execution of applications that have no right to start up. Once attackers start thinking about ways to exploit this, it could get pretty interesting.

So what have we learned here? Well first off, its difficult to trust security by path. Secondly, you should be running as a normal user so this sort of attack vector cannot be started. (The DACL on this registry hive would prevent a normal user from touching it). Thirdly, the complexity in behind Windows exposes us to risk when we least expect it. I never even knew about this execution path. Even though my threat models show why its better to use CreateProcessAsUser over ShellExecute, it never even CONSIDERED this.

I learn something new every day. Hope you do too.

Posted by SilverStr at March 21, 2005 03:43 PM | TrackBack

wow... That was interesting, and i am glad that i learnt that today. I do use GPO's with hash based certification of applications. I also use Safer, yet another great thing that MS really needs to push.
However path based lockdown would be nice to have if for instance we want executables from any drive other than hard drive not be executable. I do not know of a clear way of doing that other than allowing all apps in C (or very specific apps) and set default to dissallow.

Even when we have only selected applications to run, just one application can create all holes needed to execute other apps. Firefox allows any user on the system to download extensions that could contain malware.

Posted by: Badriram at March 21, 2005 08:30 PM