diff options
Diffstat (limited to '2010/openbsc-sstic2010')
| -rw-r--r-- | 2010/openbsc-sstic2010/gsm_network.png | bin | 0 -> 57000 bytes | |||
| -rw-r--r-- | 2010/openbsc-sstic2010/openbsc-abstract.txt | 23 | ||||
| -rw-r--r-- | 2010/openbsc-sstic2010/openbsc.pdf | bin | 0 -> 359600 bytes | |||
| -rw-r--r-- | 2010/openbsc-sstic2010/openbsc.snm | 0 | ||||
| -rw-r--r-- | 2010/openbsc-sstic2010/openbsc.tex | 638 |
5 files changed, 661 insertions, 0 deletions
diff --git a/2010/openbsc-sstic2010/gsm_network.png b/2010/openbsc-sstic2010/gsm_network.png Binary files differnew file mode 100644 index 0000000..c5f6399 --- /dev/null +++ b/2010/openbsc-sstic2010/gsm_network.png diff --git a/2010/openbsc-sstic2010/openbsc-abstract.txt b/2010/openbsc-sstic2010/openbsc-abstract.txt new file mode 100644 index 0000000..7ff5a28 --- /dev/null +++ b/2010/openbsc-sstic2010/openbsc-abstract.txt @@ -0,0 +1,23 @@ +OpenBSC: A tool for GSM protocol level security analysis of mobile phones + +By: Harald Welte[1] + +The OpenBSC project[2] is a Free Software implementation of the minimal +neccessarry elements to operate a GSM network. It includes the functionality +typically performed by the Base Station Controller (BSC), Mobile Switching +Center (MSC), Home Location Register (HLR), SMS Switching Center (SMSC) and +others. Using OpenBSC and a commercially available BTS (Base Transceiver +Station), it is possible to operate a completely indpendent GSM network. + +Running your own GSM network will enable you to take full control over +every protocol message that is exchanged with the mobile phone. Suddenly, +it is possible to send arbitrarily crafted and corrupted messages to the +various layers of the GSM protocol stack inside the phone. Attacks can +be performed that so far only cellphone manufacturers or network operators +could implement. + +In 2010, it is finally time for GSM mobile phones to see the kind of +protocol-level attacks that TCP/IP has seen at least a decade ago. + +[1] http://laforge.gnumonks.org/ +[2] http://openbsc.gnumonks.org/ diff --git a/2010/openbsc-sstic2010/openbsc.pdf b/2010/openbsc-sstic2010/openbsc.pdf Binary files differnew file mode 100644 index 0000000..d959319 --- /dev/null +++ b/2010/openbsc-sstic2010/openbsc.pdf diff --git a/2010/openbsc-sstic2010/openbsc.snm b/2010/openbsc-sstic2010/openbsc.snm new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/2010/openbsc-sstic2010/openbsc.snm diff --git a/2010/openbsc-sstic2010/openbsc.tex b/2010/openbsc-sstic2010/openbsc.tex new file mode 100644 index 0000000..fe41e1c --- /dev/null +++ b/2010/openbsc-sstic2010/openbsc.tex @@ -0,0 +1,638 @@ +% $Header: /cvsroot/latex-beamer/latex-beamer/solutions/conference-talks/conference-ornate-20min.en.tex,v 1.7 2007/01/28 20:48:23 tantau Exp $ + +\documentclass{beamer} + +\usepackage{url} +\makeatletter +\def\url@leostyle{% + \@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}} +\makeatother +%% Now actually use the newly defined style. +\urlstyle{leo} + + +% This file is a solution template for: + +% - Talk at a conference/colloquium. +% - Talk length is about 20min. +% - Style is ornate. + + + +% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>. +% +% In principle, this file can be redistributed and/or modified under +% the terms of the GNU Public License, version 2. +% +% However, this file is supposed to be a template to be modified +% for your own needs. For this reason, if you use this file as a +% template and not specifically distribute it as part of a another +% package/program, I grant the extra permission to freely copy and +% modify this file as you see fit and even to delete this copyright +% notice. + + +\mode<presentation> +{ + \usetheme{Warsaw} + % or ... + + \setbeamercovered{transparent} + % or whatever (possibly just delete it) +} + + +\usepackage[english]{babel} +% or whatever + +\usepackage[latin1]{inputenc} +% or whatever + +\usepackage{times} +\usepackage[T1]{fontenc} +% Or whatever. Note that the encoding and the font should match. If T1 +% does not look nice, try deleting the line with the fontenc. + + +\title{OpenBSC network-side GSM stack} + +\subtitle +{A tool for GSM protocol level security analysis} + +\author{Harald Welte} + +\institute +{gnumonks.org\\gpl-violations.org\\OpenBSC\\airprobe.org\\hmw-consulting.de} +% - Use the \inst command only if there are several affiliations. +% - Keep it simple, no one is interested in your street address. + +\date[SSTIC 2010] % (optional, should be abbreviation of conference name) +{SSTIC 2010, June 2010, Rennes/France} +% - Either use conference name or its abbreviation. +% - Not really informative to the audience, more for people (including +% yourself) who are reading the slides online + +\subject{GSM Security} +% This is only inserted into the PDF information catalog. Can be left +% out. + + + +% If you have a file called "university-logo-filename.xxx", where xxx +% is a graphic format that can be processed by latex or pdflatex, +% resp., then you can add a logo as follows: + +% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename} +% \logo{\pgfuseimage{university-logo}} + + + +% Delete this, if you do not want the table of contents to pop up at +% the beginning of each subsection: +%\AtBeginSubsection[] +%{ +% \begin{frame}<beamer>{Outline} +% \tableofcontents[currentsection,currentsubsection] +% \end{frame} +%} + + +% If you wish to uncover everything in a step-wise fashion, uncomment +% the following command: + +%\beamerdefaultoverlayspecification{<+->} + + +\begin{document} + +\begin{frame} + \titlepage +\end{frame} + +\begin{frame}{Outline} + \tableofcontents + % You might wish to add the option [pausesections] +\end{frame} + + +% Structuring a talk is a difficult task and the following structure +% may not be suitable. Here are some rules that apply for this +% solution: + +% - Exactly two or three sections (other than the summary). +% - At *most* three subsections per section. +% - Talk about 30s to 2min per frame. So there should be between about +% 15 and 30 frames, all told. + +% - A conference audience is likely to know very little of what you +% are going to talk about. So *simplify*! +% - In a 20min talk, getting the main ideas across is hard +% enough. Leave out details, even if it means being less precise than +% you think necessary. +% - If you omit details that are vital to the proof/implementation, +% just say so once. Everybody will be happy with that. + +\begin{frame}{About the speaker} +\begin{itemize} + \item Using + playing with Linux since 1994 + \item Kernel / bootloader / driver / firmware development since 1999 + \item IT security expert, focus on network protocol security + \item Core developer of Linux packet filter netfilter/iptables + \item Board-level Electrical Engineering + \item Always looking for interesting protocols (RFID, DECT, GSM) +\end{itemize} +\end{frame} + +\section{GSM/3G security} + +\begin{frame}{GSM/3G protocol security} +\begin{itemize} + \item Observation + \begin{itemize} + \item Both GSM/3G and TCP/IP protocol specs are publicly available + \item The Internet protocol stack (Ethernet/Wifi/TCP/IP) receives lots of scrutiny + \item GSM networks are as widely deployed as the Internet + \item Yet, GSM/3G protocols receive no such scrutiny! + \end{itemize} + \item There are reasons for that: + \begin{itemize} + \item GSM industry is extremely closed (and closed-minded) + \item Only about 4 closed-source protocol stack implementations + \item GSM chipset makers never release any hardware documentation + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{The closed GSM industry} + +\begin{frame}{The closed GSM industry}{Handset manufacturing side} +\begin{itemize} + \item Only very few companies build GSM/3.5G baseband chips today + \begin{itemize} + \item Those companies buy the operating system kernel and the protocol stack from third parties + \end{itemize} + \item Only very few handset makers are large enough to become a customer + \begin{itemize} + \item Even they only get limited access to hardware documentation + \item Even they never really get access to the firmware source + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The closed GSM industry}{Network manufacturing side} +\begin{itemize} + \item Only very few companies build GSM network equipment + \begin{itemize} + \item Basically only Ericsson, Nokia-Siemens, Alcatel-Lucent and Huawei + \item Exception: Small equipment manufacturers for picocell / nanocell / femtocells / measurement devices and law enforcement equipment + \end{itemize} + \item Only operators buy equipment from them + \item Since the quantities are low, the prices are extremely high + \begin{itemize} + \item e.g. for a BTS, easily 10-40k EUR + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The closed GSM industry}{Operator side} +\begin{itemize} + \item Operators are mainly banks today + \item Typical operator outsources + \begin{itemize} + \item Network planning / deployment / servicing + \item Even Billing! + \end{itemize} + \item Operator just knows the closed equipment as shipped by manufacturer + \item Very few people at an operator have knowledge of the protocol beyond what's needed for operations and maintenance +\end{itemize} +\end{frame} + +\begin{frame}{GSM is more than phone calls} +Listening to phone calls is boring... +\begin{itemize} + \item Machine-to-Machine (M2M) communication + \begin{itemize} + \item BMW can unlock/open your car via GSM + \item Alarm systems often report via GSM + \item Smart Metering (Utility companies) + \item GSM-R / European Train Control System + \item Vending machines report that their cash box is full + \item Control if wind-mills supply power into the grid + \item Transaction numbers for electronic banking + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Security implications} + +\begin{frame}{The closed GSM industry}{Security implications} +The security implications of the closed GSM industry are: +\begin{itemize} + \item Almost no people who have detailed technical knowledge outside the protocol stack or GSM network equipment manufacturers + \item No independent research on protocol-level security + \begin{itemize} + \item If there's security research at all, then only theoretical (like the A5/2 and A5/1 cryptanalysis) + \item Or on application level (e.g. mobile malware) + \end{itemize} + \item No open source protocol implementations + \begin{itemize} + \item which are key for making more people learn about the protocols + \item which enable quick prototyping/testing by modifying existing code + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The closed GSM industry}{My self-proclaimed mission} +Mission: Bring TCP/IP/Internet security knowledge to GSM +\begin{itemize} + \item Create tools to enable independent/public IT Security community to examine GSM + \item Try to close the estimated 10 year gap between the state of security technology on the Internet vs. GSM networks + \begin{itemize} + \item Industry thinks in terms of {\em walled garden} and {\em phones behaving like specified} + \item No proper incident response strategies! + \item No packet filters, firewalls, intrusion detection on GSM protocol level + \item General public assumes GSM networks are safer than Internet + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{The closed GSM industry}{Areas of interest for Security research} +\begin{itemize} + \item Specification problems + \begin{itemize} + \item Encryption optional, weak and only on the Um interface + \item Lack of mutual authentication + \item Silent calls for pin-pointing a phone + \item RRLP and SUPL to obtain GPS coordinates of phone + \end{itemize} + \item Implementation problems + \begin{itemize} + \item TMSI information leak on network change + \item TLV parsers that have never seen invalid packets + \item Obscure options in spec lead to rarely-tested/used code paths + \end{itemize} + \item Operation problems + \begin{itemize} + \item VLR overflow leading to paging-by-IMSI + \item TMSI re-allocation too infrequent + \item Networks/Cells without frequency hopping + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Security analysis of GSM}{How would you get started?} +If you were to start with GSM protocol level security analysis, where and +how would you start? +\begin{itemize} + \item On the handset side? + \begin{itemize} + \item Difficult since GSM firmware and protocol stacks are closed and proprietary + \item Even if you want to write your own protocol stack, the layer 1 hardware and signal processing is closed and undocumented, too + \item Publicly known attempts + \begin{itemize} + \item The TSM30 project as part of the THC GSM project + \item mados, an alternative OS for Nokia DTC3 phones + \end{itemize} + \item none of those projects successful so far + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Security analysis of GSM}{How would you get started?} +If you were to start with GSM protocol level security analysis, where and +how would you start? +\begin{itemize} + \item On the network side? + \begin{itemize} + \item Difficult since equipment is not easily available and normally extremely expensive + \item However, network is very modular and has many standardized/documented interfaces + \item Thus, if BTS equipment is available, much easier/faster progress + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Security analysis of GSM}{The bootstrapping process} +\begin{itemize} + \item Read GSM specs (> 1000 PDF documents) ;) + \item Gradually grow knowledge about the protocols + \item Obtain actual GSM network equipment (BTS) + \item Try to get actual protocol traces as examples + \item Start a complete protocol stack implementation from scratch + \item Finally, go and play with GSM protocol security +\end{itemize} +\end{frame} + + +\subsection{The GSM network} + +\begin{frame}{The GSM network} + \begin{figure}[h] + \centering + \includegraphics[width=100mm]{gsm_network.png} + \end{figure} +\end{frame} + +\begin{frame}{GSM network components} + \begin{itemize} + \item The BSS (Base Station Subsystem) + \begin{itemize} + \item MS (Mobile Station): Your phone + \item BTS (Base Transceiver Station): The {\em cell tower} + \item BSC (Base Station Controller): Controlling up to hundreds of BTS + \end{itemize} + \item The NSS (Network Sub System) + \begin{itemize} + \item MSC (Mobile Switching Center): The central switch + \item HLR (Home Location Register): Database of subscribers + \item AUC (Authentication Center): Database of authentication keys + \item VLR (Visitor Location Register): For roaming users + \item EIR (Equipment Identity Register): To block stolen phones + \end{itemize} + \end{itemize} +\end{frame} + +\begin{frame}{GSM network interfaces} + \begin{itemize} + \item Um: Interface between MS and BTS + \begin{itemize} + \item the only interface that is specified over radio + \end{itemize} + \item A-bis: Interface between BTS and BSC + \item A: Interface between BSC and MSC + \item B: Interface between MSC and other MSC + \end{itemize} + GSM networks are a prime example of an asymmetric distributed network, + very different from the end-to-end transparent IP network. +\end{frame} + + +\subsection{The GSM protocols} + +\begin{frame}{GSM network protocols}{On the Um interface} + \begin{itemize} + \item Layer 1: Radio Layer, TS 04.04 + \item Layer 2: LAPDm, TS 04.06 + \item Layer 3: Radio Resource, Mobility Management, Call Control: TS 04.08 + \item Layer 4+: for USSD, SMS, LCS, ... + \end{itemize} +\end{frame} + +\begin{frame}{GSM network protocols}{On the A-bis interface} + \begin{itemize} + \item Layer 1: Typically E1 line, TS 08.54 + \item Layer 2: A variant of ISDN LAPD with fixed TEI's, TS 08.56 + \item Layer 3: OML (Organization and Maintenance Layer, TS 12.21) + \item Layer 3: RSL (Radio Signalling Link, TS 08.58) + \item Layer 4+: transparent messages that are sent to the MS via Um + \end{itemize} +\end{frame} + + +\section{Implementing GSM protocols} + +\subsection{Getting started} + +\begin{frame}{Implementing GSM protocols}{How I got started!} +\begin{itemize} + \item In 2006 I bought an old BTS (Siemens BS-11) on eBay + \begin{itemize} + \item This is 48kg GSM900 BTS with 2 TRX at 2W output power (each) + \item I didn't have much time at the time (day job at Openmoko) + \item Started to read up on GSM specs whenever I could + \item Bought a HFC-E1 based PCI E1 controller, has mISDN kernel support + \item Found somebody in the GSM industry who provided protocol traces + \end{itemize} + \item In September 2008, we were first able to make the BTS active and see it on a phone +\end{itemize} +\end{frame} + +\subsection{Timeline} + +\begin{frame}{Implementing GSM protocols}{Timeline} +\begin{itemize} + \item November 2008: I started the development of OpenBSC + \item December 2008: we did a first demo at 25C3 + \item January 2009: we had full voice call support + \item Q1/2009: Add support for ip.access nanoBTS + \item June 2009: I started with actual security related stuff + \item August 2009: We had the first field test with 2BTS and > 860 phones + \item Q1/2010: The first 25 OpenBSC instances running in a commercial network +\end{itemize} +\end{frame} + +\subsection{OpenBSC} + +\begin{frame}{Security analysis of GSM}{OpenBSC} +What is OpenBSC +\begin{itemize} + \item A {\em GSM network in a box} software + \item Implements minimal subset of BSC, MSC, HLR, SMSC + \item Is Free and Open Source Software licensed under GNU GPL + \item Supports Siemens BS-11 BTS (E1) and ip.access nanoBTS (IP based) + \item Has classic 2G signalling, voice and SMS support + \item Implements various GSM protocols like + \begin{itemize} + \item A-bis RSL (TS 08.58) and OML (TS 12.21) + \item TS 04.08 Radio Resource, Mobility Management, Call Control + \item TS 04.11 Short Message Service + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{Security analysis of GSM}{OpenBSC} +OpenBSC features +\begin{itemize} + \item Run a small GSM network with 1-n BTS and OpenBSC + \item No need for MSC/HLR/AUC/... + \item No need for your own SIM cards + \item Establish signalling channels + \item Make incoming and outgoing voice calls between phones + \item Send/receive SMS between phones + \item Connect to ISDN PBX or public ISDN via Linux Call Router + \item Telnet console with Cisco-style interface +\end{itemize} +\end{frame} + +\section{Security analysis} + +\subsection{Theory} + +\begin{frame}{Known GSM security problems}{Scientific papers, etc} +\begin{itemize} + \item No mutual authentication between phone and network + \begin{itemize} + \item leads to rogue network attacks + \item leads to man-in-the-middle attacks + \item is what enables IMSI-catchers + \end{itemize} + \item Weak encryption algorithms + \item Encryption is optional, user does never know when it's active or not + \item DoS of the RACH by means of channel request flooding + \item RRLP (Radio Resource Location Protocol) + \begin{itemize} + \item the network can obtain GPS fix or even raw GSM data from the phone + \item combine that with the network not needing to authenticate itself + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Observations} + +\begin{frame}{Interesting observations}{Learned from implementing the stack} +While developing OpenBSC, we observed a number of interesting +\begin{itemize} + \item Many phones use their TMSI from the old network when they roam to a new network + \item Various phones crash when confronted with incorrect messages. We didn't even start to intentionally send incorrect messages (!) + \item There are tons of obscure options on the GSM spec which no real network uses. Potential attack vector by using rarely tested code paths. +\end{itemize} +\end{frame} + +\subsection{GSM Protocol Fuzzing} + +\begin{frame}{GSM Protocol Fuzzing}{Theoretical basis} +How to do GSM protocol fuzzing +\begin{itemize} + \item From the handset to the network + \begin{itemize} + \item Basically impossible due to closeness of baseband + \item However, some incomplete projects working on it + \end{itemize} + \item From the network side + \begin{itemize} + \item Easy in case of {\em rogue network} attacks + \item Fuzzing target is the GSM stack in the baseband processor + \end{itemize} + \item As an A-bis man in the middle + \begin{itemize} + \item Needs access to an A-bis interface of an actual network + \item Very attractive, since no encryption and ability to fuzz both network and handset + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{A-bis injection}{for A-bis over IP} +How to do inject messages into A-bis over IP? +\begin{itemize} + \item Problem + \begin{itemize} + \item A-bis/IP uses one TCP connection for OML and RSL messages + \item OML initialization is essential for BTS to become operational + \item TCP makes insertion of additional messages relatively hard + \end{itemize} + \item Solution: Build an {\em A-bis injection proxy} + \begin{itemize} + \item Transparently pass OML and RSL packets between BTS and BSC + \item Add additional stateless UDP sockets for injecting messages, one socket each for + \end{itemize} + \begin{itemize} + \item injecting OML/RSL to the network + \item injecting OML/RSL to the BTS + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{A-bis Injection Proxy}{Principle of operation} +\begin{itemize} + \item Proxy needs to be brought between BTS and BSC + \item Luckily, A-bis/IP SSL support not always used + \item Thus, physical access to the Ethernet link sufficient + \item Configure system with two interfaces + \begin{itemize} + \item BSC-facing interface has IP of BTS + \item BTS-facing interface has IP of BSC / default gw + \end{itemize} + \item BTS will make TCP connection to proxy + \item proxy will make independent TCP connection to BSC +\end{itemize} +\end{frame} + +\begin{frame}{scapy GSM support}{The actual fuzzing} +How to actually craft the packets for the fuzzing +\begin{itemize} + \item GSM has many, many protocols + \item Writing custom code will be a hard-coded special case for each of them + \item Solution: Use scapy and implement the GSM protocols as scapy {\em Layers} + \begin{itemize} + \item IPA protocol header + \item RSL protocol layer + \item RLL data indication / data request + \item GSM 04.08 RR / MM / CC messages + \end{itemize} +\end{itemize} +\end{frame} + +\begin{frame}{OpenBSC silent calls}{A more elegant fuzzing interface} +\begin{itemize} + \item Injection at the A-bis level has many problems + \begin{itemize} + \item you can only do it while a call is active + \item you simply piggy-back on existing RR connections + \end{itemize} + \item The OpenBSC {\em silent call} feature can help + \begin{itemize} + \item we use OpenBSC to establish a RR connection + \item in the GSM master/slave model, the phone will not close a connection unless told to do so + \item we then send arbitrary data to the phone and receive its responses + \item this currently only works from within OpenBSC, but we'll provide UDP injection sockets soon + \end{itemize} +\end{itemize} +\end{frame} + +\section{Summary} + +\subsection{What we've learned} + +\begin{frame}{Summary}{What we've learned} +\begin{itemize} + \item The GSM industry is making security analysis very difficult + \item It is well-known that the security level of the GSM stacks is very low + \item We now have multiple solutions for sending arbitrary protocol data + \begin{itemize} + \item From a rogue network to phones (OpenBSC, OpenBTS) + \item From an A-bis proxy to the network or the phones + \end{itemize} +\end{itemize} +\end{frame} + +\subsection{Where we go from here} + +\begin{frame}{TODO}{Where we go from here} +\begin{itemize} + \item The tools for fuzzing mobile phone protocol stacks are available + \item It is up to the security community to make use of those tools (!) + \item Don't you too think that TCP/IP security is boring? + \item Join the GSM protocol security research projects + \item Boldly go where no man has gone before +\end{itemize} +\end{frame} + +\subsection{Where we go from here} + +\begin{frame}{Current Areas of Work / Future plans} +\begin{itemize} + \item OsmoSGSN/OpenGGSN: Packet data (GPRS/EDGE) support + \begin{itemize} + \item GPRS/EDGE is used extensively on modern smartphones + \item Enables us to play on IP level with those phones without a heavily filtered operator network + \item Status: Already functional, but very fragile/incomplete. 1-2 more months + \end{itemize} + \item UMTS(3G) support in OpenBSC + \item Playing with SIM Toolkit from the operator side + \item Playing with MMS + \item More exploration of RRLP + SUPL +\end{itemize} +\end{frame} + +\subsection{Further Reading} + +\begin{frame}{Further Reading} +\begin{itemize} + \item \url{http://laforge.gnumonks.org/papers/gsm_phone-anatomy-latest.pdf} + \item \url{http://bb.osmocom.org/} + \item \url{http://openbsc.gnumonks.org/} + \item \url{http://openbts.sourceforge.net/} + \item \url{http://airprobe.org/} +\end{itemize} +\end{frame} + +\end{document} |
