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.


September 19, 2011

So after nearly two whole decades of on-again/off-again blundering my way towards Yet Another Stupid Death, I finally capitulated and begun to read some NetHack spoilers.  The difference between “figuring things out on your own” and having a comprehensive guide to follow is phenomenal.  I can’t help but think about all of the cumulative hours I’ve spent (wasted?) trying to figure out a workable strategy for long-term survival in those cavernous depths; and can’t help but feel awe for those that have managed to ascend without the use of such inside information.  Several times I’ve considered reading the source-code (well, I did read a small piece of it after finding an easy-as-you-like stack based buffer overflow in the command line arguments about a year before someone else discovered and disclosed the same bug[1]), and I always knew I could be playing “smarter” by writing down the various hints and rumours that the game provides, but I guess I was always too lazy.  That laziness held me in a spiral of playing intently for a week or two, invariably dying repeatedly before ever really reaching the true ‘mid-game’, becoming disillusioned, and then casting the entire game aside only to pick it up again 6 months later.

For most people who end up reading this, the sad part will be that I have bothered playing this game so much, bothered writing this post, or pretty much bothered existing in the first place – but for the true NetHack gods, the sad part will be that I am so obviously crap at it.  Not only did I not manage to progress beyond the mid-game in almost 20 years of fumbling around in the darkness, but I didn’t even grasp some of the fundamental basics.  Unbelievably, I’d never even made use of Elbereth (although I do claim that until very recently no pre-compiled versions I had ever played with had the option included), and I never got my head around sourcing a unicorn horn well in advance of eating things willy-nilly.  One definition of insanity is “repeating the same behaviour and expecting a different result”, and in the context of my nearly 20 years of periodic NetHack’ing I can well and truly lay claim to a spot in the gamers loony-bin.

‘Frodo halted for a moment, looking back. Elrond was in his chair and the fire was on his face like summer-light upon the trees. Near him sat the Lady Arwen. […]  He stood still enchanted, while the sweet syllables of the elvish song fell like clear jewels of blended word and melody.  “It is a song to Elbereth,” said Bilbo. “They will sing that, and other songs of the Blessed Realm,  many times tonight.  Come on!”‘

But not anymore!  Now armed to the teeth by virtue of online playing guides, I have become…. no, not ascendent (not yet anyway)… but instead hopelessly, hopelessly addicted.  Hooked like I’ve taken one too many chuffs on the old crack pipe.  Wired like I’m main-lining, leaving me playing 8+ hours a day on the weekend, late through the evening on week nights, and jonesing through what has become mostly sleeplessness as I alchemise potions and attempt to complete Sokoban from my pillow.  The truth is, this game is the real pinnacle of computer gaming.  It is the funniest, most random, hardest and most satisfying game I have ever played.  It is the true epic, and yet it runs in all of only 256 colours and I can play it on my phone.  It has been compiled across pretty much every platform ever made (still waiting for a PS3 version though!), and it can be played through a number of different user interfaces (although not using a full keyboard with a dedicated keypad is mildly aggravating).

Any game where you can go from striding along confidently in your blessed +3 orcish ringmail to being polymorphed in an instant into a Brown Pudding incapable of wearing armour or holding anything at all just lends itself to hilarity, despair and general entertainment.  I still feel the pang of guilt when I let my kitten die after thrusting it between myself and the oncoming horde.  I still love the fact that once I have the permanent invisibility intrinsic (having eaten the corpse of an Invisible Stalker), that shopkeepers won’t let me into their stores (“Invisible guests are not welcome!”) until I don a mummy wrapping around myself.  I continue to be amazed by gems like the one I picked up today: find a scroll of destroy armour, curse it by dipping it into unholy water, read a cursed scroll of confuse monster to become confused, read the cursed scroll of destroy armour while confused and…. one of your pieces of armour is granted an inherent resistance bonus!


The observent amongst you will recognise that this is in fact a screenshot from unNetHack, not the original 'vanilla' NetHack.

I’m left feeling like a using drug addict who can reel off a list of one hundred ways in which his or her drug of choice has been proven to be beneficial in some way.  In that blind state of denial that can only be brought about by the obsequiousness of being wilfully chained to your master.  I’m still in the happy phase where the highs are high and the lows really aren’t that low.  I haven’t quit my job to play NetHack full-time, and I haven’t started sucking dick just to get that Amulet of Life Saving.  My biggest fear now is that the spoilers turn out to be just that – that things could become too easy – and that it would have been better to spend the next 20 years continuing to chip away at the survival skills that are so desperately essential to staying alive in that dungeon.  Thankfully this is not yet the case: tonight my Level 14 Woman-at-Arms only narrowly survived a skirmish with a Disenchanter, where she had to unequip all of her magic items and struggle through the furious resultant melee.  I’m 24,130 turns into the game and feeling like i want it to last another 24,000,000.

Latest messages
It hits!
It kicks!
It hits!
It kicks!
It hits!
It kicks!
It hits!
It kicks!
It hits!
It kicks!
It hits!
You die…

‘…. fonetikli was killed on level 9 by a b0f!’

[1] In a former life I was momentarily involved in a not-so-underground hacking community that boasted a remotely accessible “test lab” of several different platforms and operating systems.  The lab was to be used for the sole purpose of exploit research and development, and while not entirely useless, was less interesting for me due to the number of discrete UNIX platforms I already had access to play with at work.  At some point inbetween all of the posturing, penis-length comparison and for the most part shit-talking, someone noticed that not only was NetHack installed on the sparc Solaris 9 core Bastion – but that for some reason it was installed setuid root.  Anyone who managed to 0wn the box via the nethack binary was to become a god among men among small-time hackers in a small-time test network.  I set to work with an entirely unscientific hit-and-miss approach of perl driven CLI buffer overflow and format string attempts, and was genuinely surprised when the binary crashed.  Not wanting anyone else to see what I’d found, I retreated to another sparc platform I had access to at work, plaguerised and modified some handy sparc shell code, bashed my head against the keyboard for about a day and a half while i tried to stop making mistakes with endianness and byte-alignment (I was writing exploits in an x86 environment at the same time and not context-switching well), before finally coming out with something that worked.  Thinking myself much funnier than I actually am, AND of course being an avid fan of the game itself – as the stack overflow exploit ran it printed:  “…. fonetikli was killed on level 9 by a b0f!” before dropping the user out into a root shell.  Not one fucking person in that circle seemed impressed, and the only other people in my life I have ever tried to repeat this story to just look at me like I am the most pitiful creature to have ever dragged its carcass across the face of the planet.  *Sigh*