Happy Halloween: The Ghost Really May Be In The Machine

Published: 2013-10-31
Last Updated: 2013-10-31 22:27:17 UTC
by Russ McRee (Version: 1)
38 comment(s)

Ghost in Shell

@dangoodin001 over at ArsTechnica dropped a fabulously spooky tale today of "mysterious Mac and PC malware that jumps airgaps." If you follow @dragosr (Dragos Ruiu) via Twitter you've probably heard about #badBIOS, but if you don't you have some reading to do.

Meet “badBIOS,” the mysterious Mac and PC malware that jumps airgaps - ArsTechnica

#badBIOS features explained - Errata Security

#badBIOS - Security Artwork

Its been three years now that this issue has plagued Dragos, the CanSecWest and PacSec conferences organizer, and the founder of the Pwn2Own hacking competition, who as Dan states "is no doubt an attractive target to state-sponsored spies and financially motivated hackers."

While the Internet Storm Center is not yet in possession of enough information (We can neither confirm nor deny, Senator) to confirm with absolute certainty, this is a real humdinger in the context of immediately recent reports alleging that the Russian Gov Slipped a Little Bit of Malware in G20 Attendees Gift Bags. Additionally, let me lay some propositional logic on you:

If Dragos is smart, then #badBIOS is a legitimate malware threat.
Dragos is smart.
Therefore, #badBIOS is a legitimate malware threat.

To quote directly from the close of Dan's article as he cites Dragos: "It looks like the state of the art in intrusion stuff is a lot more advanced than we assumed it was," Ruiu concluded in an interview. "The take-away from this is a lot of our forensic procedures are weak when faced with challenges like this. A lot of companies have to take a lot more care when they use forensic data if they're faced with sophisticated attackers."

ISC would love reader feedback via comments regarding thoughts on detection and mitigation as more details on this surface.

Happy Halloween and enjoy the ghost hunt. :-)


Keywords: BIOS malware
38 comment(s)


1. faulty hardware
2. is trying to sell something
3. has developed a drug addition
First off Steve C....its "addiction" not "addition".

@dragosr is the founder of the Pwn2Own contest, and the organizer for both CanSecWest and PacSec conferences. His credentials, and contributions to the security world are extremely large, very helpful, and well respected.

What do you have to show that even compares slightly to @dragosr?

Good day......I SAID GOOD DAY!
Need to reflash that BIOS using JTAG instead of the reflash code built into the BIOS. If that doesn't purge it, then the gremlins are running amok.
[quote=comment#28073]First off Steve C....its "addiction" not "addition".

@dragosr is the founder of the Pwn2Own contest, and the organizer for both CanSecWest and PacSec conferences. His credentials, and contributions to the security world are extremely large, very helpful, and well respected.

What do you have to show that even compares slightly to @dragosr?

Good day......I SAID GOOD DAY![/quote]
This is why there's a question of 'wtf?'.

All of the things mentioned in the article, individually, have a lot of feasibility. We've seen persistent threats in the BIOS, MIT and other engineering schools are working on networking over sound, cross-platform exploits, and more.

But what makes it fail the McGuffin test is the combination of things and the manner in which its presented, plus the timeframe. He claims it's been infecting multiple machines. Except that EFI, UEFI, and BIOS are all different -- and even amongst one of those, they'll have different entry points, security vulnerabilities, and more, from version to version and vendor to vendor.

Considering that the BIOS EEPROM can't be smaller than 256K, it must have exploits for multiple versions and more in that small of a package. It must also have exploits for multiple OSes (at least 4) in it.

Even if that were possible, the man's a security researcher who's been working on this for 3 years now. Within the first year you'd think he'd have dumped the firmware of the BIOS and run a simple diff against a known good version and the dump. If a threat survives an OS wipe and reinstall, even to another OS entirely, the next logical choice to look is at the BIOS. But he hasn't done that, nor has he set up a simple oscillator to look for evidence of this sound networking.

But even beyond that, no other anti-virus vendors have vetted the story or reported anything similar (before Dragos mentioned it 20 days ago). No one else has reported anything similar. It's not peer-reviewed or backed by anyone else in the industry.

So because of all of that, it fails the McGuffin test. This means it's either:
A) A prank or hoax (perhaps even a 'What if?' scenario)
B) Someone grasping for attention
I'm interested in the "air-gapped"-ness of the spread.

If an infected machine was trying to infect a non-infected machine with high-frequency sounds, then surely there must be a sound interpreter of some sort to be able to decode the "data" sent?

Unless there is a hidden tigger code, which springs the non-infected machine into life to act on the instructions.

If someone suspects covert audio communications the answer is easy, grab a decent microphone, preamp and 'scope. With commercial stuff it isn't hard to get up to 50 kHz. Guessing about communications is not the right way to answer the question.

If someone suspects USB chicanery, grab a USB analyzer. For USB 2.0 they are pretty cheap and easy to find. The answer is direct.

Maybe it is a new kind of radio communications. Well, roll out the spectrum analyzer. Old ones that still go to 20 GHz are not worth much but would answer this question immediately.

But what if it's optical. See if the infection moves between one room and the next.

... all this to say that it isn't worth guessing when some simple measurements can answer the questions. It's done all the time by those of us who debug boardrooms. Having been around the business for quite a while I would guess that much of the issue is generated by the computer inside someone's aluminum foil hat.
I'll be glad to accept donations of USB analyzers or Spectrum analyzers. Both are now on my must purchase list as soon as I have the budget to. Right now I'm dependent on the generosity and help of others - and we do intend to look closely. So far we've been limited to the diagnostic tools me and my colleagues whom I've consulted have had at their ready disposal. Your typical forensics kit/software/equipment - which has been clearly proven sorely lacking. I'm not sure we'll ever catch the full scope of this intrusion, but the process of chasing it alone has proven to have more than enough educational value to share.

I would be glad to answer questions, here of all places. And thank you for the kind words Russ. As that arstechnical article seems to have elicited the usual spectrum from the tin-foil hats, to the name callers, reasonable words from folks *I* trust start to mean even more to me, my gratitude.

p.s. heh, nice quote and graphic.
as i've stated on twitter, there was no evidence of audio infection, it was stricly used for command & control, and slow and laggy at that. We used their lag to try to selectively elicit responses, and insert surprise counters (mostly playing at the registry level on windows, but we did try a few creative filesystem modifications, and network device configuration disabling on live connected boxes, to try to identify components and communications). We triggered and observed complete re-installs of their rootkit on a number of occasions.
None of the articles I saw pointed me to a write-up of this, other than Twitter posts which are just too difficult to follow and questions probably leading in circles. This might have been best documented in something like a Wiki, to record individual findings, and showing 'method': tests comparing infected vs. clean systems (and how you were sure of that), results or measurements taken and how you were confident in the accuracy of those and so on.

In this situation I would have also thought it best to acquire an 'immune' trusted system for creating+verifying media and disk drives for the test systems, and network sniffing. Maximum diversity seems key to making sure it is immune. An old Sun workstation for example has different CPU architecture and BIOS, and might not even have any USB ports, or would likely be OHCI rather than EHCI type.

Acquiring authentic install media and setting up the first trusted computer able to verify other media, is quite hard if you consider communications, mail, and customs interception and such. Even if you did have a trusted computer to do the verifying, you have to establish a web of trust before you can confirm what are the correct hashes from the OS vendor. This requires collaborating with other people perhaps in real life to initially verify media and signatures.

Diary Archives