LANtenna attack reveals Ethernet cable traffic contents | Hacker News Reader

LANtenna attack reveals Ethernet cable traffic contents

theregister.com

59 pointsrcarmo19 comments

Oh god, this guy again. The title is misleading clickbait, as is the case with every recent article about his papers.

This isn't revealing "Ethernet cable traffic contents". This is using crafted data over the wire to produce specific measurable (low bandwidth) RF emissions that can be picked up externally. It's obvious that this would work, and doing a proof of concept is a weekend project for anyone with an SDR.

Just like that "RAM as WiFi transmitter" (not really WiFi, just radio noise) and the previous one with GSM (same story) and all his other covert channel papers, this is completely boring stuff that requires malware on the sending side to leak data. His papers are superficial and he never attempts to measure maximum practical channel bandwidths, or do any other useful science. He's literally getting hundreds of times lower bandwidth than what would be theoretically possible with his approaches, because he doesn't actually know how to use proper encoding schemes or optimize his receiver/demodulator. It's all extremely low effort.

Every time he just comes up with a random idea of "something that can be measured externally from a computer", from spurious radio emissions to temperature to LEDs, then makes the minimum viable PoC to encode data over it and measure it externally, and cranks out a paper. Every single time. He's running a paper mill, nothing more. None of this is useful research, anyone can come up with his ideas and test them in a few hours. And he's really good at getting a news cycle out of it through misleading clickbait titles; he's really taken a liking to that recently.

All this air-gap jumping nonsense he describes only applies if you already have malware inside your air-gap. And if you do, well, the only way you're going to be able to stop leakage is to put the tainted computer in a concrete bunker surrounded by a Faraday cage and running off of isolated batteries. This isn't news.

FWIW, his clickbait theme was one of the things that inspired me to release https://M1RACLES.com the way I did. It's sad seeing real infosec issues getting mixed in with irrelevant clickbaited stuff that nobody cares about. And it works; a whole bunch of news sites didn't even bother to read past the first page of that site....

Maybe he's looking for a US O-1 VISA, eg, showing extraordinary this and that. One of the qualifying points is published stuff.

I see sooooo many blogs from India, and this may be another reason why. Publish.

This sounds so correct. I feel stupid for not having connected the dots before.

Yeah, but it's not that he is acting wrong, he is just one particular example out of millions. It's the scientific system as a whole that has gone wrong. We have to find ways to fix it in such a way that it doesn't force researchers to crank out a massive amount of low quality publications.

I thought the idea was to get data out/transmit out of an "infected" computer when it has no public network access: and not actually sniffing normal traffic. so it assumes a compromised air-gapped computer, is that not a concern of infosec? is that a purely theoretical scenario that won't happen ? why?

If you're at the level where that is a concern, you should be putting your air-gapped computers inside a bunker. This should be obvious to anyone doing threat modeling at this level.

It is clear that there are a myriad ways of modulating data in environmental emissions out of a computer; we don't need a new paper from this guy for every single light, RF, sound, and heat emitting component in a computer. We know. I can come up with as many of these as you want. Last time I talked about this I came up with a dozen or so, and after checking he'd done them all, except one: the camera LED. So I wrote a 5-minute tweet-sized PoC to modulate data using the camera LED. That would've been on par with his papers.

If he actually did real science e.g. trying to estimate maximum theoretical data transfer rates with these techniques then his research would be valuable, but he isn't. He's just doing minimal proofs of concept. We all know these things work. Tempest for Eliza has been around for 20 years now and was a cooler demo than anything this guy has put out [1].

[1] http://www.erikyyy.de/tempest/

This feels like one of those obvious-in-hindsight things. Of course an unshielded conductor would radiate RF correlating with the signal it carries, and if you could pick up the radiated RF, and knew the modulation scheme and how do decode it, you could see what was on the wire.

I do find myself wondering some things though.

Ethernet cables are 4 differential pairs. As I understand, the whole idea of these twisted pairs carrying a differential signal is that any RF the cable picked up from the environment would be common-mode, and get cancelled out receiver side, allowing the transmitted signal to arrive unspoiled. So, in theory, one would have a hard time injecting spurious transmissions into an Ethernet cable via RF.

Is this supposed to work in reverse, where the common-mode rejection of a differential pair would prevent RF from leaking out of the cable? Or is this one of those theory vs. practice things, where in theory, it shouldn't, but in practice, being a not-ideal twisted differential pair (e.g. twist rate is wrong for frequency of interest, untwisted section, conductors of slightly different lengths, etc) allows some RF emission to leak out, uncancelled. And in the case of a cheap cable, something claiming to be Cat 6A in actuality might never have passed spec for Cat 5, and thus leaks way more RF than it should, because the quality and balance of the twist was half-assed?

Or am I badly misunderstanding how this works because I haven't started studying for an amateur radio license yet?

There is always going to be some leakage. The question is whether you can get a high enough signal to noise ratio to get any useful information about it.

What this guy is doing is what he always does: deliberately modulate the signal (in this case, sending packets slowly) at a very low rate and encoding information in that. Of course that works; it always does. It's not news and it has no research value. It's obvious that you can take any system that produces measurable emissions and then drive it in such a way to encode low-bandwidth data in those emissions.

It would be nice if he actually studied practical channel bandwidths and determined just how much information you can transmit with these techniques, but he doesn't have the chops for that. He just cranks out minimum viable PoCs to get the news cycle, using misleading clickbait headlines.

You've got the basics right. An optimally coupled pair won't radiate. Nothing is optimal, however, so there is a small amount of RF radiation. Obviously this means not all RF energy from the environment is common mode as well. Thus the ever more substantial shielding that has appeared in later copper Ethernet cabling.

The implication of this click bait is that ordinary traffic is being recovered from RF leakage. While that's theoretically possible given short range and a sensitive receiver, what we have here is someone creating a low frequency transmitter using copper Ethernet. That doesn't mean it is without interest or value; dismissing side channels like that has a poor track record. But it's not what you're led to believe with "attack reveals Ethernet cable traffic!"

I do wonder how close you'd have to go to actually demodulate real Gigabit Ethernet over the air. Given the 8 simultaneous data streams (4 pairs times two directions), I imagine you'd need at least 8 antennas to get anywhere, probably arranged in very close proximity to the cable to pick up on the spatial differences between the pairs. Then you'd have to use MIMO demodulation techniques. At that point you might as well just tap the cable.

100BASE-TX would be a lot easier, since that just uses a single pair in each direction.

FWIW, this isn't a side channel, at least not the way he's presenting it. It's a covert channel. That's different; side channels leak (significant) information from uncooperating sources. Covert channels require a cooperating source. There's a huge difference. Covert channels are largely academic and almost never relevant in real life. This isn't like research on things like extracting RSA keys from CPU EMI emitted during OpenSSL operations, which is a real side channel and much more valuable research.

or just tap the fiber optic cables, which seems easier and more reliable than trying to capture stuff with antennas.

Tomorrow news: Mordechai Guri uses $50 camera to see thru your optical patchcords!

You would probably need to pierce the cable with needles.

Hence the reason for standards. Here's an intro:

"Classified Facility Communications Cabling Infrastructure Design Basics"

https://www.bicsi.org/docs/default-source/conference-present...

Those that understands these things, have known about RF leakage on data cables for decades.

When I worked at the Ministry of Defence (UK) back in the late 1990s, the network cables for different data classifications were always strung along conduits at least 3 feet apart, and anything over the old 'confidential' (i.e. 'secret' and 'top secret') used fibre instead of copper.

This is reasonably well known, as are some of countermeasures in use:

https://en.wikipedia.org/wiki/Tempest_(codename)

Actual paper https://arxiv.org/abs/2110.00104.

Aside from the clickbait and non-news of this possible information leakage when you already have a foot on the inside:

I always assume that what the headline wrongly alludes to (actually reading traffic content) is possible, and use encryption even on my own LAN (VPN, SSH, HTTPS). Wireguard has made all of this a lot easier. I use a high MTU for most things, and the tunnels that have routes to the outside Internet run with an "inside" MTU of 1500, so no issues there. A few things can talk directly to the outside internet without a VPN, but only HTTPS to specific destinations. This is for bootstrapping reasons (for building everything from scratch).

Some things are is still in the clear, but contains no real secrets:

Internal DNS: Reveals internal primary hostnames, and a few services (like ntp.mydomain, mirror.mydomain and boot.mydomain).

ARP, DHCP, LLDP, LACP, BGP (some of it) and PFSync: Not really worried about that. IP and MAC addresses are revealed. The MAC addreses are usually switched after bootstrapping, mostly because I have an internal MAC address scheme that let me quickly identify hosts from just looking at the MAC address.

Chainloading iPXE from regular PXE via TFTP: This reveals the iPXE binary and the CA certificate contained within. After this the traffic is HTTPS.

Internal mirror: Some accesses to my internal mirror, but only base OS packages that are part of a normal default install. After basic bootstrapping HTTPS or VPN is used.

NTP: Meh... what is the current time?

iSCSI: Only boot loader is in the clear and contains no secrets. I use "FDE" on top of iSCSI. Auth is not used as a dedicated VLAN for each host takes care of unintended access.

Samba: I have a dedicated Windows PC only used for gaming and I use Samba to load my collection of games (mostly GOG). Not really sure if this Samba protocol version is encrypted or not. The password used for the share has no relation to anything else. I don't really care, as this is a separate network. I don't really know why I don't just use "public" Samba shares for this.

Stuff on the outside of the primary firewall: My girlfriends phone, my work-phone and a Chromecast. This is just behind the outer router/firewall that does NAT for my network. The "real" network is behind another layer of firewalls.

There is probably something else, I should probably have a look with tcpdump more often.

Many years ago I stopped asking myself if something should be encrypted and now just use encryption by default (if possible/practical).

Is it needed? Probably not. Is it hard? Not with automation.

i have friends that talked about this concept years and years ago.

Reply on news.ycombinator.com