Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Community Forums

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Happy Halloween: The Ghost Really May Be In The Machine
Quoting Diary:

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. :-)


Russ McRee

103 Posts
ISC Handler
1. faulty hardware
2. is trying to sell something
3. has developed a drug addition
Steven C.

164 Posts
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!

65 Posts
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.

108 Posts
Quoting @HackDefendr: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!

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
David Trest

3 Posts
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.

4 Posts

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.

6 Posts
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.


15 Posts
p.s. heh, nice quote and graphic.

15 Posts
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.

15 Posts
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.
Steven C.

164 Posts
And something obvious in case someone didn't already bring it up: bad RAM or other faulty hardware, could cause all kinds of odd behaviour in any OS that might look like a system is compromised - data changing that shouldn't (especially if it is frequently overwritten, like Windows' registry), signatures failing to verify, media written from that system being corrupt or unbootable, or appearing to change on subsequent reads, and all kinds of odd behaviour that presents itself only sometimes.

If many systems at the same location exhibit the same problem, before assuming malice I might consider something environmental like strong EMI/RF interference, which is where tin foil really might come in useful after all. Do you live near an airport radar?
Steven C.

164 Posts
I guess the first question we may want to ask is this simply someone really smart doing something really stupid, placing an untrusted USB stick in to a production environment. (Sounds like @dragosr has a good life long research project.)

More details would be needed to make any judgement and remove the foil from my head.

That is not to say you cannot engineer a host of attacks which may use a non traditional delivery or communication method. (On/off-->0 & 1 's ; beautiful.
Blink Blink Blink Blink; Blink Wink ;Blink Wink Wink Blink;Blink Wink Wink Blink; Wink Blink Wink Wink; Blink Blink Blink Blink; Blink Wink;Blink Wink Blink Blink; Blink Wink Blink Blink;Wink Wink Wink;Blink Wink Wink;Blink;Blink;Wink Blink )

Tools are extremely valuable not to mention have a shelf life and deployment life (kind of like halloween candy), so if something at this level of sophistication, or creativity, was discovered in public exceptional evidence would be needed. (I am sure he has it. LOL)

beer, candy, spooky face, boo........

2 Posts
We've been using small cheap media pcs ($350), with dedicated unshared usb drive, installed from retail media, with bluetooth and wifi cards removed, ir transceivers taped over, and motherboard speakers removed, uh forcibly - I think I've voided my warranties there :-) as reference systems. We've been running those systems (fortunately they have super light power draw) from car booster lead acid battery packs to preclude powerline voltage signalling (you get pretty detailed voltage info from bios, and can affect the voltage with cpu speed and backlights and such :-) - just in case. We've also crossreferenced install media checksums with colleagues, and _never_ connected the reference systems to any network or external wire.

Nowadays since we confirmed USB infection we are using Rock Ridge formatted CDs to load software, but even that is tricky if you need to get data from compromised systems, because we observed the malware accessing files (presumably under operator control, it was slow and laggy) on the burn sets for CDs. The changes they made still need analysis. I've uploaded one set of data _deleted_ from a burned forensic cd image here

md5 checksum of kit.tgz 7a64f35c2db85cc1f5cc1f5eefebb924e081b - thanks in advance for any analysis shared back - filelen 949437030

One other resource we've used is WORM SD cards from SanDIsk.
We've also been doing analysis the old fashioned way, pop the drive from infected boxes and take it to a trusted computer and image read-only. But the way we arrive dhere is when we discovered persistence (or re-infection) on systems with brand new from foil envelope disks installed.


15 Posts
The usb keys we were using to transfer data to forensics systems were all brand new from package use only once. We've been goign through $300 in the cheapest USB keys we could find (Patriot, Adata, Kingston) a week for the last few months isolating this stuff.

We are definitely talking about stuff beyond anything explainable by bad RAM, bad RAM can't materialize install sets from software only available on the network on machines that have never been networked. Bad RAM can't selectively add registry configuration sets, dynamically change registry key permissions to reset and lock out changes after they are made and make repeated periodic access to new crypto libraries...


15 Posts
Is this documented someplace where someone can read up on everything and save having to ask the same questions again?
Steven C.

164 Posts
Well, I need to spend some time documenting. All in good time.
In the meanwhile, ask away, I'm making myself and my analysis available here.
cheers, --dr

15 Posts
Also, we've shared with Microsoft, and a few trustworthy security companies, one additional vector that seems to be used for infection, awaiting patch information there. cheers, --dr

15 Posts

Sign Up for Free or Log In to start participating in the conversation!