Blue Screen of Death (BSOD) errors have been around for a long time and is commonly seen if something went horribly wrong with the computer. It is not as easy to do it on demand for proof of concept. However, it is now a reality due to the proof of concept is now a real thing. This time they were able to easily generate the blue screen of death (BSOD) on Windows devices. They even have a video demonstrating that the denial-of-service effect can take place even if the device is locked.
In their video, they have used a handcrafted image of a Windows NT file system (NTFS) loaded onto a USB stick. What they did is crash the system by simply inserting the drive into the USB port.
This is possible due to the fact the “Auto-play is activated by default”. Wherein this automatically crashes the system when USB stick is inserted. This has been reported by 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.”
People are not aware that that when you insert a memory stick even when the computer is in a locked state, it still runs a lot of computer code in the background. To begin with, it mounts the USB’s file system and if this file system is designed and aimed to exploit the OS vulnerabilities to run arbitrary code to their advantage. This process should be changed for all operating systems.
Tivadar’s test systems that were affected are the following: 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.
He reached out to Microsoft for a patch to be made and released to the public, however he has not heard any positive feedback that it will be done anytime soon.
“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.”
