Details about SS7map risk rating calculation are coming soon after our presentation at 31C3 !

You can subscribe here to be notified: http://eepurl.com/baeFU5

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.

Ericsson data

http://en.wikipedia.org/wiki/PLEX_(programming_language)

http://en.wikipedia.org/wiki/AXE_telephone_exchange

Billing

http://en.wikipedia.org/wiki/Billing_Mediation_Platform

http://en.wikipedia.org/wiki/Online_charging_system