Speaker 1: Welcome back to the deep dive. Today, we are cracking
Speaker 1: open the essential digital infrastructure that connects us all telecommunications networks.
Speaker 2: Yeah, absolutely essential.
Speaker 1: We depend on them for everything, I mean really.
Speaker 2: Everything, which makes them, you know, incredibly attractive targets for.
Speaker 1: Any serious adversary, right, nation states, organized crime exactly.
Speaker 2: So our mission today is a deep dive into the
Speaker 2: emerging state of security in these crucial systems. Okay, we've
Speaker 2: pulled together analysis on vulnerabilities cellular data, SMS, voiceover IP, and.
Speaker 1: We're focusing on why, right, why are these networks sometimes
Speaker 1: so fragile?
Speaker 2: Precisely, the sources suggest it really comes down to this
Speaker 2: collision old meets new.
Speaker 1: The old phone system architecture, yeah.
Speaker 2: The legacy stuff bumping right into the modern Internet.
Speaker 1: But maybe first let's quickly define security in this context.
Speaker 1: Our sources put it pretty simply.
Speaker 2: Right, Security is just the expectation that a system will
Speaker 2: behave like.
Speaker 1: You think it should as anticipate.
Speaker 2: Yeah, and we're going to look at where that expectition
Speaker 2: just gets completely well betrayed. We'll show how these fundamental
Speaker 2: conflicts in the design things inherited from frankly an era
Speaker 2: of blind trust. They don't just create gaps, They actually
Speaker 2: create mechanisms for amplification. Amplification meaning meaning simple low effort
Speaker 2: attacks can cause catastrophic denial of service, much bigger impact
Speaker 2: than you'd expect.
Speaker 1: Okay, so let's dig into those roots. The historical side.
Speaker 1: You mentioned blind trust.
Speaker 2: Yeah, the first failure point was really architectural. It was
Speaker 2: built on trust.
Speaker 1: Traditional systems like the old digital backbone SS seven Signaling
Speaker 1: System number seven exactly.
Speaker 2: They were built assuming a totally controlled.
Speaker 1: Environment like a walled garden.
Speaker 2: Pretty much the phone company was a fortress. Why authenticate
Speaker 2: signals between core machines if they're all supposedly inside your trusted.
Speaker 1: Walls, right, makes sense in that old context.
Speaker 2: But that lack of authentication between say, routers and switches
Speaker 2: back then, that vulnerability state echoes today in parts of
Speaker 2: our cellular infrastructure. It's foundational.
Speaker 1: And even before s S seven was really a big target,
Speaker 1: you had the originals, the phone freaks.
Speaker 2: The phone freaks, yes, which is just wild when you
Speaker 2: think about it.
Speaker 1: They proved you could exploit that trust with like the
Speaker 1: simplest tools.
Speaker 2: It's true. Back then, the signals managing your call routing,
Speaker 2: set up billing traveled on the same physical line as your.
Speaker 1: Voice that was inband signaling.
Speaker 2: In band signaling, and the freaks figured out that if
Speaker 2: they played a specific tone twenty six hundred hertz, the
Speaker 2: magic twenty six hundred hertz tone. Yeah, the network heard
Speaker 2: that and thought, okay, hang up the trunk line, stop billing.
Speaker 1: But the call was already connected exactly.
Speaker 2: So they just kept talking free long distance.
Speaker 1: Using things like a blue box or I love this
Speaker 1: the whistle from a cap'n Crunch cereal box.
Speaker 2: Yeah, the cap'n Crunch whistle. It's almost unbelievable. A kid's
Speaker 2: toy defeated this massive infrastructure just.
Speaker 1: By speaking the network's interurn old secret language.
Speaker 2: That vulnerability was so deep they had to completely rip
Speaker 2: out in band signaling, move it.
Speaker 1: Out of ban a whole redesign.
Speaker 2: But then history repeats. We moved to digital celluler GSM.
Speaker 1: Networks and made a similar mistake.
Speaker 2: Basically, yes, this time with weak cryptography.
Speaker 1: Okay crypto. We hear about strong crypto, and there's this
Speaker 1: core idea Kirkoff's principle, right.
Speaker 2: Kirkhoff's principle says, a strong system assumes the bad guy
Speaker 2: knows how it works. The only secret should be.
Speaker 1: The key, the algorithm itself should be public.
Speaker 2: And strong, precisely, But early GSM ciphers like A fifty one,
Speaker 2: and especially the deliberately weakened export version.
Speaker 1: A fifty two, they weren't strong.
Speaker 2: Not even close, and they relied on keeping the algorithm's secret,
Speaker 2: which is the opposite of Kirkoff's why weakened Well, The
Speaker 2: sources point to political pressure. Back then, governments didn't want
Speaker 2: strong encryption getting out, especially overseas.
Speaker 1: A export controls.
Speaker 2: Yeah, but that political choice led directly to a massive
Speaker 2: security failure. How bad was Researchers like ber Ucov later
Speaker 2: showed A fifty one the main cipher. You could get
Speaker 2: the key on a standard PC.
Speaker 1: Yeah, how long did it take?
Speaker 2: Under a second?
Speaker 1: Wow?
Speaker 2: And a fifty two the weekend one ten milliseconds basically instantaneous.
Speaker 1: So real time decryption of calls was.
Speaker 2: Possible, absolutely, and it wasn't just eavesdropping. The authentication algorithm comp.
Speaker 1: One eight, the one that checks if your phone is legit.
Speaker 2: Yeah, it was so flawed attackers could potentially clone sim
Speaker 2: cards or worse craft messages to lock legitimate users out
Speaker 2: completely denial of service.
Speaker 1: Again, that sounds like a nightmare to fix it was.
Speaker 2: Took years replacing millions of SIM cards worldwide to patch
Speaker 2: those fundamental digital holes.
Speaker 1: Okay, so we had trust issues, crypto issues. Let's talk
Speaker 1: architecture now. Yeah, where's the design conflict causing these new problems?
Speaker 2: Right? The core conflict now is really rigidity versus flexibility,
Speaker 2: Meaning well, think about how old phone networks were built
Speaker 2: for voice calls. Right, that's rigid.
Speaker 1: Get switched traffic, like reserving a dedicated pipe for.
Speaker 2: The whole call exactly, a guaranteed connection, no sharing, no interruptions, ideally,
Speaker 2: very predictable, very rigid.
Speaker 1: But now everything runs on packet switch data the Internet model.
Speaker 2: Right, data chopped into little packets, routed flexibly, sharing the
Speaker 2: network efficiently. Total opposite philosophy, and this clashes massively. It
Speaker 2: leads to violations of a key Internet principle, the end
Speaker 2: to end argument.
Speaker 1: Okay, what's that argue?
Speaker 2: It basically says the network itself should be done just
Speaker 2: forward packets, keep it simple.
Speaker 1: All the complex of like making sure data arives reliably
Speaker 1: or managing a session you should happen.
Speaker 2: At the ends on your phone, on the server, not
Speaker 2: in the middle of the network.
Speaker 1: But cellular networks do put intelligence in the middle, don't they.
Speaker 2: They absolutely do. They have to think about it. They
Speaker 2: need to know where your phone is, manage battery life
Speaker 2: by putting it to sleep.
Speaker 1: Stuff. The basic Internet doesn't worry.
Speaker 2: About exactly, but building that intelligence, that state management into
Speaker 2: the network core that creates rigidity.
Speaker 1: And that rigidity that's the weakness.
Speaker 2: It creates the opportunity for weakness, especially amplification. Here's why.
Speaker 2: In the packet world, the basic unit is one small packet. Okay,
Speaker 2: in the cellular world, especially older standards, receiving even one
Speaker 2: packet can trigger this expensive, complex sequence of actions to
Speaker 2: do what to set up a much larger virtual resource
Speaker 2: for your phone, a channel. It allocates resources based on
Speaker 2: that old voice model.
Speaker 1: So a tiny input triggers a big, heavyweight response from
Speaker 1: the network.
Speaker 2: Precisely, It's like you knock lightly on a bank vault door,
Speaker 2: and instead of just checking who's there, they swing the
Speaker 2: whole mass door open, call in extra guards, block off
Speaker 2: the hallway.
Speaker 1: Okay, I get the analogy.
Speaker 2: When an attacker sends thousands of those little knocks, the
Speaker 2: network exhausts itself doing these heavyweight setups over and over.
Speaker 1: It overreacts based on its rigid design.
Speaker 2: That's the amplification exploiting the network's mandatory, expensive procedures.
Speaker 1: Okay, let's see this amplification play out the SMS bottleneck attack.
Speaker 1: It sounds counterintuitive, it really does.
Speaker 2: But yeah, you can weaponize text messages to block voice calls.
Speaker 1: How on earth does that work? It seems like such
Speaker 1: a basic function.
Speaker 2: It works because of a shared resource conflict deep in
Speaker 2: the architecture. Both voice calls and incoming SMS messages need
Speaker 2: the same thing to get started, which is these things
Speaker 2: called standalone dedicated control channels sdcchs. Okay, sdcs, think of
Speaker 2: them as the on ramps or the setup coordinators for
Speaker 2: the cell tower. Very limited capacity. How limited The sources
Speaker 2: give examples like maybe only nine hundred SMS sessions per
Speaker 2: hour per channel.
Speaker 1: That sounds tiny, especially for a busy city.
Speaker 2: It is incredibly low, So the exploit is painfully simple.
Speaker 2: An attacker uses just a little bit of bandwidth like
Speaker 2: a home internet connection, yeah, comparable to a cable modem.
Speaker 2: They just pump enough bogus SMS set up requests into
Speaker 2: the network to keep those sdcchs constantly busy.
Speaker 1: Like creating a traffic jam on those critical on.
Speaker 2: Ramp exactly gridlock. And here's the aha moment. As you said, ye,
Speaker 2: once those sdcchs are saturated with fake SMS traffic, they
Speaker 2: can't be used to set up voice calls either.
Speaker 1: Oh wow, So blocking texts also blocks calls because they
Speaker 1: share that initial choke point.
Speaker 2: That's it. Legitimate calls, legitimate texts, nothing can get established.
Speaker 1: What's the impact In reality?
Speaker 2: The researchers modeled this for a major city like Manhattan,
Speaker 2: minimal attack resources could block seventy one percent of call and.
Speaker 1: Text attempts seventy one percent. That's basically taking the network.
Speaker 2: Down pretty much, near total denial of service with almost
Speaker 2: no attack or bandwidth, just by exhausting those rigid set
Speaker 2: up resources.
Speaker 1: And this extends to data too. GPRS edge the older
Speaker 1: data standards.
Speaker 2: Directly similar principle, different mechanism. Remember the network managing device
Speaker 2: states idly standby ready to save battery.
Speaker 1: Right.
Speaker 2: Getting a device into that ready state where it can
Speaker 2: actually send and receive data involves paging it, locating it,
Speaker 2: setting up this packet data protocol context. It's expensive for.
Speaker 1: The network, lots of overhead each time, right.
Speaker 2: So to avoid doing that constantly. The network uses delayed teardown,
Speaker 2: meaning it keeps your phone in that costly ready state
Speaker 2: for a few seconds after the last data packet goes through,
Speaker 2: just in case more data is coming.
Speaker 1: Okay, seems sensible, but exploitable highly.
Speaker 2: The attacker just needs to send tiny, infrequent data packets to.
Speaker 1: Your phone, just enough to reset that timer exactly.
Speaker 2: Each tiny packet makes the network think, oh, still active,
Speaker 2: and it keeps that expensive ready state along with associated
Speaker 2: resources like TBFS and tfis, the traffic channels allocated indefinitely.
Speaker 1: Like keeping the bank vault door open with the toothpick.
Speaker 2: That's a good way to put it, and the impact
Speaker 2: is huge. The analysis showed just one hundred and sixty
Speaker 2: kilobits per second of attack praffic. That's minuscule, tiny, It
Speaker 2: was enough to block over ninety six percent of legitimate
Speaker 2: data requests across Manhattan.
Speaker 1: Ninety six percent. Yeah.
Speaker 2: Again, the attack isn't flooding the data pipes. It's exhausting
Speaker 2: the network's administrative resources, the virtual channels and set up
Speaker 2: processes dictated by that rigid state management.
Speaker 1: So as we move more towards voiceover IP VoIP and
Speaker 1: this ims architecture that's supposed to fix the old rigidity.
Speaker 2: Right.
Speaker 1: Yeah, moving voice onto packet networks, it.
Speaker 2: Solves some old problems, definitely gets rid of some of
Speaker 2: that circuit switched baggage, but it inherits a whole new set.
Speaker 1: Of problems, problems from the Internet side of things.
Speaker 2: Exactly all the lovely security risks we know from the
Speaker 2: open Internet now applied directly to voice. Okay, Like what, well,
Speaker 2: take call setup. We use protocols like SIP Session Initiation Protocol,
Speaker 2: and there's an encrypted version SIPs using TLS.
Speaker 1: Like each TTPs for websites.
Speaker 2: Sounds secure, it is, but only hop by hop Your
Speaker 2: phone connects securely to the first server, that server connects
Speaker 2: securely to the next.
Speaker 1: What happens at the server?
Speaker 2: Ah, that's the catch. At every intermediate proxy server, the
Speaker 2: session has to be decrypted, looked at, and then re
Speaker 2: encrypted to send it to the next hop. Wait decrypted
Speaker 2: in the middle, Yes, which means your supposedly secure call
Speaker 2: set up information is exposed in plaintext on potentially many
Speaker 2: machines along the.
Speaker 1: Path, so malicious insiders or just a compromise server.
Speaker 2: Can see everything about the call setup. There's no true
Speaker 2: end to end privacy guarantee.
Speaker 1: There, What about entrypting the actual voice conversation itself?
Speaker 2: For that, we have secure RTP or SRTP that can
Speaker 2: provide true end to end encryption of the audio.
Speaker 1: But there's always a butt.
Speaker 2: The butt is key management. How do you and the
Speaker 2: person you're calling securely exchange the encryption keys before the
Speaker 2: call starts without someone intercepting them. It's a hard problem.
Speaker 1: And sometimes it just doesn't happen.
Speaker 2: Worse, the standards often allow endpoints to negotiate down to
Speaker 2: using no encryption at all the NUL cipher. So you
Speaker 2: might think you're secure, but the call is going out
Speaker 2: completely unencrypted. It it seems bad, it's not ideal. But honestly,
Speaker 2: beyond these protocol issues, the biggest modern threat is probably.
Speaker 1: Malware on the device itself.
Speaker 2: Exactly, if your smartphone or your computer gets compromised, it
Speaker 2: doesn't matter how good the network encryption is, because.
Speaker 1: The malware sees the data before encryption or after decryption.
Speaker 2: Precisely, game over for privacy at that point.
Speaker 1: Okay, but let's say you avoid malware, you use strong
Speaker 1: SRTP with good key exchange. Yeah, are you safe then?
Speaker 2: Still maybe not completely hidden. There's this fascinating area of traffic.
Speaker 1: Analysis analyzing the encrypted traffic pattern.
Speaker 2: Yeah, even perfectly encrypted voice data leaks information. When you
Speaker 2: speak different languages, The way voice codecs chop up the
Speaker 2: sound results in different patterns of packet sizes, a distinct
Speaker 2: packet length profile for each language.
Speaker 1: Seriously, you can tell the language just from packet sizes
Speaker 1: even if you can't read the content.
Speaker 2: The research shows you can with surprisingly high accuracy, up
Speaker 2: to ninety percent in some studies. So even if the
Speaker 2: content is secret, an observer might figure out what language
Speaker 2: you're speaking, which could reveal who you're talking to or
Speaker 2: what kind of conversation it is. Sensitive metadata leakage, hashtags,
Speaker 2: tag tag outro Okay.
Speaker 1: So wrapping this all up, what's the big takeaway from
Speaker 1: this deep dive?
Speaker 2: I think the central lesson is pretty stark. These really
Speaker 2: dangerous vulnerabilities, especially the denial of service ones we talked about.
Speaker 1: You have the SMS and data attacks.
Speaker 2: They're fundamentally rooted in that architectural rigidity that clash between
Speaker 2: the old assumptions of circuit switching and the reality of
Speaker 2: flexible packet data.
Speaker 1: The network trying to provide old guarantees in a new world.
Speaker 2: Exactly, and things like rate limiting SMS messages that's just treating.
Speaker 1: A symptom the band aid right.
Speaker 2: Real fixes require systemic change, addressing that core problem of
Speaker 2: resource amplification and the expensive rigid session handling. Until the
Speaker 2: architecture truly modernizes, will likely keep finding these kinds of
Speaker 2: low effort, high impact vulnerabilities, which leads.
Speaker 1: Us with a final thought, maybe something for you the
Speaker 1: listener to think about.
Speaker 2: Yeah, the really big challenge now is this convergence SS seven,
Speaker 2: the old stuff, IMS, the vulip stuff, and the open Internet.
Speaker 2: They all have to talk to each other.
Speaker 1: You need your cell phone VoIP call to connect to
Speaker 1: Grandma's old landline precisely.
Speaker 2: But the security implications of stitching these vastly different systems together, honestly,
Speaker 2: they're not fully understood yet.
Speaker 1: We're connecting systems with known but different.
Speaker 2: Flaws and creating new connection points between them. Could an
Speaker 2: attacker exploit a weakness in one system, say the Internet side,
Speaker 2: to disrupt traffic in another, like the core phone network.
Speaker 2: Through these new gateways across system attack vector Potentially, are
Speaker 2: we building something more interconnected but ultimately less resilient than
Speaker 2: the sum of its parts. That's the ongoing challenge, ensuring
Speaker 2: security without breaking the performance we need for real time communication.
Speaker 1: Constant vigilance and research needed there.
Speaker 2: Absolutely, the work is far from over