Threat Level: green Handler on Duty: Russ McRee

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

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

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

170 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!
@HackDefendr

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.
Moriah

120 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

5 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.
amilroy

8 Posts
Odd...

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.
GordonM

11 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.

cheers,
--dr
Anonymous

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

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.
Anonymous

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.

170 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.

170 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........
steve

5 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 http://goo.gl/3pQbeZ

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.

cheers,
--dr
Anonymous

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

cheers,
--dr
Anonymous

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

170 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
Anonymous

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
Anonymous

15 Posts
Surely to solve a complex problem you need to be keeping a written record yourself as you go along, to avoid going over the same ground repeatedly and to plan where to go next. If you want to involve other people, share that online? Or else someone might maintain that for you. Having dialog with hundreds or thousands of people split across Twitter, here, and wherever else can't possibly be efficient without such a reference. And at the end of all things, that documentation would be the basis of a fascinating write-up on the whole thing.

That you were not doing this is actually seemed a little strange to me, so an initial thought was that this was really a 'thought experiment' designed to elicit ideas for a discussion of forensic technique against a particularly pervasive threat. A maximum-audience discussion on social media seems more fitting with that.

Anyway, I feel there's a lot of trust being put in modern cheap hardware, that it was even pre-installed with a 'clean' BIOS and OS image in the first place (e.g. compromise at the factory/vendor/during shipping), the trust put in tools that have been used for flashing and such, and not least the proprietary Windows OS. Isn't a simpler, more transparent OS like OpenBSD an easier place to look for erroneous behaviour (since I heard it was affected in some way by this)? And is it really known what hardware is immune to it (I think maximum diversity in hardware and its age/era is important for this); or else how do we know the forensic machines are not infected and producing false results this whole time.
Steven C.

170 Posts
My colleague Richard Chadderton, another forensics professional I have shared data with, has also posted a verification set of checksums for data we found that had "appeared" on a non-networked Thinkpad X1 Carbon (with wan, wifi and bluetooth cards removed, stock win8 install, never patched or networked, reflashed bios but _no_fresh_ drive) those checksums also include the kit.tgz files above - they disappeared when we were copying the data from SD card to CD on consecutive CD burns on fresh install win8.1 system also un-networked (but with network/wifi hw installed) but patched and prepared at another colleagues office, brought to our lab. (we did plug a usb key into this fresh system before the SD card) His checksum list of "appeared" files is at: http://www.filedropper.com/dragosr-thinkpad-20131016filelist

cheers,
--dr
Anonymous

15 Posts
Anaysis of these files has been on the same media PCs, using Linux running from ramdisk, and openbsd runnign from ramdisk from CD and from install on fresh disks with a custom _very_ stripped kernel compiled on the box and older slower VIA 533 Mhz (too slow to do SDR or much fancy processing without noticing) embedded boxes, again running on batteries, with speakers stripped, etc... cheers, --dr

p.s. let me tell you, ripping out _all_ the network stacks and ACPI and APM as well as anything resembling a network or serial driver (except USB kb and CD) is a painful and time consuming excercise, but at one point we were suspecting ACPI as a persistence method, so I took the time to do it. Not for the faint of heart if you haven't mucked around in obsd kernels before.
Anonymous

15 Posts

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