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.

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.