This blog details the requirement for testing Telecom networks and one of the tools developed in house to facilitate this testing.

Why?

Telecoms security has always been an afterthought when the first mobile networks were developed and deployed into the wild.  Telecoms security has faced numerous challenges, leading to concerns about its effectiveness.  Several key factors contribute to the poor state of today’s networks.

1. Legacy Infrastructure: Many Telecom networks still rely on outdated legacy equipment and protocols.  These systems were not designed with security in mind, making them vulnerable to modern cyber threats.
2. Rapid Technological Advancements: The fast-paced evolution of telecom technologies such as 5G and IoT, often prioritizes functionality and speed over security.
3. Diverse and Complex Ecosystems: Telecom networks involve a complex web of interconnected components and service providers.  This complexity can create security gaps, as not all stakeholders may implement robust security measures.
4. Limited Regulation:  The regulatory environment for telecom security varies from one country to another and is often inadequate to address emerging threats.  This lack of consistent regulation can leave networks exposed.
5. Lack of Encryption: In some cases, telecom companies have been slow to implement strong encryption measures, leaving data and communications vulnerable to interception and eavesdropping.
6. Supply Chain Vulnerabilities: Telecom equipment is often manufactured globally, and supply chain vulnerabilities can be exploited to introduce malicious components into the network infrastructure.
7. Lack of Security Awareness:  Many Telecoms users and even some providers are not fully aware of the security risks, which can result in poor cyber security practices and inadequate user education.
8. Cost Constraints:  Balancing security investments with profitability can lead to underinvestment in security measures, leaving networks susceptible to breaches.

In summary, the state of Telecoms security is compromised by a combination of legacy infrastructure, rapid technological advancements, complexity, limited regulation, and a range of other factors.

Websites such as Surveillance Dashboard (surveillancemonitor.org) can be used to visualize the scale of the problem. It can be seen that location and identity threat types make up the majority of network attacks.

In order to test legacy signalling protocols in Telecom networks efficiently and consistently, NCC Group has set about creating a tool to semi automate the testing process and record the test results. This helps with retesting of any fixes that maybe applied to the networks.

As defined within the GSMA security guidance documents, it is recommended to test the interconnects between operators. These interconnects between operators are usually via the semi-private IPX/GRX network or by direct peers between operators. Various nodes such as SS7 Transfer Points (STP), Diameter Edge Agents (DEA) and GSN (Gateway Support Nodes) provide the connectivity and forwarding of interconnect signalling traffic. There are various signalling interconnect protocols which includes primarily Sigtran/MAP, Diameter and GTP. These protocols carry legitimate signalling events allowing the successful connection and roaming of mobile subscribers on mobile operator networks. However, it is possible for an attacker to abuse these signalling protocols to illicit information from a mobile operator such as subscriber phone number (MSISDN), unique identifier (IMSI), location down to the mobile cell or in some cases user traffic. These various attacks and resulting abuse are covered in detail in the GSMA FS.11 SS7 Interconnect Security Monitoring and Firewall Guidelines, FS.19 Diameter Interconnect Security, FS.20 GPRS Tunnelling Protocol (GTP) Security. The Telco Attack tool developed by NCC Group allows reliable testing as defined within these GSMA specifications.

Initial Test Requirements

Initially we wanted to create a tool that could perform the attacks detailed in the GSMA FS.19 Specification, which focuses on the DIAMETER protocol used to connect different mobile operator networks together.

Although this was the initial requirement we also wanted to create a framework that could be expanded to add more attacks for different protocols such as GTP (GSMA FS.20) and MAP (GSMA FS.11) in the future.

With the constraints of a small development team and speed of development being an important factor, we tried to leverage as many open-source projects as possible during development.

The Tech Stack

We chose to use Java as the main programming language due to several factors:

1. The availability of open-source projects that implemented the messaging protocol stacks (DIAMETER, GTP, MAP)
2. The portability of Java to run on both Windows and Linux
3. Well support development tools
4. Reasonable GUI development using JavaFX
5. Familiarity with Java language among the dev team

Due to the number of protocol specs and the significant amount of boiler plate code that is often associated with developing applications of this nature, we chose to use a couple of tools to assist in generating some of the code.

Development Tools

• Eclipse IDE used for general code editing and compiling
• Antlr4 used for code generation from DIAMETER specs
• Java Annotation Processors used for code generation related to the MAP protocol

To give some idea of the scale of the project to date, the table below approximates the lines of code for each protocol and the application itself.

Technical Challenges of Development

DIAMETER Specific

Whilst developing the initial DIAMETER attacks detailed in GSMA FS.19, it soon became clear that hand crafting the code for each DIAMETER spec would not be a sensible approach.  This is where we used Antlr 4 to pre-process the specifications in order to generate parsers that could load the specifications and create Java constants to be used in the application for message creation.

Antlr4 is a powerful parser generator for reading, processing, executing, or translating structured text or binary files, it uses a grammar file to generate the parsers.  There are several predefined grammar files available, and we used an existing DIAMETER grammar file as a starting point.

What seems like a simple decision turned out to be a lot more complex.  The biggest problem was finding a way to deal with the inconsistencies/errors in the specifications themselves.  It’s only when you try programmatically processing the specifications you realize just how many errors they contain.

The second challenge was loading the specs and dealing with the cross references between the specs.  Then there is what seems like an endless chain of specs including other specs, which include more specs, etc just to define a single field in a message.

For example to send an UpdateLocationRequest message from the 3GPP TS 29.272 spec, the field RAT-Type is defined in ETSI TS 129 212 which means this entire spec needs to be parsed just to obtain the definition for the RAT-Type.

Some things in the specs were optional and not necessarily required for the attacks we wanted to perform.  This led us to create a solution where we could choose to ignore fields that were not defined in the spec being processed.  This significantly reduced the number of specs we needed to process in order to perform the attacks.

We used 23 DIAMETER specs in total (ranging from 1000 to 15000 lines each) that would need processing in order to perform the following DIAMETER attacks:

• Individual DoS Update-Location-Request
• IMSI Acquisition
• Uesr-Data-Request Location Info
• Insert Subscriber-Data-Request Location Tracking
• Provide-Location-Request Location Tracking
• LCS-Routing-Info-Request Location Tracking

The steps below were taken in order to process each DIAMETER spec:

1. Copy the contents of the Word/PDF spec file to a plain text file
2. Use a custom written application to extract the ABNF sections from the spec and create a dictionary file
3. Manually check the dictionary file against the spec and enter the Application Id’s, default Vendor Id and any other Vendor Id’s that are used
4. Use another custom written application to generate a Java constants file, that can then be used to help create DIAMETER messages in the attack application

During execution of the attack application the dictionary files are read and processed to generate message templates.  These templates are combined with the generated constants file to create the attack messages.

MAP Specific

Due to the SS7 protocol stack implementation, we decided to use a custom Java annotation processor to generate some of the boiler plate code.  Below is an example of the annotation which is used to create the various MAP response listeners for the protocol stack.

Here is an example of the generated output for one of the smaller interfaces:

Using the java annotation processor and Antlr4 significantly reduced the coding effort required to create the MAP and DIAMETER attacks.  This also helps to improve code quality by removing the tedious and error prone task of writing some of the boiler plate code.

Demo

The image below shows the main sections of the GUI.

To watch a short demonstration video click the demo button below.

Here are some related articles you may find interesting

View articles by category

Call us before you need us.

Our experts will help you.

Get in touch