USB Sticks Can Trigger BSOD – Even on a Locked Device

Thanks to auto-play, it’s possible to crash Windows systems by simply inserting the drive into the USB port, no further user interaction necessary.

A proof of concept for easily generating the blue screen of death (BSOD) on Windows devices has been released, along with a video demonstrating that the denial-of-service effect can take place even if the device is locked.

Using a handcrafted image of a Windows NT file system (NTFS) loaded onto a USB stick, it’s possible to crash the system by simply inserting the drive into the USB port, no further user interaction necessary (as this pair of videos shows).

“Auto-play is activated by default, this leads to automatically crashing the system when [the] USB stick is inserted,” said Bitdefender researcher Marius Tivadar, in a post on GitHub from late last week exposing the problem and the PoC. “Even with auto-play disabled, system will crash when the file is accessed. This can be done…when Windows Defender scans the USB stick [even when locked], or any other tool opening it. If none the above, finally, if the user clicks on the file, system will crash.”

Further, he added that while his own PoC requires physical access to the device with a USB stick, it’s possible to code the attack into malware that could be delivered remotely via spam campaigns or even drive-by downloads.

“If this kind of crash was exploitable, and attacker could load malware even if the system is locked, [and] this could open thousands of possible scenarios,” he said in the supporting materials for the PoC. “Of course, it is not necessary to have an USB stick. A malware for example could drop a tiny NTFS image and mount it somehow, thus triggering the crash.”

Also, he told Threatpost that inserting a memory stick when a computer is in a locked state triggers the execution of plenty of OS code, such as mounting file systems. “This could be dangerous if the file system is handcrafted and aimed at exploiting the OS. This behavior should be changed for any operating system,” Tivadar said.

All three systems he tested were affected: Windows 7 Enterprise 6.1.7601 SP1, Build 7601 x64; Windows 10 Pro 10.0.15063, Build 15063 x64; and Windows 10 Enterprise Evaluation Insider Preview 10.0.16215, Build 16215 x64.

For Microsoft’s part, he said that its security team was initially responsive, but was uninterested in issuing a patch when he reached out to the software giant with the problem.

“Reported to Microsoft on July 2017, they did not want to assign CVE for it nor even to write me when they fixed it,” said Tivadar, who discovered the issue last summer. In his GitHub posting, he reprinted an email that he said was from the Microsoft team, which read, “Hey Marius, your report requires either physical access or social engineering, and as such, does not meet the bar for servicing down-level (issuing a security patch)…Your attempt to responsibly disclose a potential security issue is appreciated and we hope you continue to do so.”

Microsoft offered a short statement in response to our request for comment: “The technique described requires authenticated access to a machine. We encourage customers to always use security best practices, including securing work stations and avoiding leaving laptops and computers unattended.”

Tivadar said that he believes the problem is genuinely worthy of concern. “As a security researcher, I think that every vulnerability that requires physical access and/or social engineering is important,” he told Threatpost. “I’ve seen and studied malware like FLAME and Stuxnet, that may have been spread using physical access (FLAME and Stuxnet contained a zero-day exploit that forced the OS to run malware from a removable drive). [And] we all know the stories Kevin Mitnick taught us regarding social engineering, so yes, these types of bugs are important.”

In his post, he added: “I strongly believe that this behavior should be changed…Generally speaking, no driver should be loaded, no code should get executed when the system is locked and external peripherals are inserted into the machine. I may think [of] this as code [that] gets executed without user consent.”

Suggested articles

Discussion

  • Anonymous on

    Refusing to fix a vulnerability that allows someone to execute code on your PC, even when it is locked? That's Microsoft, again. The government should not allow this.
  • Anonymous on

    Use case: Laptop or PC screen locked while away to lunch or restroom.
  • Anonymous on

    Rehashing an old issue. Simple configuration of GP, see here: https://blogs.technet.microsoft.com/mspfe/2010/09/09/how-to-use-windows-7-to-lock-down-removable-media-and-keep-your-computer-safe/
  • KTurner on

    Use Group Policy to control/prevent this from happening.
    • Anonymous on

      It shouldn't be the user's job to configure Group Policy to not be vulnerable to code execution. It should be secure by default.
      • Anonymous on

        I agree. However, all of the complaining in the world while waiting on the software manufacturer to make changes, still leaves the end user vulnerable. So, in this case, the DIY approach gets immediate results. It sucks, but it is what it is.
  • Andrew Wolfe on

    MS Windows is full of vulnerabilities - whether by idiotic defaults like this, or by the terrible weaknesses even when strictly configured.
  • Anonoman2018 on

    its just that its harder to implement than you think, what about that USB keyboard you just plugged in? if the driver wont install you cant ever login since the keyboard wont install. Then what?

Leave A Comment

 

07/21/18 2:00
A new report said that @SanDiegoAirport has the riskiest #WiFi hotspots: https://t.co/cFIue5ERht

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.