I really don't agree with the severity rating. Instant admin-access by just plugging in a USB stick is exactly what malware like the ever-loved Stuxnet use(d) as a jump-start to get their other exploits and backdoors going.
It's like the various autorun exploits, but better because you don't need an additional privilege escalation vulnerability and you get to execute your attack even if autorun is turned off completely.
Yeah, the severity rating seems rather oblivious to simple social engineering. Leave a USB stick on a desk with a sticky note attached to it saying "Urgent, please review", and guess what is going to happen to that USB stick.
Being able to compromise a system via a mundane and apparently benign action is never low-severity.
I've always assumed the attack vector was to leave the sticks lying around. If I'm not mistaken, some people have left them at banks in hopes that the employees will plug them into one of the computers there to see what's on it. Almost everyone I know has plugged a USB stick they don't own into their computer at one point or another.
Many PCs are patched now so there's no default autorun.inf (or similar) functionality. So you'd have to run a binary on it to trigger this exploit it seems. Doable of course, but one step harder.
But it's not an autorun vulnerability, that wouldn't be newsworthy -- the problem is that simply mounting the filesystem exploits bugs in the filesystem driver.
No - more needs to be done than simply mounting the filesystem.
He explains that: "With the ability to replace arbitrary kernel memory with arbitrary data, one has lots of options to choose from in order to hijack ring-0 code execution flow." and then goes on to mention "I decided to go with HalDispatchTable, being the easiest and most commonly used technique."
Something has to be run locally that exploits the ntfs filesystem driver bug (introduced by the usb stick) and uses that to write arbitrary data to kernel memory, but then has to divert ring-0 code execution flow (he chooses to overwriting the nt!HalDispatchTable+sizeof(void*) function pointer).
Severity isn't that low. If you hand out a USB stick to a friend and they run a .exe on it, you could surely trigger this exploit invisibly. It's probably not a broad vector attack, but surely would fit very well into a spearphishing scenario. Hand this to a less-than-savvy user and either auto-run via .inf (on older OSes) or dupe them into running some arbitrary binary to "unencrypt the volume" or something they wouldn't understand.
Many newer USB sticks even have preloaded binaries for the supporting software (SanDisk volume utilities come to mind) - this would be a perfectly innocuous location to load this sort of attack.
Buddy, did you even read the article before commenting??
"andrewaylett:
But it's not an autorun vulnerability, that wouldn't be newsworthy -- the problem is that simply mounting the filesystem exploits bugs in the filesystem driver."
In the video he has to run "ntfs_exploit.exe" in order to exploit the vulnerability. That's why a local account, as well as the ability to insert the USB dongle, is needed in order to leverage the exploit. So simply mounting the filesystem is not sufficient to trigger the exploit
You appear to not understand the concepts you are attempting to participate in a discussion about.
To "trigger" the vulnerability is to deliver your exploit code. This USB stick can be inserted into any Windows 7 system and, voila you have your rootkit on that machine, without any user interaction required. No running of .exe files anywhere. You could put some pictures on the usb drive for the user to look at while his system is compromised. (Rootkitted is that a word? Backdoored is.)
In his demo video, he needs to run a specially crafted program to actually achieve privilege escalation. That's why you need both physical access and a local user account.
Social engineering only gets you both if you can autorun the executable upon insertion of the usb stick.
Most systems that are physically available with local users (e.g. libraries, college computer labs, etc.) will have booting from anything other than the hard drive disabled, and the BIOS password protected. You'd need to open up the machine and reset the CMOS to use this approach.
While I was at university, every lecture hall data projector had a PC connected to it. Often people would bring their presentations from home on USB memory sticks.
Nowerdays there are viruses that spread by USB memory stick - and lie dormant on the computer infecting every USB memory stick that gets plugged in. Needless to say, lecture hall computers quickly became infected - even without any malicious intent on the part of the physically present user.
Hiren's BootCD is exactly the kind of tool I've been looking for - but I can't find the download link on that page. Am I an idiot, or does he not host his own boot cd on his site?
My coworker says he found it on Argentinean site Taringa! ( http://www.taringa.net ), which has had it's brushes with copyright infringement in the past as well.
Coming from a *nix background, it seems odd to me that a kernel null dereference would be exploitable from userland. Or that kernel functions be directly addressable from userland.
Is kernel memory mapped into user processes on Windows?
I've had an usb stick of death for years now. Any system you plug it in instantly freezes. No idea how I made it, but it was certainly not the goal! And whatever I do, I can't get it to overwrite whatever data is on there :P
Oh hey, I had one of those too. I eventually smashed it and threw it out because I tired of plugging it in and having slow down problems.
(I noticed it first when I was working with the jump drive and had the system grind to a halt. Removed the drive and it immediately unfroze. further testing confirmed)
It's like the various autorun exploits, but better because you don't need an additional privilege escalation vulnerability and you get to execute your attack even if autorun is turned off completely.