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:
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