Screen shot of possible high frequency audio channel in badBIOS |
- It infects OpenBSD, Linux, Mac and Windows systems.
- It infects the BIOS (UEFI and others).
- Even if the BIOS has been reflashed, it persists through reboots.
- Dragos posited it is due to video or network card firmware modifications
- It utilizes IPv6 even if that's disabled in the network stack.
- It loads a hypervisor
- It transfers via USB and other mechanisms.
- It "reacts and attacks the software that we're using to attack it". For example, the registry editor stopped functioning to prevent them from performing forensics analysis.
- It communicates via high frequency audio sent through the computer microphones and speakers.
- It can hide itself in Windows font files and deletes them if inspected.
From the Ars interview:
"We had an air-gapped computer that just had its [firmware] BIOS reflashed, a fresh disk drive installed, and zero data on it, installed from a Windows system CD," Ruiu said. "At one point, we were editing some of the components and our registry editor got disabled. It was like: wait a minute, how can that happen? How can the machine react and attack the software that we're using to attack it? This is an air-gapped machine and all of a sudden the search function in the registry editor stopped working when we were using it to search for their keys."
The argument being that if it is not connected via the network (Bluetooth, Wifi and Ethernet were all removed/unplugged) and a USB drive wasn't used to reinfect the system, how could it have been infected despite a reflashed BIOS and new hard drive?
But the story gets stranger still. In posts here, here, and here, Ruiu posited another theory that sounds like something from the screenplay of a post-apocalyptic movie: "badBIOS," as Ruiu dubbed the malware, has the ability to use high-frequency transmissions passed between computer speakers and microphones to bridge airgaps.
That summarizes the major posited properties of the malware. With such powerful, never before seen, complex properties posited, Dragos has encountered some skepticism from (normally skeptical) security/IT community. I won't highlight them all, but there are plenty on Twitter, the Blogosphere (here, here, etc.), etc. Even Ars posted a follow up article to give attention to the amount of skepticism. badBIOS already has its own satirical Twitter account. Renowned researcher Tavis Ormandy went through the font files and disk images and concluded that there was nothing suspicious there and Dragos should just ignore it and relax. [Turned out to be good advice.]
The major concerns seem to revolve around the following points:
- Where is the evidence? (Both the lack of available data, and nothing in the data provided)
- Why has this been going on for three years and just now being exposed?
- Why would someone combine so many novel attacks into one network/attack against Dragos?
- Can you even build a set of code that is portable against so many firmware/hardware/OS configurations? In a bandwidth constrained environment?
There have been multiple people supporting Dragos, with Tweets from known members of the community (like Alex Stamos or Jeff Moss), blogs (here and here), or even news pieces.
There are viable counter arguments for the doubters:
- Dragos has been providing some disk images, spectral analysis of the audio and other forensics data sources for analysis (although mostly to private, often unnamed sources).
- It is possible that the code has been growing in complexity over time. And Dragos wasn't aware of the issue until later on.
- Dragos runs the Pwn2Own competition at CansecWest. Between that and his normal work (which presumably involved enough 0-day research to qualify him to start such a contest in the first place) might make him an interesting target for someone trying to acquire 0-days.
Interestingly, almost nobody seems to doubt that the individual components are not possible. Now that I've summarized how we got here and what's been seen to date, I'm going to add some thoughts.
First, there were a LOT of skeptics when Stuxnet came out. I was one of the early people (late September 2011) who embraced Ralph Langer's hypothesis (seemed like the most obvious solution given all the evidence.) There were people speculating that the analysis was flawed, it was really a ruse by the Russians or Chinese, etc.) Turned out that the analysis was fine and the nefarious/advanced malware option, was in fact, the correct conclusion. There are lots of compelling research demonstration in each of the areas postulated to date, the only really novel thing here (so far) would be the fact that they are all combined into one VERY complex piece(s) of code:
- Researchers at Siege Technologies and academics in Germany have demonstrated covert channels are possible over audio channels.
- BIOS infections can provide persistence and are definitely not new. They just keep getting better over time.
- Proof of concept infections/reprogramming of Network cards (here and here) and video cards have already been developed (and now people are publishing papers on how to catch them). One aspect of such low level attacks is they are impervious to disk replacement or BIOS reflashing and don't care about the version of the operating system.
- Hypervisor attacks have been around for years.
- Ipv6 is just a standard network protocol. Even if it is "disabled" you could still utilize the code on the host system.
- USB sticks have been a well known attack vector for years. In 2005 researchers at Blackhat showed that you could exploit the operating system USB drivers when plugging in the device. This was also shown more recently in 2014, where it had been improved to hide on USB firmware.
- Malware has been sensing/reacting to evade detection for years.
- Multiple platforms can be handled many ways. One would be code residing on the BIOS or peripheral devices (NIC/Graphics/etc) as discussed in bullets above. Another would be motherboard/processor components such as the AMT / manageability engine.
- For storage, people have used hard drives for ages. Given they were removed here, other approaches must be considered. Obviously if components in hardware were reflashed (as described in the research papers above) that would provide persistence. Other research has shown that NAND regions marked as unusable on disks could be utilized (of course, that would most likely be on the hard drive removed, but it could theoretically extend to boot flash for other components). Others have discussed since 2006 modification of the processor itself, by exploiting the ability of the processor to upgrade the microcode. (Of course that's difficult to do given the cryptographic signature constraints.) McAffee filed for a patent in 2011 to put security in at the microcode level.
So to summarize:
- The lack of third party confirmation means that probably everything that is "suspected" isn't "actual". The very definition of suspected means that confirmation is missing.
- Nothing that has been suggested as a possibility is theoretically new, although the practical deployment of a robust tool might be novel.
- Certainly the integration of all of those capabilities would be very novel. The combination of even 3/4ths (or maybe even half!) of the alleged capabilities would put it on par or ahead of Stuxnet.
- Knowledge of capabilities and threats can certainly induce paranoia, especially in a field that advocates it as a desirable property.
Personally, I think it's likely that there have been a few nefarious things on the network, some of which are gone. As a result of that absence, significantly advanced properties are suspected instead of assuming that the attack is transient. I remember significant challenges I had trouble shooting a random hard crash my system was experience. A mistake in malware that was exploiting hardware was definitely one of my concerns... but nothing I did could identify a problem. Turned out after I turned for outside help it was temperature, the fans were going and it was simply overheating.
Seems obvious now but the complete absence from logs, random behavior, persistence despite testing and replacement of hardware had led me to some interesting possibilities that were theoretically possible but unlikely. Might be the same thing going on here. [Update: Turns out that's exactly what it was..., Dragos came out and said he was incorrect. Looks like he was just overly paranoid and hadn't spent enough time looking at all the weird OS things that happen under the hood. His knowledge led him to unlikely but possible nefarious causes, instead of a simpler answer.]
Seems obvious now but the complete absence from logs, random behavior, persistence despite testing and replacement of hardware had led me to some interesting possibilities that were theoretically possible but unlikely. Might be the same thing going on here. [Update: Turns out that's exactly what it was..., Dragos came out and said he was incorrect. Looks like he was just overly paranoid and hadn't spent enough time looking at all the weird OS things that happen under the hood. His knowledge led him to unlikely but possible nefarious causes, instead of a simpler answer.]
It's really hard to do forensics when you don't have a position of trust. When you don't know what's good or bad. And when those beliefs keep getting disrupted because you don't have consistent data/records. And doing complex analysis in isolation is a bad idea, crowdsourcing is a great approach to this sort of problem (with data provided of course, everyone was crowdsourcing opinions!)
It's also been interesting to see the community awaken to the possibilities of these academic, proof of concept types of attacks existing in the wild. Much like the snarky reactions to Stuxnet, most don't believe these would ever occur in the "real world". But most of the techniques discussed in this post and around badBIOS date back to mid 2000's and probably even earlier in less obvious forums (obscure blogs, email lists, IRC, etc.) There's nothing new under the sun, and yesterday's research will be today's proof of concept... and tomorrow's operational code.
[November 2014: Updated to include Dragos saying he was wrong, just overly paranoid, #badBIOS USB firmware publications, and MITRE's BIOS implant work]
It's also been interesting to see the community awaken to the possibilities of these academic, proof of concept types of attacks existing in the wild. Much like the snarky reactions to Stuxnet, most don't believe these would ever occur in the "real world". But most of the techniques discussed in this post and around badBIOS date back to mid 2000's and probably even earlier in less obvious forums (obscure blogs, email lists, IRC, etc.) There's nothing new under the sun, and yesterday's research will be today's proof of concept... and tomorrow's operational code.
[November 2014: Updated to include Dragos saying he was wrong, just overly paranoid, #badBIOS USB firmware publications, and MITRE's BIOS implant work]