Towards the end of last year, we learned that a group (allegedly affiliated with the Chinese government, referred to as “Salt Typhoon”) breached T-Mobile and other telecommunications companies and caused all sorts of havoc.
This isn’t really a blog post about that incident, but it was the catalyst that inspired a bit of curiosity within me.
I can’t (legally) access most mobile phone companies’ networks to see what vulnerabilities I can find, but there are plenty of open source software projects related to telecommunications on GitHub. So when I heard about the Salt Typhoon hacks, I wondered, “Is any of this open source telecom software any good?”
In a previous life, I worked with companies that used Asterisk and FreeSWITCH, but I’d never really looked into them beyond the surface-level familiarity congruent to “this uses a similar protocol as RedPhone, somewhere” (this was when Signal was still called TextSecure).
I don’t know much about PBX systems, SIP, or even audio encoding. Furthermore, some of the best C programmers I’ve ever met worked in telecom. Hell, some of the longest-running hacker communities have their roots in phone phreaking from the 1980s. Not to mention all the legendary engineers that trace their roots to Bell Labs.
This is all to say, I thought looking at this sort of software would be a fruitless endeavor.
Surely all of the low-hanging fruit would be found already?
Thus, I opened FreeSWITCH’s source code on GitHub and almost immediately found a vulnerability.
Buffer Overflow in HTTP Request Handler for XMLRPC
In this excerpt of code, the HTTP request handler for the XMLRPC library bundled with FreeSWITCH writes an arbitrary-length URI to a 4096-byte stack variable called z.
char z[4096];
char *p,z1[26],z2[20],z3[9],u;
const char * z4;
int16_t i;
uint32_t k;
if (text) {
sprintf(z, "Index of %s" CRLF, uri);
The uri variable is populated by the path part of the Request URI, which is attacker-provided.
This is not typically a problem, since most browsers don’t support URLs longer than 2048 characters, but the relevant RFCs support up to about 8 KB in most cases. (CloudFlare supports up to 32KB.)
I think it’s reasonable to assume that attackers are capable of sending a Request URI longer than 4096 characters.
Putting these observations together, it’s pretty easy to see this is a no-auth buffer overflow in their XMLRPC library.
Turning this into remote code execution is an exercise left to the reader (mostly because I’m not really up-to-date on OS-level exploit mitigation techniques, and how to bypass them).
How To Fix This Issue
This is kind of “defensive C programming practices 101” level.
Soatok Attempts Coordinated Disclosure
(n.b., Please stop saying “responsible” disclosure.)
2025-01-27: I send an email on to the email address listed on FreeSWITCH’s security policy with the details of the vulnerability.
2025-02-07: I send a follow-up email to ensure they received my report.
2025-02-07: Andrey Volk responds:
Hello Soatok.
Thank you for your email!
Issues you describe were recently fixed.
Please see:
https://github.com/signalwire/freeswitch/pull/2752
https://github.com/signalwire/freeswitch/pull/2753
https://github.com/signalwire/freeswitch/pull/2754
Best regards,
Since the fixes are now public, I’m left to assume that “embargo has broken,” so to speak. That means I’m free to blog about this publicly.
However, I notice they haven’t tagged a new release with this security fix for FreeSWITCH users. I reply:
Oh, wonderful. Thanks for getting back to me.
Do you have an ETA on when the release will be tagged? I don’t want to publish anything until people can easily install an updated version.
A few hours later, Andrey responds to my email.
Brace yourselves, it’s a stupid one.
…
Hello Soatok.
Thank you for your interest in FreeSWITCH.
We do not have plans to make a release of FreeSWITCH Community till summer 2025.
Best regards,
(Art: CMYKat)
What Just Happened?
To recap: An employee of SignalWire (which develops FreeSWITCH) came right out and said they would let people who aren’t paying for FreeSWITCH Advantage stay vulnerable until their regularly scheduled release (sometime in the Summer).
There are about 8,300 hits on Shodan for FreeSWITCH as I write this. I highly doubt they’re all paying for enterprise support, so we’re talking about 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.
While such a decision might be perfectly legal, it really does not inspire trust in the stewards of this software project to give a shit about the harm their careless coding practices inflict upon their users.
TelecomSec: A Systemic Issue
The worst part is, when I confided in a friend that works in telecom (after SignalWire published the fixes, of course) about this carnival-quality vulnerability management from the FreeSWITCH developers, their response was:
That fast?
[…]
December 2024 is the last time that alarms were once again raised about known SS7 vulnerabilities that have continued to exist in telephone networks for the past 17 years.
And, to be honest, that kind of took the wind out of my sails so I didn’t bother looking at Asterisk or any of the other software.
I mean, why bother? I already had the answer to the question that prompted me to look in the first place: Telecom security sucks today.
The reason things sucks is largely because there’s very little (if any) money to be made in securing these systems today.
Things don’t have to be this way, of course.
Maybe there’s some opportunity for some enterprising young hacker to write a FreeSWITCH competitor in Rust that has sane vulnerability management around it.
(Or, at least, is marginally harder to find vulnerabilities in than Damn Vulnerable Web Application. Maybe the OpenBSD team can be inspired to act?)
Maybe in the future, we’ll find the political will to invest in the security of America’s telecommunications infrastructure. Who knows, some of that money might even percolate towards open source software, and they can hire someone who knows how to run valgrind.
Or maybe everything will continue to suck, because incentives rule anything, and there currently aren’t any to do better.
Closing Thoughts
It took me a long time to write this one up, despite it being a rather simple technical issue, because I’m sure there are eldritch horrors lurking beneath the surface of this relatively simple finding.
The vendor’s response was pretty lame, yeah. But is this vendor the lamest in their industry? I’m not so sure about that one. At least they responded within 90 days and fixed the issue on their GitHub.
But, hey, if you’re waiting on SignalWire to get around to running git tag… maybe rebuild from source or block public HTTP access to your FreeSWITCH stack at the firewall level?
Sorry I can’t help more.