1. SS7 hacking still exposes many phone users to hacking threats
2. Security testing helps find and fix SS7 issues
3. Clear rules are needed to vet security test providers for SS7 access
Your calls, texts, and mobile data are enabled through complex international networks known as "interconnects," running signaling protocols like SS7, Diameter, and GTP. Essential for global communication, the interconnect protocols also present considerable hacking surface.
The SS7 protocol, designed for closed networks in the 1980s, contains fundamental security gaps due to its assumption that everyone connected to SS7 trusts each other.
Security Research Labs conducted comprehensive assessments that revealed fundamental security flaws within the SS7 protocol:
SRLabs emphasized at CCC in 2014 that these vulnerabilities are not "bugs" but a result of fundamental SS7 design flaws, where any participant with core network access is implicitly trusted. In 2024, we confirmed the results together with Veritasium, and explained the details here.
The research has raised global awareness among telecommunication operators, governments, and the public about the need to secure these foundational protocols. The solution is well-configured SS7 firewalls that block malicious messages.
And yet, SS7 abuse is still (too) common. Despite public demonstrations of SS7 security issues in 2014–2015, operators still see millions of abuse messages each month.
Abuse cases range from charging fraud to call and text message intercept to location tracking. Due to SS7 security issues, criminals and spies rob bank accounts and track victims, as shown by TechCrunch.
In IT security, hacking attempts are accepted as a fact of life — inconvenient, but unavoidable. In a comedic interpretation of hacking’s inevitability, an RFC standard document — published on April 1 — requires hackers to signal their malicious intent in the TCP header so firewalls could discard the evil packets.
In the real world, we acknowledge that global networks are intrinsically untrusted and shield our systems from suspicious packets. We activate firewalls for each computer (since Win XP) and conduct configuration reviews and penetration tests to configure higher-level firewalls on our networks.
The GSMA published guidelines on securing SS7, notably through firewalls that block malicious SS7 messages (see the FS.11 guidelines). Most operators have not implemented these guidelines (see the ENISA study on signaling security). And where they have, the firewalls often have configuration gaps: Even operators with state-of-the-art SS7 firewalls struggle to prevent all SS7 abuse because configuring SS7 firewalls is complex.
SS7 messages can be exploited in multiple ways, making proper firewall configuration essential for security (see Figure 1).
Effective SS7 defense hinges not only on detection but on proper configuration. Industry guidelines like FS.07, FS.11, and IR.82 provide detailed firewall rules, filtering categories, and implementation practices that operators should follow to mitigate known vulnerabilities (see Figure 2).
IT security relies on continuous testing because the design, implementation, and configuration of complex systems leave room for error. SS7 firewalls are no exception. They, too, must be assured through testing to be effective.
The journey to SS7 security starts with installing a firewall, and it doesn’t stop there!
To configure their firewalls correctly, telcos rely on interconnect pentests to find and close gaps.
This specialized telco security assessment simulates real-world attacks against crucial network interconnection points. Unlike a typical IT security scan, it targets vulnerabilities of telecom signaling protocols to uncover weaknesses that could lead to subscriber tracking, call or SMS interception, service disruption (denial of service), or fraud.
For telecommunication operators, securing the invisible wires is essential, as a single vulnerability can have global repercussions, impacting millions of subscribers, causing significant financial losses, and eroding trust in the very backbone of modern communication.
SS7 firewall tests need to be executed from a hacker’s perspective: From outside the target network, and possibly without roaming agreement privileges. This requires SS7 network access (GT leasing).
The GSMA code of conduct rightfully calls for “alternative solutions [to] be used to replace GT Leasing”. Unfortunately, no alternatives exist for SS7 security testing, which needs to mimic malicious actors with direct SS7 access. Some ethical hackers had to go as far as to become telcos with their own GT allocation. They now play a vital role in securing the signaling ecosystem.
How do we close this gap and create alternative solutions for proper SS7 security testing? How do we enable security testing that elevates the SS7 ecosystem’s security (‘white hat’ or ‘ethical’ experts) while restricting access for malicious actors (‘black hat hackers’)?
GT leasing means acquiring access to a Global Title (GT), a unique identifier in signaling systems like SS7, used to route signaling messages.
By leasing GTs, companies can quickly establish connectivity and deliver SMS, voice, and roaming services without investing in complex infrastructure. This creates a cost-effective and streamlined way to offer services globally.
While the practice offers significant benefits in cost savings, flexibility, and speed, from a security perspective, GT leasing is generally a bad idea.
Leasing access to GTs significantly impacts network security and fraud prevention in telecommunications, introducing potential vulnerabilities and mitigation challenges. Exposing sensitive network functions to third parties increases the risk of misuse, abuse, or exploitation. Unauthorized or poorly controlled GT leasing can allow adversaries to intercept or manipulate signaling traffic, posing significant security threats.
Security researchers and testers lease GTs for active testing. Controlled leasing lets them probe SS7 networks for vulnerabilities, allowing operators to identify and fix issues before hackers exploit them. This approach is essential for effective SS7 security assessments.
Active testing for SS7 vulnerabilities is more important than ever. After decades of relatively open SS7 networks, most operators have settled into the status quo. Remaining configuration issues won’t be found and fixed without active testing.
Evidence from IT security shows that malicious hackers have strong motivation and resources to circumvent rules, while white hats stick to them. A general rules-based embargo on GT leasing impacts mostly white hat security experts, not criminals, and possibly makes their work easier by allowing security defects to persist due to the lack of testing.
We need a vetting scheme to certify GT leases for security testing. The GSMA code of conduct calls for “due diligence” on the commercial and technical details of each GT lease. This is the right direction, but it leaves the responsibility with individual operators, who often lack the time or expertise to vet security service providers.
Instead, the GSMA and its working groups have this expertise, and they should introduce a vetting scheme for Interconnect Security Assurance providers. Such accreditation schemes have been successfully introduced in IT security, notably through the CREST certification for IT security test providers, mandated for security testing on critical infrastructure.
We have a chance to combat decade-long criminal abuse of interconnect networks only if security controls, testing, and abuse monitoring are centrally governed.
It’s time to collaborate more closely than ever.
