Hacker News Reader

Comment by ofrzeta | Hacker News Reader

From the article I am not totally convinced that "Telecom security sucks today", given they just randomly picked Freeswitch to find a buffer overflow. "Telecom stacks" might or might be not insecure but what's done here is very weak evidence. The Salt Typhoon attacks allegedly exploited a Cisco vulnerability, although the analysts suggest the attackers have been using proper credentials (https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...) So nothing to do with Freeswitch or anything.

View on HN

Cisco Unified Call Manager almost certainly has vulnerabilities, as does Metaswitch which has shambled along in network cores after Microsoft publicly murdered it, Oracle SBC is often wonky just doing the basics, whatever shambling mess Teams is shipping this week for their TRouter implementation definitely has Denial of Service bugs that I can't properly isolate.

Lets not even talk about the mess of MF Tandems or almost every carrier barebacking the web by slinging raw unencrypted UDP SIP traffic over the internet...

It is possible to build secure systems in this space, but instead we have almost every major telecom carrier running proprietary unmodifiable platforms from long dead companies or projects (Nortel, Metaswitch,etc) and piles of technical debt that are generally worse than the horribly dated and unpatched equipment that comprises their networks.

I find it absolutely insane that the industry standard for SIP trunks is unencrypted UDP, usually using IP-based authentication.

When I asked a popular VoIP carrier about this a while back, they argued that unencrypted connections were fine because the PSTN doesn't offer any encryption and they didn't want to give their customers a false sense of security. While technically true, this doesn't mean we shouldn't at least try to implement basic security where we can - especially for traffic sent over the public Internet.

PSTN starts at the home router these days, I don't think I can get an actual analog line in my house.

My DOCSIS service provider turned off encryption. That's likely due to the certificate expiring on a popular modem brand. Key management is hard, certificate management is hard. Especially when they don't care about security. The encryption was only DES to begin with instead of AES which is supported in DOCSIS but few service providers bother. Anyone who has the tools to sniff DOCSIS can eavesdrop on my provider's nodes and hear the incoming leg of phone calls.

Great example. Anyone who cavalierly states "let's do PKI!" has not done PKI.

Painting a dire picture here!

It'd be lovely to see some nations of the world pour some serious money into the various Linux Foundation (or other open source) telco & cellular projects.

Pouring money is not how you get good quality software. You need a company driving product quality. Most Linux foundation projects have companies heavily invested in productionizing the projects and that leads to them contributing to them to ensure high quality code. Code without a driving product tends to wander aimlessly.

That's, like, your opinion man.

Maybe the money should have more strings attached, be attached to grant proposals, whatever.

I don't see that that is an important or clarifying distinction. Governments should be directly helping, with money, somehow. Collectivizing the investment is better returns and far better outcomes, open source is the only way you're going to avoid risking your investment in a single company that may over time fail. Having your nation take its infrastructure seriously should be obvious, and this is how. And I disagree that good things only happen at companies. The post I was responding to stands as incredibly broadscale evidence that that often doesn't happen.

Contract work is tricky because individuals who own a particular project may be full time employed already and not capable of taking on contract work. Not every project is capable of generating enough contract work to make it sustainable to do it full time and not everyone wants that level of instability on their income.

Hiring an outside company to do contract work leads to longer term maintenance issues where they disappear after the contract completes. It would be better to have individuals from a distributed set of organizations all collectively pitch in to do maintenance. This is how the Linux project is organized and it's very successful. While this is understandably unlikely to happen for smaller projects I think that just means it's important for projects to be created and maintained by larger collectives. Again, this is a common trend you see occur.

Governments are often the ones the encryption is protecting us from - they're not going to fund better encryption.

Linux foundation is the thing financing backdoors. do not confuse it with Linux. the only money from the foundation that goes to actual Linux are a couple build servers. and one event sponsorship. absolutely nothing else.

>Cisco Unified Call Manager

Is that not a kind of business/enterprise thing?

"Telecom" to me is like a network core equipment and radio towers - https://www.cisco.com/c/en/us/products/wireless/pgw-packet-d...

Call Manager etc have zero to do with SP networks.

I've had a few conversations with [security nerds more familiar with telecom] since SignalWire broke embargo.

The "everything sucks and there's no motive to fix it" was a synopsis because, frankly, those conversations get really hard to follow if you don't know the jargon. And I didn't feel like trying to explain it poorly (since I don't understand the space that well, myself), so I left it at what I wrote.

(I didn't expect Hacker News to notice my blog at all.)

As security nerd working within telecom agreed. Nobody really cares about security issues. And when people already struggle to care about the issues it gets even worse when fixing some of the issues (such as SS7 vulns) requires coordination with telcos around the world. cape[1] at least seems like its a breath of fresh air within the space.

[1] - cape.co

Can confirm. It’s not even nonchalance, but outright hostility to security because that sounds like work and change. And if there’s anyone who hates change, it’s telcom. They still resent having to learn voip and it could have kids in college at this point.

Hi, CEO of Cape here. Great insights. Salt Typhoon is just the latest example of how fragile these systems are. Vulnerabilities in protocols like SS7 are just the tip of the iceberg, and the incentives to fix them are weak. Telcos prioritize uptime and revenue collection over security, and addressing these attack surfaces requires coordination between multiple entities—something that is slow and complicated. The industry tends to accept these risks rather than truly mitigate them.

cape.co marketing sounds suspiciously like the cia front in Switzerland in the late 90s.

"hey you who needs privacy, here's something that somehow costs even less than the ones selling your data"

I'll have to try to find a video of the HOPE presentation where I first heard about SS7 and how riddled it was with known vulnerabilities, my jaw hit the floor.

> (I didn't expect Hacker News to notice my blog at all.)

Your blog actually gets posted somewhat regularly [0]. I actually remembered it, because it’s one of the rare cases where I like the "cute" illustrations.

[0]: https://hn.algolia.com/?q=https%3A%2F%2Fsoatok.blog%2F

I worked with telecom code. It's code that parses complicated network protocols with several generations of legacy, often written in secrecy (security by obscurity), and often in C/C++.

There's just no way it can be insecure. Right.

That's also how the majority of network appliances are handled outside of Telecom.

Yep. And the network appliance world also tried to make that a "feature", by making things like "management VLANs" and pretending that you don't need to be secure because of it.

I don't doubt that this cruft is insecure. It's just a bit of a stretch to get to that conclusion from finding a potential buffer overflow in Freeswitch. Maybe it's not a stretch but just a conclusion by analogy but then you might just say "all software is insecure".

Telecom stacks are full of questionable security decisions, some stemming from the protocol level. Protocols like SS7 were designed without any concept of hackers or malicious actors. You can slap firewalls on top of them, but those interfere with desired functionality and even if they don't they require extra investment. DIAMETER is better but still full of holes.

Security in the telecom space has been a point of priority for the past couple of years and things are improving, but there are decades of legacy hardware, software, firmware, and network designs to cover for.

I doubt anyone is running standard Freeswitch in their telco networks, but the problems Freeswitch has as an aging telecom product with a history of not looking for security as much as one might expect those are all over the place.

This blog article is a combination of "I did a thing I do for a living" plus "recipient of my report does not share my (and the rest of the Security Industry) values", and concludes that Telecom security sucks.

It's very nice that the author spent their free time looking at code, found a bug and reported it -- I don't want to discourage that at all, that's great. But the fact that one maintainer of one piece of software didn't bow and scrape to the author and follow Security Industry Best Practises, is not a strong basis for opining that "Telecom security sucks today" (even if it does)

If someone came to you with a bug in your code, and they didn't claim it was being actively exploited, and they didn't offer a PoC to confirm it could be exploited... why shouldn't you just treat it as a regular bug? Fix it now, and it'll be in the next release. What's that? People can see the changes? Well yes, they can see all the other changes too. Good luck to them finding an exploit, you didn't.

The same thing happens in Linux distros. A security bug gets reported. Sometimes, the upstream author is literally dead, not just intransigent. If you want change on your own timeline, make your own releases.

When the code is sprintf(stackbuf, "%s", attacker_supplied_input) in 2025, I expect some serious bowing and scraping.

In fairness, with that level of vulnerability in the code, fixing it is like using paper towels to mop up the ocean.

Yeah if anyone thinks people don't just run searches for `sprintf` they're pretty naive.

Reply on news.ycombinator.com