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 countries and external parties ?

This score is based on answers to the following SS7 MAP messages:

• ATI: Any-Time-Interrogation, to gather MSC and Cell-ID from HLR
• PSI: Provide-Subscriber-Information, to gather Cell-ID directly from MSC

Number of different MAP messages vulnerabilities disclosing subscriber private information (leak_privateinfos)

How operators in the country are protecting subscribers private unique identifier (IMSI) ?

Gathering IMSI allows attackers to gather further informations on a subscriber.

This score is based on answers to the following SS7 MAP messages:

• SRISM: Send-Routing-Information-for-Short-Message, to gather IMSI from HLR
• SRI: Send-Routing-Info, to gather IMSI from HLR

Number of different MAP messages vulnerabilities disclosing subscriber location (leak_location)

How operators in the country are protecting subscribers city-level (50km) location from other countries and external parties ?

This score is based on answers to the following SS7 MAP messages:

• SRISM: Send-Routing-Information-for-Short-Message, to gather MSC from HLR
• SRI: Send-Routing-Info, to gather MSC from HLR
• ATI: Any-Time-Interrogation, to gather MSC from HLR

Leak of subscriber keys (Network Impersonation possible) (leak_authvectors)

How operators in the country are protecting subscribers against decryption of calls and SMS by attackers ?

This score is based on answers to the following SS7 MAP messages:

• SAI: Send-Authentication-Info, to gather Authentication vectors from HLR

Leak of prepaid/postpaid subscriber status (leak_subscriberplan)

How operators in the country are protecting informations about subscriber account, like the postpaid/prepaid options of the subscription ?

This score is based on answers to the following SS7 MAP messages:

• INTSS: Interrogate-SS, to gather subscriber plan informations from MSC/VLR

Leak of subscriber location through Home Routing bypass (net_homerouting, net_homerouting_defeated_psi, net_homerouting_defeated_ati)

Are operators in the country using protection mechanism to hide subscriber location from other operators / third-parties ?

This score is based on answers to the following SS7 MAP messages:

• SRISM: Send-Routing-Information-for-Short-Message, to gather informations from HLR
• ATI: Any-Time-Interrogation, to gather informations from HLR
• PSI: Provide-Subscriber-Information, to gather informations from MSC

Network Exposure

In Network Exposure our focus is the Core Networks of operators in a country:

• Attack surface of the Operators (network topology, identification of the network nodes (a.k.a Network Elements)
• Network misconfigurations allowing attackers to modify data
• Bypass of Network security mecanisms

We map operators Network Exposure of a country by sending SS7 Transaction Capabilites Application Part (TCAP) and SS7 Mobile Applicaiton Part (MAP) messages, as shown on this diagram:

The formula for Network Exposure calculation is the following:

networkexposure = 
  200 * net_fingerprint_ne
+ 100 * net_homerouting
+ 30 * net_homerouting_defeated_ati
+ 30 * net_homerouting_defeated_psi
+ 50 * leak_location
+ 40 * leak_subscriberplan
+ 20 * leak_locationcell
+ 10 * leak_authvectors
+ 10 * net_ne
+ 5 * net_directanswer

We are using the following subscores for Network Exposure rating:

Network Elements fingerprint (net_fingerprint_ne)

Are the operators revealing the type of Network Elements they are using ?

This score is based on answers to the following SS7 messages:

• SRISM: Send-Routing-Information-for-Short-Message, to gather network informations from HLR
• SRI: Send-Routing-Info, to gather network informations from HLR
• ATI: Any-Time-Interrogation, to gather network informations from HLR
• PSI: Provide-Subscriber-Information, to gather network informations from MSC
• TCAP, to gather network informations from all Network Elements

SCCP discovery attack surface (net_ne)

Are the operators exposing a lot of Network Elements or disclosing there Network Topology ?

This score is based on answers to the following SS7 messages:

• SRISM: Send-Routing-Information-for-Short-Message, to gather network informations from HLR
• SRI: Send-Routing-Info, to gather network informations from HLR
• ATI: Any-Time-Interrogation, to gather network informations from HLR
• PSI: Provide-Subscriber-Information, to gather network informations from MSC
• TCAP, to gather network informations from all Network Elements

Potential change of prepaid/postpaid status (fraud) (net_directanswer, leak_subscriberplan)

Do the operators allow change on subscriber information from anyone, allowing potential fraud ?

This score is based on answers to the following SS7 MAP messages:

• INTSS, REGSS: Interrogate-SS, Register-SS, to gather MSC/VLR configuration

Home Routing (net_homerouting)

Are the operators using protection mechanism (Home Routing) to hide customer location and private identifiers ?

This score is based on answers to the following SS7 MAP messages:

• SRISM: Send-Routing-Information-for-Short-Message, to gather network informations from HLR
• SRI: Send-Routing-Info, to gather network informations from HLR
• ATI: Any-Time-Interrogation, to gather network informations from HLR

Leak of internal topology through Home Routing bypass (net_homerouting, net_homerouting_defeated_psi, net_homerouting_defeated_ati)

Is Home Routing susceptible to bypass, revealing real Network Topology ?

This score is based on answers to the following SS7 MAP messages:

• SRISM: Send-Routing-Information-for-Short-Message, to gather network informations from HLR
• SRI: Send-Routing-Info, to gather network informations from HLR
• ATI: Any-Time-Interrogation, to gather network informations from HLR
• PSI: Provide-Subscriber-Information, to gather network informations from MSC

Global Risk

Global Risk combines Privacy Leaks and Network Exposure, using the following formula:

globalrisk =
  5 * privacyleak
+ 1 * networkexposure

These ratings are going to evolve as we continue our research, we will post notifications accordingly.

Register to get email news about SS7map.

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 !

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

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.

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.

# 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
     Product: not provided
  Serial No.: not provided
-------------------------
Looking for active driver ...
 OK, driver found ("usb-storage")
 OK, driver "usb-storage" detached
Setting up communication with interface 0
Using endpoint 0x06 for message sending ...
Trying to send message 1 to endpoint 0x06 ...
 OK, message successfully sent
Resetting response endpoint 0x85
USB error: could not clear/halt ep 133: Connection timed out
 Could not reset endpoint (probably harmless): -110
Resetting message endpoint 0x06
-> Run lsusb to note any changes. Bye.

So after that, a new lsusb would show us:

# lsusb 
Bus 001 Device 040: ID 04e8:6889 Samsung Electronics Co., Ltd GT-B3730 Composite LTE device (Commercial)
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

In order to have a device descriptor for the stick, we need to modify the linux driver already available.

https://github.com/mkotsbak/linux-2.6/blob/Samsung_kalmia_driver-3.0/drivers/net/usb/kalmia.c

The new file kalmia.c is present HERE
. (Special thx to Xavier Martin for his this)
and I added the Makefile that let me compile it

obj-m += kalmia.o

all:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
	make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Now 2 new devices are present:

	/dev/ttyUSB0
	/dev/c2xx

Now the /dev/c2xx device will give us all the debug packet, including NAS and RRC, so we could look at them with wireshark.
In order to do that, we need a wireshark dissector that: packet-c2xx.c
As seen on the following picture, the dissector takes a packet that we named c2xx.

This packet is itself composed of a header, a HDLC flag, and a frame.

Packet containing NAS are then visible

Samsung LTE USB dongles codename Kalmia

I acquired a couple of GT-B3740 800Mhz LTE Dongle, and decided to open one of them to find out what the chipset was used in it.

The very surprizing part was to see that it had a JTAG connector there and it was written JTAG !
So after looking for some documentations about it, another interesting thing came. Googling a bit let me find the Service Manual of the device !

Even more surprizing, there was a schematic in there, with the JTAG pinout description!

After some investigation, I found the connector DATASHEET: http://www3.panasonic.biz/ac/e_download/control/connector/base-fpc/catalog/con_eng_f4s.pdf?via=ok It is in fact a PANASONIC AXT512124.

One can find those at Digikey or Mouser.
So THE problem with those connector is the size. In fact, any soldering iron would melt the connector before being able to soler anything to it. So there is no other way than finding the Female connector and extending it. My first attemp was a failure. In fact, I tried to do it with a flex based copper sheet and PNPBlue. here is the result

In fact, the clearance is so low that it could only be done in a factory with a pick and place.
Looking here and there, I found on Alibaba a multiple JTAG cable that looked quite similar.

http://www.aliexpress.com/store/product/JTAG-JPin-JIG-Pinouts-by-RIFF-ORT-JPR-MEDUSA-BOX/927318_922669231.html

So I decided to buy one to give it a test. The thing is that you have to buy the whole set. At the time I’m writing, it’s price was $68.

As one can see, the result is shown here under

The interesting part about this cable is that the little adapter they give respects the JTAG pinout standard of the ARM, therefor, I could easily connect it with a Board to Board connector to a Amontek Jtag-Mini. So it was time to play with OpenOCD !
Here is the configuration file used.

telnet_port 4444
#gdb_port 0
#tcl_port 0

jtag_khz    100000000
adapter_khz 100000000
#jtag_speed 3

reset_config trst_and_srst

jtag_nsrst_delay 400
jtag_ntrst_delay 400

if { [info exists CHIPNAME] } {
  set _CHIPNAME $CHIPNAME
} else {
  set _CHIPNAME cmc220
}

#reset_config none

if { [info exists CPU_TAPID ] } {
  set _CPU_TAPID $CPU_TAPID
} else {
  set _CPU_TAPID 0x4ba00477
}
jtag newtap $_CHIPNAME tap -irlen 4 -ircapture 0x1 -irmask 0x3 -expected-id $_CPU_TAPID

set _TARGETNAME $_CHIPNAME

target create $_TARGETNAME cortex_r4 -endian little -chain-position $_TARGETNAME.tap

So I managed to dump the Memory of the chip. And I got the firmware extracted. A couple of strings on the file shows that the file is REALLY verbose. All the debug symbols are there. All the printf are still there… It’s time to play with IDA pro !
One interesting part is that I was able to tell IDA pro that the GDB Server is in fact OpenOCD. so IDA pro would go into debug mode and be able to step in the running code. Most of the time that would generate an interrupt tho. But that is quite good enough with some scripting to see what part of the Firmware is Code segment or Datasegment..

And as said earlyer, the amount of Strings debug is really big. Worth digging into it.

In the meantime, I decided to get myself some GT-B3730 that does the 2.6Ghz LTE band as well as 2.75G and 3G. Hoping that they are similar.

So Opening it showed me that it’s based on the same chip, which is connected to another chip in charge of the 2/3 G.

2 different Firmware are written in this one. mode A and B. A is LTE, B = 2/3 G. Therefor, in order to switch, it needs to reboot on its new firmware.

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.

P1 CERT role is to guarantee a professional incident and vulnerability management by direct cooperation with Customers, VKB Subscribers, Telecom Vendors, Operators, Governments and other CERTs. P1 CERT is also collaborating with TCERT for Telecom-related coordination activities.

Also you may wish to know more about our work on Mobile and  Telecom vulnerabilities releases by checking our Vulnerability Knowledge Base.

Here is an overview of the the work of P1 CERT that is integrated into the VKB:

This a visualization of P1 Security VKB vulnerability evolution over time. You can see that P1 CERT has done intense amount of reverse engineering and vulnerability research in order to qualify vulnerabilities and develop knowledge.

VKB vulnerabilities, sorted by risk, and including Best Practices. You can see here that P1 CERT focuses on high-impact vulnerabilities but at the same time provides Best Practices to help securing networks.

VKB vulnerabilities by Network Element type. HLR & MSC are currently the most impacted equipment, according to P1 VKB.

VKB vulnerabilities per Vendor indicate that Huawei is the most concerned vendor in term of vulnerabilities entries. This can be a bias of analysis as Huawei is present in nearly 90% of the operators we do work with, so its representation in number of vulnerability is not only due to the intrinsic vulnerability of their equipment, but also to their ubiquitousness.

For more demonstration, you may visit P1 Security VKB tour.

Contact P1 Security CERT at : cert@p1sec.com

• Click here to see the P1 Security CERT PGP Key

  —–BEGIN PGP PUBLIC KEY BLOCK—–
  Version: GnuPG v1.4.12 (GNU/Linux)

  mQINBEtXaFIBEADgJGDE1OLUtmN+v0tmlmjWdJZA1dWCtvC+LPdkvYIWiLJSiqpZ
  5v+MaLMxIsQ0A4emjBzW2vD5buTNwyTzi5Jy8xRw0uQJZtFww73W0QIksukGqLu/
  BtcyhoZdZeNYfkJc+/FaRczvEJOsp3dYjpztygAwLDzftagrQ3SM4J5dfjbkR4qU
  3BVjgcrSKnUihc2UwGgXNZi7MjA09doCpr+IvtuWMZKVOShF1Y0jPuVbzWhrb8/e
  Kr3ikrBdxuV97UXXLERFMxmuPAWJhsjxObjqCCXhwwuhSpA1kZ26za7b/Dzy1C0V
  WpuI4DTJevAOtIqss64uyDpuh+UFh0GMHLkYJu+GQftwcM6Pxs2xrADBuqWzgbvK
  q3OJrgK4LQGiBYPiK+s0tyE/w7rXu2QO4sml/EKVpbbTcRWiFodQPspTn0kkPtnI
  WFoLrM58EBDxTOMrVySri4pvcGvwsU+KW2n2vkPRH2tS2kGK5FocEpW1lN/U8VBA
  l0i2NayC/ro1yK+fe2Tfe5Eo0bDyEyQQsWGCY5cYEnyhUHVuNayDhx1B1oAqbo6v
  Um1ISaTvq7eCGtCtegD3nLUlR/I7UQ2cvCctrYtpc8qZdcVPAENfur6ZyBMeSsGx
  S7j8LfNlddMNVx5lJ4jxDuHVItThiwyFtgKL+5g1YqXbjiQinqNNUEKeiQARAQAB
  tB9DZXJ0LUlTVCA8Y2VydGlzdEBjZXJ0LWlzdC5jb20+iQIVAwUQS1dze7a+qPo1
  CmC6AQI1lg//QhwVz2axRWn4jearE4q6qkIQ3vHnxJ1piqK4eePxUNcDeB5GwDUT
  QfeQ3SeSFOw1ERVDZGlq21PPz+9RG/vDhJQnQ/QaUIFZfFMEsq01vqYFtCC8a80v
  gikPbC/kRj1Q3YgumK6CTbVSLiZLckd7wyTe33Acr3cql5EWsN7LHwD8hnHoH0zT
  FSjSbB9xu6W/8uVJqk3CqZIIEJfMirtcm1yrMzxRtgKOGNqNrI73q7HhPbw67Sax
  VZb7QpFmzIDIUnbE5eJUqELSq3QEBY0Z/YNXnBDFFHGBhJAs89LKluNXPPK8H/rr
  /PUN1a3e/eqOiOS8RHvI9KPh8nb8QwMonQvFUdxjG0owRwHHfm3za2BiPn1vk3+W
  ApsH9xyZTsG6rbziPUfpVtSF46Mes+0uCnS0/ynYIleHmtQMLwCVuSZqL8D9Vbml
  fEkwW15G3JAWwa/Knnwon63KDKcOb+jXq3vs0nbI65UX68l41kqGkhTsI9UNsQlq
  5jkRz9yw29qf3qj6ACAeo4N+vjEhwmd4WQbnqLQ5leGLWulQsHp5lYZNCrXHJyHW
  HhcTfP1Z12cimbU5q6NEqMVynsY1+YBIi9jn6lBtkS79pCZbCVZWMLmNQmb4nvxs
  LIfNKYAEHiP2vIZMsWLaeugMtDw/jnnq9fvlfi7QFdEfjyaX4W/pFaqJARUDBRBL
  WAJ6ji95MC7uHgsBAjQHB/0VQB9OHwZ7tuvmGEm8z2ThjP3T0SirSmHswmn3k7VY
  WfcqFEgR5pk9maWT4XgUrmWPRZUyv2FXkAUKAX6Qp8aGFOk4vETsV357THz/vRc8
  oqxgdgAVBbMkTpuL8w+SOlV+A/H7WEqt+i4cTqGkzrC2mxFJ/qsXXnu/PH7IA+Ap
  PbzQqWRIAZfuDiVeThhEuERvbL4T8AMQ8q+oIQqoGEk8HpsWFbFg7AiWKgr/6Fn+
  GTz/0AutmB0hoDAexRw8eBglI3NlyreHTdm3t/1iQIK8YxY7RemENWy1R0m+dQjk
  jUughf5q6ty4iQhwysAoI+9f0X2/ed5kMXGfP3kPiz8qiEYEExECAAYFAkwvukoA
  CgkQ13JbYSPmlWmzTwCfU1Ed3CsiQYrp6jaiNkPQE+tAqakAnjhkePGzSufgdVV7
  jTtFuOyCYXZptBxDZXJ0LUlTVCA8Y2VydEBjZXJ0LWlzdC5jb20+iQIVAwUQS1dz
  Vra+qPo1CmC6AQJaXA/+L0f6lXfIC1zILETJRbVN1BRSJNBH1H2l7+MaBiv1UUro
  swhD5IVxqPzdb1RLv6c2EnlUmpGDgtYWlaY4omYnp2F7bazWIvJjcEM1POK6s/wn
  5ZLHtctIC8NWqYeVXuC4+3sX+b3/hMije3PxhIblJSzPYRha1x+7ydz1rZewuSzA
  Dr45GPArkVa2m/3PH2foXNVdWcpU+rb9QVuD8p+tW8FLJERRJvFDIKW6RGkExoRS
  XBzBNgUpH2mdL0vukN86PHaHERYWcMWghXj4M7AJYxzYUVOD+Q0bL0MUkTqYxwa9
  OSByCkijOUwwl9ZuTdXehJgRGThFn6cVOqcuQR+Bvj6KH220oY58KHJkJycC2q5n
  Iayw2MGNj96goeefqSa/GLKCg3SUu8qAz23goWQEWKbCp9N+SM3OpHSlIRslsY0E
  6oZ3VkS1kTofGTtDJ8J12PSfwsr2kYn/IMMPnhHerhJAFFnYpSZNcvP4nphwWZX0
  T2U/qjhQuVdIvJ4fY+2KELzYHCrUl/sKx6JjmtO8gnuNI4wpmZhOz1qWn3wjM+G8
  VyfJooa8Mn5yvLqqirQx+JQLpAlkFog7PZiuF6/zFFB/muIeborrK9vRVmBb4tzb
  xAiGx+xNOqBbMfDdbk3U2VAD9cNiHZOFMzZubpc119cLwoxvuCw9ZlVF1x4f6TqJ
  ARUDBRBLWAIoji95MC7uHgsBAl4RB/wJLvfvQzrzFk6W+fw4GnRxwK1EbzCC+dXU
  gQyw56kKOLgMVoosIq/Qlz3vrkX72Cb52N+xWjVigzibhPi7AYKAXG80nmdxPZZV
  /cpv9kI/mcCgoqW0q2yyHXn6nHodXRkqU/Sw3PBR36N6viABf/G+EXF9j47/LObl
  qoib53qLWLzROovHxJz0ueLhiRaa11HK4o4tYEhOLS3u7OvrJKTQqYIqzu6uTAT2
  Puvtny8Opi7cwsfQU/usDw48QnDG5PrXasQXb/E34RCzBrkg67FOA8XEaj5ZJu+Y
  JfrALNylnVYCnVaZfr5XFwyf+8fqTSlt2DNI9X+xENN78sbsuVaXiEYEExECAAYF
  AkwvukoACgkQ13JbYSPmlWmHYACfe3ITSHy0eRm5a4Tg9OhWPrFfIWMAn1HKPuyo
  TYhZJ+dScK5AGsGxhtjnmQINBFHxTVMBEADSdK3BX33CMBQyGinh8eNxRcs2Aicb
  m0NhUtPUjUYujno6QFFsmi+DPp4PhFP+xt2Ys/H9soBJ58QYUD7gd9G82aCRIe16
  Uaz6fhp+g6BC34glrkEmVPGNKR9NY45WOcBu2D9G91X3dCafbBoIZSo+bAsR34V1
  WAN1RQez1ABeDp069u4BNCuoWZNaUn26bdSu6T6ClWA8s/POo/lZkqNMhSdZC/9B
  KbfDEvgt0CDVYaMgC6fXhwJoxpIp1aMAOjdOxgwTIo+JkMwUNxfIX5tWHNrhupR2
  ePpkhqGiQ5B2MLSXw2CdeKXZH+/0mP/G5EPSCWbvuHxaegAfEVxD77uksLOjuOdq
  X/HQ7Vaqwz/NRWJCxuCHBg8/675YGBSkLVW4v9171cP5M4YOnaHyZ5in04r+EjkL
  6yK9y+y/1BXHkL+6xW08TtUmoT4AQk0EFnUzNLXHa6argmqbxuxxVWghYNStjFnV
  D0bVuwKwusZlJ7b5x83Z2QztHDQcwumcA9uTN4SePqck+N6H4PF2EntFEYtKyGdp
  vyLAMk728xtCo6ArCmsIkzF64ddvKPCHgxtGf/JaIHvaCXxkVlasYitOhqi0lr4L
  Kib5t+5urQinJcbBbyGP67MPuRljXxCnUzk1ngBRXp0W/i1Ho+NoLQrUJwfC2jQz
  nD1TMeo3vn3P3QARAQABtHRQMSBTZWN1cml0eSBDb21wdXRlciBFbWVyZ2VuY3kg
  UmVzcG9uc2UgVGVhbSAoVGhpcyBpcyB0aGUgb2ZmaWNpYWwgUEdQIGtleSBvZiB0
  aGUgUDEgU2VjdXJpdHkgQ0VSVCkgPGNlcnRAcDFzZWMuY29tPokCOAQTAQIAIgUC
  UfFNUwIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQjevsxXEnPnVGTA//
  eaRwXlR9MpH/+8eS0HB5t1EyWlkmRBb1ExmszBHyTRz8AomFUSjB7OZ+kvIskPkN
  RbWoaxFSUpZqVEID2qJbsQ5z6hLcAmFHhlHmXdh7sbGpkTwbm8bxwjx44jrb5ryq
  kKmsYWbNf1v2ie/iWlNmkR8t58szkkx+H+hEpxwcofjzocmmea1urjCCTsHv7lV7
  da/Q5GGUJHsED9AZJUsYQ3r7pJ7wSskUuGjMRTSl66qO90+xuETq9CFirj2CbSNU
  v/7ohKbjaZDXhm4TmPJ8/61erpHfmpuNkG7drlUBvqPZk/xOlorfswcjW8N6KTFw
  8ksI9aGeOug5LIFLZGnrlmAPQMJloVicXYkIfwh04LxOM1mzs5ri+3fwF3+SV6kl
  zFWdch4AY3wdzpp/ewgkwJPQpbvRxbXmCK4mP4Srs6gFv29zQBotE4QBQTmwLXvg
  wZ7YwT47XwW337MCBZOZuOl3sX/GiFxoT+nC7rvoQovC+at68Cl3AAJQTy0crr/c
  PgJuST1RpLp9BIzZhGpyXGckm80i7kXxSPbz0ZqchX+1ln7XTDW8gVsfYci3t4tu
  RS0QYLG6trFTw+d7KkqPdXWxvFOq9XWscfNcCADU2zLvI5UHNcQeomQldSnjtkOn
  BMHofqU+j1vByLOfa9LW7R/kmqFNptg9/rnnRyOCT3q5Ag0EUfFNUwEQANrOvLS2
  Jupnnb5x/oEViyI+OthYcWFS4/FD3vKCin4ag1UHX1tQe9Ex21Ey2gW9ga/cg6bi
  9ZGyomDHi0roYNl9RjwLE5fs/HKDF47W3ohLKln7bAI9160WF2fNoRI0YVQuBKqL
  qKgJMeTB1AYNYAJR1VIdh5jQcDHbSmXIU12CPwoyfWx6zBeUlAj+emkIyhzY83xR
  wJJJFlfIX8QpySOhMW/cEeOFD0OIV5iOetPwR4C9ef/WYxjAnRo4QA7cQygtad70
  nf0ldLj822emM5VfpajGiE5HYVSIx+1DRq+YAyD6hqHl6bLD5dhRDNXdp2MPG+r/
  PCj1XCKCBbcGLbUK6KQl4iK3ydIab8dfUJZqe//QpLud2XMNBxP1o617muPLlmM4
  2icPHnIVp/d8LEPc/OVsY/rNuzQFfYjL/OZmkUq7xI2E2pkdsl+Yey4Rodq22KrT
  SlOtja80DzT+99/aRf3etDvz0ZEghrRxvwxHKFXneL4bFNtr25gCNXKNT5HW6Tm/
  qNYwOBUZ1/pVxfoPQ5yjiZLuk9oxEin/eEJBQSrzNX6GN/+5wQPpE7xzzB4lJH7M
  qnm6jrnneqpI45nMg94mOJQ9C0AGGyDaijeZ4l8sLTVKvx70RHV5FzRJKdF8Eczg
  H0tNvUR6c7F0llvdCSaPqNCWKgUTkLQj6IspABEBAAGJAh8EGAECAAkFAlHxTVMC
  GwwACgkQjevsxXEnPnVvhhAAyYrbcEpoWIy5dWkY1zqgfCDGtjHMSmut/RoiKwnu
  4Zpdc29xx2qj/yzBYwJT9o3r5ceM1aiN7QREWeuaBBDcHc9CkrC30UPWKGcGKzjD
  lwd1DV7DbodEAROf5gGdL3ooh3B3gWNhA6dgPldZflGpXlFnPqcbruVSO4QQdLJn
  gIj6+WQgJo7RrL2WEdNhmEM+dkUHLX22CZhDvWwK0mr0p711GaAl7b36ys6RDfiE
  yy0xjK6+50iwfqv+eha1wplL3bV92sm+8RA5wiCY7gY2Zbt8GGDaOMeP5Za8Fqk7
  xhjJNQDRs8W7QSKBM8R72ljr5mcWujdr6qDtCG5XtzD/fmKev4rptBUphKcTFbc6
  apHk178ET8xUBcdNZZtgXOhvmPZ85HxLJGyYxVi7ZBCL+YasGQIYGZMzUV58AMht
  jBdSEK5MQrrSLvodZ+TWdd0cMOQlU6inpfPjUH69aAbvksvNJcgM6fPlz5uidUIY
  HFCcI+z1QYtMnf5x9G9F2iQCcVlnS9xJC/Er31XlwCFsKKtaxQPJlnl/kWxtR1vl
  bLU/gxSUYFAOQlWqUDsGW4ObnZbBcFJ9J7exLDKI7dMIYP7WwSdsgW1SfXGt/75V
  MyL1Rt1Oiu9oKRQXBQw6gf26W1ciKBxUquLMfItIcWTmlHy1Zwoi97in57PayYKq
  AL8=
  =N3+w
  —–END PGP PUBLIC KEY BLOCK—–

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.

As part of our effort to further the knowledge on telecommunications technologies in the open source and security community we have presented an introduction into mobile and telecom networks and

From walled garden to open and reviewed security 

Telecommunication networks differ from IP networks in several important aspects. First, telecom networks have to provide the infrastructure ensuring high-availability, high throughput as well as resilience for a wide range of services. Second, telecom networks must offer support for legacy network elements and services as old as 40 years, requiring a multitude of protocols for backward compatibility and interoperability. Third, telecom networks support multiple addressing schemes making analysis and mapping more difficult than IP networks. The Internet is based in essence on a comparably small set of basic protocols that offer all the needed capabilities for higher layer services. The existing tools designed for the analysis of IP based networks offer little support for telecom networks and hence necessitate the development of dedicated tools. Here we present the techniques and tools that we have developed in order to better understand telecom networks. These tools allow us to scan, communicate on and visualize telecom networks. SCTPscan allows us to reliably and efficiently scan hosts for open SCTP ports which are possible entry points to the SS7 network. pysctp is a python library providing a simple API to the SCTP protocol, which is the basis for communicating on telecom networks. Finally, we demonstrate the capabilities of our toolset by analysing a typical telecom network and highlighting the aforementioned properties of such networks.

The network architecture of a typical mobile network operator. Telecom networks are powered by a large number of different technologies.

A passive network scan showing the different network elements (nodes) and the communication (edges) between them. The edge width is drawn proportional to the number of exchanged messages in the recorded period of time. (global titles have been anonymized)

We have recently presented this topic at the Libre Software Meeting, Security Track 2013 (slides). Also check out the RMLL website.

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.