The author admits to having zero experience with carrier-level infrastructure, but their suspicions are essentially correct.
I actually have done a fair bit of 4G and 5G specific pentesting and security research for a number of major carriers. While it varies between carriers and between product vendors, it's still an absolute horror show. Until very recently, the security was entirely achieved through obscurity. The 4G and 5G standards have started to address this, but there are still gaps big enough to be deeply concerning. I don't think it's overly hyperbolic to assume that any moderately sophisticated threat actor who wants a beachhead on a carrier can achieve it. I've demonstrated this multiple times, professionally.
IMHO the hardware vendors from a certain East Asian state have such poorly written software stacks, that they could almost be classified as APTs - security is non-existent. There are valid reasons Western countries have banned them. Western hardware vendors have significantly more mature software, but are still many years behind what most of us would consider modern security best practices.
A few years back the U.K. tried a political experiment in which it purchased Huawei equipment and also set up a special government/Huawei lab where they could analyze the source code to ensure it was safe to use. GCHQ found that the code quality made it unreviewable, and that they could not even ensure that the source code provided actually ran on the equipment (because Huawei had direct update capability.) I believe that equipment has been banned since 2020. https://www.washingtonpost.com/world/national-security/brita...
I've been personally involved in evaluating the security of a certain vendor starting with the letter H. Let us just say they are "less than honest". I had pcaps of their bullshit trying to reach out to random C2 shit on the internet, which garnered a response of "there must be a mistake, that is not our software".
Let China sell their telecom bullshit to all the poor people of the world - they will learn hard lessons.
To be honest, the conclusion of the blog post that Freeswitch are not budging from their community release schedule does not surpise me one iota.
Freeswitch used to have a strong community spirit.
Things all changed since they took a more agressive commercial turn, a couple of years ago IIRC.
Since that point you now have to jump through the "register" hoop to gain access to stuff that should be open (I can't remember what it is, IIRC something like the APT repos being hidden behind a "register" wall, something like that).
I don't want to "register" with a commercial company to gain access to the foss community content. Because we all know what happens in the tech world if you give your details to a commercial company, the salesdroids start pestering you for an upsell/cross-sell, you get put in mailing lists you never asked to be put on, etc.
One thing I absolutely don't understand about telecom security is how, in 2025, we're still using pre-shared keys in our mobile phone standards.
RSA and Diffie Hellman[1] have existed for decades, so have CA systems, yet SIM cards are still provisioned with a pre-shared key that only the card and the operator knows, and all further authentication and encryption is based on that key[2]. If the operator is ever hacked and the keys are stolen, there's nothing you can do.
To make things even worse, those keys have to be sent to the operator by the SIM card manufacturer (often a company based in a different country and hence subject to demands of foreign governments), so there are certainly opportunities to hack these companies and/or steal the keys in transit.
To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world.
[1] I'm aware that those algorithms are not considered best practices any more and that elliptic curves would be a better idea, but better RSA than what we have now.
> "AMERICAN AND BRITISH spies hacked into the internal computer network of the largest manufacturer of SIM cards in the world, stealing encryption keys used to protect the privacy of cellphone communications across the globe, according to top-secret documents provided to The Intercept by National Security Agency whistleblower Edward Snowden."
From what I remember from early 2000’s only the air interface was encrypted. Since anyway they have to provide lawful intercept capability there was not much benefit in providing end to end encryption. It’s not like it was a top of mind feature for consumers.
You appear to be neglecting the need for symmetric stream ciphers to achieve realtime communications (needed for performance reasons). No matter what you do, you are going to have a symmetric key in there somewhere for adversaries to extract. Once the adversary owns the telco, it is over (i.e., calls can be decrypted), no matter how strong the cryptography is. Your strongest cryptography cannot withstand a key leak.
Do you know how TLS works? The asymmetric keys are used to negotiate temporary symmetric keys, which are used for the actual data. That's exactly what the mentioned Diffie-Hellman algorithm does. Also check out "perfect forward secrecy".
> To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world.
This feels like the obligatory XKCD comic[1] when in reality there isn't any secretive key extraction or cracking...things are just sent unencrypted from deeper into the network to the three-letter-agencies. Telco's are well known to have interconnect rooms with agencies.
Not a requirement, but if for some reason you don't do the Right Thing that the NSA wants, oh dear your CEO goes to jail, he was a bad boy, look at all that insider trading. You'll do the Right Thing next time we ask, capiche?
Are you suggesting end-to-end encryption? Telecom providers have to implement "lawful intercept" interfaces to comply with the law in many jurisdictions.
I worked for a major telco in technical support/customer service.
I saw numerous security issues, and when I brought them up, with solutions to improve the service for customers, I was informed the the company would lose money.
Scammers are big customers for telcos, and when they get caught, and banned, they come back again and pay a new connection fee and start the cycle again. Scammers also enable feature upselling, another way to profit from not solving the problem.
I imagine most of the people running Freeswitch have their own patches on top of the community releases anyway so we're compiling those security fixes in to our own builds. That's what we did anyway when I worked for a place using Asterisk, Freeswitch, and OpenSER/Kamailio whatever it is called this decade.
"potentially thousands of telecom stacks around the world that SignalWire has decided to keep vulnerable until the Summer, even after they published the patches on GitHub."
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.
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.
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.
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.
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.
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.
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.
> (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.
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++.
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".
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.
One area where freeswitch is probably used quite often (and without support contract) are BigBlueButton installations (virtual classroom system) in schools and universities. I am more worried about them then about telcos.
Yeah, it's enabled with `load mod_xml_rpc`. Listening on 8080.
$ ./test3 # see above
<HTML><HEAD><TITLE>Error 408</TITLE></HEAD><BODY><H1>Error 408</H1><P>Problem getting the request header</P><p><HR><b><i><a href="http://xmlrpc-c.sourceforge.net">ABYSS Web Server for XML-RPC For C/C++</a></i></b> version 1.26.0<br></p></BODY></HTML>
Motorola's low-end 911 phone system, Emergency CallWorks (ECW), is Asterisk with proprietary modules running on Linux under Proxmox. Granted, Motorola is killing the produce, but it's out there. The one I babysit is heavily firewalled but I'd imagine not all of them are.
I would dare to whisper that the lack of security suits the NSA just fine. However you can add just about every technically competent nation state, organised crime, major corporations, and a collection of non-state actors. About the only group besides us nomies who I think might really care about this are the payment rails folks as this insecurity facilitates more fraud.
1) To be slightly annoyingly contrarian, there is money to be made in secure telecom; Skype founders made a bundle, no?
2) This article conflates freeswitch with major telecom carrier infeastructure. My impression is that 30+% of the problem with security is not technical but economic. Carriers outsource a ton of their operations, effectively outsourcing most efforts to care about security... which never helps security posture unless the outsourcer considers their core value proposition, which they generally don't, instead pushing themselves as a cost/capitalization play.
Rust only fixes the memory safety issues. It doesn’t fix bad software design, the problem where we have to trust other companies to keep their security issues under control (eg. Cisco), and it can’t undo bad decisions that have become industry standards (eg. SS7)
Allowing any random bozo to connect to the network's trusted center was a bad decision.
If the regulatory mandate to allow interconnection had also mandated the development and usage of a secure protocol for that interconnection, we'd be fine. But it mandated the opposite. Politicians got us into this mess, not programmers.
I don't have a lock on my mailbox. It is bad that the "low trust" internet overflows into my everyday life. I would rather that there was some separation of telephone calls, local community and banking etc from the lawless voids, than normalizing all these scams.
Telephone scam calls are mostly an internet problem.
You probably don't need an LLM to find vulnerabilities in software written like this. It took me a few minutes with GitHub in a web browser, but I'm sure you could make some headway with semgrep if you were bold enough.
The author admits to having zero experience with carrier-level infrastructure, but their suspicions are essentially correct. I actually have done a fair bit of 4G and 5G specific pentesting and security research for a number of major carriers. While it varies between carriers and between product vendors, it's still an absolute horror show. Until very recently, the security was entirely achieved through obscurity. The 4G and 5G standards have started to address this, but there are still gaps big enough to be deeply concerning. I don't think it's overly hyperbolic to assume that any moderately sophisticated threat actor who wants a beachhead on a carrier can achieve it. I've demonstrated this multiple times, professionally. IMHO the hardware vendors from a certain East Asian state have such poorly written software stacks, that they could almost be classified as APTs - security is non-existent. There are valid reasons Western countries have banned them. Western hardware vendors have significantly more mature software, but are still many years behind what most of us would consider modern security best practices.
A few years back the U.K. tried a political experiment in which it purchased Huawei equipment and also set up a special government/Huawei lab where they could analyze the source code to ensure it was safe to use. GCHQ found that the code quality made it unreviewable, and that they could not even ensure that the source code provided actually ran on the equipment (because Huawei had direct update capability.) I believe that equipment has been banned since 2020. https://www.washingtonpost.com/world/national-security/brita...
That kind of analysis needs a control.
But I guess it’s like you said: a political experiment.
Correct. Both the US and Canada also did similar investigations and came to similar conclusions.
I've been personally involved in evaluating the security of a certain vendor starting with the letter H. Let us just say they are "less than honest". I had pcaps of their bullshit trying to reach out to random C2 shit on the internet, which garnered a response of "there must be a mistake, that is not our software".
Let China sell their telecom bullshit to all the poor people of the world - they will learn hard lessons.
To be honest, the conclusion of the blog post that Freeswitch are not budging from their community release schedule does not surpise me one iota.
Freeswitch used to have a strong community spirit.
Things all changed since they took a more agressive commercial turn, a couple of years ago IIRC.
Since that point you now have to jump through the "register" hoop to gain access to stuff that should be open (I can't remember what it is, IIRC something like the APT repos being hidden behind a "register" wall, something like that).
I don't want to "register" with a commercial company to gain access to the foss community content. Because we all know what happens in the tech world if you give your details to a commercial company, the salesdroids start pestering you for an upsell/cross-sell, you get put in mailing lists you never asked to be put on, etc.
One thing I absolutely don't understand about telecom security is how, in 2025, we're still using pre-shared keys in our mobile phone standards.
RSA and Diffie Hellman[1] have existed for decades, so have CA systems, yet SIM cards are still provisioned with a pre-shared key that only the card and the operator knows, and all further authentication and encryption is based on that key[2]. If the operator is ever hacked and the keys are stolen, there's nothing you can do.
To make things even worse, those keys have to be sent to the operator by the SIM card manufacturer (often a company based in a different country and hence subject to demands of foreign governments), so there are certainly opportunities to hack these companies and/or steal the keys in transit.
To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world.
[1] I'm aware that those algorithms are not considered best practices any more and that elliptic curves would be a better idea, but better RSA than what we have now.
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
Gemalto was hacked 15 years ago:
> "AMERICAN AND BRITISH spies hacked into the internal computer network of the largest manufacturer of SIM cards in the world, stealing encryption keys used to protect the privacy of cellphone communications across the globe, according to top-secret documents provided to The Intercept by National Security Agency whistleblower Edward Snowden."
https://theintercept.com/2015/02/19/great-sim-heist/
I have talked to telephone engineers and they said they could read all passing SMSs verbatim when they hooked up to a cell tower to debug stuff.
Dunno if that is still the case though. However, cell phones as secure communication did not use to be the case.
You would probably want to communicate with encrypted data traffic device to device.
From what I remember from early 2000’s only the air interface was encrypted. Since anyway they have to provide lawful intercept capability there was not much benefit in providing end to end encryption. It’s not like it was a top of mind feature for consumers.
> It’s not like it was a top of mind feature for consumers.
BlackBerry got some market share for promoting their encryption.
Of course the encryption was complete junk, possibly worse than junk because of the false sense of security, unless you were an enterprise customer.
https://www.theregister.com/2016/04/15/canada_blackberry_wat...
You appear to be neglecting the need for symmetric stream ciphers to achieve realtime communications (needed for performance reasons). No matter what you do, you are going to have a symmetric key in there somewhere for adversaries to extract. Once the adversary owns the telco, it is over (i.e., calls can be decrypted), no matter how strong the cryptography is. Your strongest cryptography cannot withstand a key leak.
Do you know how TLS works? The asymmetric keys are used to negotiate temporary symmetric keys, which are used for the actual data. That's exactly what the mentioned Diffie-Hellman algorithm does. Also check out "perfect forward secrecy".
> To me, this absolutely feels like a NOBUS vulnerability, if the SIM manufacturers and/or core network equipment vendors are in cahoots with the NSA and let the NSA take those keys, they can potentially listen in on all mobile phone traffic in the world.
This feels like the obligatory XKCD comic[1] when in reality there isn't any secretive key extraction or cracking...things are just sent unencrypted from deeper into the network to the three-letter-agencies. Telco's are well known to have interconnect rooms with agencies.
[1] https://xkcd.com/538/
> Telco's are well known to have interconnect rooms with agencies.
Maybe these connections are a requirement for their permits in the first place. Who knows?
https://en.wikipedia.org/wiki/Qwest#Refusal_of_NSA_surveilla...
Not a requirement, but if for some reason you don't do the Right Thing that the NSA wants, oh dear your CEO goes to jail, he was a bad boy, look at all that insider trading. You'll do the Right Thing next time we ask, capiche?
https://en.wikipedia.org/wiki/Room_641A
Are you suggesting end-to-end encryption? Telecom providers have to implement "lawful intercept" interfaces to comply with the law in many jurisdictions.
I worked for a major telco in technical support/customer service.
I saw numerous security issues, and when I brought them up, with solutions to improve the service for customers, I was informed the the company would lose money.
Scammers are big customers for telcos, and when they get caught, and banned, they come back again and pay a new connection fee and start the cycle again. Scammers also enable feature upselling, another way to profit from not solving the problem.
"I don't understand it, must be <insert conspiracy>."
You realize this exact thing was in the Snowden docs a decade ago? This exact worry, sim keys being hacked by the NSA, was in the leaks.
You seem to have forgotten, anything inconvenient to the government is a conspiracy theory.
follow the money. perverse incentives at play.
I imagine most of the people running Freeswitch have their own patches on top of the community releases anyway so we're compiling those security fixes in to our own builds. That's what we did anyway when I worked for a place using Asterisk, Freeswitch, and OpenSER/Kamailio whatever it is called this decade.
"potentially thousands of telecom stacks around the world that SignalWire has decided to keep vulnerable until the Summer, even after they published the patches on GitHub."
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.
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.
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.
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.
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.
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 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.
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".
That's also how the majority of network appliances are handled outside of Telecom.
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.
One area where freeswitch is probably used quite often (and without support contract) are BigBlueButton installations (virtual classroom system) in schools and universities. I am more worried about them then about telcos.
I wonder how many people are even using the XML RPC module. It doesn't get loaded by default.
Edit: 468 according to Shodan. I'm wondering if senddirectorydocument gets used at all by the XML RPC module.
Following up on this, I was unable to get it to do anything.
Any ideas on triggering it? I imagine if we get a PoC that at least causes a segfault or whatever, they will be more likely to do a security release.I maybe wrong, but I think you need to enable the module for API access.
Yeah, it's enabled with `load mod_xml_rpc`. Listening on 8080.
hmmmWhy was FreeSWITCH written in C? Even in 2006 there were more secure alternatives.
We as an industry keep poking each ourselves in our collective eye with a sharp stick, wondering why it hurts.
It's the lang devs were comfortable with and some of them came from the asterisk world.
No major carrier is running FreeSwitch or Asterisk at the core.
Motorola's low-end 911 phone system, Emergency CallWorks (ECW), is Asterisk with proprietary modules running on Linux under Proxmox. Granted, Motorola is killing the produce, but it's out there. The one I babysit is heavily firewalled but I'd imagine not all of them are.
This very much depends on your definition of major.
Is that a Foss or GPL compliant codebase/OS?
I would dare to whisper that the lack of security suits the NSA just fine. However you can add just about every technically competent nation state, organised crime, major corporations, and a collection of non-state actors. About the only group besides us nomies who I think might really care about this are the payment rails folks as this insecurity facilitates more fraud.
Three thoughts.
1) To be slightly annoyingly contrarian, there is money to be made in secure telecom; Skype founders made a bundle, no?
2) This article conflates freeswitch with major telecom carrier infeastructure. My impression is that 30+% of the problem with security is not technical but economic. Carriers outsource a ton of their operations, effectively outsourcing most efforts to care about security... which never helps security posture unless the outsourcer considers their core value proposition, which they generally don't, instead pushing themselves as a cost/capitalization play.
3) No discussion of Matrix here as where things are headed, security-wise? https://matrix.org/blog/2024/10/29/matrix-2.0-is-here/
> Carriers outsource a ton of their operations
most of them - if not all of them. This article is from 2021:
https://berthub.eu/articles/posts/how-tech-loses-out/
Thanks for the pointer. What a /great/ article.
> 3) No discussion of Matrix here as where things are headed, security-wise?
From the same author (that is to say, from me): https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...
[dead]
Time to rewrite telecom software in Rust?
I’m guessing this is a joke.
Rust only fixes the memory safety issues. It doesn’t fix bad software design, the problem where we have to trust other companies to keep their security issues under control (eg. Cisco), and it can’t undo bad decisions that have become industry standards (eg. SS7)
SS7, to summarize charitably, was built assuming trust exists. Some of the vulnerabilites aren't vunerabilities, they're features!
SS7 wasn't a bad decision.
Allowing any random bozo to connect to the network's trusted center was a bad decision.
If the regulatory mandate to allow interconnection had also mandated the development and usage of a secure protocol for that interconnection, we'd be fine. But it mandated the opposite. Politicians got us into this mess, not programmers.
> (eg. SS7)
I don't have a lock on my mailbox. It is bad that the "low trust" internet overflows into my everyday life. I would rather that there was some separation of telephone calls, local community and banking etc from the lawless voids, than normalizing all these scams.
Telephone scam calls are mostly an internet problem.
This made me think, how many people have tried feeding some of this critical code to the best LLM models and asking it to point out any bugs?
You probably don't need an LLM to find vulnerabilities in software written like this. It took me a few minutes with GitHub in a web browser, but I'm sure you could make some headway with semgrep if you were bold enough.