openbsc network-side gsm stack - · pdf filegsm) harald welte openbsc network-side gsm stack....

GSM/3G securityImplementing GSM protocols

Security analysisSummary

OpenBSC network-side GSM stackA tool for GSM protocol level security analysis

Harald Welte

gnumonks.orggpl-violations.org

OpenBSCairprobe.org

hmw-consulting.de

SSTIC 2010, June 2010, Rennes/France

Harald Welte OpenBSC network-side GSM stack



Outline1 GSM/3G security

The closed GSM industrySecurity implicationsThe GSM networkThe GSM protocols

2 Implementing GSM protocolsGetting startedTimelineOpenBSC

3 Security analysisTheoryObservationsGSM Protocol Fuzzing

4 SummaryWhat we’ve learnedWhere we go from hereWhere we go from hereFurther Reading




About the speaker

Using + playing with Linux since 1994Kernel / bootloader / driver / firmware development since1999IT security expert, focus on network protocol securityCore developer of Linux packet filter netfilter/iptablesBoard-level Electrical EngineeringAlways looking for interesting protocols (RFID, DECT,GSM)





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

Network planning / deployment / servicingEven Billing!

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





GSM is more than phone calls

Listening to phone calls is boring...Machine-to-Machine (M2M) communication

BMW can unlock/open your car via GSMAlarm systems often report via GSMSmart Metering (Utility companies)GSM-R / European Train Control SystemVending machines report that their cash box is fullControl if wind-mills supply power into the gridTransaction numbers for electronic banking





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





The closed GSM industryMy self-proclaimed mission

Mission: Bring TCP/IP/Internet security knowledge to GSMCreate tools to enable independent/public IT Securitycommunity to examine GSMTry to close the estimated 10 year gap between the state ofsecurity technology on the Internet vs. GSM networks

Industry thinks in terms of walled garden and phonesbehaving like specifiedNo proper incident response strategies!No packet filters, firewalls, intrusion detection on GSMprotocol levelGeneral public assumes GSM networks are safer thanInternet





The closed GSM industryAreas of interest for Security research

Specification problemsEncryption optional, weak and only on the Um interfaceLack of mutual authenticationSilent calls for pin-pointing a phoneRRLP and SUPL to obtain GPS coordinates of phone

Implementation problemsTMSI information leak on network changeTLV parsers that have never seen invalid packetsObscure options in spec lead to rarely-tested/used codepaths

Operation problemsVLR overflow leading to paging-by-IMSITMSI re-allocation too infrequentNetworks/Cells without frequency hopping





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, tooPublicly known 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 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 BTS equipment is available, much easier/fasterprogress





Security analysis of GSMThe bootstrapping process

Read GSM specs (> 1000 PDF documents) ;)Gradually grow knowledge about the protocolsObtain actual GSM network equipment (BTS)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, ...





GSM network protocolsOn the A-bis interface

Layer 1: Typically E1 line, TS 08.54Layer 2: A variant of ISDN LAPD with fixed TEI’s, TS 08.56Layer 3: OML (Organization and Maintenance Layer, TS12.21)Layer 3: RSL (Radio Signalling Link, TS 08.58)Layer 4+: transparent messages that are sent to the MSvia Um




Getting startedTimelineOpenBSC

Implementing GSM protocolsHow I got started!

In 2006 I bought an old BTS (Siemens BS-11) on eBayThis is 48kg GSM900 BTS with 2 TRX at 2W output power(each)I didn’t have much time at the time (day job at Openmoko)Started to read up on GSM specs whenever I couldBought a HFC-E1 based PCI E1 controller, has mISDNkernel supportFound somebody in the GSM industry who providedprotocol traces

In September 2008, we were first able to make the BTSactive and see it on a phone





Implementing GSM protocolsTimeline

November 2008: I started the development of OpenBSCDecember 2008: we did a first demo at 25C3January 2009: we had full voice call supportQ1/2009: Add support for ip.access nanoBTSJune 2009: I started with actual security related stuffAugust 2009: We had the first field test with 2BTS and >860 phonesQ1/2010: The first 25 OpenBSC instances running in acommercial network





Security analysis of GSMOpenBSC

What is OpenBSCA GSM network in a box softwareImplements minimal subset of BSC, MSC, HLR, SMSCIs Free and Open Source Software licensed under GNUGPLSupports Siemens BS-11 BTS (E1) and ip.accessnanoBTS (IP based)Has classic 2G signalling, voice and SMS supportImplements various GSM protocols like

A-bis RSL (TS 08.58) and OML (TS 12.21)TS 04.08 Radio Resource, Mobility Management, CallControlTS 04.11 Short Message Service





Security analysis of GSMOpenBSC

OpenBSC featuresRun a small GSM network with 1-n BTS and OpenBSCNo need for MSC/HLR/AUC/...No need for your own SIM cardsEstablish signalling channelsMake incoming and outgoing voice calls between phonesSend/receive SMS between phonesConnect to ISDN PBX or public ISDN via Linux Call RouterTelnet console with Cisco-style interface




TheoryObservationsGSM 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





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





A-bis injectionfor A-bis over IP

How to do inject messages into A-bis over IP?Problem

A-bis/IP uses one TCP connection for OML and RSLmessagesOML initialization is essential for BTS to becomeoperationalTCP makes insertion of additional messages relatively hard

Solution: Build an A-bis injection proxyTransparently pass OML and RSL packets between BTSand BSCAdd additional stateless UDP sockets for injectingmessages, one socket each for

injecting OML/RSL to the networkinjecting OML/RSL to the BTS





A-bis Injection ProxyPrinciple of operation

Proxy needs to be brought between BTS and BSCLuckily, A-bis/IP SSL support not always usedThus, physical access to the Ethernet link sufficientConfigure system with two interfaces

BSC-facing interface has IP of BTSBTS-facing interface has IP of BSC / default gw

BTS will make TCP connection to proxyproxy will make independent TCP connection to BSC





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





OpenBSC silent callsA more elegant fuzzing interface

Injection at the A-bis level has many problemsyou can only do it while a call is activeyou simply piggy-back on existing RR connections

The OpenBSC silent call feature can helpwe use OpenBSC to establish a RR connectionin the GSM master/slave model, the phone will not close aconnection unless told to do sowe then send arbitrary data to the phone and receive itsresponsesthis currently only works from within OpenBSC, but we’llprovide UDP injection sockets soon




What we’ve learnedWhere we go from hereWhere 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 phones





TODOWhere we go from here

The tools for fuzzing mobile phone protocol stacks areavailableIt is up to the security community to make use of thosetools (!)Don’t you too think that TCP/IP security is boring?Join the GSM protocol security research projectsBoldly go where no man has gone before





Current Areas of Work / Future plans

OsmoSGSN/OpenGGSN: Packet data (GPRS/EDGE)support

GPRS/EDGE is used extensively on modern smartphonesEnables us to play on IP level with those phones without aheavily filtered operator networkStatus: Already functional, but very fragile/incomplete. 1-2more months

UMTS(3G) support in OpenBSCPlaying with SIM Toolkit from the operator sidePlaying with MMSMore exploration of RRLP + SUPL





Further Reading

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

http://bb.osmocom.org/

http://openbsc.gnumonks.org/

http://openbts.sourceforge.net/

http://airprobe.org/


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

http://bb.osmocom.org/

http://openbsc.gnumonks.org/

http://openbts.sourceforge.net/

http://airprobe.org/

openbsc network-side gsm stack - · pdf filegsm) harald welte openbsc network-side gsm stack....

Documents