9 ms·
Title is misleading. This isn't generating Wi-Fi signals. It's generating non-Wi-Fi signals (i.e. effectively noise) in the Wi-Fi frequency bands, in a way that
by marcan_42 6y ago
Title is misleading. This isn't generating Wi-Fi signals. It's generating non-Wi-Fi signals (i.e. effectively noise) in the Wi-Fi frequency bands, in a way that encodes information and can be detected using existing Wi-Fi chipsets (e.g. measuring channel noise), as a very low bandwidth communications channel.
The bit rate with off the shelf Wi-Fi chipsets as receivers is ~10 bits per second.
This is definitely interesting and clever, but as a security researcher I will say I consider this particular research lab a bit of a paper mill. Their entire schtick is they pick any random emission from a computer that can be picked up remotely, and hype it up as an airgap-defeating measure. The thing is, once you accept that either 1) if your air-gapped computer has malware that can do this, you've already lost, or 2) if you need to be resilient to that, your "air gap" needs to be a sealed vault insulated from sound, EMI, and any other physical transmission medium, then this whole body of research becomes purely academic.
IIRC they've done LEDs, temperature, inductor noise, ultrasound, etc. When I first started looking into this I could come up with a good dozen of their ideas without looking. Of course all this stuff works. It's cute, it's clever, but it's not particularly obscure nor difficult to make work, and it all relies on having malware on the target machine to begin with. Yes, computers are noisy beasts, and you can encode information in the noise; we've known this for decades, picking a new technique and implementing it isn't particularly interesting after the fifth or sixth time.
Personally, I find their techniques primitive and boring. Like here, they set the RAM bus frequency to 2.4GHz (DDR-2400). Yes, of course, if you do that, then RAM traffic generates noise in the Wi-Fi band. Then they just used the most boring and trivial encoding possible on top of that. I don't remember ever reading one of their papers and thinking they'd used a clever technique. It always seems to be "pick a leak vector, then do the least amount of work possible to make it work at a few bits per second and get a paper out".
The interesting side channel papers are those where you can get information from emissions (e.g. crypto keys) without malware on the target computer, during normal operation. Those are real threats. And this is not what this group is researching.
- marcan_42 6y agoJust for my own amusement, I tried to come up with one he hasn't done. He's done HDD LEDs, screen brightness, switch LEDs, and keyboard LEDs (those are 4 independent papers). But he hasn't done camera LEDs! So: xxd -c 1 -p secret.txt | while read a; do for b in ${a:0:1} ${a:1:1}; do ffmpeg -y -f v4l2 -i /dev/video0 -t $((0x$b)) -f rawvideo /dev/null ; done; done That leaks a file via the camera LED, PWMing it at 4 bits per pulse (16 different pulse widths), tested on my iMac. Can I get a paper now? :-)
- isoprophlex 6y ago"Anonymous Reviewer 2" stipulates that you include twenty citations to papers written by a single lab before your paper can be accepted for publication :^)
- rrobukef 6y agoAnd at least one or two to his papers... Of course, he's anonymous!
- geckyrc 6y agoThis website is pretty cool sometimes.
- deleted 6y ago[deleted]
- im3w1l 6y agoYes maybe it's too many papers for too little material. But I do think even your the code you posted has some merit (even if not enough to stand alone).
- anfractuosity 6y agoHeh, I think the keyboard LED trick was mentioned in Cryptonomicon iirc. I created one that takes a mere 14 minutes to transmit 'hello' using a cd drive's movement: https://www.anfractuosity.com/projects/cditter/ https://www.anfractuosity.com/projects/cditter/
- studius 6y agoThe camera led is cool. That might work in a noisy environment, but it draws attention visually, which might not be great. Also, (1) users tend to cover their cameras with tape or post-its, (2) why would a super secure endpoint have a camera if it wouldn't be on the network, (3) slight chance of being noticed on external/detached security webcam.
- Phait 6y agoI went through the command trying to understand what you did and I realized I know nothing about using the CLI properly. So cool!
- yholio 6y agoI think that you are too harsh. I don't know their other papers but the fact that they demonstrate such a cheap way to break the airgap has real world implications. You don't have to be an international spy agency with custom hardware listening to side channel noise, anybody with a WiFi card and the right know how can do it. This is significant, killing the WiFi card on your device is not enough to deter exfiltration even by the least sophisticated attackers. Yes, the attack is unidirectional, but that is not without value. Time and time again, the airgap has been breached from the outside, from stuxnet to various cryptocurrency heists. Security is about layers and there are many applications where the gap must me breached bidirectionally - this is an example of breaching one of those layers, indeed, the weaker inside-to-outside layer. You might also intentionally run untrusted code on an airgap, that could report back information about the environment or tests you perform on it. So, yes, predictable and not a danger by itself, but not without value and possibly a key component of an elaborated real world attack.
- marcan_42 6y agoYou're mixing up two scenarios. The "international spy agency" scenario is using custom hardware listening to side channel noise from an untouched computer. That's stuff like decoding screen images from EMI from VGA/HDMI cables, or getting crypto keys from EMI from a CPU running standard code. That's what the whole TEMPEST thing was about decades ago. Those demos are interesting. We also use them in device security research, e.g. power or EMI analysis to extract crypto keys from a secure SoC. This guy just puts malware on the airgapped computer to force it to broadcast its secrets in the slowest, simplest, easiest to pick up way through some channel. That is not hard. His entire clickbait operation is basically predicated on the fact that people confuse these two scenarios, while they are two completely different things.
- giantg2 6y agoExactly. It's impressive when the computer is untouched and air gapped. If you can load malware on the PC, you might as well just extract/copy the data while you're in there.
- BlueTemplar 6y agoI don't see what is wrong with making "simple" proofs of concept - on the contrary, it makes it easier to build on them later !
- marcan_42 6y agoWhat I'm saying is it's not interesting research. It's not advancing science. I can stare at any given computer system, and come up with most of this guy's ideas in a few minutes, and implement them in a short time. It's extremely low effort. The papers aren't even good - his power leak paper uses a SparkFun current transformer connected to the audio line-in of a computer (doesn't get much lower tech than that) as a receiver, and made no attempt to actually trace the path the leaking signal takes, or use proper analysis equipment. I think he's wrong when he seems to imply it's a power consumption signal surviving backwards through the PSU (due to filtering); I think it's just EMI coupling across it to the power lines (he didn't analyze any of this, all he did was see the signal on the other end and everything about how it got there is an assumption presented as fact). If he'd at least implement some clever modulations then the papers would at least have value in researching how to cram more data into lossy side channels, but he's not doing that. All his modulations are textbook radio/modulation 101 stuff with very conservative parameters and no attempt to explore the actual theoretical limits of the channel bandwidth.
- 3pt14159 6y agoI also agree. I actually literally had this thought yesterday walking down the street and I'm far from a low level security researcher. Row hammer[0] is a real attack worth actual money to thousands of entities. This attack is literally one of the simplest imaginable and any computer that it would apply to would already have shielding. Had it gained true wifi access then yes, maybe worth a tiny amount of money if it were faster for the like 12 computers in an office whose sole protection is some snipped wires on an ethernet cable and incoming data on UDP. For any real actor that has to worry about this type of attack they already employ all sorts of measures to defeat it, including actual bunkers underground with a secret entrance in the cow fields. [0] https://en.wikipedia.org/wiki/Row_hammer https://en.wikipedia.org/wiki/Row_hammer
- studius 6y ago> The interesting side channel papers are those where you can get information from emissions (e.g. crypto keys) without malware on the target computer, during normal operation. What about using GSM on cell phones to steal data? (2015): https://www.sciencedaily.com/releases/2015/07/150728123634.htm https://www.sciencedaily.com/releases/2015/07/150728123634.h... Also, here's a nifty resource for exfiltration; leakage through DNS would seem like a big one after any airgap is bridged: https://github.com/rmusser01/Infosec_Reference/blob/master/Draft/Exfiltration.md https://github.com/rmusser01/Infosec_Reference/blob/master/D... Or maybe you could use one of NYU's robotic geese to insert a USB key into an airgap'd PC and have it use it's webbed foot to hold lower keys down then peck type a command to copy files.
- marcan_42 6y agoThat GSM one is.... exactly the same as this attack. Literally. DDR3-1600 RAM, 800MHz I/O bus, 800MHz GSM frequencies. Pump out data encoded in bursts of noise by exercising RAM. Receive it with a hacked phone. They built on all the work of OsmocomBB (which already is a completely open source GSM stack on a commercial phone baseband). Even building on such a powerful and well-documented platform, they only got a, quite honestly, pathetic ~1.5 bit/second speed out of it, making excuses about "inadequate access to the DSP's full capabilities" and it being an old phone (which is nonsense, the entire point is that it's an open stack, thus much easier to build powerful software on even with hardware limitations, they just weren't capable). Then they gave up on OsmocomBB and just used an SDR as a receiver to get 1kbps. Sorry, this is just sad. Anyone actually experienced in these fields would be able to do orders of magnitude better, guaranteed, with that kind of hardware. Oh yeah, there's an appendix to the paper where they got it to work with an unmodified Android phone... by putting it 10cm from the motherboard, so the emission jams the cell signal, and you see the bars drop. No actual bitrate attempted, but it looks like you wouldn't get more than 0.5bps out of that from their graph. And now 5 years later he's rehashing the same exact technique, on a different frequency. Sigh.
- ChrisLomont 6y ago>Those are real threats. And this is not what this group is researching. Also as a security researcher, this type of research is a real threat. Lots of DoD practice works on knowing exactly how outside and inside threats can exfiltrate data. If a secret facility had locked down networks, and ensured no insider could carry out CDs, but completely ignored threats like this, then insiders (and any outsider that gets something onto such a network) can exfiltrate data without detection. There's a reason DoD pays lots of groups to do work like this. He even mentions that common DoD practice of leaving phones outside secure facilities is not enough to prevent data from escaping (although some places I've been, but not all, have been smarter in putting phones in Faraday cages to lessen the issue). As they say, attacks don't get weaker, they only get stronger. Apply some proper modulation and signal processing, even with a custom receiver and antenna, and you can likely extract data at vastly faster rates, and, for some processes, perhaps even without on device malware.
- marcan_42 6y agoYes, this threat is real, but it's not useful to spread it out across two dozen papers. You can cover most of these techniques in a single paper. Once you realize that any light/sound/RF channel can be abused, you either accept you are vulnerable to this attack, or you make your airgap involve a Faraday cage, thick walls, and generator power or extreme power filtering (e.g. through batteries to strictly reduce the bandwidth of the power usage channel). There isn't much more to it. His techniques are not something you block individually. You block entire classes. Block light, there goes all the LEDs. Block sound/vibration, there goes the fan/coil whine stuff. Insulate thermally, that takes care of that. Faraday cage, bye bye RF. Etc. Either you care about this entire class of channels, and you do all of those things, or you don't, and your air gap just means no Ethernet cable between two adjacent computers. The specific details of each of his attacks are not useful. They do not contribute to the state of the art in any way. It's just pumping out papers. Indeed, if advanced modulation and processing were used, that would be useful research. That would be science, measuring the true information-carrying capacity of these approaches. But he's not doing that. At all. Not even trying.
- ChrisLomont 6y ago
- Scoundreller 6y agoHaving said all that, I think an iPod « undumpable » firmware or ROM was first dumped through the “click” thingy in a soundproof box over many hours.
- marcan_42 6y agoNothing is truly "undumpable", but generally "undumpable" means "you can't get code execution with read access" which is not the case here. This is just a case of using the simplest possible output peripheral you can find before you can get anything else running. Canon camera firmwares have been dumped via blinking the LEDs. I've debugged low-level bringup by blinking codes out of LEDs too. This has nothing to do with side channels, it's just a case of not having documentation for the hardware so you find the first thing that gives any feedback and use it to dump the rest of the firmware so you can reverse engineer it and figure out how e.g. the screen works.
- pletsch 6y agoHey, I just started as a security researcher working with mobile devices. Would you have any recommendations for labs I could follow?
- lemonspat 6y ago> non-Wi-Fi signals (i.e. effectively noise) in the Wi-Fi frequency bands, Wasnt that exactly the side channel that was feared from badBIOS? Dunno if it was WiFi bands as I dont see anyone confirmed it, so may be a diff frequency
- marcan_42 6y agoA lot of side channels along these lines were feared from BadBIOS (ultrasound was another one). But the whole BadBIOS thing was a lot of hypothesizing started by one security researcher with psychological issues (at the time). Lots of ideas about what could be done, but not a single shred of evidence that anything was actually being done. (He briefly relapsed a few years later saying his Raspberry Pis had been loaded with implanted Ethernet jacks, and I had to spend some time teaching him about what Ethernet magnetics are... I hope I helped calm him down a bit that time)
- giantg2 6y agoYeah, the interesting attack vectors for side channel signals are ones that don't require malware. Reading data emitted by knowing the target machine's hardware and software is a little more realistic, but still difficult. I remember seeing a demo of someone using an SDR (AM band or close to it) to read emissions from Word's spell check on a laptop in the same room. If I remember correctly, AWS identified a side channel vulnerabily a year or so ago and had to make some updates. I forget the mechanism, but I think it had to do with VMs on the same hardware being able to access statistics (voltages or power consumption) on the hardware usage that would allow an attacker to access sensitive data, or leak data between the VMs. I don't think any attack actuallly used that mechanism before they patched it though.
- deleted 6y ago[deleted]
- badrabbit 6y ago> 1) if your air-gapped computer has malware that can do this, you've already lost Ughh...no? Delivering malware to airgapped computers is not the difficult task. If you have sophisticated persistent attackers then they will figure out how you get data in/out of that system and find a way to execute code on it. "At this stage you have bigger problems" is a terrible thing to say especially by a security researcher. You know why there is always a plethora of unpatched systems in corporate networks you can move laterally to? Because IT admins have the same mindset "if we have hackers in the network, we have bigger problems to worry about". Real attacks against airgapped systems exist and are documented, research that assumes initial access and execution on airgapped systems to focus on hardening against C2/exfil channel establishment is very useful in my opinion. > 2) if you need to be resilient to that, your "air gap" needs to be a sealed vault insulated from sound, EMI, and any other physical transmission medium, then this whole body of research becomes purely academic. Academic or not, research like this helps people that actually need airgapped systems with threat modeling. Knowing what is possible is critical when evaluating what possible attackers might do to attack a system. 10bits/second sucks but it is usable for attackers and just like crypto attacks this can be improved over time.
- deleted 6y ago[deleted]
- nabla9 6y agoGetting malware into air-gapped computers is order of magnitude easier than getting information out.
- fulldecent2 6y agoJust chiming in to note that "1) if your air-gapped computer has malware that can do this, you've already lost" is a problem specific to this implementation. Other implementations exist (related work, not in 2.4G band) where it is not necessary to install malware to make measurable transmissions. For example (shilling) https://fulldecent.github.io/system-bus-radio/ https://fulldecent.github.io/system-bus-radio/ allows to broadcast just by loading a web page. And, importantly, this is an attack vector that is reasonable to execute offline (i.e. connected to a local network with HTTP services, but not the internet).