summaryrefslogtreecommitdiff
path: root/2009/gsm_fuzzing-0sec2009
diff options
context:
space:
mode:
authorHarald Welte <laforge@gnumonks.org>2015-10-25 21:00:20 +0100
committerHarald Welte <laforge@gnumonks.org>2015-10-25 21:00:20 +0100
commitfca59bea770346cf1c1f9b0e00cb48a61b44a8f3 (patch)
treea2011270df48d3501892ac1a56015c8be57e8a7d /2009/gsm_fuzzing-0sec2009
import of old now defunct presentation slides svn repo
Diffstat (limited to '2009/gsm_fuzzing-0sec2009')
-rw-r--r--2009/gsm_fuzzing-0sec2009/gsm_fuzzing.pdfbin0 -> 259168 bytes
-rw-r--r--2009/gsm_fuzzing-0sec2009/gsm_fuzzing.snm0
-rw-r--r--2009/gsm_fuzzing-0sec2009/gsm_fuzzing.tex568
-rw-r--r--2009/gsm_fuzzing-0sec2009/gsm_fuzzing.tex.bak535
-rw-r--r--2009/gsm_fuzzing-0sec2009/gsm_network.pngbin0 -> 57000 bytes
5 files changed, 1103 insertions, 0 deletions
diff --git a/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.pdf b/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.pdf
new file mode 100644
index 0000000..8c387e4
--- /dev/null
+++ b/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.pdf
Binary files differ
diff --git a/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.snm b/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.snm
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.snm
diff --git a/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.tex b/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.tex
new file mode 100644
index 0000000..e7080dd
--- /dev/null
+++ b/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.tex
@@ -0,0 +1,568 @@
+% $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}
+
+% 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{GSM Protocol Fuzzing}
+
+\subtitle
+{and other GSM related fun}
+
+\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[0sec 2009] % (optional, should be abbreviation of conference name)
+{0sec conference, October 2009, Berne/Switzerland}
+% - 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 specialist, focus on network protocol security
+ \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 Billing
+ \item Network planning / deployment / servicing
+ \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}
+
+\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}{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 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 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 day and night (> 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 September 2008, we were first able to make the BTS active and see it on a phone
+ \begin{itemize}
+ \item This is GSM900 BTS with 2 TRX at 2W output power (each)
+ \item A 48kg monster with attached antenna
+ \item 200W power consumption, passive cooling
+ \item E1 physical interface
+ \end{itemize}
+ \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}
+\end{frame}
+
+\subsection{Timeline}
+
+\begin{frame}{Implementing GSM protocols}{Timeline}
+\begin{itemize}
+ \item In November 2008, I started the development of OpenBSC
+ \item In December 2008, we did a first demo at 25C3
+ \item In January 2009, we had full voice call support
+ \item In June 2009, I started with actual security related stuff
+ \item In August 2009, we had the first field test with 2BTS and > 860 phones
+\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}
+
+\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{The Baseband}
+
+\begin{frame}{Known GSM security problems}{The Baseband side}
+\begin{itemize}
+ \item GSM protocol stack always runs in a so-called baseband processor (BP)
+ \item What is the baseband processor
+ \begin{itemize}
+ \item Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5G phones)
+ \begin{itemize}
+ \item Runs some RTOS (often Nucleus, sometimes L4)
+ \item No memory protection between tasks
+ \end{itemize}
+ \item Some kind of DSP, model depends on vendor
+ \begin{itemize}
+ \item Runs the digital signal processing for the RF Layer 1
+ \item Has hardware peripherals for A5 encryption
+ \end{itemize}
+ \end{itemize}
+ \item The software stack on the baseband processor
+ \begin{itemize}
+ \item is written in C and assembly
+ \item lacks any modern security features (stack protection, non-executable pages, address space randomization, ..)
+ \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 hardcoded special case for each of them
+ \item Solution: Use scapy and implement the GSM protocols as scapy "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}
+
+\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}
+ \item There is ongoing work for a phone-based tool to fuzz the network
+\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}{Future plans}
+\begin{itemize}
+ \item Packet data (GPRS/EDGE) support in OpenBSC
+ \begin{itemize}
+ \item GPRS is used extensively on modern smartphones
+ \item Enables us to play with those phones without a heavily filtered operator network
+ \end{itemize}
+ \item UMTS(3G) support in OpenBSC
+ \item Access to MS side layer 1
+ \item Playing with SIM Toolkit from the operator side
+ \item Playing with MMS
+ \item More exploration of RRLP
+\end{itemize}
+\end{frame}
+
+\subsection{Further Reading}
+
+\begin{frame}{Further Reading}
+\begin{itemize}
+ \item http://openbsc.gnumonks.org/
+ \item http://airprobe.org/
+ \item http://openbts.sourceforge.net/
+\end{itemize}
+\end{frame}
+
+\end{document}
diff --git a/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.tex.bak b/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.tex.bak
new file mode 100644
index 0000000..b9397a1
--- /dev/null
+++ b/2009/gsm_fuzzing-0sec2009/gsm_fuzzing.tex.bak
@@ -0,0 +1,535 @@
+% $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}
+
+% 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{GSM Protocol Fuzzing}
+
+\subtitle
+{and other GSM related fun}
+
+\author{Harald Welte}
+
+\institute
+{gnumnks.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[0sec 2009] % (optional, should be abbreviation of conference name)
+{0sec conference, Bern, October 2009}
+% - 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 Secirity}
+% 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 specialist, focus on network protocol security
+ \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 scrutiniy
+ \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 Sicne 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 Billing
+ \item Network planning / deployment / servicing
+ \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}
+
+\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 Oor 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}{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 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 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 day and night (> 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 September 2008, we were first able to make the BTS active and see it on a phone
+ \begin{itemize}
+ \item This is GSM900 BTS with 2 TRX at 2W output power (each)
+ \item A 48kg monster with attached antenna
+ \item 200W power consumption, passive cooling
+ \item E1 physical interface
+ \end{itemize}
+ \item I didn't have much time at the time (dayjob 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}
+\end{frame}
+
+\subsection{Timeline}
+
+\begin{frame}{Implementing GSM protocols}{Timeline}
+\begin{itemize}
+ \item In November 2008, I started the development of OpenBSC
+ \item In December 2008, we did a first demo at 25C3
+ \item In January 2009, we had full voice call support
+ \item In June 2009, I started with actual security related stuff
+ \item In August 2009, we had the first field test with 2BTS and > 860 phones
+\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 minmal 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}
+
+\section{Securty 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 algorithsm
+ \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{The Baseband}
+
+\begin{frame}{Known GSM security problems}{The Baseband side}
+\begin{itemize}
+ \item GSM protocol stack always runs in a so-called baseband processor (BP)
+ \item What is the baseband processor
+ \begin{itemize}
+ \item Typically ARM7 (2G/2.5G phones) or ARM9 (3G/3.5G phones)
+ \begin{itemize}
+ \item Runs some RTOS (often Nucleus, sometimes L4)
+ \item No memory protection between tasks
+ \end{itemize}
+ \item Some kind of DSP, model depends on vendor
+ \begin{itemize}
+ \item Runs the digital signal processing for the RF Layer 1
+ \item Has hardware peripherals for A5 encryption
+ \end{itemize}
+ \end{itemize}
+ \item The software stack on the baseband processor
+ \begin{itemize}
+ \item is written in C and assembly
+ \item lacks any modern security features (stack protection, non-executable pages, address space randomisation, ..)
+ \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 closedness 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 hardcoded special case for each of them
+ \item Solution: Use scapy and implement the GSM protocols as scapy "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}
+
+\section{Summary}
+
+\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}
+ \item There is ongoing work for a phone-based tool to fuzz the network
+\end{itemize}
+\end{frame}
+
+\begin{frame}{Further Reading}
+\begin{itemize}
+ \item http://openbsc.gnumonks.org/
+ \item http://airprobe.org/
+ \item http://openbts.sourceforge.net/
+\end{itemize}
+\end{frame}
+
+\end{document}
diff --git a/2009/gsm_fuzzing-0sec2009/gsm_network.png b/2009/gsm_fuzzing-0sec2009/gsm_network.png
new file mode 100644
index 0000000..c5f6399
--- /dev/null
+++ b/2009/gsm_fuzzing-0sec2009/gsm_network.png
Binary files differ
personal git repositories of Harald Welte. Your mileage may vary