Telecom Informer
by The Prophet
Hello, and greetings from the Central Office!
It was a hot summer here in Puget Sound country, with forest fires turning the skies as brown as Beijing for two weeks in July. The fires returned at the end of August, but fortunately were put down by cooling rains. It's back to the interminable Seattle drizzle. Although summers have gotten hotter, the rest of the year has gotten - if anything - more wet!
It's time for some real talk, and this issue's column is less about technology than usual. It's about what level of disclosure is responsible in the telecommunications space. I have a confession to make. There are a few telecommunications topics I haven't covered in this column over the years because I think they are simply too dangerous to cover responsibly. In my column, I have always gone right up to the line of what I think is both lawful and acceptable to disclose, but I don't cross it. Admittedly, the line keeps moving so it's hard to know exactly where it is and, so far, I haven't been arrested, but phone companies are still upset with me so I think I'm probably doing an O.K. job.
There is a reason for this, though, apart from my own personal desire to stay out of prison. On a worldwide network like the phone system, deciding what to disclose and when to disclose it is a very tough balance. This is one of the reasons why I very rarely talk about security vulnerabilities in the Central Office - that is, apart from my parking lot which is again full of fresh tire tracks and oil stains left by a local teenager doing donuts in his 1981 Pontiac Grand LeMans. I'd normally be annoyed, but I have to admire his skill in managing to do this in such a small parking lot as the one here at the Central Office! There is a lot of phun to be had in the telecommunications system that doesn't risk breaking the whole damned thing in a way that is impossible to fix. And this is what I have focused on writing about over the years.
If you're working in or familiar with the information security sphere, you're probably aware of the concept of "responsible disclosure." There are fairly established protocols for dealing with security problems in software. You generally notify the company that built the vulnerable product through a formal channel. They issue a patch, maybe pay you a bug bounty, and everyone lives happily ever after. In telecom, these programs work for problems that are specific to an individual vendor. But what do you do when there is an entire vulnerable protocol?
To most 2600 readers with an "information wants to be free" mindset, I know this concept is virtually anathema. However, let me explain. Naturally, my readership consists of the world's smartest hackers. It also consists of a lot of not-so-smart folks in telecom security departments. Unfortunately, people - usually smart people - working in the darkest corners of spooky world governments read it as well. Of course, 2600 isn't the front page of The New York Times, but when I cover something, the wrong people can get the wrong ideas. I do need to consider the impact of my writing.
The closest Internet-era parallel to the current state of telecom is when Dan Kaminsky discovered fundamental vulnerabilities in DNS. Along with reporting of his discovery, a protocol fix - called DNSSEC - was rolled out, and it was widely (and quickly) adopted. The flaw still causes occasional problems, but since most DNS servers are patched and updated with DNSSEC, the impact is limited. Nevertheless, the implementation of DNSSEC is probably one of the most massive engineering efforts that has ever taken place in the history of the Internet, with the possible exception of IPv6 implementation (the reason why I say "possible" is that IPv6 implementation isn't actually finished and it's not clear it ever will be). However, a relatively small number of large players needed to agree on the solution and, from a technical perspective, it was easy to roll out. DNS was a far easier problem to solve than the problems facing telecom today.
In telecom, we have two fundamental flaws that are worse than the DNS flaws of yesteryear, and there is no good way to fix them yet. What's more, it's going to take years to even begin to fix these problems, and the entire world is going to have to agree on a solution. And there's the rub. Responsible disclosure isn't just about disclosing vulnerabilities to some corporation; it's thinking through the impact of a disclosure. Privately, I've been warning anyone who will listen for years, but at this point the genie is out of the bottle. Enough mainstream publications have written about this problem, and sitting Congressmen are giving speeches about it, that I am probably safe from prison for saying that Signaling System 7 (SS7) is the Achilles' heel of the worldwide telecommunications network.
And there is very little that we can do about it. Not yet, anyway.
Sure, there are a couple of things that can be done in the interim, but it is just so much rearranging of the deck chairs.
There are a couple of fundamental principles in the development of telecommunications technology, and one of the key drivers is billing. You see innovation when there is a problem with revenue, or an opportunity to make more money. Billing drives the whole thing. Fiber to the node? Yeah, that was done for billing - it was impossible to remain competitive with cable companies without it. Flat rate long distance? Well, without it, people would drop their landlines because cell phones were offering it. Billing. VoIP for transport? Well, why not reduce operating costs but charge the same? Billing. And SS7? Again, billing.
SS7 was developed in 1975 as a "next generation" digital telecommunications signaling network, but a primary objective was to move signaling from in-band to out-of-band. And this had to be done fast because there was a major revenue problem. Why? You can thank a phreak named Captain Crunch and another one named Woz who may or may not have raised the seed funding for Apple by selling Blue Boxes. Blue Boxes had gotten popular enough to begin costing the phone company serious money, so they were incentivized to invest in fixing the technical problem that allowed Blue Boxing to happen. There were also additional features that could be added with digital switches (for more revenue), and the majority of analog switches were nearing the end of their useful life anyway, so it made sense to accelerate the upgrade.
1AESS digital switches equipped with SS7 began rolling out in 1976 (to give you an idea of how slowly telecommunications evolves, the last one of them - operating in Odessa, Texas - was finally retired on June 3, 2017). However, it took until 1988 - 12 years later - before international C5 signaling was updated to C7, an ITU standard (then CCITT) based on SS7. At this point, it started to get harder to Blue Box. However, it was well into the 1990s before Blue Boxing became a thing of the past. Eventually, China upgraded to C7 (using their "country direct" number was a popular loophole for toll fraud) and shortly thereafter, it was all over.
Unfortunately, SS7 is a very lightweight protocol.
There isn't a ton of security around it. In fact, there pretty much isn't any security around it. With the benefit of hindsight, this was a terrible idea, but there are good reasons why it happened. First of all, the protocol was developed in 1975, during a time when memory was precious, bandwidth was even more precious, and CPUs operated at 200 kHz. The 1AESS was a massive upgrade - its CPU ran at 1 MHz! If you have ever worked with old computers that have limited processing power, you know that every resource is precious. It used to make sense to send a week optimizing a program to save 1 kB of RAM. So, any overhead for security probably seemed foolhardy at the time. Who would ever be on the network except for the Bell System and a few dirty independents like GTE? Besides, you could only gain access to the network from arcane systems requiring specialized training and credentials locked behind strong, heavy doors in Phone Company Central Offices.
The SS7 protocol, generally speaking, trusts messages sent to it.
The design principle behind this was to ultimately deliver calls recognizing things can sometimes be misconfigured. So, the network defaults to a "trust and deliver" state. This is why you can send any Caller ID you like, no matter how improbable, and SS7 will believe you. If you're on a mobile phone network, you can send a roaming location, even if it's in Russia, and SS7 will (more or less) believe you and act accordingly. In fact, if an SS7 command is sent to the network from a carrier that could have no conceivable business issuing that command, the network will usually go ahead and process it. Those vulnerabilities that have been publicly disclosed only scratch the surface.
And now, pretty much every VoLTE cell phone has full direct access to the SS7 network. Along with pretty much every VoIP carrier. This is where we are right now. It takes astonishingly little effort to hack your way onto the network and issue whatever SS7 commands you like, which the network will probably believe. There are far more terrible things you can do than have already been demonstrated - I'm not going to get into what they are. However, I can pretty much guarantee you (although I have no evidence) that spooky corners of the government are already doing them. It's open season, folks.
How do you fix it?
While some filtering can be implemented in the meantime, a long term fix is going to require a complete re-architecture of SS7, and that means everything needs to first be running on next-generation switches. This doesn't include the 5ESS or DMS-100, the workhorse switches that still run the majority of landlines in North America. And remember, the last major re-architecture of the telecommunications network took 12 years to even get started worldwide - and that was when a lot of money was at stake. Right now, phone companies aren't the ones who are actually losing money from security vulnerabilities in SS7, so I don't expect a fix soon. Their incentive to actually fix this is limited unless people start switching en masse to Skype.
And with that, I'll leave you with this thought: this is only one of multiple extremely serious vulnerabilities I'm aware of in the U.S. telecommunications network.
There is an actual prayer of fixing the second largest one, so I'll try responsible disclosure first. I'm not holding my breath that blowing the whistle will work, though.
So have a pleasant autumn, and I'll see you in the winter!