{"id":31748,"date":"2019-11-11T15:12:11","date_gmt":"2019-11-11T15:12:11","guid":{"rendered":"https:\/\/packetstormsecurity.com\/news\/view\/30669\/BlueKeep-Exploit-To-Get-Fix-For-Its-BSOD-Problem.html"},"modified":"2019-11-11T15:12:11","modified_gmt":"2019-11-11T15:12:11","slug":"bluekeep-exploit-to-get-fix-for-its-bsod-problem","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/bluekeep-exploit-to-get-fix-for-its-bsod-problem\/","title":{"rendered":"BlueKeep Exploit To Get Fix For Its BSOD Problem"},"content":{"rendered":"

\"exploit-globe-code-cyber.jpg\"<\/span><\/p>\n

Currently, the only public proof-of-concept exploit code for the infamous BlueKeep vulnerability is a module for the Metasploit penetration testing framework.<\/p>\n

The BlueKeep Metasploit module was put together from a proof-of-concept code donated by RiskSense security researcher Sean Dillon (@zerosum0x0<\/a>) over the summer.<\/p>\n

While the exploit works, it has a downside, namely that on some systems it can crash the target with a Blue Screen of Death (BSOD) error, instead of granting the attackers a remote shell.<\/p>\n

This BSOD error is how security researcher Kevin Beaumont discovered the first BlueKeep-based attacks in the real-world last week after he noticed that 10 of his 11 RDP honeypots were down with a BSOD error.<\/p>\n

However, this week, the BlueKeep Metasploit module will get a fix for this bug. The fix removes the BSOD error and makes BlueKeep attacks more reliable.<\/p>\n

BlueKeep was crashing because of the Meltdown patch<\/h3>\n

In an interview with ZDNet<\/em> over the weekend, Dillon said the root cause of the BSOD errors was Microsoft’s patch for the Meltdown Intel CPU vulnerability.<\/p>\n

“From looking at screenshots of the analysis Marcus ‘MalwareTech’ Hutchins did<\/a>, we know code execution was achieved and that the honeypots were crashing because the exploit did not support kernels with Meltdown,” Dillon told ZDNet<\/em>.<\/p>\n

\n<\/section>\n

“The future BlueKeep Metasploit exploit will support kernels patched for Meltdown and does not even need a KVA Shadow mitigation bypass,” he said.<\/p>\n

[KVA Shadow is the technical name that Microsoft gave to the Meltdown patch. See here for details<\/a>.]<\/em><\/p>\n

The new BlueKeep exploit changes the exploit routine early in a BlueKeep attack, so a Meltdown patch bypass isn’t even needed. Diving deeper into the technical details, Dillon told ZDNet<\/em>:<\/p>\n

“For the [BlueKeep] exploit payload to transition from kernel mode to a traditional user-mode payload (such as reverse TCP shell callback), we were changing the system call register in a way that was not allowed by the Meltdown KVA Shadow mitigation. After writing a bypass for the KVA Shadow mitigation, it was pointed out that the exploit payload could be written without needing to hook the system call at all. The need for a Meltdown bypass is actually unnecessary and part of wrong assumptions early on in the exploit development That is the fix that will be going in.”<\/p>\n

Dillon expects the Metasploit project to update the BlueKeep module later this week<\/a>. A technical deep-dive into the root cause of the BlueKeep BSOD is also available on Dillon’s personal blog, here<\/a>.<\/p>\n

Some perspective from MalwareTech<\/h3>\n

What this means for all of us is pretty obvious. BlueKeep’s public exploit is getting more reliable, meaning attackers have a higher chance of breaking into a company that runs at least one vulnerable system.<\/p>\n

As Hutchins pointed out in a Twitter thread<\/a> last week, the cyber-security community has focused too much on Microsoft’s initial warning that BlueKeep could be used to create “wormable malware.”<\/p>\n

The result was that everybody missed the point that even if attackers don’t create a BlueKeep-based worm, BlueKeep is still a major threat and should not be ignored.<\/p>\n

“I’m not really worried about a worm, what I’m worried about is something that could be already happening,” Hutchins said.<\/p>\n

“Most BlueKeep vulnerable devices are servers. Generally speaking, Windows servers have the ability to control devices on the network. Either they’re domain admin, have network management tools installed, or share the same local admin credentials with the rest of the network. By compromising a network server, it is almost always extremely easy to use automated tooling to pivot internally (Ex: have the server drop ransomware to every system on the network),” he added.<\/p>\n

“The real risk with BlueKeep is not a worm. A worm is pointless and noisy. Once an attacker is on the network, they can do far more damage with standard automated tools than they could ever do with BlueKeep,” Hutchins said.<\/p>\n

“Remember all those news stories about entire networks being ransomwared? That starts with a single system being hacked. Not even a server, a normal, non admin, client system. Attackers don’t need worms.<\/p>\n

“People need to stop worrying about worms and start worrying about basic network security. Firewall your servers off from the internet, learn about credential hygiene. Occasionally worms happen, but every day there are entire networks compromised using only standard tools.”<\/p>\n

\n
\n

When the news broke about BlueKeep exploitation in the wild, most of the reactions were basically “it’s not a worm, so it doesn’t matter”. I decided I’d do a thread on why that’s wrong, and why a worm isn’t even a worst case scenario.<\/p>\n

THREAD:<\/p>\n

\u2014 MalwareTech (@MalwareTechBlog) November 8, 2019<\/a><\/p><\/blockquote>\n<\/div>\n

The BlueKeep lowdown<\/h3>\n

Because there’s been a flood of BlueKeep-related coverage this year, below is a summary of what you need to know. Just the essentials:<\/p>\n