[HN Gopher] The insecurity of telecom stacks in the wake of Salt...
___________________________________________________________________
The insecurity of telecom stacks in the wake of Salt Typhoon
Author : zdw
Score : 241 points
Date : 2025-03-12 05:21 UTC (17 hours ago)
(HTM) web link (soatok.blog)
(TXT) w3m dump (soatok.blog)
| ofrzeta wrote:
| 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.
| posperson wrote:
| 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.
| tjohns wrote:
| 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.
| jvdvegt wrote:
| PSTN starts at the home router these days, I don't think I
| can get an actual analog line in my house.
| supertrope wrote:
| 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.
| ngneer wrote:
| Great example. Anyone who cavalierly states "let's do
| PKI!" has not done PKI.
| jauntywundrkind wrote:
| 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.
| surajrmal wrote:
| 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.
| jauntywundrkind wrote:
| 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.
| 1oooqooq wrote:
| 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.
| heraldgeezer wrote:
| >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...
| some_furry wrote:
| 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.)
| Semaphor wrote:
| > (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
| sunbum wrote:
| 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
| ikiris wrote:
| 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.
| 1oooqooq wrote:
| 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"
| ethagnawl wrote:
| 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.
| cyberax wrote:
| 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.
| surajrmal wrote:
| That's also how the majority of network appliances are
| handled outside of Telecom.
| cyberax wrote:
| 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.
| ofrzeta wrote:
| 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".
| amiga386 wrote:
| 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.
| tlb wrote:
| When the code is sprintf(stackbuf, "%s",
| attacker_supplied_input) in 2025, I expect some serious
| bowing and scraping.
| matthewdgreen wrote:
| In fairness, with that level of vulnerability in the code,
| fixing it is like using paper towels to mop up the ocean.
| camgunz wrote:
| Yeah if anyone thinks people don't just run searches for
| `sprintf` they're pretty naive.
| xvilka wrote:
| Time to rewrite telecom software in Rust?
| thephyber wrote:
| 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)
| zinekeller wrote:
| SS7, to summarize charitably, was built assuming trust
| exists. Some of the vulnerabilites aren't vunerabilities,
| they're features!
| thephyber wrote:
| Do you believe this statement refutes my claim that SS7 was
| badly designed?
| rightbyte wrote:
| > (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.
| thephyber wrote:
| I don't get how your anecdote relates to SS7. SS7 is
| available country-wide (I'm assuming it doesn't directly
| cross national borders) and the surface area of all of the
| cell towers and data centers they connect to is very large.
| Even larger if you consider all of the software that runs
| on the devices that are legitimately connected to that
| network. This isn't even remotely comparable to some
| fictional high trust small rural town where everyone knows
| everyone.
|
| I _do_ have a lock on my mailbox, but it has to adhere to
| the USPS skeleton keys (which have been leaked and are
| exploited by thieves). Another example of bad design, or at
| least design that wasn't able to withstand reasonably
| foreseeable changes to the operating environment.
| myself248 wrote:
| 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.
| thephyber wrote:
| I would argue it's the managers of the programmers who
| failed to foresee this as a future requirement, hence they
| didn't tell the programmers to make it resilient to
| reasonably foreseeable changes to the operating
| environment.
| myself248 wrote:
| It was not reasonably foreseeable. The Bell system had
| been a government-blessed monopoly since its inception.
| Pigs would fly before scammers were allowed to connect to
| raw SS7.
| richardwhiuk wrote:
| No major carrier is running FreeSwitch or Asterisk at the core.
| tonetegeatinst wrote:
| Is that a Foss or GPL compliant codebase/OS?
| Narkov wrote:
| This very much depends on your definition of major.
| EvanAnderson wrote:
| 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.
| shrubble wrote:
| That is not the core, however; the core means the central
| pieces of a large telecom, the part that handles all the
| needed data to set up say, 10,000 or more calls per second.
| EvanAnderson wrote:
| For sure. The implicit trust that participants on the PSTN
| appear to give to each other, imparts a certain amount of
| undue influence to the constellation of dodgy systems
| interconnected to it.
| kamma4434 wrote:
| Depends on your definition of 'major'
| heraldgeezer wrote:
| I am in the same boat as OP and the blog's example is a PBX
| software for business. I was also confused.
|
| Major carriers are like Vodafone, T-Mobile, O2, Telia etc :)
| cootsnuck wrote:
| No, but plenty of businesses that process your call data,
| whether it's for call recording, transcription, IVRs, speech
| analytics, CRM integration, call queuing, auto dialing, or
| SMS/chat features, are liable to be running stuff like
| FreeSWITCH, Asterisk, or similar somewhere in their stack.
|
| Any business with a PBX that wants to do more than just basic
| call routing and PSTN connectivity is likely using third party
| tools. And a significant number of those tools are built on
| FreeSWITCH, Asterisk, or similar.
| dqv wrote:
| 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.
| dqv wrote:
| Following up on this, I was unable to get it to do anything.
| curl --show-error --get --request GET --user freeswitch:works
| "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}"
|
| 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.
| dangerboysteve wrote:
| I maybe wrong, but I think you need to enable the module for
| API access.
| dqv wrote:
| 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>
|
| hmmm
| asimpleusecase wrote:
| 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.
| miki123211 wrote:
| 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-...
| Narkov wrote:
| > 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/
| bayindirh wrote:
| > 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?
| amiga386 wrote:
| https://en.wikipedia.org/wiki/Qwest#Refusal_of_NSA_surveill
| a...
|
| 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
| whyever wrote:
| Are you suggesting end-to-end encryption? Telecom providers
| have to implement "lawful intercept" interfaces to comply with
| the law in many jurisdictions.
| dylan604 wrote:
| That's fine. Let them have lawful intercept into my encrypted
| communications. Let them eat static
| secondcoming wrote:
| If it's all encrypted you wouldn't be able to call land
| lines.
| toast0 wrote:
| I think they're just suggesting improvements on device-to-
| network encryption. Requiring the sim card secret to live on
| the sim card and the network means it needs to be transmitted
| from manufacturing to the network, which increases exposure.
|
| If it were a public/private key pair, and you could generate
| it on the sim card during manufacturing, the private key
| would never need to be anywhere but the sim card. Maybe
| that's infeasible because of seeding, but even if the private
| key was generated on the manufacturing/programming equipment
| and stored on the sim card, it wouldn't need to be stored or
| transmitted and could only be intercepted while the equipment
| was actively compromised.
| johnwayne666 wrote:
| 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/
| 2OEH8eoCRo0 wrote:
| "I don't understand it, must be <insert conspiracy>."
| KevinGlass wrote:
| 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.
| DaSHacka wrote:
| You seem to have forgotten, anything inconvenient to the
| government is a conspiracy theory.
| newsclues wrote:
| follow the money. perverse incentives at play.
| newsclues wrote:
| 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.
| rightbyte wrote:
| 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.
| ArnoVW wrote:
| 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.
| Scoundreller wrote:
| > 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_wa
| t...
| immibis wrote:
| Blackberry's (probably) legally allowed to provide text
| message encryption, but telcos aren't. "Lawful intercept"
| (which should more accurately be called "gunpoint
| eavesdropping") is a legal requirement for all telcos,
| and the larger the telco, the more optimized and
| automated the process is required to be. They _have_ to
| be able to read customer SMSes and tap phone calls. If
| the SMS happens to be gibberish, that 's not their
| problem, but they can't _make_ it gibberish.
| marcus0x62 wrote:
| In the late 90s/early 2000's, I would hear voice telephone
| conversations in central offices quite frequently. (Nobody
| was spying on purpose, or even paying much attention to what
| was being said. It was incidental to troubleshooting some
| problem report.)
| ethagnawl wrote:
| I'll bet you've got some other great war stories, too.
| marcus0x62 wrote:
| Most of my telecom experiences were pretty boring. It
| largely consisted of handling digital circuits for modem
| banks, then later setting up a very small CLEC and
| building small PBX systems out of open source software in
| the early 2000s, which at the time worked about as well
| as you might imagine[0]. The outside plant people for the
| local ILEC had the _best_ war stories:
|
| * Someone tried to carjack a friend while he was
| suspended in the air in the bucket of a bucket truck,
| making a repair in a splice case[1].
|
| * Another friend was making a repair in a bad part of
| town, and while doing some work in junction box (larger,
| ground-based version of a splice case,) a drug addict
| hobbled out of a nearby house and asked him if he was
| with the phone company. When he replied in the
| affirmative, the drug addict asked him to call 911 as one
| of his compatriots was ODing.
|
| ... etc...
|
| I did get to help another service provider recover from a
| tornado by physically removing mud and debris from their
| equipment over the course of a few days and powering it
| back on. It almost all worked, with a few parts swapped
| out. I wrote about that one[2].
|
| *Edit* I forgot I have one good CLEC war story. I wrote a
| test system that ended up calling 911 several times and
| playing a 1 kilohertz test tone at the 911 operator until
| they hung up. The test system was meant to troubleshoot
| an intermittent call quality issue that we were having
| difficult isolating. It consisted of a machine with a SIP
| trunk on one side and an analog telephone on the other.
| It would call itself repeatedly, play the 1k test tone to
| itself, and look for any audio disturbances, and record a
| lot of detail about which trunks were in use, etc., when
| that occurred. That all worked fine. The problem was the
| telephone number for the SIP trunk, which I remember to
| this day (20 years later) - 5911988. Every once and a
| while, when calling the SIP trunk from the analog line
| (this thing made _thousands_ of calls,) the leading 5
| wouldn't get interpreted correctly, and the switch would
| just process the subsequent digits... 9, 1, 1 - as soon
| as that second one was processed, it sent the call to the
| local PSAP. After a few days a police officer showed up
| and asked us to please stop whatever it was we were
| doing.
|
| 0 - "not at all"
|
| 1 - in the US, anyway, these are the black cylindrical
| objects you see suspended from cables strung along
| utility poles
|
| 2 - https://marcusb.org/posts/2023/11/a-real-life-
| disaster-recov...
| zelon88 wrote:
| This is still the case when troubleshooting POTS lines on
| analog PBX systems.
|
| All you need is the probe side of a tone generator and you
| can listen to analog phone conversations in progress with
| no additional configuration or hardware.
| marcus0x62 wrote:
| That's done sometimes in central offices, although for
| analog lines a lineman's handset was the more common
| tool.
|
| Digital test systems (I don't know what they use now;
| back then the venerable T-BERD 224 was the standard tool)
| can decode a single DS0 out of a larger multiplexed
| circuit and play the audio back and usually allow you to
| insert audio into a channel. That's normally what was
| being used to isolate a fault at one or more of the
| mux/demux/translation points.
| codedokode wrote:
| Not only they can read, they probably record them because SMS
| don't use much space.
| ngneer wrote:
| 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.
| andrewflnr wrote:
| 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".
| xen2xen1 wrote:
| Phase 1 and Phase 2.
| ngneer wrote:
| Of course I know how TLS works, as well as PFS. I recommend
| Kaufman on the subject. The general scheme you refer to is
| known as hybrid cryptography, and the key material that is
| derived is used to generate symmetric keys for the TLS
| session (several keys, in fact, separately for
| confidentiality and integrity, and for duplex
| communications). You missed my point completely, though.
| Unlike TLS sessions, which rely on packets, calls are
| multiplexed with TDMA or CDMA, for example. Unlike TCP,
| these channels have realtime requirements that necessitate
| stream ciphers be employed. I could ask you if you know how
| telecom works, but that would be childish and demeaning. As
| ephemeral as you wish to make it, the telco must know the
| secret key, for imagine if the call is being relayed to
| Timbuktu and must be passed in plaintext.
| lxgr wrote:
| > these channels have realtime requirements that
| necessitate stream ciphers be employed
|
| Even if that were relevant (you can easily convert a
| block cipher to a stream cipher): It's absolutely
| possible to do key derivation for a symmetric stream
| cipher asymmetrically.
|
| > the telco must know the secret key
|
| No, the telco must _not_ know the secret key if they 're
| serious about confidentiality.
| ngneer wrote:
| Right, let's redesign telecom infrastructure...
| lxgr wrote:
| Isn't every new mobile standard effectively a complete
| redesign of the core network anyway?
|
| Sure, it'll take decades to be fully rolled out, but
| that's true for every large-scale change. The real
| problem is that it's not in the interest of stakeholders
| to have end-to-end security.
| ngneer wrote:
| You can "easily" convert a block cipher to a stream
| cipher on paper (e.g., using OFB or output feedback
| mode), but you will not get the performance. You clearly
| have no working knowledge here.
| lxgr wrote:
| I don't doubt that it's hard _in existing systems_ ,
| which might not have AES hardware instructions, spare
| processing power available etc., but my point is more
| that, _if it were made a design goal_ , it would be
| absolutely feasible.
|
| If we can encrypt basically every HTTP request on the
| Internet, surely we can encrypt a few phone calls too?
|
| But the main problem is not technical, but that
| stakeholders don't want to anyway (lawful interception
| etc.), so presumably nothing will change.
| tsimionescu wrote:
| > If we can encrypt basically every HTTP request on the
| Internet, surely we can encrypt a few phone calls too?
|
| Again, you seem to not understand the performance
| requirements of real-time audio. The amount of data is
| tinry, but the latency (and particularly jitter)
| requirements are on a completelt different level than
| HTTP.
| lxgr wrote:
| Given that Signal and WhatsApp manage it just fine even
| on the slowest Android smartphones made in the past
| decade (without hardware AES acceleration), I'd say you
| are vastly overestimating the computational load of
| symmetric encryption.
|
| The added latency is probably undetectable, and unless
| the CPU is at capacity, there's no extra jitter either.
| andrewflnr wrote:
| You're telling me it's absolutely impossible to run a key
| exchange over these channels?
| ngneer wrote:
| Not without redesign. I am telling you that whatever key
| exchange you run, it will result in key material that is
| accessible by the telco and therefore by your adversary
| (e.g., PRC). This is true even if you deployed
| authenticated Diffie-Hellman between endpoints. You might
| be able to do secure VoIP on top of that, but you cannot
| use existing telco infrastructure for your calls without
| expecting the tower to be able to decrypt the call. The
| ability of the telco to decrypt the call is the very
| basis of CALEA and LI, or lawful interception modules,
| and the reason why Salt Typhoon works.
| andrewflnr wrote:
| The point is to limit the damage of a key leak, not
| eliminate it. Limiting the scope of a compromise to a
| single connection rather than all communications for the
| past and future is an improvement.
|
| And yeah, of course we're talking about a redesign. If we
| were content with the status quo why would we be here?
| lxgr wrote:
| Yes, but that "somewhere" could very well be only the two
| phones involved in a call, with key establishment happening
| via Diffie-Hellman. Doesn't protect against an active attack,
| but there's no key to leak inside the network.
| ngneer wrote:
| Right, let's redesign telecom infrastructure...
| some_furry wrote:
| After seeing STIR/SHAKEN's implementation details (hey
| what if we used JWT, and then maximized the metadata
| leakage of who you're calling), I really do not want to
| trust telecoms to roll their own crypto.
|
| https://securitycryptographywhatever.com/2024/04/30/stir-
| sha...
| lxgr wrote:
| At least they're now only botching protocols instead of
| self-rolling low-level primitives like block and stream
| ciphers...
| lxgr wrote:
| Some of these algorithms have to run on the SIM card, and smart
| cards (at least in the past) don't support RSA or (non-
| elliptic-curve) DH without a coprocessor that makes them more
| expensive.
|
| Also, symmetric algorithms are quantum safe :)
|
| But yes, I also wish that in 2025 we'd at least support ECC,
| which most smart cards should support natively at this point.
|
| > 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.
|
| If you can't trust your SIM card vendor, you're pretty much out
| of luck. The attack vector for an asymmetric scheme would look
| a bit different, but if you can't trust the software running on
| them, how would you know if they were exfiltrating plaintexts
| through their choice of randomness for all nondeterministic
| algorithms?
| tptacek wrote:
| If you have the ability to distribute keys directly, asymmetric
| cryptography adds complexity without much payoff. Certainly the
| idea that introducing RSA to a symmetrical system makes it
| _more_ sound isn 't well supported; the opposite is true.
|
| The "NOBUS vulnerability" thing is especially silly, since the
| root of trust of all these systems are telecom providers. You
| don't have to ask if your American telecom provider is "in
| cahoots" with the US intelligence community; they are.
| gregw2 wrote:
| 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/
| svilen_dobrev wrote:
| > 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/
| gregw2 wrote:
| Thanks for the pointer. What a /great/ article.
| some_furry wrote:
| > 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...
| lsnd-95 wrote:
| 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.
| 0xbadc0de5 wrote:
| 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.
| matthewdgreen wrote:
| 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...
| 0xbadc0de5 wrote:
| Correct. Both the US and Canada also did similar
| investigations and came to similar conclusions.
| gmueckl wrote:
| The ban always seemed weird to me. Not even a shred of a
| technical argument made it into public discourse when this
| was an issue. Governments just said "trust us" without
| giving any examples. This thread is the first time I read a
| hint at why that decision was made. Still, I don't know how
| much of this was a political stunt vs. grounded in reality.
| Maybe I am too jaded/cynical?
| dralley wrote:
| I mean, it obviously did make it to the public because
| that WP article was written in 2019, and I remember
| hearing some of those details (that it wasn't so much
| "the code has backdoors" as "the code is so shit, it
| doesn't even matter if there's a backdoor in there
| deliberately") back then.
|
| By the time any highly-technical topic makes it to the
| mainstream discourse, the details tend to get stripped
| out simply because none of the 70 year olds watching CNN
| or Fox appreciate the difference and none of the anchors
| or panelists know what they're talking about either.
| some_furry wrote:
| A song parody comes to mind (HN strips the music emoji)
| We built this city We built this city We
| built this city on broken code
| 0xbadc0de5 wrote:
| When it comes to government, it's hard to be too cynical.
| But in this particular case, it definitely was not a
| political stunt. There are a number of reasons for the
| limited disclosure - including NDA's signed by the
| governments and labs with the vendors in order to gain
| access to their intellectual property at a level
| sufficient to conduct the depth of analysis required.
| heraldgeezer wrote:
| Government has a mandate. That's how it can function.
| They have evidence, why reveal it to the public (and thus
| china)? I grew out of my Ron Paul phase at 15.
|
| You trust China over your own government? Move then.
| gmueckl wrote:
| Whoa there, kiddo! I deeply, deeply resent being called
| 15! The tone of your comment is just wild.
|
| I am old enough to have seen several instances where
| organizations had internal reasons for their decisions
| and chose to argue something completely different in
| their outward communication. Given that an exclusion of
| Huawei had the obvious side effect of protecting domestic
| markets, this leaves quite some room for doubt around
| this specific instance. You say it yourself that
| governments have mandates.
| FreebasingLLMs wrote:
| 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.
| codedokode wrote:
| Does it send more data to more endpoints than US-made
| Windows OS (I wiresharked it in a VM so I know)?
| FreebasingLLMs wrote:
| I'm not comparing it to an OS. I'm comparing it to other
| competitors in the particular solution space. To answer
| your question: no one else's equipment behaved in that
| manner.
| secondcoming wrote:
| Was this for phones or home routers?
| Scoundreller wrote:
| That kind of analysis needs a control.
|
| But I guess it's like you said: a political experiment.
| Etheryte wrote:
| Does it really need a control when many countries across
| the globe have independently tried it out and reached the
| same conclusion? I would say the results are pretty clear.
| kbolino wrote:
| The purpose of the control would be to establish whether
| the competition is actually any better.
| tristor wrote:
| That control already exists because similar levels of
| audits have already happened on the competition. I'm not
| saying the competition is a shining example of quality,
| it definitely isn't, but it meets a bar of some set of
| basic security compliance standards.
| matthewdgreen wrote:
| The main purpose of this system was not to judge code
| quality (although that's a _very useful_ side effect!)
| The goal was to convince politicians that they could
| allow the installation of cheaper telecom hardware made
| by a geopolitical rival, yet also protect themselves from
| espionage and deliberate sabotage.
|
| Now personally I would say that this is a crazy idea from
| the jump, given the usual asymmetry between attackers and
| defenders. But even if you grant that it's possible, it
| requires that you begin with extremely high standards of
| code quality and verifiability. Those were apparently not
| present.
| thfuran wrote:
| But if they're no worse than the alternative, there's no
| point in spending the extra money.
| godelski wrote:
| You're not thinking of the entire scope of the issue. For
| example, the UK cannot legislate Huawei or any other
| Chinese company. You might say that that's true about the
| US too, and to some degree you'd be correct, but this
| also isn't taking into account that the US is (was?) a
| strong ally and this provides much more leverage over the
| situation. It ALSO means that IF these networks are being
| used to spy on citizens that there's a lower worry (still
| a worry, but lower). It would also mean that if this data
| is not being shared with the UK then this would be a
| violation of the 5 eyes agreement, which means the UK has
| more leverage over that situation.
|
| So yeah, even if they are equal, there are A LOT of
| reasons to spend the extra money.
| groby_b wrote:
| But they are worse. Massively so.
|
| Also, even if all providers provide equally crappy
| versions, it's _still_ slightly more secure to prefer a
| vendor in your own or an allied nation. At least your
| interests are mildly aligned.
|
| But really, they are massively worse.
| 0xbadc0de5 wrote:
| Anecdotally, having done multi-year deep-dive security
| reviews of both Asian and Western carrier equipment (and
| compared notes with many colleagues working on similar
| efforts), there is a stark difference. It's not even
| close. I've focused on firmware security analysis of
| RAN/eNodeB/gNodeB equipment but have also done many
| pentests targeting core infra as well. Western nations
| have actually done the baseline assessment over years and
| years of deployment and defence - this is why we are able
| to see the contrast in the comparison.
| godelski wrote:
| That's a different kind of experiment and I just got to
| say that there is no "one size fits all" method of
| experimentation. The reason there doesn't need to be a
| control here is because comparitors have ZERO effect on
| the answers being asked. The question
| being tested is: - Do Huawei devices have the
| capacity for adequate capacity Not - Are
| Huawei devices better or on par in terms of security
| compared to other vendors.
|
| These are completely different questions with completely
| different methods of evaluation. And honestly, there is
| no control in the latter. To have a control you'd have to
| compare against normal operating conditions and at that
| point instead you really should just do a holistic
| analysis and provide a ranking. Which is still evaluating
| each vendor independently. _You don't want to compare_
| until the very end. Any prior comparison is only going to
| affect your experiments.
|
| tldr: most experiments don't actually need comparisons to
| provide adequate hypothesis answering.
| ghostpepper wrote:
| How does a regular hacker get their hands on this kind of
| equipment to do research?
| 0xbadc0de5 wrote:
| eBay, Alibaba, various grey-market sellers. There's no
| shortage of availability if you know what to look for.
| markus_zhang wrote:
| Just curious is there write ups on certain devices? Would love
| to buy one from Ali express and look into this.
|
| Is this a good starting point?
|
| https://vulners.com/search/types/huawei
| hulitu wrote:
| > 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.
|
| Thank god we have the hardware and software vendors from a
| certain north american state, who take security very seroisly.
| Oh, wait ... /s
| shakna wrote:
| At least those can currently pass industry level audits.
| mschuster91 wrote:
| Given that Cisco has RCEs and hardcoded credential CVEs at
| least once every half year or so, the question does arise
| if our current level of audits is even remotely sufficient.
| And it's not Cisco alone - _any_ major vendor of VPN or
| firewall or general network gear suffers from the same
| problem.
| eadmund wrote:
| Why 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.
| dangerboysteve wrote:
| It's the lang devs were comfortable with and some of them came
| from the asterisk world.
| traceroute66 wrote:
| 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.
| BEBAA7 wrote:
| In Signalwire's defence, reading through the old mailing list,
| I got the feeling they drove the development of Freeswitch for
| years without being properly compensated by downstream
| projects. Sadly I've also seen other parts of the Voip
| community recalibrate their generosity when it comes to open
| source and I honestly can't blame them.
|
| The team behind Matrix.org talked about a similar problem in
| one of their FOSDEM'25 talks: commercial vendors free loading
| on development.
| tmaly wrote:
| 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?
| some_furry wrote:
| 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.
| ngneer wrote:
| First, can you point to examples where using LLMs to find
| vulnerabilities works?
| johann8384 wrote:
| 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."
| CursedSilicon wrote:
| In a past life I worked at AWS as a support engineer
|
| I once got a ticket from T-Mobile (US) asking what "AWS's best
| practices were around security patching. How long should we
| wait?"
|
| A week later they admitted to an enormous data breach
|
| I'd say I switched phone carriers after that, but after working
| in the ISP market I already knew they were all absolute clown
| shows where all the money only went to C-levels and not
| infrastructure or security
| lenerdenator wrote:
| I think it's fair to assume that between foreign threat actors,
| the Five Eyes/other Western pacts, and the demand to make the
| line go up, there's no _real_ anonymity online. If they want you,
| they 've got the means to get you.
|
| In reality that's really no different than the pre-internet age.
| If you don't want your stuff intercepted, you need to encrypt it
| by means that aren't trivial to access electronically for a major
| security apparatus. Physical notes, word-of-mouth, hand signals,
| etc.
|
| Also, you need to be ready for the consequences of what you say
| and do online should a state actor decide to allocate the
| resources to actually act upon the data they have.
| Nextgrid wrote:
| I highly recommend checking out P1 Security's presentations
| around mobile telco security:
| https://www.slideshare.net/slideshow/day1-hacking-telcoequip....
|
| It's old but there's no reason to believe things have improved as
| there are zero incentives to. Also, software security
| vulnerabilities are only part of the problem - the other part is
| that telcos _willingly_ outsource control and critical access to
| the lowest bidder: https://berthub.eu/articles/posts/5g-elephant-
| in-the-room/
| sakras wrote:
| I've been beating the drum about this to everyone who will listen
| lately, but I'll beat it here too! Why don't we use seL4 for
| everything? People are talking about moving to a smart grid,
| having IoT devices everywhere, putting chips inside of peoples'
| brains (!!!), cars connect to the internet, etc.
|
| Anyway, it's insane that we have a mathematically-proven secure
| kernel, we should use it! Surely there's a startup in this
| somewhere..
| wmf wrote:
| Rewriting all software would cost infinite money.
| sakras wrote:
| New smart grids with new software do not require a rewrite!
| ngneer wrote:
| They will!
| wmf wrote:
| Almost all vulnerabilities are in apps and libraries which
| seL4 does little or nothing to solve. The only solution is
| secure coding across the entire stack which will reveal
| that much of the existing code is so low-quality that it
| just has to be thrown away and rewritten.
| ta20240528 wrote:
| The really good hacks happen with CAMEL MAP injection. Controls
| all sorts of goodness like SMS, USSD, and the crown jewel:
| location services.
|
| Many a "bulk SMS" provider in places like the richer carribean
| islands, and Indonesia that do a lot more than send spam.
| heraldgeezer wrote:
| To add, MAP is 2G and 3G.
|
| So, it is old. 2G was designed in the 90s.
|
| I don't really know what people expect? I'm just happy it works
| at all, lol.
| capitainenemo wrote:
| From the article. "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.)"
|
| So obviously relying on browsers is not enough, but a nitpick.
| The article links to a stackoverflow which actually notes
| browsers support a lot more. Browser
| Address bar document.location or anchor tag
| ------------------------------------------ Chrome
| 32779 >64k Android 8192
| >64k Firefox >300k >300k
| Safari >64k >64k IE11
| 2047 5120 Edge 16 2047 10240
| some_furry wrote:
| Ah, that's fair.
| kamma4434 wrote:
| I wonder who in practice runs XMLRPC today. My feeling id that
| nobody looked at that code in decades, because nobody cares.
| heraldgeezer wrote:
| SS7 again... ofc. Kinda tiresome now.
|
| Yes, insecure, but needed. Unless you want to shut down 2G and 3G
| worldwide. It is happening, slowly.
|
| The FreeSwitch stuff? Telcom buy from vendors like Nokia, Cisco,
| Ericsson, Huawei where they can't see src anyway.
___________________________________________________________________
(page generated 2025-03-12 23:00 UTC)