Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Happy Halloween: The Ghost Really May Be In The Machine SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
Happy Halloween: The Ghost Really May Be In The Machine
You could put this sort of thing into a table, to correlate the minimum set of ingredients that can result in an infected system:
hardware | ever networked? | flashed? | pre-installed OS? | peripherals plugged in | media used | software used to test

Probably asset tags are needed for all hardware and media or this could get confusing very quickly. And a log of their history (what it has been plugged into, or what was plugged into it).
Steven C.

171 Posts
it was a stripped down openbsd (amd system E2-1800) like this that was infected by plugging in a USB key(adata s102 series) into it (drive unrecognized, no message on syslog/console - previosuly "bricked"), back into infected and networked Sony Vaio S (drive mysteriously fixes itself and shows up on desktop), then back into forensics openbsd PC, _never_mounted_ (now the drive is recognized and a message shows up in dmesg/syslog/console). Forensics system rebooted, and shows signs of infection, including variant sections on disk depending on read start location (disk seagate momentus 7200.2 500gb ST9500420ASG), refuse to boot from CD teltale (American Megatrends bios ver 4.6.5.3 project A261PA 13 x64).

cheers, --dr
Steven C.
15 Posts
it was a stripped down openbsd system like this that was infected by plugging in a USB key into it (drive unrecognized, no message on syslog/console - previosuly "bricked"), back into infected and networked Sony Vaio S (drive mysteriously fixes itself and shows up on desktop), then back into forensics openbsd PC, _never_mounted_ (now the drive is recognized and a message shows up in dmesg/syslog/console). Forensics system rebooted, and shows signs of infection, including variant sections on disk depending on read start location, refuse to boot from CD teltale.

cheers, --dr
Steven C.
15 Posts
Programmable firmware certainly hides everywhere, not just BIOS. Indeed on USB sticks, which seems to be the case here (I've seen those which can have two resizable LUNs to store read-only or potentially hidden data). And even in optical drives (and that may explain why it fails to boot media properly after infection - I wonder if the drive's firmware 'hooks' at all during boot, even when not booting from that drive specifically).
Steven C.

171 Posts
I would want to test infection on older hardware, perhaps trying a 1yr old system, 2yr old, 4yr old which would eventually narrow down to specific BIOSes and hardware and chipsets involved. Also testing the effect of a suspected bad USB stick on another CPU architecture, such as OpenBSD on SPARC or Loongson would be interesting; the code of OpenBSD's USB stack is probably the same, so an exploit should have some effect on that, except the payload should be unable to work and may give visible clues.

it goes without saying to try different OSes. Even different OS versions - starting from the oldest version that works on your hardware - older versions of OpenBSD might not have added support yet for whatever the exploit vector might be.
Steven C.

171 Posts
p.s. have you tried swapping hardware components around to see how you can transfer infection between two machines? Particularly BIOS chips if removable, maybe the optical drives, and anything else which might contain writeable memory.
Steven C.

171 Posts
You mentioned using a USB keyboard. Even BIOS interacts with that before the OS does. Something like this could be a potential infection vector and command/control if it contains any goodies; a USB device isn't limited to emulating a keyboard but can attack the whole USB stack. A two-way communications sidechannel would allow to monitor you, restrict certain key input, and possibly launch new targetted exploits on-the-fly.
Steven C.

171 Posts
The audio aspect of this putative air-gap communication intrigues me. If it's genuinely occurring then we need a spot of House, MD brainstorming to come up with candidates for vectors.

Some years ago an inventor by the name of Woody Norris (Google him and check out his credentials, specifically the references to LRAD, and also check related technologies such as that found at holosonics.com) reasoned that combining two ultrahigh frequency audio signals could produce a third, human-audible, signal. He tested and confirmed his ideas, and discovered some interesting properties.

One is that the third signal is narrowly-focused and highly directional - it's possible to pick out an individual in a crowd, target them with a transmission, and make them feel as though the sound is originating from within their head. None of the people around them hear a thing.

Another is that the third signal is resistant to interference by ambient noise - one of Woody's demos involved talking to someone across a busy freeway.

Assuming that there really is some level of audio communication going on here - and there would obviously need to be at least some kind of minimal bootstrap code already installed on the receiving system(s) together with an operational microphone AND an audio facility on the transmitting machine capable of producing very high frequency sound, (and the list of constraints goes on and on), it could theoretically be possible to transmit a focused audio signal even in a very noisy environment in a way that might not necessarily be immediately evident to anyone standing nearby.

I'm not an expert (far from it) - just juggling a few not very well developed ideas here - and I don't know how reflection impacts the third signal but it might allow a kind of ricochet effect such that even if a potential receiving machine was not directly within the field of the original broadcast it might still receive enough of the transmission to be able to accept data. Think of aiming the TV remote over your shoulder and having the signal bounce off suitably reflective surfaces and end up controlling the TV in front of you.

Occam's razor dictates that this suggestion should be tossed out on the grounds that it's unduly complicated - but then Stuxnet relied completely on an awfully long shot to get around air gaps and look how that turned out.
Ancient Brit

2 Posts
It should be disputed because the method of investigation doesn't seem up to the task of studying something as sophisticated as what is being claimed here. Running tools on the infected (Windows) system, and seeing odd results in the networking stack, should not imply there is an SDR or out-of-band audio communications happening. Right now they are looking at 'suspicious' HF on audio spectrograms which could be easily enough explained by the switch-mode power supplies or inverters often used in laptops and to power displays. Using a 'control' in the experiment (testing in a quiet place, and comparing an uninfected reference system) might have trivially confirmed that.
Steven C.

171 Posts
@Steven C: If I've understood the reports correctly, the only point at which changes stopped occurring was when the microphone and speaker hardware was disconnected. That could be a simple coincidence, obviously, but it doesn't preclude the possibility of audio comms IMHO.
Ancient Brit

2 Posts
we also used separate usb keyboards. Audio recordings at 96k 24bits have identified HF bit stream signals (at 20.5 kHz, 35KHz, and 39.5-40.5 kHz) that are present in some recordings and not others (which rules out them being recording equipment artifacts). I'm just going over my colleague's analysis of the recordings. We'll post the recordings for others to analyze - maybe they can demodulate the signals themselves and gain more info.

We know air-gapped access was going on becuase of software configuration and dynamic reaction to our changes on the systems was going on, it's just a matter of identifying HOW they were gaining access not IF.

The good news is that it seems to be confirmed to be HF audio now, not the more dangerous SDR possibility. BTW Related: i just invited some folks from Argentina who have a X86 SDR communications prototype to present at CanSecWest next year, so we aren't exactly safe there yet either, unfortunately. Here is a demo video of their prototype which uses PCB LED traces as antennae: http://goo.gl/P1Eh0A

My analysis is focusing on the USB and disk data now. This thing is far too complex to live in firmware alone, and firmware is hard. I'm working to provide firmware samples to others who are knowledgeable and reputable and have volunteered to analyze.

cheers,
--dr
Ancient Brit
15 Posts
we also used separate usb keyboards. Audio recordings at 96k 24bits have identified HF bit stream signals (at 20.5 kHz, 35KHz, and 39.5-40.5 kHz) that are present in some recordings and not others (which rules out them being recording equipment artifacts). I'm just going over my colleague's analysis of the recordings. We'll post the recordings for others to analyze - maybe they can demodulate the signals themselves and gain more info.

We know air-gapped access was going on becuase of software configuration and dynamic reaction to our changes on the systems was going on, it's just a matter of identifying HOW they were gaining access not IF.

The good news is that it seems to be confirmed to be HF audio now, not the more dangerous SDR possibility. BTW Related: i just invited some folks from Argentina who have a X86 SDR communications prototype to present at CanSecWest next year, so we aren't exactly safe there yet either, unfortunately. Here is a demo video of their prototype which uses PCB LED traces as antennae: http://goo.gl/P1Eh0A

My analysis is focusing on the USB and disk data now. This thing is far too complex to live in firmware alone, and firmware is hard. I'm working to provide firmware samples to others who are knowledgeable and reputable and have volunteered to analyze.

cheers,
--dr
Ancient Brit
15 Posts
we also used separate usb keyboards. Audio recordings at 96k 24bits have identified HF bit stream signals (at 20.5 kHz, 35KHz, and 39.5-40.5 kHz) that are present in some recordings and not others (which rules out them being recording equipment artifacts). I'm just going over my colleague's analysis of the recordings. We'll post the recordings for others to analyze - maybe they can demodulate the signals themselves and gain more info.

We know air-gapped access was going on becuase of software configuration and dynamic reaction to our changes on the systems was going on, it's just a matter of identifying HOW they were gaining access not IF.

The good news is that it seems to be confirmed to be HF audio now, not the more dangerous SDR possibility. BTW Related: i just invited some folks from Argentina who have a X86 SDR communications prototype to present at CanSecWest next year, so we aren't exactly safe there yet either, unfortunately. Here is a demo video of their prototype which uses PCB LED traces as antennae: http://goo.gl/P1Eh0A

My analysis is focusing on the USB and disk data now. This thing is far too complex to live in firmware alone, and firmware is hard. I'm working to provide firmware samples to others who are knowledgeable and reputable and have volunteered to analyze.

cheers,
--dr
Ancient Brit
15 Posts
we also used separate usb keyboards. Audio recordings at 96k 24bits have identified HF bit stream signals (at 20.5 kHz, 35KHz, and 39.5-40.5 kHz) that are present in some recordings and not others (which rules out them being recording equipment artifacts). I'm just going over my colleague's analysis of the recordings. We'll post the recordings for others to analyze - maybe they can demodulate the signals themselves and gain more info.

We know air-gapped access was going on becuase of software configuration and dynamic reaction to our changes on the systems was going on, it's just a matter of identifying HOW they were gaining access not IF.

The good news is that it seems to be confirmed to be HF audio now, not the more dangerous SDR possibility. BTW Related: i just invited some folks from Argentina who have a X86 SDR communications prototype to present at CanSecWest next year, so we aren't exactly safe there yet either, unfortunately. Here is a demo video of their prototype which uses PCB LED traces as antennae: http://goo.gl/P1Eh0A

My analysis is focusing on the USB and disk data now. This thing is far too complex to live in firmware alone, and firmware is hard. I'm working to provide firmware samples to others who are knowledgeable and reputable and have volunteered to analyze.

cheers,
--dr
Ancient Brit
15 Posts
I feel like I am missing something. Where is the independent confirmation of any of these things? DR mentions some colleagues in a post above, but I couldn't find any mention of who these colleagues might be or what they might have to say about it. Dan Goodin said in a comment over at Ars that no independent confirmation exists, after 3 years of research. I think anyone can understand how, looked at in this way, some skepticism might be in order.
jbmartin6

20 Posts
Quoting jbmartin6:I feel like I am missing something. Where is the independent confirmation of any of these things? DR mentions some colleagues in a post above, but I couldn't find any mention of who these colleagues might be or what they might have to say about it. Dan Goodin said in a comment over at Ars that no independent confirmation exists, after 3 years of research. I think anyone can understand how, looked at in this way, some skepticism might be in order.


You should read other comments before posting: Dragos has releasted one Gig of files; They really exist, the link http://goo.gl/3pQbeZ is
https://mega.co.nz/#!5Rpn3JyC!SEb5vB_KofcMl-vBKMS_j3RBdFlj0ROmFmKt8huNdNk
Here is the original quote from Dragos:

Quoting Anonymous: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
Example file names in that archive:
kit/WinSxS/amd64_microsoft-windows-audio-dsound.resources_31bf3856ad364e35_6.2.9200.16384_en-us_b4c413b0e7135612/dsound.dll.mui.Z
kit/WinSxS/amd64_microsoft-windows-a..bility-ui-recording_31bf3856ad364e35_6.2.9200.16384_none_200c99c61e0ac9f1/uireng.dll.Z
kit/WinSxS/amd64_microsoft-windows-a..roblemstepsrecorder_31bf3856ad364e35_6.2.9200.16384_none_33bb3890d4bdf8e5/psr.exe.Z
kit/WinSxS/amd64_microsoft-windows-a..roblemstepsrecorder_31bf3856ad364e35_6.2.9200.16384_none_33bb3890d4bdf8e5/Steps Recorder.lnk.Z
kit/WinSxS/amd64_microsoft-windows-a..srecorder.resources_31bf3856ad364e35_6.2.9200.16384_en-us_269e753f13515c86/psr.exe.mui.Z
Anonymous
Anonymous, I did read the other postings. You failed to understand mine. I saw the link to uploaded files, what I didn't, and still don't, see is anyone else besides DR saying "yes I looked at these and they do exhibit the behavior he describes" Or even some basic static analysis of the files in question. Yes, I understand that I could do that work myself. My point was that after three years I find it very suspicious that this work hasn't been done and published already.

http://arstechnica.com/security/2013/11/researcher-skepticism-grows-over-badbios-malware-claims/
jbmartin6

20 Posts

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