Nonsense ZDNet article
-
I recently read this article. It's obvious the author doesn't understand networking. He talks about "packet-in-packet" and "outer shells". I guess he's never heard of encapsulation as a fundamental function of network protocols. Further, he talks about how interference or bad cables will release the bad inner packet, supposedly by changing bits, causing the outer packet to break. He obviously doesn't know what the CRC field is for. If there is so much as a single bit error, the CRC will fail and the entire Ethernet frame discarded. His claim that "bit flips" will slowly destroy the outer packet is pure B.S.. Also he went through the "demonstration" so quickly it was impossible to follow. I'm surprised ZDNet published such an idiotic article.
-
The author of the article is doing a news piece on a proposed attack and he uses the terminology used by the group presenting. Read the White Paper linked in the article. I have only glanced over it yet but I think it's explained pretty good. I'm sure these guys are aware of encapsulation. The "packet-in-packet" terminology isn't theirs but have been used previously in work they've been inspired by. Maybe the terminology is used to distinguish it from valid encapsulation? The CRC is of course a problem but they cover that as well. I don't see it as a huge threat (it would be a very complex attack to try) but I'm not surprised that ZDNet publishes it. Black Hat presentations are usually news regardless of if the attacks work or not.
-
More than CRC is a problem. In that demo, he used a NAT router. So, on top of everything else, they have to craft a packet that can handle NAT changing the contents of the frame. Also, how does a bad cable remove a bit? It can change it, but it can't remove it. On top of this, plain bits haven't been placed on the wire since 10baseT. At every other speed, complex modulation is used, so the interference would trash several bits at the same time. Again, any modification would result in CRC failure, which would cause the entire frame to be discarded, before any inner packet could be released. I just don't see a bad cable or some interference making that sort of change.
-
I’m not defending the work, I just thought that you severly overreacted on it when you attacked several things that were actually explained in the white paper. Now you continue with talking about "remove a bit". Neither in the ZDNet article nor in the white paper can I find that claim. As far as I can tell they only talk about "bit flips" so I think that you and the Armis guys are actually in agreement about that at least.
-
Take a look at how the bits are actually encoded on the line. Back with 10baseT, Manchester encoding was used, which meant each bit was discrete. On the other hand, with 100 Mb, a method called 4b/5b encoding is used, which means if you change anything with that, you're changing possibly 4 bits. On Gb, a method called 4D-PAM5 is used, which takes 8 bits and spreads it over all 4 pairs. These are complex modulation protocols, which make it impossible for a bad cable to do what's claimed. A bad cable or interference that changes bits will cause the CRC to fail and the frame to be tossed. To expect something that's as random as a poor connection to magically remove an outer packet and reveal an inner one is just plain nonsense. Also, poor connections will mean packet loss in general and that will tend to be noticeable.
Here's a quote, which I took to mean removing bits.
slowly destroying the outer shell and leaving the internal payload active.
Either remove or flip, it's the same nonsense.BTW, I don't know what your background is, but here's a bit of mine. Decades of experience with telecom, computers and networks and that's mostly hands on as a tech. This also included something called bit error rate testing (BERT) on telecom and microwave links, as well as certification testing of Ethernet connections. I also studied Electrical Engineering, with a telecom focus. In addition, I am probably the only one in this forum who has actually hand wired an Ethernet controller, built with discrete logic and wire wrap.
If you want to read a bit about how data is actually carried on Ethernet cables, I can recommend Ethernet The Definitive Guide, by Charles E. Spurgeon, from O'Reilly.
-
@P3R said in Nonsense ZDNet article:
Now you continue with talking about "remove a bit".
Further on this. Let's consider the simplest situation, which is UDP in UDP. The outer packet is something benign and the inner the attacker. To create that, you start with the inner packet and then add another UDP header. That's it. A UDP header is 8 bytes long. Now, to release the inner packet, those 8 bytes have to be removed. Just changing them will likely cause a CRC failure. How does a bad cable or interference remove precisely 8 bytes and also change the CRC to match the resulting Ethernet frame? Going through a router means you'll also have to account for the different hop count and possibly NAT causing address and port changes, considering with CRC a small change results in a significantly different CRC value. As I said, that's a bit much to ask of a bad cable.
-
I only know you by reading this forum and let’s just say that I have enough technical background to very much respect your knowledge. I just thought that you went overboard here and I still do but as I never was seeking this argument I’m out of here for good.
-
Sorry, I didn't mean to offend you. I was just trying to help you understand that what's required for this to work is so improbable as to be essentially impossible. The author of that article apparently doesn't know enough about Ethernet & IP to understand that.
