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

After having analyzed the Samsung Stick firmware, it was time to make something useful out of it. When first plugged into a linux machine, it appears to be a usb Storage.
With the help of usb_modswitch, it is possible to activate the ttyUSB device, as well as the control device.
Here is the output of a lsusb

# lsusb 
Bus 001 Device 038: ID 04e8:689a Samsung Electronics Co., Ltd LTE Storage Driver [CMC2xx]
Bus 002 Device 002: ID 05ca:18c2 Ricoh Co., Ltd 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

The command line for the usb_modswitch would be:

usb_modeswitch -W -v 0x04e8 -p 0x689a -I -M '55534243785634120100000080000601000000000000000000000000000000' 

Here is an output log:

# usb_modeswitch -W -v 0x04e8 -p 0x689a -I -M '55534243785634120100000080000601000000000000000000000000000000' 
Taking all parameters from the command line

 * usb_modeswitch: handle USB devices with multiple modes
 * Version 1.2.3 (C) Josua Dietze 2012
 * Based on libusb0 (0.1.12 and above)

 ! PLEASE REPORT NEW CONFIGURATIONS !

DefaultVendor=  0x04e8
DefaultProduct= 0x689a
TargetVendor=   not set
TargetProduct=  not set
TargetClass=    not set
TargetProductList=""

DetachStorageOnly=0
HuaweiMode=0
SierraMode=0
SonyMode=0
QisdaMode=0
GCTMode=0
KobilMode=0
SequansMode=0
MobileActionMode=0
CiscoMode=0
MessageEndpoint=  not set
MessageContent="55534243785634120100000080000601000000000000000000000000000000"
NeedResponse=0
ResponseEndpoint= not set

InquireDevice disabled
Success check disabled
System integration mode disabled

usb_set_debug: Setting debugging level to 15 (on)
usb_os_find_busses: Found 006
usb_os_find_busses: Found 005
usb_os_find_busses: Found 004
usb_os_find_busses: Found 003
usb_os_find_busses: Found 002
usb_os_find_busses: Found 001
usb_os_find_devices: Found 001 on 006
skipping descriptor 0x30
skipped 1 class/vendor specific endpoint descriptors
usb_os_find_devices: Found 001 on 005
usb_os_find_devices: Found 001 on 004
usb_os_find_devices: Found 001 on 003
usb_os_find_devices: Found 002 on 002
skipping descriptor 0xB
skipped 1 class/vendor specific endpoint descriptors
skipped 5 class/vendor specific interface descriptors
skipping descriptor 0x25
skipped 1 class/vendor specific endpoint descriptors
skipped 18 class/vendor specific interface descriptors
usb_os_find_devices: Found 001 on 002
error obtaining child information: Inappropriate ioctl for device
usb_os_find_devices: Found 038 on 001
usb_os_find_devices: Found 001 on 001
error obtaining child information: Inappropriate ioctl for device
Looking for default devices ...
  searching devices, found USB ID 1d6b:0003
  searching devices, found USB ID 1d6b:0002
  searching devices, found USB ID 1d6b:0001
  searching devices, found USB ID 1d6b:0001
  searching devices, found USB ID 05ca:18c2
  searching devices, found USB ID 1d6b:0002
  searching devices, found USB ID 04e8:689a
   found matching vendor ID
   found matching product ID
   adding device
  searching devices, found USB ID 1d6b:0002
 Found device in default mode, class or configuration (1)
Accessing device 038 on bus 001 ...
Getting the current device configuration ...
USB error: error sending control message: Connection timed out
Error getting the current configuration (error -110). Assuming configuration 1.
Using first interface: 0x00
Using endpoints 0x06 (out) and 0x85 (in)

USB description data (for identification)
-------------------------
Manufacturer: not provided