OsmocomBB - Sending arbitrary protocol data to GSM networksgit.gnumonks.org/laforge-slides/plain/2010/osmocombb-phneutral20… · GSM/3G Network Security Introduction Security Problems

GSM/3G Network Security IntroductionSecurity Problems and the Baseband

OsmocomBB ProjectSummary

OsmocomBBSending arbitrary protocol data to GSM networks

Harald Welte

gnumonks.orggpl-violations.org

OpenBSCairprobe.org

hmw-consulting.de

ph-neutral 2010, May 2010, Berlin/Germany

Harald Welte OsmocomBB



Outline

1 GSM/3G Network Security Introduction

2 Security Problems and the Baseband

3 OsmocomBB Project

4 Summary




About the speaker

Using + playing with Linux since 1994Kernel / bootloader / driver / firmware development since1999IT security specialist, focus on network protocol securityBoard-level Electrical EngineeringAlways looking for interesting protocols (RFID, DECT,GSM)




The closed GSM industrySecurity implicationsThe GSM networkThe GSM protocols

GSM/3G protocol security

ObservationBoth GSM/3G and TCP/IP protocol specs are publiclyavailableThe Internet protocol stack (Ethernet/Wifi/TCP/IP) receiveslots of scrutinyGSM networks are as widely deployed as the InternetYet, GSM/3G protocols receive no such scrutiny!

There are reasons for that:GSM industry is extremely closed (and closed-minded)Only about 4 closed-source protocol stack implementationsGSM chipset makers never release any hardwaredocumentation





The closed GSM industryHandset manufacturing side

Only very few companies build GSM/3.5G baseband chipstoday

Those companies buy the operating system kernel and theprotocol stack from third parties

Only very few handset makers are large enough tobecome a customer

Even they only get limited access to hardwaredocumentationEven they never really get access to the firmware source





The closed GSM industryNetwork manufacturing side

Only very few companies build GSM network equipmentBasically only Ericsson, Nokia-Siemens, Alcatel-Lucent andHuaweiException: Small equipment manufacturers for picocell /nanocell / femtocells / measurement devices and lawenforcement equipment

Only operators buy equipment from themSince the quantities are low, the prices are extremely high

e.g. for a BTS, easily 10-40k EUR





The closed GSM industryOperator side

Operators are mainly banks todayTypical operator outsources

BillingNetwork planning / deployment / servicing

Operator just knows the closed equipment as shipped bymanufacturerVery few people at an operator have knowledge of theprotocol beyond what’s needed for operations andmaintenance





The closed GSM industrySecurity implications

The security implications of the closed GSM industry are:Almost no people who have detailed technical knowledgeoutside the protocol stack or GSM network equipmentmanufacturersNo independent research on protocol-level security

If there’s security research at all, then only theoretical (likethe A5/2 and A5/1 cryptanalysis)Or on application level (e.g. mobile malware)

No open source protocol implementationswhich are key for making more people learn about theprotocolswhich enable quick prototyping/testing by modifying existingcode





Security analysis of GSMHow would you get started?

If you were to start with GSM protocol level security analysis,where and how would you start?

On the network side?Difficult since equipment is not easily available andnormally extremely expensiveHowever, network is very modular and has manystandardized/documented interfacesThus, if equipment is available, much easier/faster progressHas been done in 2008/2009: Project OpenBSC





Security analysis of GSMHow would you get started?

If you were to start with GSM protocol level security analysis,where and how would you start?

On the handset side?Difficult since GSM firmware and protocol stacks are closedand proprietaryEven if you want to write your own protocol stack, the layer1 hardware and signal processing is closed andundocumented, tooKnown attempts

The TSM30 project as part of the THC GSM projectmados, an alternative OS for Nokia DTC3 phones

none of those projects successful so far





Security analysis of GSMThe bootstrapping process

Read GSM specs day and night (> 1000 PDF documents)Gradually grow knowledge about the protocolsObtain actual GSM network equipment (BTS, MS tester, ...)Try to get actual protocol traces as examplesStart a complete protocol stack implementation fromscratchFinally, go and play with GSM protocol security





The GSM network





GSM network components

The BSS (Base Station Subsystem)MS (Mobile Station): Your phoneBTS (Base Transceiver Station): The cell towerBSC (Base Station Controller): Controlling up to hundredsof BTS

The NSS (Network Sub System)MSC (Mobile Switching Center): The central switchHLR (Home Location Register): Database of subscribersAUC (Authentication Center): Database of authenticationkeysVLR (Visitor Location Register): For roaming usersEIR (Equipment Identity Register): To block stolen phones





GSM network interfaces

Um: Interface between MS and BTSthe only interface that is specified over radio

A-bis: Interface between BTS and BSCA: Interface between BSC and MSCB: Interface between MSC and other MSC

GSM networks are a prime example of an asymmetricdistributed network, very different from the end-to-endtransparent IP network.





GSM network protocolsOn the Um interface

Layer 1: Radio Layer, TS 04.04Layer 2: LAPDm, TS 04.06Layer 3: Radio Resource, Mobility Management, CallControl: TS 04.08Layer 4+: for USSD, SMS, LCS, ...




TheoryThe BasebandObservationsGSM Protocol Fuzzing

Known GSM security problemsScientific papers, etc

No mutual authentication between phone and networkleads to rogue network attacksleads to man-in-the-middle attacksis what enables IMSI-catchers

Weak encryption algorithmsEncryption is optional, user does never know when it’sactive or notDoS of the RACH by means of channel request floodingRRLP (Radio Resource Location Protocol)

the network can obtain GPS fix or even raw GSM data fromthe phonecombine that with the network not needing to authenticateitself





Known GSM security problemsThe Baseband side

GSM protocol stack always runs in a so-called basebandprocessor (BP)What is the baseband processor

Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5Gphones)

Runs some RTOS (often Nucleus, sometimes L4)No memory protection between tasks

Some kind of DSP, model depends on vendorRuns the digital signal processing for the RF Layer 1Has hardware peripherals for A5 encryption

The software stack on the baseband processoris written in C and assemblylacks any modern security features (stack protection,non-executable pages, address space randomization, ..)





A GSM Baseband Chipset

CALYPSODigital Baseband

DSPMCUSRAMMask ROMUART, SPI, I2C

TWL3025ABB

BSP

USP

TSP

BULBDL

AntennaSwitch

ASM4532

TRF6151

TransceiverMixersVCOPLL

RF3166

RF PA

TSP

GSM

DCS/PCS

GSM

DCS

PCS

RFCLK

I/Q Analog

CLK13M

AFC Analog

TSP Parallel

TSP Serial

CLK32K

GS

M

DC

S/PC

S

APC Analog

I/Q Digital

SPI

http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf






Interesting observationsLearned from implementing the stack

While developing OpenBSC, we observed a number ofinteresting

Many phones use their TMSI from the old network whenthey roam to a new networkVarious phones crash when confronted with incorrectmessages. We didn’t even start to intentionally sendincorrect messages (!)There are tons of obscure options on the GSM spec whichno real network uses. Potential attack vector by usingrarely tested code paths.





GSM Protocol FuzzingTheoretical basis

How to do GSM protocol fuzzingFrom the handset to the network

Basically impossible due to closeness of basebandHowever, some incomplete projects working on it

From the network sideEasy in case of rogue network attacksFuzzing target is the GSM stack in the baseband processor

As an A-bis man in the middleNeeds access to an A-bis interface of an actual networkVery attractive, since no encryption and ability to fuzz bothnetwork and handset





scapy GSM supportThe actual fuzzing

How to actually craft the packets for the fuzzingGSM has many, many protocolsWriting custom code will be a hard-coded special case foreach of themSolution: Use scapy and implement the GSM protocols asscapy "layers"

IPA protocol headerRSL protocol layerRLL data indication / data requestGSM 04.08 RR / MM / CC messages




OsmocomBB IntroductionOsmocomBB ArchitectureOsmocomBB SoftwareOsmocomBB Hardware SupportOsmocomBB Project Status

OsmoocmBB Introduction

Project was started in January 2010Implementing a GSM baseband software from scratchThis includes

GSM MS-side protocl stack from Layer 1 through Layer 3Hardware drivers for GSM Baseband chipsetSimple User Interface on the phone itselfVerbose User Interface on the PC

Note about the strange project nameOsmocom = Open Source MObile COMmunicationBB = Base Band





OsmoocmBB Software Architecture

Reuse code from OpenBSC where possible (libosmocore)We build libosmocore both for phone firmware and PC

Initially run as little software in the phoneDebugging code on your host PC is so much easierYou have much more screen real-estateHardware drivers and Layer1 run in the phoneLayer2, 3 and actual phone application / MMI on PCLater, L2 and L3 can me moved to the phone





OsmoocmBB Software Interfaces

Interface between Layer1 and Layer2 called L1CTLFully custom protocol as there is no standardImplemented as message based protocol overSercomm/HDLC/RS232

Interface between Layer2 and Layer3 called RSLmsIn the GSM network, Um Layer2 terminates at the BTS butis controlled by the BSCReuse this GSM 08.58 Radio Signalling LinkExtend it where needed for the MS case





OsmoocmBB Target Firmware

Firmware includes software likeDrivers for the Ti Calypso Digital Baseband (DBB)Drivers for the Ti Iota TWL3025 Analog Baseband (ABB)Drivers for the Ti Rita TRF6151 RF TransceiverDrivers for the LCD/LCM of a number of phonesCFI flash driver for NOR flashGSM Layer1 synchronous/asynchronous partSercomm - A HDLC based multiplexer for the RS232 tohost PC





OsmoocmBB Host Software

Current working name: layer23Includes

Layer 1 Control (L1CTL) protocol APIGSM Layer2 implementation (LAPDm)GSM Layer3 implementation (RR/MM/CC)GSM Cell (re)selectionSIM Card emulationSupports various ’apps’ depending on purpose





OsmoocmBB Supported Hardware

Baseband ChipsetsTI Calypso/Iota/RitaSome early research being doen on Mediatek (MTK)MT622x

Actual PhonesCompal/Motorola C11x, C12x, C13x, C14x and C15xmodelsMost development/testing on C123 and C155GSM modem part of Openmoko Neo1973 and Freerunner

All those phones are simple feature phones built on aARM7TDMI based DBB





The Motorola/Compal C123





OsmoocmBB Project Status: Working

Hardware Drivers for Calypso/Iota/Rita very completeLayer1

Power measurementsCarrier/bit/TDMA synchronizationReceive and trnasmit of normal bursts on SDCCHTransmit of RACH bursts

Layer2 UI/SABM/UA framesLayer3 Messages for RR / MM / CCCell (re)selection according GSM 03.22





OsmoocmBB Project Status: Not working

Actual SIM card reader inside phone (WIP)Layer1

Automatic Tx power control (APC)Automatic Rx gain control (AGC)Frequency HoppingNeighbor Cell MeasurementsTraffic Channels (TCH)

Layer2 Asynchronous Balanced Mode(ACK/retransmissions)Actual UI on the phoneDrivers for Audio/Voice signal path





OsmoocmBB Project Status: Executive Summary

We can esetablish control/signalling channels withnon-hopping cells

Used in small single-TRX cells in rural areasUsed in GSM-R networksAs provided by OpenBSC + OpenBTS

We can send arbitrary data on those control channelsRR messages to BSCMM/CC messages to MSCSMS messages to MSC/SMSC

Adding frequency hopping support not very hard




What we’ve learnedWhere we go from hereFurther Reading

SummaryWhat we’ve learned

The GSM industry is making security analysis very difficultIt is well-known that the security level of the GSM stacks isvery lowWe now have multiple solutions for sending arbitraryprotocol data

From a rogue network to phones (OpenBSC, OpenBTS)From an A-bis proxy to the network or the phonesFrom custom GSM phone baseband firmware to thenetwork





TODOWhere we go from here

The basic tools for fuzzing mobile networks are availableNo nice interface/integration from OsmocomBB to scapyyetIt is up to the security community to make use of thosetools (!)Don’t you too think that TCP/IP security is boringJoin the GSM protocol security research projectsBoldly go where no man has gone before





Further Reading


http://bb.osmocom.org/

http://openbsc.gnumonks.org/

http://openbts.sourceforge.net/

http://airprobe.org/



http://bb.osmocom.org/

http://openbsc.gnumonks.org/

http://openbts.sourceforge.net/

http://airprobe.org/

Documents

OsmocomBB - Sending arbitrary protocol data to GSM networksgit.gnumonks.org/laforge-slides/plain/2010/osmocombb-phneutral20… · GSM/3G Network Security Introduction Security Problems