Live data from Hacker News

Introducing the USB Stick of Death

j00ru.vexillium.org

21–30 of 35 posts

Re: Introducing the USB Stick of Death

#21
post #16

Earlier quoted context omitted.

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."

Understood, but to fully _exploit_ the vulnerability one would need to actually execute more code than just triggering the vulnerability presumably.

[deleted]

Re: Introducing the USB Stick of Death

#22
post #5

Earlier quoted context omitted.

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 wou…

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."

@Rastafarian

Did you watch the video before retorting?

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

Re: Introducing the USB Stick of Death

#23
post #6
post #2

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

Post a stacktrace? You can take a photo for us of the kernel panic.

It doesn't crash (no kernel panic), just makes the system so slow that you can't use it anymore until you pull the stick out.

Re: Introducing the USB Stick of Death

#24
post #8

Earlier quoted context omitted.

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).

Check out the video to verify

Re: Introducing the USB Stick of Death

#25
post #2

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

Boot Linux, disable automount, make a raw copy using dd, upload somewhere?

Re: Introducing the USB Stick of Death

#26
post #23
post #6

Earlier quoted context omitted.

Post a stacktrace? You can take a photo for us of the kernel panic.

It doesn't crash (no kernel panic), just makes the system so slow that you can't use it anymore until you pull the stick out.

if you dd on another usb-drive the same data -- will it stay the same? if yes -- you could post it somewhere and try to get more details etc.

Re: Introducing the USB Stick of Death

#27
post #4

As a security vulnerability, it's interesting but, as they stated, low-severity. If you have physical access and a local user, it's much easier to use any Linux boot CD and one of the myriad "password recovery" systems. I used Petter N Hagen's http://pogostick.net/~pnh/ntpasswd/ back in my tech support days (several years ago). The current tech support guy swears by Hiren's BootCD http://www.hiren.info/pages/bootcd

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?

He probably doesn't because it contains non-free software.

http://en.wikipedia.org/wiki/Hiren%27s_BootCD

Wikipedia links to this download location:

http://www.hirensbootcd.org/download/

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.

Re: Introducing the USB Stick of Death

#29
post #14

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 complete…

You have to be running an exploit program while you play with the USB stick.

Re: Introducing the USB Stick of Death

#30
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?

Post reply on HN