Mobile Access Security: Some Thoughts

October 17, 2011

The latest round of the Kiwicon binge-drinking/sheep-buggering-joke-laden/fear-mongering hui is imminent, and once again I find myself refusing to sit in a room full of several hundred people smarter than I am.  Maybe it’s just that I am an unsociable creature, but my psychologist suggests that it is more likely to be due to the fact that I am an egomaniac with an inferiority complex.  Ever wanting to improve both my mental health and my social stature (actually, scratch that – fuck everyone), I’ve decided to get in on the spirit as best I can by jotting down a few notes about Mobile 3G/4G Access in a security context.  I’ve been lucky enough to work in the mobile telecommunications industry for a while, including being paid at times to conduct security assessments of large networks containing many different 3GPP network interfaces and elements.  Here I desperately want to embark on a long tirade about the endless number of snake-oil merchants I’ve run into in this industry, but I’ll just have to cry and bitch and pitch a fit another day.

Snake Oil

A typical sec industry pundit

Anyone with a real interest will have seen and read the numerous analyses of 2G (primarily GSM) weaknesses, including some very sophisticated SIM cloning attacks against COMP128 (anyone want to buy me an electron microscope?), the cracking of A5/1, the OpenBTS project and associated subsequent network impersonation trickery etc., etc.  The ongoing ‘consumerisation’ of GSM hacking utilities and portable interception kits is still an interesting subject given the size of the underlying 2G deployment base, but the discussion has been done to death and has become a ‘less interesting’ topic as a result.

The 3GPP stepped up with the development of the 3G standards, including moving away from proprietary/closed algorithms to those published in the public domain for open scrutiny.  USIM technology as yet remains robust, and the cloning of MILENAGE based end-user secrets has not been proven possible to-date[1].  The development of UMTS introduced AKA, or mutual authentication between the UE and the network, rendering the network impersonation attacks disclosed in the 2G space close to impossible.  There have been inroads made into cryptographical weaknesses of the KASUMI algorithm, but the practicalities of applying these in a real-world threat context are negligible.

While the main focus of most mobile security researchers and BadGuys™ has been applied to theft of service (which makes sense), I’ve spent time over the last few years thinking on and off about what other avenues have not been explored in any particular depth.  My prediction-come-hypothesis, and the real guts of why I bothered to write this post in the first place, is that the shared medium of Mobile Access may be vulnerable to more than just disruption caused by creating a wall of noise across the radio interface.  If we look at other widely deployed shared-medium network access technologies, such as 802.11 Wi-Fi and wired Ethernet, we know there is a long history of pre-authentication security problems that have been widely exploited.  The nature of the majority of these issues has been Denial of Service (network disruption); a weakness that mobile networks can little afford, particularly where they carry traffic such as emergency calls, and where the coverage of the shared medium is far more expansive than your local wireless hot-spot.

I’ll dive in to one example, hopefully without this becoming a novel.  If we pull open the 3GPP TS 25.331 specification, Section 8.1.3, we look at the guts of the Radio Resource Control transaction required by all 3G UE in order to facilitate a network operation such as making a phone call, sending a text message or establishing a data session.  It’s probably also worth noting here that the RRC protocol is an essential part of LTE.  A high-level picture of the sequence required in order to establish a successful RRC connection is shown below:

RRC Connection Request

RRC Connection Request Procedure

This 3-way handshake is analogous to TCP’s SYN, SYN-ACK, ACK combination for connecting ports.  The contents of the RRC Connection Request message include the following mandatory parameters: Message Type, Initial UE Identity, Establishment Cause and Protocol Error Indicator.  The Initial UE Identity is populated as per Section 8.5.1 of 25.331, and is based on either the TMSI, P-TMSI or IMEI of the UE, depending on whichever is available to the handset.  Section of the specification requires the UE to set a running timer (T300) once an RRC Connection Request has been successfully delivered to the underlying MAC layer.  The UE then evaluates a complex set of procedures to determine whether or not to resubmit an RRC connection request once this timer expires.

The RRC Connection Request is delivered over the Common Control Channel (CCCH) which is a shared radio access medium for all mobiles attempting to make use of the network.  Remember that prior to authenticating to the network, your handset needs to acquire the CCCH and establish an RRC connection in order to perform its first Location Update and associated authentication procedures.

Section of TS 25.331 goes on to describe the requisite behaviours for the RNC on reception of such an RRC Connection Request message.  Early drafts of the specification describe a requirement for the RNC to set a timer known as T350 (or T352 in the event of an RRC Connection Re-Establishment Request), which decrements until such time as an RRC Connection Setup Complete message is received from the UE, completing the three-way transaction.  At one stage the default value for this timer was 3000ms, although this was always considered a configurable, implementation-specific parameter.  This timer is analogous to the TCP wait timer set by networking stacks on SYN-ACK reply transmission to an incoming SYN request.  More recent versions of the specification do not make any mention of T350/T352, and as such, one can only assume that the management and release of these RRC connection resources is left to the discretion of the implementor.  Note that 3GPP TS 25.331 also assumes that only a single RRC state machine can exist per UE (analagous to how PPP might be managed by a BRAS for example).

An attacker with the ability to send arbitrary RRC Connection Requests into the mobile network[2] could send a stream of messages, each containing unique “Initial UE Identity” parameters.  The RNC will then allocate internal state and associated resources for each incoming request.  These resources are effectively controlled by the connecting UE in an unsolicited fashion; remembering that no network authentication has been performed at this point.  This scenario is somewhat analogous to a TCP SYN-flood, with the “Initial UE Identity” comparable to a randomized source IPv4 address.  The attacker will never respond to the RRC Connection Request Setup messages returned from the RNC (in part by ignoring T300).

The RNC resources consumed, however, may be of least concern if the goal of the attacker is simply a DoS of the local cell resources.  Okay, you could potentially save yourself time and effort by buying a cheap and nasty UMTS signal blocker (assuming you can get it past customs) and jam the hell out of the RF interface, but as illustrated below, this ‘half-open RRC attack’ triggers the allocation of radio bearers inside the UTRAN.  The consequence being resource exhaustion on the local NodeB, along with the obvious increase in load at the RNC.

3G Call Setup

3G Call Setup Sequence

The effectiveness of this attack will be partly dependent on the attacker’s ability to send sufficient levels of fake RRC Connection Request messages within the T350/T352 (or equivalent) timeframe; however there is still a fundamental issue in that the network must allocate more resources than have been required on the part of the attacker.  The attacker may need multiple UE in order to consume all available network RRC processing queue resources, but this just opens things up to thinking about the distribution of such attacks across discrete NodeB’s, clusters or Location Areas.  Depending on the behaviour of the RRC state machine management inside the network RNC, control of the Iub interface may be required in order for the attacker to simulate a large number of connections (see [2] below).

Similarly, for the CM/MM/GMM protocols atop RRC, exposures are likely.  It may be harder to deliver anything malformed all the way through to the VLR, but attacks in the same vein, where protocol state is intentionally broken by the malicious UE, are bound to exist.  The Initial Direct Transfer procedure for authentication is one example where resources are allocated inside the target network; resources that may only be freed at a rate below that which an attacker can deliver the requests.

Hopefully I’m several years behind the 8-ball and someone has already looked long and hard at some of this stuff.  The 3GPP Security Working Group seems like a fairly smart bunch, and I’m sure they will have discussed this subject.  I know for a fact that there is some mitigation in the software running on particular vendors equipment (agressive T3XX timers, partitioning of RRC context availability pools across limited clusters of NBs, etc.), so it has obviously been given consideration at some point.  If you are a mobile network god, and you know for certain why this suspect deficiency in the RRC protocol doesn’t exist, or why what I am suggesting is impossible, please let me know!  The only real way the TCP gods managed to mitigate this type of issue was by using SYN-cookies.  Perhaps the 3GPP could consider an equivalent for RRC?  Should I quickly try and drop in a patent for RRC-cookies??

RRC Cookies

How I propose the 3GPP implements RRC-Cookies

[1] This is always going to be an arms-race scenario.  As modern electron microscopy technology improves, and with the flourishing nanotechnology industry, it is almost certain that advances will be made in the field of reverse engineering K secrets from modern USIMs.  Someone will discover some new side-channel attacks; it is certainly only a matter of time, and the big question will be whether or not this can be achieved within the lifetime of the target network.  This would be a fascinating area of study.

[2] Obtaining a full baseband UMTS chipset would be a fun way of doing this, although coding the air interface channel allocation feature-set would be a serious undertaking (think GNUradio / OpenBTS scale and beyond).  Better would be to build a device along the lines of the ones demonstrated already in the 2G hacking world – an inline device sitting across the Iub interface, avoiding the MAC/PHY layers, with a basic FP/RLC state machine and the associated higher level stacks that the attacker is looking to target (RRC as an example).  Depending on the underlying transport you may require TDM, ATM or IP/Ethernet interfaces in your kit.  The practicalities of tapping an Iub might be best saved for another post, suffice to say that it probably requires doing something highly illegal.  The more honest approach would be with the baseband chipset – or some very clever stop instruction management of a running phone chipset.  Building this sort of capability would be an investment mainly in time, but once created, would open a world of possibilties.  Think fuzzers.  Think about the fact that a number of the devices in the mobile access path run flavours of embedded Linux.  Keep thinking pre-authentication.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: