To get Administrator access on Windows (theoretically) you could plug in a USB hub with a virtual keyboard, USB mass storage and a random unknown device. The USB mass storage would have the payload you wanted to run in the form of a driver for the unknown device and the virtual keyboard would replay the keys needed to accept the warning messages about installing unsigned drivers.
In XP, all bets are off, as the vast majority of users run with local admin rights.
For Vista and 7, I believe that the much-hated-by-numpties User Account Control should prevent this from happening, as it opens a virtual screen or something to give access to the 'OK/Cancel' dialog.
From UAC on Wikipedia: 'User Account Control asks for credentials in a Secure Desktop mode, where the entire screen is temporarily dimmed, Windows Aero disabled, and only the authorization window at full brightness, to present only the elevation user interface (UI). This is to prevent spoofing of the UI or the mouse by the application requesting elevation.'
For Vista and 7, I believe that the much-hated-by-numpties User Account Control should prevent this from happening
I think the idea was that the USB device would include a keyboard and that this would press the keys required to confirm UAC.
This wouldn't work if the machine was locked, and if the user could see the screen then they'd at least notice it.
In a past thread about hardware exploits, someone suggested simply having a device that poses as a keyboard and then types out the source of a rootkit and compiles it. Or even just type the binary straight onto the disk somehow.
That my friends, is genius. Credit goes to whoever suggested it originally.
I don't see how you could do this for PE files, which would be required to pull this off on x64 (since you can't run 16-bit binaries like .COMs). There are several fields in the headers that require non-ASCII values.
The UAC runs in a context called the protected desktop. When the UAC is active things like this won't work. Your program won't be able to press "Okay" or anything.
Secondly, non-admin users can't install most drivers and autorun will ask them if they really want to run the app. Admin users can install but will also have to deal with the autorun dialog.
So you are saying that protected desktop accepts key presses only from some but not all keyboards connected to system? That does not seem quite right.
And as for UAC and protected desktop: take debugger and look at how most UAC prompts are invoked. Many of them are caused by user-space code running in address space of "offending" process, so you can patch them out.
