>An excel spreadsheet crashed this company's network.
>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.
For what it is worth in the rf world (and probably the whole “physical layer” space) you want to avoid a DC bias on your line. Otherwise you are gonna be pulling a current in one direction.
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.
Hmm. I friend of mine claimed that requesting trade with another player in World of Warcraft crashed his router. When he needed to trade, he always insisted that the other player should initiate the transaction.
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?
If you were using a dial-up modem and sending raw data -- extremely common -- then sending +++ATH0 would cause most modems to hang up.
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.)
This won't work with the line coding of modern network protocols. The key part of this story is T1 using the older AMI coding that is susceptible to loss of sync from the right data pattern.
Once at work I tried to upload a file to our fileserver to share it with some coworkers and it failed. Other files uploaded fine. The file wasn't very large, didn't have any funny characters in the name, or anything that would conflict with a reserved name, or anything like that.
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.
Not only is this blogspam, but the whole rest of the story is missing; there's no link, just a bare claim—some network somewhere failed when an XLS file traversed its lines; no backstory, no details, no resolution.
Avoiding this issue would be a pleasant side effect of encryption. Since encrypted data is indistinguishable from noise, it wouldn’t matter if the underlying format has specific bit patterns that mimic a signal pattern.
In a monkeys in front of a typewriter world, statistically, you are as likely to have a one off event that matches a specific bit pattern in the underlying format as you would the encrypted format. It would not be reproducible though since most encryption uses nonces
It's not particularly uncommon to have a non-cryptographic whitening/scrambling step as part of high-speed signalling protocols (e.g. PCI-E) in part for this reason. Even for interconnects between different chips on the same PCB.
Yes, SONET includes a "scrambler" for exactly this purpose. It keeps the lasers happier. I tried for a while to produce pathological payloads that would cancel out the scramble polynomial when combined with it, but two things make this impractical:
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.
Low level signaling is a completely different work that we never even bother to think about these days - but it has its own idiosyncrasies and strangeness that has - mostly - been factored out.
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.
I read somewhere about a home router that corrupted packets in transit. In this case it was a torrent that never completed because of this. IIRC something in the nat engine bugged out and replaced bytes in the data and not just in the ip header.
More or less everything is broken. Its just that most protocols are designed to handle it.
For more context, read the comment[0] on Reddit's /r/sysadmin thread from the follow-up tweet[1]. It boils down to a certain bit-pattern in the spreadsheet's headers that corresponded to a signalling pattern in their T1 line, around the year 2003, causing the T1 equipment to fail.
Oh, it's entirely possible in principle (I don't know about the details of T1 in this specific case).
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.
Hayes figured out how to make that impossible: The "guard time" interval. When you want to interact with the modem, you have to send _nothing_, not a single character, for a whole second before sending +++ and then another whole second of nothing. Only then would the modem place you into command mode. That way, +++ could happily appear in payload but never mess with the modem, because there'd be other payload either side of it.
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... ;)
Repeated patterns in digital signals can cause errors in several ways such as DC bias (likely the case here), or a buildup of energy on the edges of the signal's fourier spectrum which then gets filtered out and shows up as signal degradation on the oscilloscope.
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.
OSI model makes it more possible. After all for each layer anything above it is just well bits... And if some layer is poorly implemented it can interpret certain run of bits as something else and act accordingly, but wrong.
There is lot of bad code specially when you have multiple implementations and all doing their own thing on their own level.
>An excel spreadsheet crashed this company's network.
>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.
Thank you, saved me a click.
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.
For what it is worth in the rf world (and probably the whole “physical layer” space) you want to avoid a DC bias on your line. Otherwise you are gonna be pulling a current in one direction.
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.
Hmm. I friend of mine claimed that requesting trade with another player in World of Warcraft crashed his router. When he needed to trade, he always insisted that the other player should initiate the transaction.
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?
My last name contains the character sequence "rz".
Back in the BBS days this would trigger a Zmodem transfer on certain clients. It made a lot of people upset.
If you were using a dial-up modem and sending raw data -- extremely common -- then sending +++ATH0 would cause most modems to hang up.
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.)
This won't work with the line coding of modern network protocols. The key part of this story is T1 using the older AMI coding that is susceptible to loss of sync from the right data pattern.
Once at work I tried to upload a file to our fileserver to share it with some coworkers and it failed. Other files uploaded fine. The file wasn't very large, didn't have any funny characters in the name, or anything that would conflict with a reserved name, or anything like that.
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.
Some very poorly coded NAT boxes translated any bit pattern that looked like the local/public network IP address.
Did he play as a mage?
Not sure if I'm missing a joke here - if so, whoosh, I guess. But he played as everything. At the time his main was a rogue :)
Not only is this blogspam, but the whole rest of the story is missing; there's no link, just a bare claim—some network somewhere failed when an XLS file traversed its lines; no backstory, no details, no resolution.
It’s a twitter repost of a reddit discussion https://old.reddit.com/r/sysadmin/comments/9si6r9/postmortem...
Avoiding this issue would be a pleasant side effect of encryption. Since encrypted data is indistinguishable from noise, it wouldn’t matter if the underlying format has specific bit patterns that mimic a signal pattern.
In a monkeys in front of a typewriter world, statistically, you are as likely to have a one off event that matches a specific bit pattern in the underlying format as you would the encrypted format. It would not be reproducible though since most encryption uses nonces
It's not particularly uncommon to have a non-cryptographic whitening/scrambling step as part of high-speed signalling protocols (e.g. PCI-E) in part for this reason. Even for interconnects between different chips on the same PCB.
Yes, SONET includes a "scrambler" for exactly this purpose. It keeps the lasers happier. I tried for a while to produce pathological payloads that would cancel out the scramble polynomial when combined with it, but two things make this impractical:
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.
https://threadreaderapp.com/thread/1838256923428438345.html
Low level signaling is a completely different work that we never even bother to think about these days - but it has its own idiosyncrasies and strangeness that has - mostly - been factored out.
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.
I read somewhere about a home router that corrupted packets in transit. In this case it was a torrent that never completed because of this. IIRC something in the nat engine bugged out and replaced bytes in the data and not just in the ip header.
More or less everything is broken. Its just that most protocols are designed to handle it.
In phreaking tradition I think it’s appropriate to call this the Excel Box.
So if you know the proper byte sequences (incantations) you can basically mess (do magic) with some routers.
Unless it’s satire and I’ve missed the point. I'd have thought this wouldn't physically be possible because of the OSI model.
For more context, read the comment[0] on Reddit's /r/sysadmin thread from the follow-up tweet[1]. It boils down to a certain bit-pattern in the spreadsheet's headers that corresponded to a signalling pattern in their T1 line, around the year 2003, causing the T1 equipment to fail.
[0] (2018) https://old.reddit.com/r/sysadmin/comments/9si6r9/postmortem...
[1] https://twitter.com/lauriewired/status/1838257118685921694
Oh, it's entirely possible in principle (I don't know about the details of T1 in this specific case).
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.
Hayes figured out how to make that impossible: The "guard time" interval. When you want to interact with the modem, you have to send _nothing_, not a single character, for a whole second before sending +++ and then another whole second of nothing. Only then would the modem place you into command mode. That way, +++ could happily appear in payload but never mess with the modem, because there'd be other payload either side of it.
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... ;)
Repeated patterns in digital signals can cause errors in several ways such as DC bias (likely the case here), or a buildup of energy on the edges of the signal's fourier spectrum which then gets filtered out and shows up as signal degradation on the oscilloscope.
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.
OSI model makes it more possible. After all for each layer anything above it is just well bits... And if some layer is poorly implemented it can interpret certain run of bits as something else and act accordingly, but wrong.
There is lot of bad code specially when you have multiple implementations and all doing their own thing on their own level.
[flagged]
there's no need to be a jerk
[flagged]