Tuesday, November 12, 2013

#badBIOS and Nefarious / Advanced Malware

Screen shot of possible high frequency audio channel in badBIOS
"badBIOS" is a name given to a suspected attack that had been going on for several years against systems owned by Dragos Ruiu. He posted on it on Twitter (@dragosr) using the hashtag #badBIOS and Google+. The story gained momentum when Ars Technica did an excited writeup about it. I'm going to try to summarize the nearly magical properties that it is believed/suspected to possess with references (herehere, here) but I apologize if I confuse the claims/rumor/possibilities:
  • 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 herehere, 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:
  1. Where is the evidence? (Both the lack of available data, and nothing in the data provided)
  2. Why has this been going on for three years and just now being exposed?
  3. Why would someone combine so many novel attacks into one network/attack against Dragos?
  4. 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:
  1. 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). 
  2. It is possible that the code has been growing in complexity over time. And Dragos wasn't aware of the issue until later on.
  3. 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 AMTmanageability 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.]

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]

Monday, February 11, 2013

Cyber-espionage tool - Gauss

[Note: This post was written in August 2012 but I never finished it to my satisfaction so it didn't get posted. Posting it here now because I loved this font signaling trick and wanted to write about. One advantage of posting 6 months later is I can report on what they found after 6 months of analysis, see below.]

Kaspersky has been spearheading a rash of discovery and analysis of advanced cyber-espionage tools that they (and others) are attributing to "nation-states". Stuxnet broke ground in 2011 and eventually even the hardened skeptics admitted it was state sponsored... then came Flame, Duqu and now Gauss this summer.

I didn't write as multiple people have covered these topics at length, I'm pretty confident things are nearing saturation when my wife mentions them to me. But a couple of things are interesting. First, it seems that either nation states are getting more active in this space, or AV companies are getting better at detecting them. I'm curious which it is. Second, Gauss demonstrated that the authors learned from at least some of the mistakes that Stuxnet made. Particularly of interest to me was their use of an encrypted payload that was keyed to the system configuration and not reversible. (Unlike Stuxnet, which had a child-like "if PCI device address = xyz, than decrypt) approach. I'd considered this possibility 6 years ago when learning about ABE (Attribute Based Encryption), which enables the implementor to use attributes as part of the key in a one way function. In the case of Gauss, they simply hashed the %PATH%” environment string and the name of the directory in %PROGRAMFILES% so that analysts don't know what variables are necessary to unlock the encrypted payload.

Another interesting feature of Gauss is its installation of a custom font, called Palida narrow.

Kaspersky had no idea why it was installed. But the researchers at Crysys have some good hypotheses:

One possibility is that there are other components using Palida for some reasons. E.g., tricking with some characters on web pages to hide alerts, or similar, not really clear operations.
A very far-fetched idea is that Gauss uses the font for printed material. It actually tricks some parts of the system to substitute fonts with Palida, so any prints will contain Palida. Later, printed documents could be identified by looking on the tiny specialities of the font.
A third, and more probable idea is that Palida installation can be in fact detected remotely by web servers, thus the Palida installation is a marker to identify infected computers that visit some specially crafted web pages.

They go on to document how web developers could use CSS style pages to determine if a font is installed on a system or not. If the browser discovers it doesn't have the font it can be directed to a URL to retrieve the proper font file. By hosting this on a site controlled by the attacker they can determine if a given system has Gauss installed. A writeup with code is provided on the Crysys page.

Another possibility is the font is inserted to create a vulnerability that provides a backdoor into the system. Fonts have been used in attacks in the past, this could just be another opportunity for future access. More specifically, the TrueType font DLL was exploited by Duqu, which is alleged to be developed by the same people that developed Gauss due to their architectural similarities.

[Feb, 2013] The Wired article I linked to describing Gauss says that both Kaspersky and Crysys believe that signaling was the intent and I agree that is clearly most likely. Given the targeted, sensitive nature of the attack and the limited number of machines it was on (and lessons learned from Stuxnet landing all sorts of unintended locations) and the fact nobody has identified (or reported at least) a vulnerability resulting from the Palida vulnerability signaling just makes sense. Easy to check, subtle, and useful.

As of August 15th the Internet traffic on Gauss drops significantly and people were recognizing they had a serious, unsolved mystery on their hands and were setting out to crack it. An article on ZDNet in September points out it still hasn't been cracked. In December they posted about a cracking tool trying to target the MD5 hash used to protect the payload decryption targeting/fingerprinting module. (Which incidentally runs MD5 10,000 times... not surprising it hasn't been broken yet!)

February 5, 2013 the hack cracking tool was updated to a new version (see history here) and there was no information indicating anything other than a complete stonewall. (They still haven't cracked the encrypted payload or identified what the font is used for).

[May 7, 2013] The Infosec Institute has a nice writeup on Gauss (I found it as they reference this blog post) that covers some aspects I didn't describe.