The conference “SS7map : mapping vulnerability of the international mobile roaming infrastructure” will focus on the method used to map the global SS7 network, what have been map the network and more in depth statistics and analysis.

Details of the conference schedule:
Start time: 2014-12-27 23:00:00 +0100
Room: Saal 6

CCC is one of the main security event in Europe, it will take place from 27th Dec to 30th Dec 2014.

See you at #31C3 !

Download slides here.

Abstract:

Mobile telecommunication networks are complex and provide a wide range of services, making them a tempting target for fraudsters and for intelligence agencies. Moreover, the architecture, equipment and protocols used on these networks were never designed with security in mind, availability being the first concern. Today, even though some telecom operators are investing money into securing their network, events confirm that for most of them maturity in term of security is yet to come, as recently shown with the example of massive traffic interception on compromised SCCP and GRX providers like Belgacom’s BICS. Here we present the most typical and legitimate telecom callflows from making a mobile phone call to sending a SMS. Then we describe the protocol layers involved and how to abuse them, which fields can be manipulated in order to attack both the operator infrastructure and its subscribers. Finally, we show a real life example of scan performed from an international SS7 interconnection and practical attacks on subscribers such as spam, spoofed SMS and user location tracking.

Source: Mobicents

From a security standpoint SS7 (and SIGTRAN, its transport over IP) is a legacy protocol (but still the most used protocol for roaming), with protocol stacks which are sometime not very robust, even fragile, and have been released with only reliability to load in mind, not with reliability in front of malformed traffic. Hence the quite high number of crashes we witness in telecom and mobile core networks.

The reason for this is also the former lack of deep testing tools (fuzzers, scanners, etc..): for example, most of the fuzzers target at best M3UA (one of the encapsulation layer of SS7 over IP which is part of SIGTRAN) and do not cross neither its state machine nor the encoding. Fuzzing is mostly affecting the decoding of these message (ASN1), not the applications (MAP, INAP, CAP, …).

Source: Diametriq

Diameter is much more inspired by IETF / Internet philosophy and practices. IP protocols being more exposed to attacks, the protocols are a little bit more security-minded in term of resilience in front of hostile activities. Using Diameter also means that more attacker will know how to attack these protocols, hence more threat pressure.
Diameter is an evolution of Radius (hint: Diameter = Radius * 2).
Some very questionable protocol design decision involve for example the removal of Radius shared secret. Another questionable design decision is to consider that Diameter must either be transported with TLS _or_ with IPsec. This is very damageable as the Diameter protocol has no way to verify that IPsec is really used underneath. Therefore, some deployment are done in Diameter mode “as” IPsec but without IPsec being deployed, therefore without spoofing or interception protection.

Another factor is the “reach” of signaling messages. Deep reach vs. Shallow reach.
For example, SS7 has deep reach, can go from deep into Roaming network and deep toward Home network. For Diameter, it depends on the application being used (CCA, …).

Lastly, SS7 is being used for roaming and interworking of thousands of operators in the world whereas Diameter is being used only for maybe 10 to 20 operators for LTE roaming. SS7 and Diameter are both just “tubes” for transporting messages. Their respective strength is overrated, specifically with the myth or belief that SS7 and IPX network being closed, secure networks. They are not, they are as secure as the least secure operator having access to these. We will see the real impact and usage of Diameter as a worldwide transport mechanism in the future, but already one can see that it’s not a magic bullet regarding security from the audits we’ve done.

Some things P1 Security does with SS7, SIGTRAN and Diameter is:
* Scanning with PTA
* Fuzzing with PTF
* Intrusion/Misuse detection with PTM
and professional services, audits.

A few links about Diameter security at P1:
http://www.p1sec.com/corp/consulting/lte-and-diameter-audit/
http://www.p1sec.com/corp/2013/05/01/p1-security-newsletter-the-6-best-ways-to-secure-your-telecom-network/

Regarding the VKB, we have seen so far fewer vulnerabilities on Diameter than on SS7:

Total Diameter vulnerabilities: 10
SCCP vulnerabilities: 18
MAP vulnerabilities: 46
INAP vulnerabilities: 4
TCAP vulnerabilities: 4
SCCP vulnerabilities: 18
Total SS7 vulnerabilities: 90 (69 including overlaps vulnerabilities touching more than one SS7 protocol)

But this is also an exposure bias: we have seen much more mature/production deployment of SS7 than in Diameter so it’s only natural that the old protocol’s vulnerabilities are more known than the ones of recent protocols.

One interesting fact in the recent “Consolidated risk matrix” referenced by german BSI and produced by Deutsche Telekom, Vodafone and 1&1 Internet is that “Telecommunication and Network equipment backdoors” are one of the top rated vulnerabilities (4th top risk):

The nature of these backdoors is already troubling.  The people you trust your data and business with are the one who betray you by having secret access to your systems, even if you secure these to the maximum known best practices.

What’s worse with critical network element is that these backdoors can be activated from a great numbers of entry vectors, and can exfiltrate data by an even bigger set of vectors:

The great difference in countries preparedness at the telecom and mobile level shows extreme discrepancies in the awareness and maturity regarding the telecom and mobile security.

The National Information Security Agencies have had mixed results in their attempts to regulate security or help the operator improve their security due to the resistive posture taken by some operators, vendors and industry association and many cover-up of internal and external compromise of telecom critical infrastructure.

The liability of operators and vendors is huge with regard to this matter, most notably with VIP eavesdropping consequences and with the potential for general public class actions where law permits.

So of course, when you’re dealing with Core Network elements such as Huawei MSC, MSC Proxy and SoftSwitch MSoftX 3000, you don’t expect to find these Chinese ASCII arts of an octopus being killed by an angel (!):

We can see that internally, this is called “Cool Beauty System 1.0.3″ build (?) 35808001, by HuaWei R&D CN (Research and Development Core Network).

We see also that this design dates back from when Huawei was spelled internally HuaWei, that is probably from the 1980s even if the build time of this firmware image (VxWorks Tornado based) is from 2010.

and even less usual but more interesting to find the PCB schematics in ASCII art (!!):

That reveals it’s running (well… we saw that earlier) on PowerPC RISC processor MPC750 by Freescale Semiconductor, Inc. Here is the datasheet MPC750 RISC Processor by Freescale. Please note the JTAG interface on page 15.

By googling the other components, you will find the pinout of the JTAG interfaces of each chip as well as the UART and the way to to In-Circuit debugging (and dumping) of the bootrom.

Thanks to Huawei engineers for this moments of fun and education. Is it best practice to teach reverse engineers what your hardware architecture looks like?

Oh… and thanks for the 4 new vulnerabilities added in the VKB based on this reverse engineering and bug hunting session.

Primary usage of wireshark is to visualize packets coming from traditional IP traffic, that is why default wireshark settings provides a relatively good overview of IP packets for most of the use cases.

The problem is that this configuration is not at all suitable for specific needs of Telecom traffic analysis, and does not give you a quick vision when you are working on an SS7 Pcap.

Here is an example of SS7 traffic using default wireshark settings:

(click on image to enlarge)

With default wireshark configuration:

• You cannot see the interesting addresses in packet list view due to different addressing in SS7 and multiple layers involved.
• You see only one color for all different SS7 traffic types, because wireshark pre-configures coloring only for standard protocols.

Why SS7 traffic is more complex to analyze

First, SS7 Addressing is more complex than IP :
Instead of only IP + port tuples to represent endpoints of IP communication, in SS7 you use Global Titles (GT), Point Codes (PC or SPC) and Sub-System Numbers (SSN), that can be used as follow:

• Global Title (GT)
• Global Title + Sub-System Number (GT + SSN)
• Point Code (PC)
• Point Code + Sub-System Number (PC + SSN)
• Sub-System Number (SSN)

Secondly, their are much more network layers involved in Telecom traffic than on usual IP only traffic. On typical SS7 traffic you face in order:

• Ethernet
• Multiprotocol Label Switching (MPLS)
• Internet Protocol (IP)
• Stream Control Transmission Protocol (SCTP)
• MTP Level 3 (MTP3) User Adaptation Layer (M3UA)
• Signalling Connection Control Part (SCCP)
• Transaction Capabilities Application Part (TCAP)
• Mobile Application Part (MAP)

Each of these layer contains more parameters compared to IP.

Besides, many small packet flags are critically important, such as M3UA Network Indicator (Coded on 1 Byte, it represents the type of SS7 link : Internal, National or International).

Customize your wireshark

Customize Wireshark columns

You can customize the display columns of Wireshark to show GT and SSN in the packet list view, and do this in a separate profile to have different views on your packet depending of your activity.

(click on image to enlarge)

How to configure column display (wireshark >= 1.8.0)

1. Create a new profile : Go to “Edit > Configuration Profiles”, click on Add and call it “SS7″.
2. Add a column: Right click on the packet list view column titles and go in “Column Preferences”. In this window, click on “Add” to add a column, and set it’s name by clicking on it in the columns list.
3. Set the field type in the “Field Type” of your new column, select “Custom”. Now you can enter your wireshark expression in “Field Name”, for example sccp.calling.digits or sccp.called.ssn.
4. Click on “Apply”: you will have your new column in your Wireshark packet list view.

NOTE: This can be generalized to any Wireshark expression, so you can display any data you want from the pcap in the columns view.

(click on image to enlarge)

Exporting / Importing columns setting

The following file stores the configuration for your Wireshark profile:

/home/user/.wireshark./profiles/SS7/preferences

Example:

[...]
# Packet list column format.
# Each pair of strings consists of a column title and its format.
gui.column.format:
	"No.", "%m",
	"Time", "%t",
	"cgGT", "%Cus:sccp.calling.digits:0:R",
	"cgSSN", "%Cus:sccp.calling.ssn:0:R",
	"cdGT", "%Cus:sccp.called.digits:0:R",
	"cdSSN", "%Cus:sccp.called.ssn:0:R",
	"Protocol", "%p",
	"Length", "%L",
	"Info", "%i"
[...]

Customize Wireshark coloring rules

To get a better overview of the SS7 traffic and identify types of messages just by looking quickly at them, you can customize wireshark coloring rules. Each rule is defined by one filter (using the same syntax as usual wireshark display filters), and a set of 2 colors (foreground and background colors).

Here is an overview of 4 basic coloring rules applied on typical SS7 traffic:

(click on image to enlarge)

On the above screenshot, MAP layer is identified by yellow or green background color, whether the message is a MAP invoke (request) or MAP returnResultLast (answer).TCAP Abort (cancellation of TCAP dialog due to error) has a pink background, and TCAP Begin (initialization of TCAP dialog) has a light blue background (Not visible on the screenshot).

How to configure coloring rules (wireshark >= 1.8.0)

1. Go to “View > Coloring Rules”.
2. Click on “New” to add a new rule.
3. Enter a wireshark display filter in “String:” text box. For example, to match MAP invoke messages you can use the filter “gsm_map.old.Component == 1″.
4. Choose one foreground and one background color for this filter, then click “OK”

NOTE: coloring rules will be tried in order until one filter matches, top filter having the highest priority.

(click on image to enlarge)

Exporting / Importing coloring rules

1. Go to “View > Coloring Rules”.
2. Optional: select one or more filtering rules to export by clicking on them. (Ctrl + Click to select multiple filters).
3. Click on “Export”.
4. Choose an output filename and optionally check the box “Export only selected filters”.

You will get a file like this one:

# DO NOT EDIT THIS FILE!  It was created by Wireshark
@MAP ReturnResultLast@gsm_map.old.Component == 2@[61023,65535,29648][0,0,0]
@MAP Invoke@gsm_map.old.Component == 1@[37006,53439,22070][0,0,0]
@TCAP abort@tcap.abort@[65535,52907,60113][0,0,0]
@TCAP begin@tcap.begin@[36382,59634,65535][0,0,0]

This file can then be used to import coloring rules on another host.

That’s it ! Don’t hesitate to comment with you’re own Wireshark tricks.

In a future blogpost, we’ll see how to use Wireshark to edit a PCAP, in order to forge packets or anonimize a PCAP file.