P1 Security Computer Emergency Response Team – P1 CERT –  is officially open!

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

 … Read More

Backdoors are not only a problem regarding the original insertion made by the vendor, but also about the subsequent usage of these backdoors once discovered. In the recent network storage equipment backdoors (HP Keeps Installing Secret Backdoors in Enterprise Storage), the Huawei network element backdoors or the usual network equipment or DSL-router backdoors, these are now clearly a real and strong threat to enterprises.

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

Sometime, reverse engineering for bug hunting reveals some fun stuff.

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.

 … Read More

With the explosion in the mobile communications sector, the deregulation of public switched telecommunication networks (PSTN) as well as the introduction of many new services the dependence on the signalling system 7 (SS7) network has rapidly increased over the last two decades. Typically, monitoring systems on telephony networks have focused on fraud detection however the need for more effective and low-latency detection of attacks on today’s communication infrastructure has become indispensable (Gormann and Ruhl, 1999). Attacks range from fraudulent access to network services and databases (e.g., HLR) to gain access to private or sensitive information to denial of service type attacks to disrupt or deny telecommunication services.

P1 Telecom Monitor (PTM) is an Intrusion Detection System (IDS) specifically designed for SS7 and SIGTRAN networks. It is composed of a realtime detection framework and a reporting and monitoring user interface. PTM’s design allows it to be easily scaled from a single network tap to large-scale deployments throughout the network to be protected. The network traffic is filtered and processed in a decentralized manner while alerts are collected in a central datastore.

The PTM detection framework’s modular design allows us to quickly adapt and extend it to new attack types. Detectors are implemented as independent modules exposing a simple callback interface invoked by the detector framework upon interception of new traffic.

Attacks can often not be discerned from normal traffic by analyzing single packets, PTM also allows time-correlated events to be detected.

We believe that even the best IDS will be of little value if the detected events are not quickly translated into alerts and a response from the operations team. This is why PTM also offers a comprehensive web-based monitoring interface. On the one hand, a simple dashboard allows the engineer to gain a quick overview of the current status of the network and the most important threats. Aggregate statistics and real-time charts expose network activity and top attacks. On the other hand, detailed tabular reports allow the operator to understand and reconstruct events precisely and to react in the most appropriate fashion.

The combination of a scalable realtime traffic monitor, an extensible event-detector framework and simple yet powerful interface position P1 Telecom Monitor at the forefront of intrusion detection systems in the telecommunications sector.

 … Read More

The problem with wireshark

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

SIM Man In The Middle

I had in the past several time to sniff the traffic between a SIM card and a phone:

• In NFC applications, SIMs are updated OTA (Over The AIr) with the CAT_TP protocol. It was necessary to inspect the traffic
• Analyze the timing between the air traffic and the SIM traffic
• Inspect STK (SIM Tool Kit) Proactive command sent from the SIM to the phone
• …

I used several equipment to do those and created mine. I’ll explain in here what was the differences between those

• Rebel SIM

  

  RebelSim is a basic USB sniffer. Its schematic is quite simple. It’s composed of a USB to Serial converter (FTDI ft2232) and the RXD pin is connected to the data wire of the SIM and the phone. It’s therefor necessary to configure the baud-rate of the virtual serial interface to match the one of the SIM. The main disadvantage of this solution is that at the ATR (Answer to Reset) time, the bit-rate of the SIM card is not the same as the one after ATR. since the F and D factor are described in the ATR response. So following the dialog is not that trivial, and if the phone clocks the SIM at a non standard bit-rate, the dumping would not occur.

• Bladox

  

  Bladox is made of two pieces. the Turbo Lite 2, which embed an ARM processor which does the MITM between the SIM and the mobile. This one respond to the ATR and set its own ATR response. The Turbo Programmer hosts the TurboLite2 and sends the data back to the host computer using a FTDI chip. The advantage of the TurboLite2 is that the lines are isolated with optocoupler, and powered up with the phone itself. The disadvantage is that if a command is unknown, the TurboLite will not rely it back to the sim. It actually just uses the SIM card for its Telco resources (IMSI/Ki).

• SimTrace

  

  SIMTrace is part of the Osmocom project. It’s articulated around an ARM proc that could cut the line between the SIM and the reader and therefor emulate the SIM on one side and the reader on the other side. the software has never been finished for doing so. It has the advantaged of being connected to the CLK (clock) pin of the SIM and be able to count in order to be correct on the time division.

UMA / GAN

UMA = Unlicensed Mobile Access

GAN = Generic Access Network

ts 43.318 and 44.318

Wikipedia says: Generic Access Network or GAN is a telecommunication system that extends mobile voice, data and IP Multimedia Subsystem/Session Initiation Protocol (IMS/SIP) applications over IP networks. Unlicensed Mobile Access or UMA, is the commercial name used by mobile carriers for external IP access into their core networks.

To make it simple, on one side, a device connect to the mobile operator using IPSEC with EAP-SIM. Once connected, a session is established with ip/tcp/uma to the GANC (Gan controller) or UNC (Uma Network Controller). On top of that, GSM L3 packet could be sent

Here is a list of UMA devices

• UMA phones

  

  In order for a phone to be UMA enabled, it requires the baseband processor to communicate with the media processor since the signaling is involved, as well as to the SIM card for the EAP-sim establishment. Therefor, it’s not just an application

  here is a list of UMA enabled phone:

  Blackberry Bold 9700
  
  Blackberry Bold 9780
  
  Blackberry Pearl 8120
  
  Blackberry Curve 8320
  
  Blackberry Curve 8520
  
  Blackberry Flip 8220
  
  Blackberry 8900
  
  Blackberry 8820
  
  Blackberry 9100
  
  Blackberry 9300
  
  Blackberry 9700
  
  Blackberry 9800
  
  HP iPAQ 510
  
  LG KE520
  
  LG CL400
  
  Motorola A910
  
  Motorola Z6W
  
  Nokia 6086
  
  Nokia 6136
  
  Nokia 6301
  
  Nokia 7510
  
  Nokia E73
  
  Qisda/BenQ e72
  
  Sagem my419x
  
  Samsung P180
  
  Samsung P200
  
  Samsung P220
  
  Samsung P250
  
  Samsung P260
  
  Samsung P270
  
  Samsung T336
  
  Samsung T339
  
  Samsung T409
  
  Samsung T707
  
  Samsung T739 Katalyst
  
  SIMTech N6000
  
  T-Mobile (HTC) Shadow 2009
  
  T-Mobile (HTC) MyTouch
  
  T-Mobile (HTC) MyTouch 4G
  
  T-Mobile (HTC) G2
  
  T-Mobile (LG) Optimus T
  
  T-Mobile (Motorola) Defy
  
  

  As we can see, many of them are from RIM BlackBerry. Follows the Engineering screen mode for configuring UMA on a BlackBerry:

  

• UMA Gemalto USB key (Branded as Unik PC)

  

  
  
  Host: scsi9 Channel: 00 Id: 00 Lun: 00
  
  Vendor: Orange Model: ApplicationDRV Rev: 1.00
  
  Type: CD-ROM ANSI SCSI revision: 00
  
  Host: scsi9 Channel: 00 Id: 00 Lun: 01
  
  Vendor: Orange Model: PrivateDRV Rev: 1.00
  
  Type: Direct-Access ANSI SCSI revision: 00
  
  Host: scsi9 Channel: 00 Id: 00 Lun: 02
  
  Vendor: Orange Model: PublicDRV Rev: 1.00
  
  Type: Direct-Access ANSI SCSI revision: 00
  
  Host: scsi9 Channel: 00 Id: 00 Lun: 03
  
  Vendor: Orange Model: CommunicationDRV Rev: 1.00
  
  Type: Direct-Access ANSI SCSI revision: 00
  
  # cat /proc/scsi/usb-storage/9
  
  Host scsi9: usb-storage
  
  Vendor: GEMALTO
  
  Product: Unik PC
  
  Serial Number: A10600000000XXX
  
  Protocol: Transparent SCSI
  
  Transport: Bulk
  
  Quirks: SANE_SENSE
  
  

  When mounting the filesystem, we get 3 partitions, 1 protected by the sim pin, the 1 COM containing a CDROM image, and 1 System, writable

  
  
  mount -o loop -t vfat /dev/sdd /media/
  
  # ls -al
  
  total 128007
  
  drwxr-xr-x 2 root root 512 Jan 1 1970 .
  
  drwxr-xr-x 23 root root 4096 Jan 21 20:00 ..
  
  -rwxr-xr-x 1 root root 512 Apr 23 2009 ANCHORI.CLP
  
  -rwxr-xr-x 1 root root 512 Apr 23 2009 ANCHORO.CLP
  
  -rwxr-xr-x 1 root root 52 Apr 23 2009 AUTORUN.INF
  
  -rwxr-xr-x 1 root root 131072000 Apr 23 2009 CD-ROM.CLP
  
  -rwxr-xr-x 1 root root 1024 Apr 23 

Femtocell Ubiquisys v2

Ubiquisys G3

Here is a look of the PCB

In fact, it’s 2 PCB, one module from Ubiquisys connected with a B2B (board to board) connector to the NEC platform that is there for powering, ethernet, usb, at24 Eeprom.

Some info about the cpu, before Broadcom buys Percello, it used to be tagged as PRC6000.

 
cat /proc/cpuinfo
system type		: Percello PRC6000
processor		: 0
cpu model		: MIPS 24Kc V8.1
BogoMIPS		: 408.78
wait instruction	: yes
microsecond timers	: yes
tlb_entries		: 32
extra interrupt vector	: yes
hardware watchpoint	: yes, count: 4, address/irw mask: [0x0000, 0x07a0, 0x0e28, 0x07e8]
ASEs implemented	: mips16
shadow register sets	: 2
core			: 0
VCED exceptions		: not available
VCEI exceptions		: not available

As seen in the previous version, there is a A and B version of the File Systems. The boot contain a bootlader different from u-boot. It’s a custom Percello made.

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00020000 "boot"
mtd1: 07fe0000 00020000 "system"
mtd2: 0001f800 0001f800 "bootdata"
mtd3: 00333000 0001f800 "recovery"
mtd4: 0001f800 0001f800 "keystore"
mtd5: 0005e800 0001f800 "operator"
mtd6: 00295800 0001f800 "kernelA"
mtd7: 00fff000 0001f800 "rootfsA"
mtd8: 013b0000 0001f800 "ubiqfsA"
mtd9: 009d8000 0001f800 "databaseA"
mtd10: 00295800 0001f800 "kernelB"
mtd11: 00fff000 0001f800 "rootfsB"
mtd12: 013b0000 0001f800 "ubiqfsB"
mtd13: 009d8000 0001f800 "databaseB"
mtd14: 00333000 0001f800 "recovery-bak"
mtd15: 003f0000 0001f800 "recovery-cache"

Partitiomns are signed using a RSA algorithm. Each partiton is signed and a signature as well as a publick key is given. The bootloader is self verified

The Percello seams to be able to use an external i2c eeprom that is not populated. In the init script, “at24=at24c02..” is passed to a kernel helper called “dev_helper” which will load in this case the EEPROM. The funny part is that the EEPROM is configured at address 0x50 + A2 A1 A0. In this case A2..A0 are all wired to GND which would give this EEPROM the address 0x50. However, the script seems to be using 0x57… The script checks if the file /sys/class/i2c-adapter/i2c-1/1-0057/eeprom exist, if it does, it copies it and calls ee2ini which will convert it into an .ini file, using ipeeprom.xml as a field descriptor. Otherwise, an ipeeprom_default.bin is used.

 
# Read IP EEPROM, if present
EESPEC="at24=24c02,1,0x57,256,8,0"
echo $EESPEC >/sys/kernel/ubiquisys/dev_helper
EEPROM="/sys/class/i2c-adapter/i2c-1/1-0057/eeprom"
if [ -e $EEPROM ]; then
    cp $EEPROM /tmp/ipeeprom.bin
    if ! ee2ini /etc/ipeeprom.xml /tmp/ipeeprom.bin /etc/ipeeprom.ini 2>/dev/null; then
        echo "No valid data in IP EEPROM, setting to DHCP"
        ee2ini /etc/ipeeprom.xml /etc/eeprom_default.bin >/etc/ipeeprom.ini
    fi
    rm /tmp/ipeeprom.bin
else
    ee2ini /etc/ipeeprom.xml /etc/eeprom_default.bin /etc/ipeeprom.ini
fi

as seen on the picture, the 3 chips is not populated:

• U18: AT24C02

• R129: 10k Pullup resistor

• C87: 100nf

The eeprom is only 256 bytes wide. However, the IP configurations would use less than 128 bytes. the rest could be used for some key ? 😉

FTDI has a UMFT201XB-01 Module which is an I2C Slave to USB converter.

The module is part of the FT-X device series. Thanks to Richard Meadows who modified a FT_PROG compatible tool written my Mark … Read More

These are important links to know when you’re going to enter the telecom world for security assessment.

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

 … Read More