TR Forums

http://arstechnica.com/security/2013/10 ... s-airgaps/

Money graf:

Ars wrote:

Ruiu said he arrived at the theory about badBIOS's high-frequency networking capability after observing encrypted data packets being sent to and from an infected laptop that had no obvious network connection with—but was in close proximity to—another badBIOS-infected computer. The packets were transmitted even when the laptop had its Wi-Fi and Bluetooth cards removed. Ruiu also disconnected the machine's power cord so it ran only on battery to rule out the possibility that it was receiving signals over the electrical connection. Even then, forensic tools showed the packets continued to flow over the airgapped machine. Then, when Ruiu removed the internal speaker and microphone connected to the airgapped machine, the packets suddenly stopped.

Using the speaker and microphone to pass packets using ultrasonic frequencies. Do we need to add bats to our list of malware detection tools?

Captain Ned wrote:

http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/

Money graf:

Ars wrote:

Ruiu said he arrived at the theory about badBIOS's high-frequency networking capability after observing encrypted data packets being sent to and from an infected laptop that had no obvious network connection with—but was in close proximity to—another badBIOS-infected computer. The packets were transmitted even when the laptop had its Wi-Fi and Bluetooth cards removed. Ruiu also disconnected the machine's power cord so it ran only on battery to rule out the possibility that it was receiving signals over the electrical connection. Even then, forensic tools showed the packets continued to flow over the airgapped machine. Then, when Ruiu removed the internal speaker and microphone connected to the airgapped machine, the packets suddenly stopped.

Using the speaker and microphone to pass packets using ultrasonic frequencies. Do we need to add bats to our list of malware detection tools?

LOL... not as of yet.

(1) to spread via sound there needs to be a DSP on the receiving side .. soo the phone or other device needs to 'already' be infected with a component of the threat.
(2) despite the original reporters credentials... no-one has found absolute proof that this threat is real. we do not have any files, no sound captures, no network icaps..
(3) if this is a bios thing.. well everyone involved is being pretty dumb.. al they need to do is read the bios with a dumper.. desolder the bios. plug in to a programmer and dump the chip just like mame/eproms etc..

so.. while it is a neat claim... not buying it.

Interesting read, but I'm starting to lean towards this being a hoax.

http://www.rootwyrm.com/2013/11/the-bad ... -is-wrong/ <-- I don't agree with all (or even most) points made here, but the author does make one good point - if there is a BIOS component to this, then at least that component should be easily analyzed.

The only reason I posted it is because the guy involved has impeccable credentials in the biz.

Captain Ned wrote:

The only reason I posted it is because the guy involved has impeccable credentials in the biz.

QFT. And there are other well-respected researchers who haven't dismissed it as a hoax. It will be interesting to follow.

Yup. Been following this since the article came out. My office mate pointed out that if it is real, then it represents a pretty serious compromise of the UEFI BIOS security framework. The more complicated stuff gets, the easier it is to hide something nefarious in plain sight.

just brew it! wrote:

Yup. Been following this since the article came out. My office mate pointed out that if it is real, then it represents a pretty serious compromise of the UEFI BIOS security framework. The more complicated stuff gets, the easier it is to hide something nefarious in plain sight.

To quote a certain engineer of Scottish ancestry: "The more they overthink the plumbing, the easier it is to stop up the drain".

just brew it! wrote:

Yup. Been following this since the article came out. My office mate pointed out that if it is real, then it represents a pretty serious compromise of the UEFI BIOS security framework. The more complicated stuff gets, the easier it is to hide something nefarious in plain sight.

I'm reminded of Ken Thompson's classic 1984 Turning Award speech (prettier PDF version).

I have to wonder if someone's yanking this guy's chain, malware this virulent ought to be showing up all over the place. OTOH since he's not really sure what the payload might be perhaps he simply got lucky.

NovusBogus wrote:

I have to wonder if someone's yanking this guy's chain, malware this virulent ought to be showing up all over the place. OTOH since he's not really sure what the payload might be perhaps he simply got lucky.

Assuming this is real, it's actually a pretty clever method of attack and it's almost certainly aimed at government.

It's very common in government facilities to have dual networks - one for classified information, that is generally walled off (or at least, tightly protected) from the outside, and one for non-classified that connects to the internet. As long as you could infect at least one machine on the classified network, and at least one on the open network, you'd have a pretty decent backdoor. Security for these places is based around the notion that you need a physical network connection or a physical device (USB for example) to even touch the classified network; but with this, you just have to be within range of a speaker.

Interesting attack vector that it own set of issues and counters (slap an ultrasonic speaker and broadcast it with tons of useless noise so it will drown out any invasive source) .

Yeah, I think that they have found an interesting UEFI rootkit but the whole bit about the "ultrasonic communication" is a red herring. If this really is a sophisticated UEFI type of attack vector, then I think some of the so-called "self-healing" properties that this guy is observing are really related to the fact that this malware is loaded into a flash memory on the motherboard itself where even wiping out the OS and starting from a completely clean install isn't a guarantee of stopping the attack vector. It might even be persistent enough that a UEFI firmware update doesn't quite wipe it out of the NVRAM on the motherboard. It sounds very devious, but I'm not buying the whole ultrasonic thing without quite a bit more evidence.

If it's real, it definitely yells cyberwarfare even louder than Stuxnet. It's quite possible this guy was targeted to see if he would detect and counter it. If I wanted to blind a nuclear state in the opening moves of WW3 I wouldn't want to find out the hard way that, oops, they already know about it and have a stinger at the ready.

Even if it was a hoax... as one of the other experts pointed out he himself could write something with all of these capabilities if given a year to work on it. So best case, even if this was a hoax then it's just a matter of time before someone does write it and put all these individual, proven pieces together into one sophisticated package. And once that malware gets out, people will begin selling, copying and modifying it to make their own versions of it.

So I consider it to be a rather scary article indeed, because even if it's not here yet it will be eventually.

Not sure why people are so skeptical of the sonic data transfer - this has been around for a while... One current example is http://petapixel.com/2013/09/17/chirp-lets-send-photos-device-device-using-sound-bites/

And it's not exactly new technology. As long as the hardware is capable of generating and receiving the frequency, the fact that it's outside the range of human hearing isn't going to change anything.

chuckula wrote:

Yeah, I think that they have found an interesting UEFI rootkit but the whole bit about the "ultrasonic communication" is a red herring. If this really is a sophisticated UEFI type of attack vector, then I think some of the so-called "self-healing" properties that this guy is observing are really related to the fact that this malware is loaded into a flash memory on the motherboard itself where even wiping out the OS and starting from a completely clean install isn't a guarantee of stopping the attack vector. It might even be persistent enough that a UEFI firmware update doesn't quite wipe it out of the NVRAM on the motherboard. It sounds very devious, but I'm not buying the whole ultrasonic thing without quite a bit more evidence.

Indeed, and all they need to do is dump the bios prom to find it...

maxxcool wrote:

Indeed, and all they need to do is dump the bios prom to find it...

Not if the binary was generated ala Ken Thompson.

Some of this method is already commercialized for consumer mobiles aka Chirp on iOS

Update:

It's been proven:

http://www.slate.com/blogs/future_tense ... r_gap.html

Link to actual paper:

http://www.jocm.us/uploadfile/2013/1125 ... 803901.pdf

EDIT: Vector has been proven, not the specific malware from my OP.

Important distinction: It has been proven that malware that jumps airgaps via ultrasonic comms is feasible. AFAIK it still has not been proven that the original report of a virus "in the wild" with this capability was accurate.

just brew it! wrote:

Important distinction: It has been proven that malware that jumps airgaps via ultrasonic comms is feasible. AFAIK it still has not been proven that the original report of a virus "in the wild" with this capability was accurate.

Yep, should have clarified. My bad. Post edited.

Steve Gibson tweeted this analysis by RootWyrm which points out a pretty gaping hole in the story: speakers only work well within the audible frequency range, microphones similarly, if they're communicating (which he says the BIOS can't do as it's never connected to a microphone) people will hear it. I can't attest to everything else that he says but that certainly puts the kibosh on the whole high frequency communication theory.

puppetworx wrote:

Steve Gibson tweeted this analysis by RootWyrm which points out a pretty gaping hole in the story: speakers only work well within the audible frequency range, microphones similarly, if they're communicating (which he says the BIOS can't do as it's never connected to a microphone) people will hear it. I can't attest to everything else that he says but that certainly puts the kibosh on the whole high frequency communication theory.

The "proof" article was using frequencies between 16Khz and 20Khz on consumer-grade boxen. Data rate was slow, but not zero.

I mostly agree with Gibson's analysis. But I think the portability issue carries much more weight than the "computer mics and speakers can't handle ultrasonic frequencies" argument.

Sure, the frequency response of electromechanical transducers designed for audio frequencies will fall off once you get beyond the audible range, but it doesn't instantly go to zero. For purposes of transmitting data surreptitiously you don't have to be that far outside audio frequencies; you just need to be far enough that most people are unlikely to hear it. And even if someone does hear it, they'll probably assume it is just inductor whine or a dying fan.

Mic inputs on most sound cards have a "gain boost" feature that could be used to bring the signal up to usable levels; e.g. the Realtek ALC892 has a switchable 0/10/20/30 dB preamp on the mic input. If you don't understand how decibels work, 30 dB of gain is a *lot* -- it is a factor of 1000! Bump your sampling rate to 96 kHz (or more), enable the 30 dB boost, and I think you could easily get a usable signal at (say) 30 kHz even with cheap computer speakers and mic. This is assuming, of course, that your onboard audio's ADCs don't have a fixed "brick wall" analog filter at 20 kHz to prevent Nyquist aliasing at the default 44.1 kHz sample rate... but hey, I've heard that a lot of motherboards skip the input filtering entirely to save cost; that would actually work to our advantage in this case!

Edit:

Captain Ned wrote:

The "proof" article was using frequencies between 16Khz and 20Khz on consumer-grade boxen. Data rate was slow, but not zero.

At 16 kHz many people would still be able to hear it. I used to be able to hear the ~16 kHz "flyback whine" of CRT-based TVs (not any more though). But 16 kHz would also be well within the working frequency range of many computer mics, so you could probably transmit at a fairly low level, making it less noticeable. With decent DSP algorithms data rates in the low 1000s of bps are not at all far-feched.

I just read the "proof" paper, it actually mentions the experimenters hearing clicking sounds but passes it off as something that could be programmed out. The trouble with that is that it's a very subjective thing - age, DNA, etc. will all make a difference, you can't program inaudible communication at that frequency out for everyone because for most people it is audible - speakers and microphones are afterall tuned to work at the most audible levels.

puppetworx wrote:

I just read the "proof" paper, it actually mentions the experimenters hearing clicking sounds but passes it off as something that could be programmed out. The trouble with that is that it's a very subjective thing - age, DNA, etc. will all make a difference, you can't program inaudible communication at that frequency out for everyone because for most people it is audible - speakers and microphones are afterall tuned to work at the most audible levels.

It may be audible in some cases, but a lot of people will mistake it for something else. Most people won't automatically think "that's the sound of someone stealing my data".

As I noted in my previous post, I also think it should be possible to work outside the audible range (above 20 kHz), which would make detection more difficult.

Very interesting, can't wait to start reading the linked paper.

I will say now that Dragos Ruiu jumped the shark and is embellishing. Why? Because this is the internet and I can make any claim I want to

*edit* So I guess we'll need to do a weekly scan with a specially trained dog, I wonder how much Symantec is going to charge for that add-on.

You're right they could still do that but it would be very hardware dependent. You'd have to ping (and listen) at different frequencies and loudness until you get a response back otherwise because unless you know what the specific capabilities of the audio chip, speakers and microphone on your laptop and the other laptop's that's the only way to do it.

In the paper they used the exact same models and point out the differences of other models. I can see it working (and getting away with it) on a couple of different models, but between every computer? Far less likely.

Also I just noticed somebody else posted the link I did a few weeks ago, oops!

Going off on a tangent here, I think the common corporate IT practice of requiring identical (or similar) PCs for everyone with a common system image is detrimental to security. It's analogous to crop monoculture. By making everything the same, you ensure that everything is vulnerable to the exact same threats, making rapid spread of an infection more likely.

just brew it! wrote:

Going off on a tangent here, I think the common corporate IT practice of requiring identical (or similar) PCs for everyone with a common system image is detrimental to security. It's analogous to crop monoculture. By making everything the same, you ensure that everything is vulnerable to the exact same threats, making rapid spread of an infection more likely.

I'm not sure how many still adhere to this. Having identical systems for deployment's sake is a really a thing of the past, even the free stuff handles different platforms without a problem. You still have your central image, it just pulls the necessary drivers from the repository.

Now, obviously some companies buy in batches, but even then it seems like it's still "batches". With the way the major OEMs seem to discontinue and change their models so frequently you can have a different system even months apart. I'm sure there are still places out there that replace everything in one go but it's been a while since I've seen it. Guess it depends on the size too.