Excel spreadsheet caused network equipment's physical failure
twitter.com
twitter.com
>But it wasn't malware.
>The truth is much weirder.
>Try this out, open up a xls (not xlsx) file in your favorite text/hex editor. Notice all the repeating characters in the header.
>When receiving POP3 emails with an excel attachment, the characters bit patterns caused a signalling pattern on the physical copper of the company's T1 line, crashing the network equipment.
But this tells me the T1 was misconfigured with AMI signalling, which doesn't guarantee ones-density, and never should have been used for data in the first place. AMI is appropriate for voice, where the low bits of the PCM signal are always twiddling with noise, and statistically tend to provide plenty of transitions to keep the receiver clock synchronized.
The whole reason B8ZS was invented was to guarantee a sufficient number of transitions even in the presence of digital data, which often contains long runs of pure zero. By replacing an 8-zeroes-in-a-row string with an "invalid" pattern, the pattern still contains enough edges for the clock circuits, but the pattern is discarded as invalid and replaced with 8 zeroes again by the receiver.
B8ZS was considered mandatory on data circuits and we had special test patterns (really just a long run of zeroes with a 1 at the end) that would make AMI fail, in order to confirm that a whole path was properly configured with B8ZS.
The detail about POP3 and Excel attachment is extraneous and I can't see how it would matter. Nothing in the ones portion of the signal should throw of an already-framed circuit. Extraordinary claims and all that.
To do this you want to make sure that the flow of electrons alternates roughly 50% of the time. You can accomplish this with all kinds of “data whitening” schemes like the one the parent describes.
I was tempted to discard this as pure imagination, but this was a smart and knowledgeable fellow who worked as a programmer, so I'm assuming he had done some investigation before he came to this conclusion.
I know too little about networking equipment, but I can see how certain byte sequences (timed right?) would have some magic meaning. Given enough traffic you're likely to end up sending just such a sequence eventually. Perhaps certain versions of the WoW client spat out just such a magic sequence for the particular router he happened to use?
Back in the BBS days this would trigger a Zmodem transfer on certain clients. It made a lot of people upset.
If you could get that sent over to someone else, their session would be abruptly terminated.
(Hayes patented requiring a no-data-sent time between the +++ and the ATH0. Avoiding the patent but being otherwise compatible introduced the vulnerability. In-band signalling is usually bad.)
After some experimenting I was able to figure out that there was a particular byte sequence that simply could not be sent via the ethernet card in my computer. I changed ethernet cards and then I could send the file.
After a lot of searching I eventually found a few discussions of this, and an errata list for the chipset in my ethernet card that said that a particular revision of the chipset had an error in the checksum implementation that would compute an incorrect checksum for a particular bit pattern.
1: First, most SONET customers at the time weren't actually buying the whole rate line. (Say you have an OC12 coming into the building, are you actually purchasing an OC12c worth of capacity, or are you buying a DS3/STS1 which is only occupying 1/12th of the line, and the carrier just dropped a larger circuit for their own convenience?) So because of byte interleaving, 11/12 bytes (or whatever) are good, and even if you somehow synchronize with the scrambler, you can't cause enough ones in a row to piss off the laser, or enough zeroes in a row to confuse the receiver.
2: Second, the payload framing means that, even if you are buying a whole OCxC worth of transport, your options are still very limited. I'm rusty on this but I think you only get 87 bits in a row of payload before another framing structure ruins your day. I still feel like it might be possible, but it wasn't within my reach given the test pattern constructor built into the ASA-312.
Especially since modern encryption means that the same byte sequence on the wire will not be sent even if you do the exact same thing again. It covers quite a few sins.
More or less everything is broken. Its just that most protocols are designed to handle it.
[0] (2018) https://old.reddit.com/r/sysadmin/comments/9si6r9/postmortem...
[1] https://twitter.com/lauriewired/status/1838257118685921694
Many years ago, there used to be a vulnerability with a lot of modems where you could send a ping packet to a machine connected via dialup, and the machine would send back a response that its modem would interpret as telling it to hang up the call: https://seclists.org/bugtraq/1998/Sep/192
The OSI model is an abstraction that can be broken by implementation bugs or design flaws, not an immutable law of the universe.
EDIT: I see that some of the Twitter replies beat me to mentioning this.
Of course they patented this, and anyone who licensed the patent was likewise immune, but the manufacturers who didn't, could easily be plonked like this.
My first "hack" involved a BBS scripting language that involved a delay command... ;)
There is lot of bad code specially when you have multiple implementations and all doing their own thing on their own level.
Nowadays the lower layer transmission protocols all re-code the signal to ensure frequent edge transitions, and after a few layers of that the odds of these patterns causing problems goes way down.
And then compression and encryption (hopefully in that order!) make it go away entirely.
Buuut, 25 years ago network equipment wasn't as layered and sophisticated as it is today, so that sort of thing would crop up now and then.