Remember the Spectre side-channel info-disclosure bug? Hackers do. We’ve always feared they’d find a practical exploit, allowing them to, say, steal secrets from kernel memory—passwords, private keys, tokens, etc.
Earlier this week, we woke up to headlines screaming about a pair of “weaponized” exploits discovered on VirusTotal: one for Windows, and one for Linux.
But all might not be as it seems. In this week’s Security Blogwatch, we learn the lessons, regardless.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: breaking the TNG code.
Specter of Spectre: scary
What’s the craic? Sergiu Gatlan reports—Spectre exploits found on VirusTotal:
Spectre (CVE-2017-5753) side-channel attacks … can be used by attackers to steal sensitive data, including passwords, documents, and any other data available in privileged memory. [They] impact many modern processor models with support for speculative execution and branch prediction made by Intel, AMD, and ARM [and] affects major operating systems, including Windows, Linux, macOS, Android, and ChromeOS.
…
Security researcher Julien Voisin … found the two working Linux and Windows exploits on the online VirusTotal malware analysis platform. Unprivileged users can use the exploits to dump LM/NT hashes on Windows systems and the Linux /etc/shadow file from the targeted devices' kernel memory. The exploit also allows dumping Kerberos tickets that can be used … for local privilege escalation and lateral movement on Windows systems.
…
Those running older OS versions on older silicon (2015-era PCs with Haswell or older Intel processors) are probably the most exposed to Spectre attacks. … They are most prone to skip applying mitigations due to a more noticeable decrease in system performance after the patch.
And Catalin Cimpanu calls this the Last “patch now” warning:
[It marks] the first time a working exploit capable of doing actual damage has entered the public domain. … The Spectre bug is a hardware design flaw … which won a Pwnie Award in 2018 [and] was considered a milestone moment in the evolution and history of the modern CPU: … Along with the Meltdown bug, [it] effectively forced CPU vendors to rethink their approach to designing processors.
…
While initially there was a fear that malware authors might be experimenting with the two bugs as a way to steal data from targeted systems … no evidence was found of in-the-wild attacks. [But] Voisin said he discovered new Spectre exploits. … However, there is no evidence that the exploit was used in the wild.
…
Copies of this Spectre exploit are now making the rounds in Discord and Telegram channels run by security researchers, and it’s only a matter of time until they hit GitHub. … Voisin’s discovery is about as close the Spectre doomsday clock can tick close to midnight before attacks get underway, if they haven’t already.
Fake news? Julien Voisin tells the Artificial truth:
Someone was silly enough to upload a working Spectre … exploit for Linux (there is also a Windows one … that I didn't look at) on VirusTotal. … The crux of the exploit [uses] cpuid as a serializing instruction, rdtsc for timing, and mfence/lfence as barrier. … KASLR is bypassed … either by looking at /proc/kallsyms when available to unprivileged users … or by using the generic bypass from the prefetch side-channel … proving again that KASLR is useless at best.
…
In my lab, on a vulnerable Fedora, the exploit is successfully dumping /etc/shadow in a couple of minutes.
Wait. Pause. Dumping crucial kernel secrets in “a couple of minutes”? wyldfire scoffs that it’s nothing of the sort:
Gee, I hope my machine has more Spectre countermeasures enabled than your lab. This is a crucial omission.
…
[Reading this] you could imagine … an exploit might exist that would defeat the existing countermeasures. … So without that explicit context in the article, it's left to the reader to fret over.
Ohhh, so that’s what he was hinting at when he wrote, “on a vulnerable Fedora”? Here’s subreality:
System-wide mitigations for Spectre generally trade off security vs. performance, mostly by preventing speculative execution at critical points. Full mitigation isn't provable as long as speculative execution is enabled.
This appears to be the wrapper code for the exploit. It will choose a payload targeted to specific unmitigated kernels, if available. Otherwise it can fall back on a very slow, but generic, version.
…
This code doesn't do anything new. It's just conveniently packaged.
So nothing to see here? But what if users disable the mitigations, because they want more CPU performance? Intel dev hansendc thinks that’s not a problem, either:
I work on Linux at Intel. … While there are ways to disable mitigation against many of the side-channel issues, this is not one of them. I believe this one is mitigated by the "sbb;and" sequence.
…
There is no way to enable or disable this particular mitigation. That's probably because it's … extremely cheap.
Phew. But where did it come from? As u/netsec_burn explains, it’s from a cracked pentest suite:
This is … from Immunity Canvas, created on 03/22/2018. Hashes as proof (compare these to the hashes on the Linux and Windows VirusTotal pages). … Both binaries and support material for usage were leaked, and not just on VirusTotal.
It is the nature of Internet comments that they eventually degenerate into a blame game. Here’s Tablizer:
Intel should be punished for ignoring a known risk. Once you reach a certain size to have a significant impact on supply and prices of key components, you should be obligated to report and mitigate risks rather than stick your head in the sand and hope you don't get caught.
…
Customers want performance AND security. Customers just didn't know about the second issue. It's one of those short-term vs. long-term issues that capitalists often trip over, similar to pollution and worker safety. Greed tends to make owners short-sighted.
…
AMD made similar mistakes, by the way, but happened to recover quicker.
Be careful out there, urges Scott Scheferman:
This one is going to hurt: Massive leak of over 800 exploits including one for SPECTRE (v1) that is fully weaponized, high quality, documented, etc. … There are other firmware exploits too for Belkin, Dlink, Netgear, Asustek, and more.
…
Be aware of Trojanized/trolled versions of these downloads if you are doing research / defensive planning. They are everywhere now ranging from RAID forum to #antichat channel on telegram, and several copies on [VirusTotal] too. Use extreme caution.
Meanwhile, whatever Whateverthisis is, it sounds disappointed:
"Spectre exploit"? … I thought we were going to send the appropriate 007 agent to take out Blofeld.
The moral of the story?
IT: Ensure users don’t disable mitigations.
SecOps: Don’t even think about downloading cracked pentest suites.
And finally
You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.
This week’s zomgsauce: Toa Heftiba (via Unsplash)
Keep learning
Learn from your SecOps peers with TechBeacon's State of SecOps 2021 Guide. Plus: Download the CyberRes 2021 State of Security Operations.
Get a handle on SecOps tooling with TechBeacon's Guide, which includes the GigaOm Radar for SIEM.
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed on cyber resilience with TechBeacon's Guide. Plus: Take the Cyber Resilience Assessment.
Put it all into action with TechBeacon's Guide to a Modern Security Operations Center.
