DISCLAIMER: The contents of this analysis are meant as a critical review of data currently available on badBIOS, and are not intended to disparage in any way, the author of the badBIOS claims.
Stuxnet was a game-changer. In the words of one researcher, it marked “a clear turning point in the history of cyber security and in military history as well.” Even though some of the propagation methods employed by Stuxnet, taken in isolation, may have been known to be theoretically possible at the time, it was the first public record of an attack of such complexity against a target of substantial value. The version of Stuxnet that gained public exposure “represents the first of many milestones in malicious code history – it is the first to exploit four 0-day vulnerabilities, compromise two digital certificates, and inject code into industrial control systems and hide the code from the operator”
The scope of the Stuxnet development and execution effort also had another, perhaps unintended, consequence: it lowered the bar on what would be considered a plausible cyber attack. If the Stuxnet authors were able to physically break into two companies and steal signing certificates in order to sign the malicious binaries, the reasoning went, or exploit four zero-day vulnerabilities, then what else could they do? Did anything lie outside their reach? After Stuxnet, no idea was too outlandish. Could malware jump over an air gap? Stuxnet did. Can systems infected with a specific strain of malware communicate through a means other than traditional wired or wireless networks? Flame did. What then, is expected behavior? What is the baseline? As Dan Geer recently pointed out, “everywhere you look, cyber security practitioners are trying to get a handle on “What is normal?” so that that which is abnormal can be identified early in the game.” It is against this backdrop of behavioral uncertainty, that the claims made about the badBIOS malware should be weighed: any unexplained operation or response observed on an isolated or networked group of computers, can be taken to be the workings of malware. Because as Stuxnet, and its cousins Flame and Duqu showed, malware authors are several years ahead of what is commonly believed to be possible.
INTRODUCTION
In mid-October of this year, Dragos Ruiu, a security enthusiast well known within the infosec community, used social media channels to make a startling announcement: his home-office systems were infected with an advanced type of malware which appeared to infect the systems at the BIOS level, have the ability to jump air-gaps by communicating over the 35kHz audio range, and infect different operating systems (OSs). Ruiu called the malware badBIOS, and started sharing snippets of information relating to its operation on Twitter, Facebook, and Google+. Due to its advanced nature, Ruiu explained, it was not immediately possible to obtain samples. For the month following the disclosure, the infosec community was abuzz with discussions about badBIOS: was it real, or was it a hoax? Was this the next Stuxnet? As we will see, once the scientific method is applied to Ruiu’s assertions, the answer is self-evident.
BACKGROUND TO THE PROBLEM
Dragos Ruiu is a familiar name within the infosec community. He is best known for being an organizer of the Pwn2Own security challenge, and the CanSecWest and PacSec security conferences. His resume states that he worked as a C programmer, and later as a VAX administrator, and an Embedded Systems programmer. It also states that he was an original member of the Honeynet Project, and also a founder member of SourceFire, a company best known for its network security software and hardware. He is also listed as one of the Major Contributors to Snort, an open source Network Intrusion Detection system (NIDS). In addition to this, Ruiu authored two books (Testing Digital Video in 1997, and Testing Digital Video-Discover the Latest Techniques and Products for Real-World Video Testing, also in 1997) and also co-authored two books (Broadband Testing Technologies, B-ISDN Primer in 1993, and Deploying Snort 2. 0: Maximizing and Extending Intrusion Detection in 2003). In spite of this, there appears to be no reference to any specific security research conducted by Ruiu, presentation made by him at a security conference, or forensic or malware analysis undertaken by him.
When releasing information about badBIOS, Ruiu shared his observations progressively and without much technical detail. A sizable portion of the information available on badBIOS was released by Ruiu on Twitter, 140 characters at a time. What this means is that there is no authoritative analysis of the technical details of badBIOS that may be comparable to Symantec’s W32.Stuxnet Dossier. Graham and Jaenke are the ones that come closest to providing a technical analysis. Analyzing the primary information made available by Ruiu therefore, involves a process of reviewing a large number of sources, each with a small amount of information, and each with little accompanying context.
Compiling the data released on Twitter, Facebook, Google+ and on one podcast interview pertaining to badBIOS, it is nevertheless possible to put together a list of forty (40) distinct claims that are made by Ruiu regarding badBIOS. These are listed in their entirety, in Annex B, including reference quotes and links. For the sake of brevity, Table 1 below only includes a subset of ten (10) claims. The same process used to test the validity of these ten claims, can be applied to the remaining thirty. The numbers in Table 1 correspond to the row number in the complete list in Annex B.
INSTINCTIVE THINKING
The method of analysis that accompanies the assertions made by Ruiu are characteristic of instinctive thinking: the claims are unsubstantiated, assumptions and conjecture are combined with facts, and unexplained behavior is taken to be the work of advanced malware. Even though Ruiu notes that settling on the idea that an advanced form of malware was behind the unexplained behavior was “about the second last theory we tried,” the primary sources on badBIOS lack alternative hypotheses, and contain several examples of cognitive distortions. Ten assertions are analyzed below. The numbering corresponds to the row in the list of forty assertions presented in Annex B.
A common theme that is present throughout the first-hand reports of badBIOS operation, is the assumption that the malware exists. That the unexplained behavior is attributed to an advanced form of malware, is presented to the public as a fact. Ruiu mentions having looked at other alternative explanations early in the discovery of this malware, but does not share those hypotheses or discuss them with his readers. The assertions are presented in rapid succession, and without supporting evidence. This reduces the assertions to a series of anecdotes and eyewitness accounts. Further, Ruiu doesn’t explain why these assertion are taken to be true. These assertions should only be looked at as a list of questions that should characterize the start, not the end, of an investigation.
Assertion 1:OpenBSD systems infected with badBIOS can unexpectedly enter single user mode.
Reference: “we saw all kinds of weird effects, and things like OpenBSD boxes in single user mode, changing files while they’re not supposed to be on the network, so there’s all kinds of strange things.”
Evidence: Ruiu does not provide corroborative evidence to back this claim. No evidence is provided to explain how many OpenBSD systems entered single-user mode, or whether this was a repeatable or one-time occurrence. By making this assertion, Ruiu is making an inference based on very little data.
Biases:
Notes: Unix operating systems like OpenBSD have five stages, or ‘runlevels’ that comprise the bootstrap process. Different tasks or operations are undertaken at each runlevel, and a process or subsystem may start at one runlevel and be shut-down at another. Run-level 1 is referred to as ‘Single user mode’ referring to the fact that this runlevel does not support a multi-user environment. Only the superuser (or administrator) account, referred to as the ‘root’ account in Unix can log on to the system when the machine is in this runlevel. Single- user mode is also a stage where other services or processes have not yet started; it is a stage reserved for troubleshooting and administrative tasks, and since networking services are not active at this runlevel 1, it requires operator interaction at the system console.
Observation:
Assertion 6: Deleting registry keys that badBIOS is using, results in the malware entering an error condition.
Reference: “at one point we saw a whole bunch of registry keys as they’re accessing them, so we deleted them … And you could see that their stuff sputtered and then I guess that was the point at which it required operator intervention. And we start seeing more intelligent responses from these things.”
Evidence: Ruiu does not provide evidence to back this claim. What is also absent is detail regarding the exact steps that were followed to generate this outcome. Detailed steps would make it possible for others to try to reproduce the same behavior. In this case, Ruiu is reaching a conclusion based on very little data.
Biases:
Notes: The Windows registry, according to Russinovich, Solomon, & Ionescu (Windows Internals Part 1) is “the systemwide database that contains the information required to boot and configure the system, systemwide software settings that control the operation of WIndows, the security database, and per-user configuration settings.” Attempting to edit Windows registry keys carries with it the caveat that “you must exercise extreme caution; any changes might adversely affect system performance or, worse, cause the system to boot successfully.” It appears that Ruiu’ intention was to elicit some kind of response by deleting “a whole bunch” of registry keys from a running Windows system. This strategy may work in a well controlled setting, where the values being deleted are known, and documented, and where there is a list of likely outcomes. Deleting the registry keys in that scenario could be a method of testing likely outcomes. Indiscriminately deleting registry keys however, and reporting on the outcome does not help strengthen the assertion.
Observations: This behavior, as described, should be repeatable. The assertion that deleting registry keys causes the badBIOS malware to ‘sputter’, implies that the operation being observed — the write operations to files on disk, and read and write operations to specific registry keys — is being undertaken by the malware. Since there is insufficient evidence to prove the presence of malware, it is unclear what is entering an error condition — what is sputtering? What registry keys were being written to? Which were erased?
Assertion 12: An audio recording of badBIOS communication shows a pulse pattern in the 35kHz range; approximating 128 bits per second.
Reference: “So we made some recordings, and a colleague of mine has been looking at it, and he’s found lots of odd spectral artifacts at around 35kHz, and when you zoom it out, it looks like it’s a repeated bit pulse pattern at that rate, something like 128 bits per second, which coincidentally enough seems to match the bit rate of the packets that we’re seeing on the procmon traces, we’re seeing 8-byte payloads, and changing the packets once every one to two seconds, about the same bit-rate.”
Evidence: Ruiu provided an audio recording which shows a signal in the 35kHz range, and noise around the 40kHz range.
Biases:
Notes: The range of human hearing is 20Hz – 20,000Hz. The image depicted on the cover page of this report is that of the signal alluded to be Ruiu, which can be observed at the 35,000Hz mark. The signal was further analyzed and “slowed down 20x” to produce the image below. The pulse pattern Ruiu refers to, is the pulse that can be observed in this image.
Observations: A signal can indeed be observed at the 35kHz mark, however there is no evidence to suggest what could be generating it, and one cannot rely on a visual analysis of the waveform to conclude what it could represent. A Twitter user following the discussion for example, suggested that the signal can be generated by an electronic component present in Ruiu’s system, similar to a NCP1729, a Switched Capacitor Voltage Inverter that operates at 35kHz. In a related tweet, Ruiu expressed a sentiment that becomes characteristic of the claims made of badBIOS, he notes “slowed down it sounds like a modem. As I said I’m not doing analysis, looking at results. But it’s looking pretty viable.”
Assertion 16: The badBIOS audio link is encrypted.
Reference 12: “We haven’t captured the downloads, or gotten any of these modules, it’s all-encrypted” and “nope it probably wasn’t ipv6 over audio, it was seemingly 12byte packets, 8bytes encrypted payload.”
Evidence: Ruiu provides no evidence for this assertion.
Biases:
Notes: Ruiu takes the signal at 35kHz to denote data communications between systems infected with badBIOS, and then asserts that the signal is encrypted — and offers detail of the packet format: it contains a 4-byte header and an 8-byte encrypted payload.
Observations: As noted by the reference, Ruiu explains that the his team has not captured data showing what badBIOS is downloading onto the system, nor obtained the modules that badBIOS has pulled as part of its exploit kit; and in the same sentence makes the claim the communication is encrypted.
Assertion 21:A USB disk that has been inserted into a machine infected with badBIOS, can cause a clean system to reboot.
Reference: “So we left it in there for a little bit, and looked at the files, and pulled it out, and reinserted it into one of the forensic systems. The message came up in the console, and then in about a minute or so the system just rebooted itself spontaneously, after plugging this thing in.”
Evidence: Ruiu provides no evidence for this assertion.
Biases:
Notes: What Ruiu is depicting is a correlation between two events: plugging-in the USB disk into an uninfected system, and that system rebooting. However correlation does not imply causation: that the uninfected system rebooted a minute after the USB stick was plugged into it, does not mean that one event caused the other.
Observations: Although at first glance this assertion may appear alarming, it is provided without any context, making an accurate analysis difficult. An indication that the behavior was reproducible would help in this event. Since Ruiu refers to more than one forensic system (implying that there are at least two), the next question to ask would be: was the USB disk plugged into any of the other forensic systems, and did any of them reboot as a result?
Assertion 25: badBIOS is able to block access to internet sites, notably sites that contain technical information that pertain to badBIOS method of operation, infection. or propagation.
Reference: “and there was some blocking going on. One of the sites that we were trying to get to, and I don’t know if this was conscious on their part, but this is what triggered the thought chain from me, was a site called flashboot.ru.” Coincidentally Russian flash controller reflashing software sites are blocked on infected systems, and laptop bios downloads 404 #badBIOS”
Evidence: Ruiu does not provide any evidence to support this assertion.
Biases:
Notes: As per RFC 2616, error code 404 (Not Found) should be used by the server when it is unable to fulfill a request by the client, but does not wish to make known the reason for the refusal.
Observations: Little context is provided with this assertion, and troubleshooting steps are absent. Connecting a switch to the network and capturing the client-server communication would determine whether the traffic is being sent out to the internet, or proxied by an infected machine. Trying to access the site from another device — such as a mobile phone— would indicate whether the problem is local to the network on which badBIOS systems reside, or whether the problem lies with the flashboot.ru site. Attempting the connection over an extended period could determine whether the site was undergoing maintenance, experienced an outage, or if a flashboot.ru site administrator inadvertently broke the link Ruiu was attempting to access.
Assertion 26: badBIOS operators removed the malware from some infected boxes once there was public conversation regarding its method of operation, infection, and propagation.
Reference: “when we start talking about the USB and the ultrasound thing, it’s the first time we’ve ever seen them back off, so they actually pulled out of a bunch of boxes as soon as we started sniffing down that road, and so that’s been a really positive thing.”
Evidence: Ruiu does not provide any evidence to support this assertion. One could also ask the question: What evidence could Ruiu provide to back this claim? Since no evidence of the existence of badBIOS has been provided, it is difficult to prove the absence of that evidence.
Biases:
Notes: Proving this assertion, would be akin to trying to prove a double negative while implicitly assuming the positive: first trying to prove the absence of badBIOS from previously-infected systems — on which the presence of badBIOS has not yet been confirmed, and then trying to prove a causal relationship for its absence.
Observations: At this point, not enough information has been provided to prove the presence of badBIOS. Trying to prove its absence, or establish a causal relationship, would require proof its presence as a prerequisite.
Assertion 34: badBIOS uses TTF font files on Windows as part of its attack kit. In infected Windows systems, additional .ttf and .fon files can be observed – three of them (meiryo, meiryob, and malgunnb) have a size that is bigger than expected.
Reference: “Now suspect font files as a part of the infection vector. Found 246 extra ttf files, 150 fon files in addition to unusual DLLs #badBIOS”
Evidence: Ruiu made available an archive containing what appear to be the file contents of a Windows system. Included in this archive are the font files that he refers to in his assertion. In addition to this, Ruiu shared a link to the output of a utility that dumps the contents of TTF files (True Type Font File Dumper), with the caption “is this an TTF attack vector? table 63 of meiro.ttc.”
Biases:
Notes: 0xebfe.net. ran the sigcheck utility that is part of the SysInternals suite and found that 22 files out of 255 were not signed. Manually uploading a selection of these files to online antivirus resource VirusTotal.com, did not find known malware in any of them. The output referred to by Ruiu does show that the font meiro.ttc has a length several times that of all other fonts listed.
Observations: This finding can be characterized as inconclusive. It would however be grounds for a further review of the font files that failed the signature check, and specific analysis of the meiro.ttc file.
Assertion 36: badBIOS can disable the Windows registry editor.
Reference: “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, … At one point, we were editing some of the components and our registry editor got disabled.”
Evidence: Ruiu provides no evidence for this assertion.
Biases:
Notes: This assertion comes with very little accompanying detail. The behavior described however, is not necessarily anomalous. The registry hive is a database file, which can be left in an inconsistent state by an ungraceful shutdown, or corrupted by faulty hardware.
Observations: The assertion does not make clear what registry keys were being edited, what other changes were being made to the registry, or what characterized the registry editor’s disabled status. Did the registry editor enter an error condition and halt? Was it still functional but disallowed changes to keys? Was it functional but disallowed changes to the keys that Ruiu and his team had been writing to? A number of troubleshooting steps could help provide clarity with respect to this claim. Since the registry keys are stored in a hive, which is a file that resides on disk (some hives reside in memory), a first step to determine the validity of this assertion, would be to check the permissions on the corresponding hive when the “registry editor got disabled.” Did the permissions change? Other troubleshooting steps could involve trying alternate registry editing tools to determine whether they exhibit the same behavior, or trying to edit the same keys via the Windows command line utility reg (reg add KeyName Value).
Assertion 38: badBIOS reflashes the system BIOS and is able to persist after the machine has been re-flashed with legitimate firmware.
Reference: “We’ve already found some persistent BIOS malware that survives re-flashing with it.”
Evidence: Ruiu does not provide evidence for this assertion.
Biases:
Notes: In his detailed rebuttal of Ruiu’s claims, Jaenke refutes the idea of a portable hardware- independent BIOS, and explains that BIOS firmware is very hardware-specifc. He explains for example, that the same BIOS could not be burned (or ‘flashed’) on two motherboards from the same vendor, that do not share the same model number. He also goes on to state that modern BIOSes have very limited space (in the order of 6KB) of available space for a malicious payload.
Observations: Jaenke makes a strong case against this assertion, focusing on the difficulty associated with creating a ‘portable’ BIOS, as well as the justification provided by Ruiu for not having an infected BIOS dump to share. He writes, “If you are MISSING a block, you will fail checksum and fail a basic differential. If you have AN EXTRA block, you will fail checksum and fail basic differential. There is no ‘maybe’ no ‘if’ no ‘but.’ If it’s in the BIOS, it’s in a dump. If it’s in a dump, it’s detectable and extractable” (Jaenke, comment on Nov 1st, 2013 at 9:18 pm).
CRITICAL THINKING
In order to analyze the claims presented by Ruiu, we can formulate alternative hypotheses, and test them against each of the claims made regarding behavior attributable to badBIOS. The process to follow is depicted in Figure 2.
The hypotheses against which each of the assertions can be tested, are:
In the interest of brevity, only two hypotheses (H0 and H4) will be tested against the first five assertions.
Assertion 1: OpenBSD systems infected with badBIOS can unexpectedly enter single user mode.
Alternative Hypotheses H0:It is possible to rationally explain the behavior observed by Ruiu. In this case, the rational explanation is that a hardware or software component in the system entered an error condition due to faulty hardware or faulty software.
Likely Outcomes:
Test:
Alternative Hypotheses H4:The behavior observed by Ruiu is anomalous, caused by advanced malware. An example of the behavior expected by advanced malware is the stealth near-undetectable operation characterized by Stuxnet.
Likely Outcomes:
Test:
Assertion 6: Deleting registry keys that badBIOS is using, results in the malware entering an error condition.
Alternative Hypotheses H0:It is possible to rationally explain the behavior observed by Ruiu. In this case, the rational explanation can derive from an understanding of what the Windows registry represents, and caveats that accompany modifying its contents. As mentioned in the Notes section of the Instictive Analysis of Assertion 6 above, Russinovich, Solomon, and Ionescu (2012) characterize the Windows registry as a “the systemwide database that contains the information required to boot and configure the system, systemwide software settings that control the operation of Windows, the security database, and per-user configuration settings” and urge “extreme caution” when making changes to it.
Likely Outcomes:
Test:Although the name of the specific keys that Ruiu and team deleted is not made available, this outcome can be tested by:
Alternative Hypotheses H4:The behavior observed by Ruiu is anomalous, the product of advanced state-sponsored malware.
Likely Outcomes:
Test:
Assertion 12: An audio recording of badBIOS communication shows a pulse pattern in the 35kHz range; approximating 128 bits per second.
Alternative Hypotheses H0:It is possible to rationally explain the behavior observed by Ruiu. The rational explanation is the presence of electronic components that operate at the 35kHz range.
Likely Outcomes:
Test:
Alternative Hypotheses H4:The behavior observed by Ruiu is anomalous, the product of advanced state-sponsored malware.
Likely Outcomes:
Test:Both (1) and (2) can be tested by designing a double-blind test, where two independent RF engineers are asked to separately measure and analyze the 35kHz signal, without being told what it is suspected of being. If both conclude that the 35kHz signal is consistent with that of a communications pattern, that would prove this hypothesis.
Assertion 16: The badBIOS audio link is encrypted.
Alternative Hypotheses H0:It is possible to rationally explain the behavior observed by Ruiu. The rational explanation is that (a) the observed signal is not an audio link, and that it is therefore (b) not encrypted. The signal at 35kHz does not represent an ‘audio link’ between two devices, but rather an audio signal generated by an electronic component operating at that frequency.
Likely Outcomes:
Test:
Alternative Hypotheses H4: The behavior observed by Ruiu is anomalous, the product of advanced state-sponsored malware.
Likely Outcomes:
Test:
Assertion 21: A USB disk that has been inserted into a machine infected with badBIOS, can cause a clean system to reboot.
Alternative Hypotheses H0:It is possible to rationally explain the behavior observed by Ruiu. The rational explanation is that the system rebooted due to a system failure, related to either hardware or software.
Likely Outcomes:
Test:
Alternative Hypotheses H4:The behavior observed by Ruiu is anomalous, the product of advanced state-sponsored malware.
Likely Outcomes:
Test:
DISCUSSION
The claims presented by Dragos Ruiu were picked up by several online security news publications:ThreatPost.com,ErrataSec.com,ArsTechnica.com,PCWorld.com, and even antivirus vendor Sophos published an article which in response to the question ‘What we can predict’ noted “So the short answer to the question of what we have to say about BadBIOS is, “We can’t yet say.” An analysis however, of the forty claims put forth by Ruiu, shows that the answer to this question is self-evident: there in no substantive proof to back the claims that Ruiu has made — except for the notable exception of Assertion 34: the TTF font files missing a digital signature. What seems to have contributed to this story receiving attention that it did, is that the claims that Ruiu makes, are independently plausible, and have been so, in some cases, for years. Malware can jump airgaps using audio (Hanspach, Goetz, & Fraunhofer, 2013). It can hide in hardware (Stewin & Bystrov, 2013), even in BIOS. Malware infection via USB sticks is the norm more than the exception. Perhaps more importantly however, Stuxnet, Duqu, and Flame, have raised our expectations of what new infection and propagation methods well-funded malware writers will employ. A side-effect of this increased expectation, appears to have been our acceptance of claims without critical review. Grimes sums up what is wrong with the badBIOS story in 4 points:
He goes on to draw an insightful parallel to Stuxnet, worth quoting in full:
“When Stuxnet was discovered, multiple antimalware companies around the world were finding copies. It started with one, then quickly spread to the others — not so with BadBIOS. Somehow the most sophisticated superbug on the planet was released three years ago — and only Ruiu has found it. What would be the spreader’s motivation for infecting Ruiu? With Stuxnet, the motivation was to stop World War III. Does Ruiu or his lab have something on the same order that needs to be found out or stopped?”
It is a fair point to ask, and one that remains unanswered: Why has nobody else observed samples of this malware?
It may be the case, that Ruiu’s intention was to engage the infosec community in the process of understanding the odd behavior he observed on his home-office systems, rather than to assert that it was conclusively the work of a new breed of state-sponsored malware, but that Twitter, Google+, and Facebook did not provide an adequate means of doing so. As it stands however, the assertions made by Ruiu provide a good starting point: an interesting set of observations to guide data gathering and investigation.
CONCLUSIONS
This study has covered the weakness present in the badBIOS analysis as done by Ruiu, and provided suggestions for how it can be improved. The main failing was that it was not undertaken in a critical manner. Not enough questions were asked, there was a seeming abundance of confirmation bias, there were no alternate hypotheses, and yet there was no effort to disprove any of the assertions. Most troublesome for the researchers who wanted to help in this analysis however, was the fact that there was a lack of evidence. Ruiu’s social media posts are replete with offers to help in the analysis. As it stands now, a critical analysis of the data provided by Ruiu, and of the method of examination he employed, indicates that badBIOS is not real. Whereas it is possible that a couple of Ruiu’s systems were infected with some form of malware — which would account for some of the behavior he observed: such as the failure to boot from CD, or the font files with no signature; none of the assertions he provided indicate that the malware is of the technical complexity attributed to badBIOS.
It is not all doom and gloom however. The strength of Ruiu’s approach was to think outside the boundary of what was considered plausible. As a colleague of mine put it, referring to badBIOS, “if it didn’t exist before, it does now.”