With the introduction of 5G networks, a complete rework of the cellular core network is ongoing, in addition to the introduction of the New Radio stack (abbreviated NR). New network functions are defined, such as AMF for handling the mobility of subscribers, SMF for dealing with subscribers’ sessions… This rework brings new signaling protocols to be used between handsets and modems and the 5G core network, so-called Non-Access Stratum protocols (abbreviated NAS), and also new protocols between core network functions and for inter-PLMN signaling, relying on a Service-Based Architecture (abbreviated SBA).

P1 Security is happy to release, as part of the open-source pycrate framework, a complete support of the 5G NAS protocols in terms of signaling message encoding and decoding. A generic decoder is provided and each NAS message class can be used directly for encoding. The pycrate wiki on cellular NAS protocols was updated accordingly, too. here is a decoding example:

In [1]: from pycrate_mobile.NAS5G import * ; from binascii import unhexlify

In [2]: Msg, err = parse_NAS5G(unhexlify('7e005e7700091553837880204216f371'\
'00247e0041690010010302460fff000002680901020304f51001072e02f0f02f'\
'0504030004d2'))

In [3]: err
Out[3]: 0

In [43]: print(Msg.show())
### 5GMMSecurityModeComplete ###
 ### 5GMMHeader ###
  <EPD : 126 (5GMM)<spare : 0x0<SecHdr : 0 (No security)<Type : 94 (Security mode complete)### 5GSID ###
  <T : 119<L : 9### 5GSID ###
   <Digit1 : 0x1<Odd : 0<Type : 5 (IMEISV)<Digits : 353887080224613### NASContainer ###
  <T : 113<L : 36### 5GMMRegistrationRequest ###
   ### 5GMMHeader ###
    <EPD : 126 (5GMM)<spare : 0x0<SecHdr : 0 (No security)<Type : 65 (Registration request)### NAS_KSI ###
    ### NAS_KSI ###
     <TSC : 0 (native security context)<Value : 6### 5GSRegType ###
    ### 5GSRegType ###
     <FOR : 1 (Follow-on request pending)<Value : 1 (initial registration)### 5GSID ###
    <L : 16### 5GSID ###
     <spare : 0<Fmt : 0 (IMSI)<spare : 0<Type : 1 (SUCI)### Value : 0 -SUPI_IMSI ###
      <PLMN : 302640 (Canada.Latitude Wireless)<RoutingInd : <spare : 0x0<ProtSchemeID : 0 (Null scheme)<HNPKID : 0### Output : 0 ###
       <IMSI : 208690102030405### 5GMMCap ###
    <T : 16<L : 1### 5GMMCap ###
     <SGC : 0<5G-HC-CP-CIoT : 0<N3Data : 0<5G-CP-CIoT : 0<RestrictEC : 0<LPP : 1<HOAttach : 1<S1Mode : 1### UESecCap ###
    <T : 46<L : 2### UESecCap ###
     <5G-EA0 : 1<5G-EA1_128 : 1<5G-EA2_128 : 1<5G-EA3_128 : 1<5G-EA4 : 0<5G-EA5 : 0<5G-EA6 : 0<5G-EA7 : 0<5G-IA0 : 1<5G-IA1_128 : 1<5G-IA2_128 : 1<5G-IA3_128 : 1<5G-IA4 : 0<5G-IA5 : 0<5G-IA6 : 0<5G-IA7 : 0### NSSAI ###
    <T : 47<L : 5### NSSAI ###
     ### SNSSAI ###
      <Len : 4### SNSSAI ###
       <SST : 3<SD : 1234

Keep in touch and be notified of new 5G events by filling the 5G Interest form.

If you are involved in the development of 5G … Read More

Abstract

In this post, we explain how the TCAP-MAP protocol has been defined and extended in its successive versions, which led to some backward incompatibilities in the message decoding process. This is where pycrate comes to the rescue, providing an extended TCAP-MAP ASN.1 module that supports all MAP versions; it enables the encoding and decoding of any TCAP-MAP messages in a convenient and straightforward way.

Introduction to TCAP-MAP

TCAP-MAP is one of the main protocols used in 2G and 3G mobile core networks, and probably still the most used at operators’ interconnect to support roaming. MAP (Mobile Application Part) is a set of operations and data structures to support mobile subscribers mobility and services over 2G and 3G access networks and for both CS (Circuit Switch) and PS (Packet Switch) domains.

The TCAP-MAP protocol is mostly used (but not only) between MSC-VLR (Mobile Switching Center – Visited Location Register) and HLR (Home Location Register) in the CS domain, and SGSN (Serving GPRS Support Node) and HLR in the PS domain.

MAP is currently maintained by the 3GPP and continues to be extended regularly. It can be downloaded on the 3GPP website under the reference TS 29.002. It relies on TCAP (Transaction Capabilities Application Part) which defines generic call flows and generic message structures for any kind of application procedures. ITU-T is responsible for the TCAP specification under the following references: Q.771, Q.772, Q.773 and Q.774.

The Q.773 is of particular interest as it defines the TCAP message formatting and encoding; it has been stable for more than 20 years. In short, TCAP uses ASN.1 BER (Basic Encoding Rules) and specifies several types of generic message structures, whereas MAP defines specific operations and argument structures that get embedded into those generic TCAP messages.

TCAP-MAP messages are formally defined by using ASN.1. The ASN.1 definition for TCAP message structures can be found in the ITU-T Q.773 document (and also here). The ASN.1 definitions for MAP operations and argument structures are provided in section 17 of the 3GPP document. Those MAP ASN.1 definitions can be used to parameterize the TCAP ASN.1 definition, in order to produce a complete TCAP-MAP schema that will enable to encode and decode all possible messages for all the defined MAP operations.

This is exactly what is done within the pycrate_TCAP_MAP module within Pycrate, a Python library maintained by P1 Security that integrates an ASN.1 compiler and run-time. In order to get accustomed with this specific module, one can read the pycrate wiki dedicated to TCAP-MAP and TCAP-CAMEL (Customised Applications for Mobile network Enhanced Logic).

Basic structure of a TCAP-MAP message

A TCAP message can be of 5 different … Read More

While P1 Security professional services team are busy deploying Core Network security monitoring with PTM Signaling IDS on SS7, Diameter, GTP, SIP IMS VoLTE, and Radius, one question keeps coming back: the concept of Network Perimeter in SS7.

This recurring misunderstood aspect in SS7 shows the discrepancy of security conception between the IP-oriented domains (Diameter, GTP, Radius, SIP) and the SS7 domain.

While it’s a concept that is clearly understood from IP, it seems that in SS7 domain it is at best a fuzzy notion, and there are a couple of reason to that.

Network Indicators and regional differences

NI=Network Indicator field in MTP3 messages (same in SIGTRAN, be it transported over M2UA/M2PA or in M3UA).

NI (Network Indicator) value:

NI=0: INAT0 (The Global SCCP roaming and call delivery network between operators)

NI=1: INAT1

NI=2: NAT0

NI=3: NAT1

Now clearly, the dangerous perimeter is INAT0, as it is the group of external roaming partners, the other operators.

The Point Codes within INAT0 are assigned per country by ITU. In turn, the national regulators assign prefixes to national operators.

The Global Titles (MSISDN, phone numbers)within INAT0 are assigned per operator by ITU.

But there’s also another external perimeter, that is the national inter-operator network. Despite specifications and text, this part is much more fuzzy and unclear. In some country, NAT0 is being used for inter-operator national communications, in some other countries it’s NAT1.

These two (INAT0 and NAT0 OR NAT1) are the ones to be monitored, with the overwhelming majority of the monitoring importance and alerts coming from INAT0.

In order to prioritize security monitoring, it is vital to monitor INAT0 first, go deeper in INAT0 once one set of basic detection are mastered (for example Category 0 and 1 attacks), and then when all categories are monitored on INAt0 and that filters start to be added routinely, move to the national inter-operator network (NAT0 or NAT1) monitoring.

Network Indicators and Network Appearance

Sometime also what brings doubt is that closely named fields mean two totally separate things. NI is defined globally whereas NA is defined by an operator for its own use, to recognize and separate entities and interconnection.

NI is small (4 bits used in a bytes). NI is global.

NA is large, 8 bytes, allowing a lot of room for network segmentation and organization. NA is operator local, it is only used and communicated between direct MTP3 (or M3UA) peers.

Network still seen as a walled garden

Another root cause of this difficulty to establish network perimeters for security is the old notion that SS7 was only between nice people (operators). It is definitely not the case anymore.

Conclusion

The SS7 security is still a problem, but with emerging solution. The hype around SS7 Firewall shows that there is still a lot of immature solutions and very few actual SS7 Firewall implementations.

Some operator with a mature security governance are successfully managing such SS7 Security projects by first looking (attack monitoring) and then filtering based on this … Read More

Abstract:

In order to properly manage LTE Diameter security, and it close variants in the IMS and VoLTE domain, we proposed in this presentation a way to categorize the Diameter message types, usage and Command Codes and ways to monitor and filter them.

Presentation will be published in February 2016 at Mobile World Congress, Barcelona, Spain.

 … Read More

Mobile Network Operators rely on a network different from Internet that interconnects operators and other parties, to allow calls to work between operators especially when you are in another country (roaming).
This is what is called the “SS7 network” a.k.a. “International Roaming Infrastructure”, that by it’s nature, transmits confidential customers and operators information.

In SS7map, we are presenting the first cartography of SS7 International Roaming Infrastructure vulnerabilities, to push the industry to react, and show to all of us customers the security level of the infrastructure we are all using.

For decades the SS7 network has been used by Intelligence agencies and various entities to track location of customers and help in the interception of calls and SMS. It’s time to have visibility on which country is taking care of these issues and protecting their population. The SS7 network is obscure, and mapping it is a step towards better security.

Our first release presents SS7 Roaming Infrastructure ratings for countries worldwide. The project is still in an early stage and we have work to do to offer a precise vision, but for the first time there is a public worldwide view on the security of this vital core network.

SS7map Ratings

SS7map ratings are separated in 3 categories:

• Privacy Leaks: How much the operators of a given country are leaking out subscriber privacy data such as location of their subscribers to anyone on the SS7 network.
  Any operator and many company offering location / SMS services can gather these informations.
• Network Exposure: Network Elements exposed and security mechanism implemented by operators of a given country. It shows the attack surface of the Telecom Network of a country from the SS7 perspective.
• Global risk: This combines Privacy Leaks and Network Exposure, giving more importance to Privacy Leaks.

The country ratings for these 3 categories are showed on the SS7map website main page by colors on the map.

On the per-country pages we show also subscores for Privacy Leaks and Network Exposure, explained below.

Privacy Leaks

In Privacy Leaks we regroup leaks of customers information of all operators in a country:

• Subscriber location leak
• Subscriber private informations (identifiers, cryptographic keys, postpaid/prepaid status)
• Subscriber communications confidentiality (decryption of SMS/calls using known attacks)

Gathering privacy related informations on the SS7 Network is mainly done by sending SS7 Mobile Application Part (MAP) messages. They are numerous SS7 MAP messages related to privacy, as show on this diagram:

The answers from the operators of a particular country are processed and then a score is attributed following this formula:

privacyleak =
  150 * leak_locationcell
+ 100 * leak_privateinfos
+  60 * net_homerouting
+  50 * leak_authvectors
+  40 * leak_subscriberplan
+  10 * net_homerouting_defeated_ati
+  10 * net_homerouting_defeated_psi
+  10 * leak_location

We are using the following subscores for Privacy Leaks rating:

MAP messages vulnerabilities discloses precise subscriber location (200m) (leak_locationcell)

How operators in the country are protecting subscribers precise street-level (200m) location from other … Read More

Laurent Ghigonis and Alexandre De Oliveira from P1 Security team will be presenting the work done on the global SS7 network at Chaos Computer Conference in Hambourg the 27th Dec 2014.

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 !… Read More

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… Read More

P1 Security presented at the Hackito Ergo Sum 2014 conference in Paris (http://2014.hackitoergosum.org/) the weaknesses of Telecom Infrastructure systems, and particularly HLR/HSS equipment.

Download slides here.

Abstract:

HLR and HSS are the most important Telecom Equipment in an Operator Core Network.
We are going to see that this so-called “Critical Infrastructure” is not as robust as you could think, by exploring the some weaknesses of the HLR/HSS equipment.

Plan:
* Virtualization of HLR/HSS, for instrumentation purposes
* HLR/HSS system analysis
* SS7/Diameter network fuzzing
* HLR/HSS binaries reverse

We also did another presentation on Worldwide attacks on SS7/SIGTRAN network at HES.

 … Read More

We are pleased to announce that P1 Security was present at the Hackito Ergo Sum 2014 conference in Paris (http://2014.hackitoergosum.org/).

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.… Read More