Figure 2-1 Simplified GSM/CDMA mobile network
The cellular network underpins all of the major functionality of what we consider a smartphone. There does seem to be some confusion, however, about how magical this integral part of the cellular ecosystem actually is. Most folks, when asked how a cell phone works, would answer “It just does!” Although this might satisfy most people, it’s not a particularly satisfying answer for a security professional. Fortunately, understanding the basics of the cellular network doesn’t take complex calculus or a lifetime of experience in radio networks. We’re going to begin this chapter by introducing and then dissecting a standard Global System for Mobile (GSM) or Code Division Multiple Access (CDMA) carrier network, so you more fully understand the behind-the-scenes work that goes on when you make a phone call, upload a picture, or send a text message.
For most of the discussion in this chapter, we’ll use a semi-abstracted cellular carrier topology that gives what we like to call “end-to-end” functionality; that is, a hypothetical cell phone on our hypothetical network sends and receives phone calls, sends and receives text messages and MMS messages, and has data connectivity via IP. This topology is shown in Figure 2-1.
Figure 2-1 Simplified GSM/CDMA mobile network
The topology itself is actually quite simple—a cellular handset, a radio tower, some services, and, ultimately, the public switched telephone network (PSTN) and the public Internet. As we move into the next section, we’ll add detail to this diagram and explain how some of the most popular mobile network services can be attacked and defended.
After we pull apart the circuit switched networks, we’ll describe some of the most prominent attacks that have been developed over the years against the current technology, as well as the countermeasures to defend against those attacks.
Finally, we’ll move on to some interesting developments in the world of “Everything over IP.” Within the next few years, some larger mobile network operators will be moving toward a unified bearer network that will run—you’ve got it—exclusively over IP. This will mean a great deal of change—service-oriented plans, traffic quality of service levels (and the associated billing, we reckon!), and, potentially, the release of third-party applications into the “core” of the new mobile device networks. All this will happen pretty slowly, so don’t get your hopes up too soon, but we wanted to show you the commercial cutting edge as soon as possible.
Just about every citizen in the world has at least some access to a radio network. Plenty of cellular carriers are willing to run fiber or copper up a mast to provide monetized cellular service, whether in Kuala Lumpur, Karachi, Atlanta, or King George Island off the coast of Antarctica. In fact, it’s estimated1 that more than 80 percent of the terrestrial world is covered by some type of consumer cellular communication network, with 3.2 billion subscribers (about 50 percent of the world’s population!). This means that two out of every four humans on the planet have the ability to talk to … well, another of the two out of every four humans anywhere else on the planet.
Coverage of this sort requires organization, cooperation, and money. From a security point of view, our first job is to understand how something works. Once we know that, we can start to take it apart, attack it, and then improve it using what we learned. Let’s start by looking at some of the key features of the cellular network that can create security problems.
The first advantage attackers have is they don’t have to worry about the technology in use to connect the cell phones, or “mobile terminals,” to the cell towers. Although many folks like to talk about cellular networks as if they are islands of technology, the simple fact is this: we’re beyond simple technical hurdles when it comes to communicating. I can send an SMS from a CDMA-based North-American phone to a GSM-based Malaysian phone just fine. Getting hung up on the lowest layer of technology isn’t why we’re here. The modulation type of the radio waves moving into and out of your phone don’t matter as much today as the functionality the phone brings to the table.
For this reason, and because GSM and CDMA are the dominant radio access technologies in use today and thus constitute the primary attack surface, we’ll focus mainly on them. We’ll also chat a bit about next-generation protocols like LTE and IP-based services at the end of the chapter.
In fact, the very best part of today’s modern cellular networks happens to be exactly this interoperability—the fact that two differing radio technologies mean little to the consumer. This also makes the security researcher’s life so much easier! Hackers (of the good and bad kind) don’t have to waste time decoding radio transmissions because all of these technical details are abstracted so well by the mobile network operators (MNOs) that things just work. Us security types can focus mainly on the endpoints to be attacked—and defended.
And there are lots of juicy targets in this regard, as all major cellular networks support
• Voice calls
• Voicemail (VM)
• Short Message Service (SMS)
• Location-based services (LBS)
• IP connectivity
with most also supporting
• Binary configuration messages
• Multimedia messages (MMS)
• Faxing
Figure 2-2 shows you what this all looks like.
Figure 2-2 Service overview of a GSM cellular network
Figure 2-2 is an extremely simplified view of a relatively complex system. Even though GSM was designed a few decades ago, the system is solid, interoperates well, and is deployed worldwide. All of these features, of course, come with some complexity.
Let’s look quickly at the players in a GSM network deployment. You, of course, know that there are customers—subscribers—who carry around their mobile phones, make calls, send text messages, and so on. Those folks are on the left side of the diagram. In the GSM world, mobile devices are known as MTs, or mobile terminals. Over the course of their travels, these mobile terminals connect to a number of antennas—called base station transceivers (BTS).
The connection from a mobile device to a BTS is designated as the Um. (The U designation is a carryover from earlier digital signaling days, when Integrated Services Digital Networks, or ISDN, began offering connections to user equipment over the U channel. Add the m for mobile, and there you have it!) Each BTS connects to a base station—essentially a rack of equipment that takes the radio signals that the antenna receives and converts them to digital packetized data. The base station is composed (nowadays) of two main components—one for voice and control, called the base station controller (BSC), and one for forwarding IP packets and managing mobile IP, called the packet control unit (PCU). Both of these devices are really the “edge” of the GSM network from our perspective since we normally don’t climb over fences and break into gear sheds (for those who do urban crawling, you can consider the Mobile Switching Center, or MSC, the edge of the GSM network!). The base station subsystem (BSS) combines the BTS, BSC, and PCU. The base station subsystem can actually be owned and cared for by a number of folks who are not necessarily associated with large carriers. This allows for smaller mobile network operators throughout individual countries, while still using larger, higher-coverage carriers.
Now that we’ve laid out the basic topology, let’s look at some of those juicy, attackable capabilities in more detail.
So how do you actually make a phone call? Glad you asked. It’s taken us thousands of pages of standards, endless Wikipedia editing, and a whole lot of phone calls to understand the flow required to actually set up a phone call. In the interests of actually claiming that our time wasn’t wasted, we’re going to give you a pretty thorough view.
First, we need to talk a little bit about the Um channel—the connection between the MT and the base station. The Um channel has a number of parts, including traffic and control aspects. Although all of these parts have designations and separate duties, just remember—they’re all flowing over the same radio link, just using different time slots. Time division multiplexing (TDM) is a tried-and-true method for dividing up precious radio capacity among a host of devices. At its simplest, time division multiple access (TDMA) simply says that device 1 will use slot 1, device 2 will use slot 2, device 3 will use slot 3, and so on. Of course, that’s not helpful if you don’t know what a slot is. A slot is more or less a time during which a device is allowed to broadcast. If all devices start at the same time, using our example, you would see radio traffic from device 1 for a certain amount of time, then radio traffic from device 2, then radio traffic from device 3, and so on. This ordering allows for an orderly sharing of the available radio capacity among all participating devices (What happens when a device doesn’t participate? We’ll cover that in a moment, but think “radio jammer”). TDMA systems have been around for quite some time and have been hugely successful at slow and medium bit rates. (For our purposes, let’s stick to TDMA, but I urge those of you who actually like the physics-y aspect of this conversation to go look up FDMA, OFDM, and various other multiplexing schemes.)
So back to TDMA: Each device has a particular timeslot in which it is allowed to “speak.” This timeslot is essentially handed down from a controller—let’s call that controller the BSC—that then listens for each device’s broadcast in each device’s assigned timeslot. Note that the BSC—the brains of the BTS—is actually the one “listening” for these radio broadcasts; the BTS is really just an antenna and contains no intelligence of its own.
Now let’s subdivide those per-device timeslots one more time to give some order to the system. When a mobile device makes contact with a base station, it has to go through a lot of rigamarole simply to get assigned a timeslot that it might use. Once a device has been authenticated and begins to use the cellular network for actual services, things get slightly more complicated. At the point when, say, a subscriber wishes to make a call, or send a text message, the mobile device has been listening to five or six broadcast channels, sent a few messages to the base station controller, and has quite likely been told to reassign its radio from one frequency to another a few hundred times.
Here’s the takeaway from all this: the cellular network relies on a number of techniques to make it seem like you aren’t competing with 500 other customers for precious capacity inside a cell site. The primary technique is to divide up the radio spectrum into channels for control, data, and voice.
Imagine how many folks connect to a cell site near a stadium on game night or at a movie theatre during the next Bond flick. Concentrations can be on the order of thousands of mobile devices per cell in big cities, and the cellular network copes just about all the time. The way the cellular network copes is a retinue of uplink (from the mobile device to the cellular tower), downlink (from the cellular tower to the mobile device), and broadcast channels all working in concert to deliver a seamless experience to the user. Generally speaking, the channels can be broken into two main categories: mobile signaling and control, and traffic channels. Traffic channels carry voice data, whereas control channels manage everything else about the mobile device’s association, usage, handoff, and disconnection from the cellular network.
The control channels are the really, really interesting part of the GSM system. We’re going to take a moment to give you a peek at the complexity under the hood of a simple thing like turning on a cell phone. You’ll notice in Figure 2-3 that we’ve placed arrows on the individual boxes that label each channel; these arrows denote the direction of data for that channel. A channel with an arrow in only one direction is “read-only” and usually contains status information. These channels are generally not interesting from an injection point of view, but ultimate havoc can be wrecked by modifying the data or drowning out broadcast and common control channels. A cell phone jammer is really just a moderately loud, badly tuned transmitter. It also happens to be relatively easy to build. If you simply search online for cell phone jammer, you’ll find hundreds of designs, some useful and some not. Quite the denial of service attack, until you’re pinpointed by radio trilateration and thrown in jail.
When a cellular device first turns on, it knows very little about the world around it. It begins to listen to various frequencies (which it does know, thanks to international treaties and spectrum agreements). These various frequencies generally correspond to channels (see Figure 2-3) that are allocated to the device based on its radio capabilities and geographic origin. Usually, the first thing that a phone “hears” will be the BCCH, or the Broadcast Control Channel. The BCCH contains information that allows the mobile device to synchronize and understand which network it is attaching to, along with features (like neighboring cell identities and channel information) of the network the BTS is serving. The mobile device then knows how to access the RACH, or Random Access Channel. The RACH is essentially the first stop in a GSM handshake between a mobile device and a BTS. The RACH is how the mobile asks for information on becoming associated with a particular cell within the cellular network. Once the mobile has sent a channel request via the RACH, the BTS tries to service the request. If the BTS has slots free in its radio configuration (available capacity), it assigns a control channel, called the Standalone Dedicated Control Channel (SDCCH), to the mobile device. The BTS tells the mobile device about this assignment via the uninspiringly named Access Granted Channel(AGCH). Once the mobile device has received an SDCCH, it is a member of the network and can request what’s known as a location update.
Figure 2-3 GSM logical control channel layout
A location update really means that your mobile device is letting the GSM network know which area it’s in. It also requires, in general, that the mobile device authenticates with the network. All of this back and forth takes just about a second or so, depending on load within the cell and radio quality. Usually, this task is done before you even have a chance to unlock your phone. The location update informs the Home Location Register (HLR)—a database of subscriber information—of the current geographic area (and, hence, which Mobile Switching Center, or MSC) a device is located within.
Somewhat counterintuitively, once the mobile device has performed a location update, the base station controller tells the mobile device to “go to sleep” by deallocating the SDCCH that it assigned only a few short seconds ago. This maximizes reuse and capacity in dense cells to ensure everyone gets a decent quality of service.
Authentication and A5/1, CAVE, and AKA
Voicemail is one of those throw-back technologies that is really, really useful, and yet we tend to marginalize it quite a bit. Cast your mind back to the “voicemail hacking” scandals that rocked the print publishing world this past year, however, and you might reconsider relegating voicemail to the “has-been” tech pile.
Voicemail has always been a fundamental service associated with the phone system, and as technology has advanced, so has voicemail. We went from simple analog recording devices to digital message storage (and management) to voicemail as IMAP and now to voicemail as a cloud service.
Voicemail, at its simplest, is really just a mechanism for connecting a phone call to a recording device, saving that digitized file somewhere, and helpfully replaying that sound file during another call—usually when the mailbox owner calls in. The system itself can’t be much simpler, but it does offer a number of interesting possibilities for theft, loss, and misdirection. Most current voicemail systems operate on a funny interplay for SMS messages, phone calls, and, interestingly, IMAP mailboxes!
Many large carriers, in the interest of reusing technical know-how and system knowledge, have moved toward an IP-based voicemail implementation. Many of these implementations are really just thinly veneered IMAP servers that serve up IMAP mailboxes using simple phone numbers. As we move into the future, we may even see a move toward web-service-based pure-IP solutions. As security practitioners, this gives us pause. Whereas the telecom giants have been, in general, relatively protected from script kiddies and low-hanging fruit, the looming standardization and lowest-common denominator approach to technology deployment will create a wealth of opportunities for folks to make systems more reliable, more secure, and more functional; it will also allow folks who troll through vulnerability message boards and websites to suddenly find errors more easily, unless we all do our jobs correctly and ensure that we deploy well-configured and well-protected applications and services.
SMS is one of the most interesting features of the cellular network, which is a little strange because its addition was an afterthought. SMS messaging has become the de facto standard for most folks born after the 1970s—we’d rather tap out a quick “omw, eta 5” than call up our best friend and say “Yep, I’ll be there in 5 minutes.” Go figure.
The SMS system is actually piggy-backed on the control channel for mobile phones—the control channel that normally sets up phone calls, tears down phone calls, and manages radio channel allocation and radio access network housekeeping. Turns out that people didn’t really invent GSM with the idea of SMS, but rather the idea of SMS got added on at a later date. A number of folks have said that the cellular network would be vulnerable to an “SMS flooding attack” (smsanalysis.org), and they’re somewhat correct. Since the SMS delivery channel naturally contests the control channel, someone could conclude fairly pretty quickly that if an attacker were able to send a ridiculous number of SMS messages—on the order of hundreds a second to flood a cell to hundreds of thousands a second to flood a region—that you’d have quite a nice attack. The cell providers, however, are a resourceful lot.
SMS messages actually travel via a couple of the logical control channels we described in Figure 2-3. Usually, messages are delivered either over the SDCCH when a user is not on a call, or over the Slow Associated Control Channel (SACCH) if the user happens to be talking at the time. A single SDCCH has a nominal data rate of between approximately 0.6 kbit/sec to 2.4 kbit/sec, depending on the configuration and usage of the channels on a per-BTS basis. This means, in a best-case scenario, it takes about 0.07 seconds to send a 160-character message to a mobile device, and in a least-provisioned case, approximately 0.27 seconds. You would have to send a message that would bypass SMS Service Center (SMSC) timers and flood controls at least four times a second to a single subscriber for the subscriber to notice anything at all wrong with the network. Most likely, he or she would be flooded with text alerts, and no real harm would come to the GSM network in any event.
There is a second and slightly more interesting point in all of this—remember how we mentioned that providers are a resourceful lot? Well, they’ve thought of this issue as well. Since their minds are usually focused on keeping customers happy and maintaining network reliability, they decided early on that SMS messages would be managed by a system of timeouts and prioritization. This timeout and prioritization system usually ensures that the SMS Service Centers, or SMSCs, bear the brunt of the load when an SMS message storm happens. These things happen all the time—at sporting events, during emergencies, on Friday evenings … and when they do, text messages rarely interfere with call setup or teardown. When issues like SDCCH contention do arise, it is generally due to misconfigured equipment, rather than an issue with, say, the GSM specification itself.
And now let’s come back to the original point of this section—the SMSC is, quite literally, the hardest working piece of equipment in just about all modern cellular providers’ networks. With only a couple of data centers and just a few dozen SMS Service Centers, nationwide providers deliver over a 100 billion messages a month. That’s more than 1.2 trillion messages a year. These SMSCs are built for a simple task, and they excel at it: receive a message, read the destination phone number, and then find that phone number’s location and send the message on for delivery. Sounds simple, and it is, but the humble text messages aren’t just for sending emoticons…
SMS messages have an interesting feature—they are not just for texting! A few short years ago, when Java Mobile Information Device Profile (MIDP) and Connected Limited Device Configuration (CLDC) devices were making their way through the world, it was old hat to receive a specially formed text message, with a user data header (UDH) specifying a port to direct the message to. This was how the Java folks implemented per-application messaging, and it was, technically, quite good. It used existing SMS infrastructure (which is pretty robust); it used a simple idiom for identifying applications (“ports,” which looked and behaved very much like TCP or UDP ports); and it was accessible without too much fuss from any application and without special libraries or carrier fees.
The SMS message is actually a multipurpose mechanism for short communication between not only the user and other users, but also network elements (like configuration servers) to a mobile device and other mobile devices (like a peer-to-peer Java application). The UDH is generally the most useful extension to the SMS message, and it includes a lot of potential features:
• Changing reply-to phone number (UDH 22)
• Message concatenation (UDH 08)
• Message indicator settings—video, voice, text, email, fax (UDH 01)
• Ported SMS message (UDH 05)
We won’t go into all of the wonderful things you can do with these sorts of messages here because you can find tutorials all over the place (just type UDH tutorials into the search engine of your choice). Keep this in mind, however: The SMS message has grown and evolved over time, and the fact is that it has been, and remains, a powerful capability in mobile networks. A combination of standards, operator configuration, and handset configuration means that SMS messages can potentially create a lot of damage if operators and handset makers aren’t careful about what they place inside these messages and what sort of trust relationships these messages invoke.
Many years ago, a phone manufacturer decided to allow “configuration messages” to be sent to its handsets. Because the handset blindly obeyed the configuration directives in these messages, attackers could easily misconfigure mobile devices so long as they knew the victim’s phone number. Remember that an SMS message, by and large, has zero authentication, zero integrity checking, and zero confidentiality. Anyone in the world is allowed to send you a text message. Even if mobile network operators filter particular message types and features, like the UDH tomfoolery we just described, there are still potentially millions of people on your home network.
One of the annoying facts of life happens to hit you when you need to make multiple systems work together for a common cause. In our case, let’s say that this common cause is a fully featured smartphone—one that you might use to email, text, and call your friends or business partners. Using a standard interface, like Apple iOS, you happen to be at the mercy of the UX designer’s decisions. In the case of the iOS UDH reply-to hack, iOS decides to display the “reply-to” number rather than the originating phone number. The horrible part is that most folks using a phone would never consider double-checking the origin of a text message. Pod2g describes the scenarios here: pod2g.org/2012/08/never-trust-sms-ios-text-spoofing.html.
In addition to the iOS UDH reply-to hack, which makes it easier for an attacker to fool a user, there is another route to faking SMS messages, and it has nothing to do with the cellular network. In most cases, privileged and sometimes nonprivileged applications can simply create SMS messages out of thin air. This would, for instance, allow an attacker to install an app on someone’s phone and send authentic SMS texts directly to the user’s inbox: check out bitdefender.com/security/android-vulnerability-opens-door-to-sms-phishing-scams.html.
While it’s possible that something malicious will never happen to you, you’re likely reading this book because you’re a security-oriented person, so we ask: If you get the chance to design a system like this in the future, will you please include some strong authentication? Thanks.
OK, we’ve examined the basics of the cellular network; let’s talk about how to attack and how to defend it.
Hacking Mobile VoicemailPerhaps the best known “mobile” hack in recent memory was the News of the World break-ins to the voicemail accounts of people in the UK. Think we’ve learned our lessons from this? No, turns out that (even in the United States) may MNOs still configure voicemail accounts, by default, to authenticate anyone calling from the corresponding mobile phone number, without prompting for the voicemail password. In the case of the News of the World, the results were more tragic,2 but we’ve seen this hack performed to neat affect at parties where colleagues who’ve set up their own private PBX servers (using, for example, open source frameworks like Asterisk). With such a setup, you can rout calls and spoof caller ID numbers easily. This makes it trivial to access anyone’s voicemail as long as you know their mobile phone number. We’ve had this trick pulled on us, and it’s quite disarming when someone simply asks for your phone number, makes a call, and an instant later holds up the phone while it plays your voicemail messages back to you.
Even worse, services exist on the Internet that perform caller ID spoofing for a small fee, so you can perform this hack from any computer attached to the Internet. John Keefe writes about his experiences with this version of the trick at wnyc.org/articles/wnyc-news/2011/jul/18/hacking-voicemails-scary-easy-i-did-it/. Keefe’s article also documents (again) why this is still possible: “AT&T spokesman Mark Siegel said that for convenience, AT&T customers ‘also have the option of not entering your password when accessing your voice mail from your mobile phone.’” Once again, easy trumps secure. Sigh.
Countermeasures for Mobile Voicemail HacksWe’ll keep this short and simple—set a voicemail password (of reasonable complexity), and configure access so that entering the password is required in all cases (even when calling from your own phone!).
Rogue Mobile DevicesBack when Apple claimed that jailbroken iPhones would be a serious threat to the cellular network, they actually meant it. Just because no one has done anything bad with the technology doesn’t mean it won’t necessarily happen. In fact, the major stumbling block to a “cell phone–based network attack” is really volume—you’d need a lot of cell phones spread out geographically to really affect the cellular network in a meaningful and media-attention-grabbing way. Much like a single person with a cell phone jammer is really just an annoyance, imagine what would happen if every fifth or sixth person you meet just happened to have an active radio-blocking device?
Another interesting point, as long as we’re talking about the phone, if you’ve ever looked into the software innards of an iOS or an Android device, chances are that you’ve started to see similarities to various flavors of Unix—directory structure, libraries, file formats, and so on. This can be summed up in two simple sentences: “iOS is BSD,” and “Android is Linux.” Although not technically this simple, the nature of the iOS operating system is that it owes a significant part of its existence to Berkeley UNIX, and the Android operating system is essentially embedded Linux with some libraries and management capabilities not normally found on laptop or desktop builds.
What’s the upshot here? Anyone who’s been breaking, building, or researching on either BSD or Linux can take 90 percent of their hard-won experience and immediately apply it to iOS or Android devices.
So how can the phone affect the network? Remember the simple diagram of the GSM network shown in Figure 2-2? You’ll recall that we had a phone connected over radio to a base station transceiver (BTS) using a Um channel. As it happens, the Um channel is actually a number of different logical and physical channels, all stacked together to give the illusion of seamless calls, texts, emails, and Internet access to mobile terminals. When you send and receive calls, for instance, a number of logical channels are put into play to orchestrate a telephone call. If you had possession of a modified mobile device, one which, say, could selectively jam or modify broadcast signals or important network information transmissions from a BTS, then you could control or jam any other legitimate cell phone within your broadcast range. All in all, it’s a pretty horrible scenario to consider. The main issue here is locality: a single attacker with a single phone is really just a nuisance. Consider, though, what would happen if every single phone from a popular brand (like Android or iPhone) were to start misbehaving? It would be the largest distributed denial of service cellular carriers have ever seen.
Rogue Mobile Device CountermeasuresMobile devices modified as just described would be devastating to the cellular network, except for one thing: locality.
One of the major points to consider when people start talking doom and gloom about the cellular network is the idea that a cellular network is, by design, carved up into many smaller parts. If someone were to modify a cellular phone in order to do something “bad” to cellular gear … well, he or she would be able to affect anyone within radio earshot. For a modern phone, that’s generally on the order of a couple hundred yards or less in a big city and a few miles on flat terrain. If that person were able to do such a thing, the damage would be limited (and yes, we know “damage” is a horrible word to use here) to generally members of the cell inside the cellular network, and potentially only to those exposed to the actual original radio signal, depending on the type of interference and the attacker’s goal. Put simply—radio is the most deniable method of communication folks can deploy nowadays; it would actually be easier to use a spark gap and a relatively beefy battery tuned to the four or five basic cellular service frequencies to cause annoyance and denial of service, rather than modify the baseband of a cellular device to do it for you. We figure these types of threats, although legitimate, shouldn’t keep you up at night.
Early Rogue Station AttacksThe traditional trust model for the cellular network looks a little bit like a kindergarten class. There’s a teacher and a whole bunch of potentially rowdy children. Each child roughly corresponds to an active cell phone, and each classroom roughly corresponds to a cell site. You can imagine that most of the trust and most of the authority comes from the top—from the cellular carrier. Because of this, and because of the assumption that the skills required to modify hardware and firmware are beyond most attackers, we see a very top-down approach to network control. This means the network demands authentication from the phone, but (until recently) the phone simply didn’t bother to authenticate the network. The simplicity with which you could emulate a cellular network was really more about what you knew of the testing equipment and less about circumventing security measures.
To detail this a little further, let’s take a simple example of how we learned to impersonate any cellular carrier in the world. Back in the 1990s, we were very impressionable kids, with too much time on our hands and a rather small amount of savings. We needed to start playing with this new technology that allowed us to talk to folks from the beach, from a car, or from the top of a mountain. At the time, the magic was still fresh, and the idea of sending speech over radio waves to some other person was pretty damn awesome.
Those were the days of simple time division multiplexing, raw radio output strength, and huge batteries. There were competing technologies, and people were still struggling to achieve that nirvana of interoperability that we enjoy today.
Regardless, we were curious, we were poor, but we did have a cell phone or two. We started to poke around USENET and ask questions about radio, digitized voice, and this new-fangled thing called GSM. GSM technology was relatively immature back then, but luckily the standards and protocol specifications were available to hobbyists, if you were lucky enough to find digital copies. Armed with a 1200-page specification document, we started reading … and reading … and reading—until we stumbled on an interesting fact about the GSM protocol. Any phone can, potentially, roam on another provider’s network. This is what happens when you leave Rotterdam, arrive in Stavanger, and can still make and receive calls. This is a built-in feature of the GSM network. It also boils down to three very interesting things:
• A cellular phone can simply “join up” with another cellular provider’s network.
• Cellular phones are generally promiscuous when it comes to joining networks (how else would roaming be so easy?).
• Cellular networks are defined by a simple three-digit number and a three-digit country code, as shown in Table 2-1.
Table 2-1 GSM Network MCC/MNC Chart
(Source: Wikipedia, en.wikipedia.org/wiki/Mobile_Country_Code_(MCC))
If you’re anything like us, you’re saying something like “Now, how do we emulate that three-digit number?” If you’re not like us, that’s good, because that kind of thinking can get you into all sorts of trouble. Ultimately, though, we found what we had been looking for—a way to create a GSM network and to understand how GSM phones would join and use that network. The biggest problem was that we had no equipment to do anything with our newfound knowledge. We needed to get our hands on a base station but without using a ski mask and bolt cutters. After many months of searching, we finally found what we were looking for—another cell phone! We had no idea, at the time, how powerful the baseband was in these little devices. It turned out that many features, like being able to simulate a base station, were really just a software change away.
We had been looking everywhere for a way to simulate a full base station—the radio tower that every cellular phone connects to for service. What we hadn’t realized was that radio was, by its very nature, a shared broadcast medium—meaning if we were close enough, we could listen in to whatever was in the air around us. Pretty basic, we know, but we were younger and just learning this stuff for the first time. Armed with a slightly different goal—to listen in to cellphones, rather than to emulate a base station—we started out asking more and more questions of anyone who would listen. Ultimately, we heard back from another tech-head in Germany. He explained that you could modify the firmware on a cellular phone to place it into what he called “engineering mode.” We didn’t immediately see the benefit until he explained: “Engineering mode firmware allows these phones to sniff radio traffic on all bands at the same time, and you can log all of these packets via RS232. Stuff like voice and SMS. It’s pretty cool.”
Remember, these were the days of 14.4k modems, so it was pretty exciting for us to find a way to capture radio traffic with a cell phone. This fellow sent us a massive 300kB attachment, some instructions on how to flash a particular phone, and instructions for buying a debug cable from a vendor overseas. We paid about $20 for the cable, set up a Slackware box, and flashed our first cell phone. We haven’t looked back since.
Now, for those of you who are picturing scenes from the movie Swordfish or Hackers, we need to tell you right now: it was nothing like that. In fact, it took months of casual hacking to really understand the stuff we were looking at. When we did, though, our whole world changed. We were looking at byte streams corresponding to control channels (making and breaking telephone calls and sending text messages), voice channels, and even packet data. At the time, packet data was usually for simple low-speed tethering, and I reckoned that the voice and text messaging was cooler.
Remember, too, that all of this happened in the 1990s. Cell phones were just coming into vogue; they were starting to get less expensive; and more and more folks were using them as a day-to-day convenience. All the resources we needed to expend were the 20-odd dollars for the cable, a few dozen hours on USENET, and a dial-up connection to download some firmware. All in all, we still view those $20 as a good investment.
If we fast-forward a few years, to the point where we had real jobs and real customers, the idea of emulating a cellular base station came up again. Back in early 2002, this author was asked to provide a full testing environment for cellular phones. The idea was to be able to understand and modify the environment in which mobile phones and mobile payments would be made. Being a little smarter the second time around, I immediately approached the major cellular carriers and asked, “What do you guys use to test your phones?” Perhaps predictably, all of the carriers told me to wander off, so to speak, perhaps thinking that if some crazy consultant knew the secret to their network testing, that anarchy would soon follow.
I was reduced to wandering around the Internet again, whereupon I found a nice company called Rhode & Schwartz. R&S just happened to create test gear for GSM networks, including the holy grail of my search—base station transceiver (BTS) emulation! I quickly found out all I could about their product, including the price. Have I mentioned that these units were expensive? Like six-digits expensive? It seemed that my client didn’t mind one bit, so neither did I. I ordered the R&S CMU200 with all of the bells and whistles and I got to work. Turns out that it was still just as simple to start emulating base stations—those three digits, or the mobile network code, defined the various carriers. Once I looked up the MCC/MNC tables, I realized that there was, thoughtfully, a “Test” MCC/MNC of 001/001. Of course, for the sake of this book, I must insist that anyone who’s interested in exploring this area should stay on 001/001. Let’s perform a little imaginary experiment, however.
Let’s say you happen to have access to one of these BTS emulation boxes (purchased from an auction, a fire sale, or direct from the manufacturer). Let’s also say that you wanted to emulate one of those cellular carriers we’ve been talking about. The first thing you’d do is go look up the standard mobile country code for your country; for the sake of this gedanken (thought) experiment, let’s use Saudi Arabia. Saudi Arabia currently has two main mobile network operators (MNOs) vying for revenues from mobile subscribers: Mobily and Al Jawal (Etisalat and Saudi Telecom, respectively). Let’s presume we’re going to impersonate Mobily. We first look up the KSA’s MCC, which is 420. Good start: three digits down, three to go. Now we need to determine what mobile network code Mobily uses for its services. How do we do this? The easiest way is to look up the MCC/MNC pair on various sites online. For this experiment, we’ll use mcclist.com. Mobily uses “3” (or “003”) as its mobile network code. Armed with this information, we are now able to emulate a GSM network in Saudi Arabia.
At least … we thought we could. It turns out that, although six digits do uniquely determine a GSM network operator’s space, one final piece of information is necessary to fool GSM handsets into connecting to your fake BTS: the channel assignments. Today, channel assignments are usually a moot point, with “world phones” and “quad band” radios being more the norm than the exception, but you should always be thorough when trying to impersonate a cellular carrier. In this case, we can consult the same websites and see that, in our particular thought experiment, Mobily uses GSM 900 and UMTS/W-CDMA 2100. For our purposes, we don’t have to worry about radio compatibility or channel selection, but in the real world, we would need to cover both the standard GSM 900-MHz band as well as the CDMA 2100-MHz band, necessitating two separate radios. Figure 2-4 shows the GSM spoofing setup.
Figure 2-4 A simple GSM spoofing setup
After all of this work, let’s see what we’ve got. First, if we were to turn this unit on in Saudi Arabia, we would begin to see phones associating with our base station. We’d also see data connections, outgoing phone call attempts, and a lot of SMS messages. The subscribers would also notice something else: they would be seemingly disconnected! Although the equipment we’ve described will successfully fool a cellular phone into connecting with it, the base station emulator does not have all of the required connectivity out of the box to allow cell phones to make and receive calls, send text messages, or browse the Internet.
For some of these problems, like browsing the Internet, it’s as simple as plugging an Ethernet cable into the back of the emulation box. For phone calls, spoofing the number identification for outgoing calls is an awful lot of trouble—and it requires an equal amount of effort to intercept and proxy incoming phone calls legitimately.
Rogue Base Station CountermeasuresAs noted, this issue is about cellular network authentication, and thus, there is little that you can do about this as an end-user. Remember this next time you make that ultrasensitive phone call or send that SMS or email from your mobile device. Sigh deeply.
Rogue Femtocell AttacksIn 2009, there was significant interest in a simple open implementation of the BTS portion of the GSM stack. This implementation, OpenBTS, gained notoriety when a few security researchers realized that you could use this free software on some basic radio hardware and produce a “fake base station” for about $1500USD (remember that the R&S CMU200 cost more than a luxury yacht at the time, so this was big news). Unfortunately for the security researchers, the year 2009 was also when the general release of femtocells hit the North American market. Femtocells aren’t like base station testing equipment, and they aren’t like open source software implementations of the GSM stack. Femtocells are a hacker’s holy grail; they are bona fide mobile network operator devices that implement the complete GSM or CDMA stack, support all devices on an operator’s network, and provide legitimate calling, messaging, and data backhaul to any subscriber. Figure 2-5 shows a possible rogue femtocell setup.
Figure 2-5 Rogue femtocell spoofing setup
As with most new technology, however, there were snags. Almost as soon as they were released, these femtocells ended up as fodder for just about every interested security professional and teenager with a credit card. As one presentation at Black Hat noted, these devices were essentially a basic embedded Linux distribution with a few custom applications and some nice radio equipment. A small price to pay for a brave new world, no?
The idea of a femtocell is to place a wee tiny box placed in your apartment or home. This wee little box has a couple of connectors—antennas, power, Ethernet—and little else besides status LEDs. So how does this box make its magic happen? It’s actually quite simple. As just noted, a traditional femtocell is a rather generic Linux distribution running several specialized applications; it loads a couple of drivers and includes some nice, if simple, radios. Most of the actual implementation is via software; binaries control the control and data signaling for the connected devices. Firmware images modify the radio devices for various compliance and protocol rules. These applications generally control three main aspects: the control signaling (call setup and teardown and SMS messaging), the conversion of normal voice calls into real-time protocol streams, and the associated SIP setup.
Femtocells also include basic operating system support for securing the backhaul link; usually they accomplish this via IPSec transport or tunnel mode connections to special security gateways on the mobile network operator side. Put it all together, and you have a highly functional unit that can reside both in the operator’s network and equally well within a customer network.
The basic operation of a femtocell includes a number of aspects that security folks are interested in, including:
• Device association
• Call setup and teardown
• Message delivery
• Backhaul connectivity
Device association with most modern femtocells requires that the femtocell actually communicates with the MNO authentication mechanism. Interestingly, this offers a number of potential attack vectors. Obviously, the communication path with the back-end authentication center and its associated security (authentication, authorization, rate limiting) is critical to the security of the overall platform. Nowadays, any femtocell that receives the raw secrets used to authenticate a device is a serious risk to both MNOs and their customers. Although secrets could be protected with an IPSec tunnel between the MNO and femtocell, the fact is that anyone with physical access to a device as capable as a femtocell can easily gain access to the software and hardware. Once physical access is obtained, all security bets are off. Many off-the-shelf units do exactly this, as shown early on by hackaday.com/2012/04/12/poking-at-the-femtocell-hardware-in-an-att-microcell/and wiki.thc.org/vodafone. Because these devices are based on simple Linux distributions, any and all hacking tools and knowledge can be used by moderately skilled attackers to leverage the full power of a network-connected base station.
This leads to a serious dilemma: how can we place high-powered, highly trusted network devices in the hands of customers? Our answer: you cannot. The simple fact is that folks around the world would love to play with these femtocells for a variety of reasons—and not all of those reasons are good. Femtocells should perform only simple “radio-over-IP” functionality if they wish to maintain the security posture of their MNOs and to protect their (and potentially other) customers.
Another interesting configuration choice for most femtocells revolves around membership. A highly controversial question with many network operators goes something like this: If we limit the membership of our femtocells to a few cell phones, we’ll lose out on free network improvement. Therefore, we’ll allow any of our customers to connect to anyone’s femtocell, and everyone will be happy!
Some carriers have chosen to limit femtocell device associations only to a customer-controlled whitelist, whereas others have simply said that any phone capable of connecting to the MNO’s network can also connect to their femtocells. Let’s take a second and dissect that decision, shall we?
If the femtocell allows only connections from a whitelist, we have a trade-off among a number of factors—customer experience, MNO benefit, and security. In current deployments, we see mostly a compromise between customer experience (they don’t have to do anything to make a femtocell “work”) and benefit to the MNO (all customers can enjoy improved service even if they don’t purchase a femtocell; they only have to be near a customer who did). Combine this with the current femtocell design, which gives you a highly capable network platform, and you end up with a potential security problem: people can create rogue base stations that they, not the MNO, control. This setup provides those with, let’s say, low moral fiber the opportunity to sniff phone conversations, SMS, and data connections from unsuspecting passersby whose mobile devices will promiscuously join the rogue base station. The only real limit to this problem is physics: most femtocells employ very basic antennas, and those antennas have limited coverage. However, in our experience, it takes less than $100 to enhance the antenna, increase the transmit power, and dramatically increase the range of the compromised femtocell. A pretty nasty piece of gear.
On the other hand, those MNOs that have limited their femtocell membership to a few IMSIs still have the problem of a highly capable platform being deployed that can, in some cases, request extremely valuable information from the backhaul, for instance, encryption keys. So although those MNOs that have limited their membership have limited the “rogue base station attack” problem, they still have let a (relatively) open gateway onto the cellular network itself, which in the wrong hands could yield access to sensitive customer information—information that could be used to clone a subscriber identity module successfully and potentially harm both the customer and the MNO.
Countermeasures for Rogue FemtocellsGiven the popularity and widespread use of femtocells, we’re not going to put this genie back in the bottle anytime soon. However, there are some things that MNOs and others can do about femtocell design that could improve the situation.
Ideally, what would be easiest here would be to create a device that looks a lot like today’s femtocell, yet lacks the authority to request information regarding a particular subscriber. This new-age femtocell would protect MNOs and customers from most attacks, but it would still give a determined attacker the capability to pretend to be an MNO—something that, most likely, the MNO would not enjoy. To solve this problem, we have to swing our gaze over to handset makers and the standards committees that write up protocols and interfaces.
Funny enough, GSM networks never really had the notion that the network would have to identify itself to the handset; rather, the security is supposed to go from “outside in,” you might say. To get on the network, a mobile station has to go through hoops like answering challenges, providing a valid serial or equipment number, obey all traffic laws as set down by individual base stations, and even then, a mobile station may simply be denied network access if, for instance, the network is too busy.
This security model, as we hope you’ll agree, is flawed. One-way trust just doesn’t cut it anymore. With the capabilities inherent in even aging smartphones, we’re looking at the largest distributed computing cluster in human history, with the most connectivity, memory, and processing power we’ve ever produced—as a civilization. That’s kind of cool. It also requires somewhat novel decision making on the part of handset manufacturers, standards bodies, and MNOs. Luckily, we’re not the first folks to think of this. Good thing, too.
As we’ve been rambling on about mobile network operators, GSMs, and femtocells, people have been quietly toiling to produce a dependable, open, and correct method of mutual authentication between the mobile stations like your cell phones and the mobile networks.
In the IP multimedia subsystem (IMS) world, based on IP and using a services model, we naturally have a few choices when it comes to mutual authentication. SIP allows for a wide variety of one-sided and mutual authentication schemes, and IPSec allows for a variety as well. So how will we fare in the IMS world? Pretty well, actually, if people pay attention to things like known-bad ciphers, keys, and modes—and key handling issues—and secure-by-default defaults. All in all, we’re in a better position today than ever before to get things right.
We’ve reviewed how old-school cellular technologies work, and how interoperability, roaming, and handsets all affect the mobile network operators around the world. Now, we’ll talk about the brave new world of IMS—the IP multimedia subsystem. Most carriers are moving to a technology platform that is truly IP-based, rather than discrete or shared radio channels with data uplink and downlink. In this brave new world, all devices will simply have a baseband that is capable of connecting a device to a high-speed IP network. Gone will be the days of packetized voice, loss of data service while on a phone call, or low-speed data links.
While this technology platform is quite a nice advancement from a services and billing perspective, from a security perspective, essentially all of the services—calling, data, control plane, messaging—will be standardized onto a single unified backbone. That backbone happens to be good-old IPv4 (and, soon enough, IPv6). Along with that transition, you can expect a few more changes, as well:
• Voice calls become Real-time Transport Protocol (RTP) streams delivered via UDP.
• SMS and MMS messages become Short Message Peer-to-Peer (SMPP) interactions.
• Control channels become SSL- or IPSec-protected TCP endpoints on your phone.
This will skew the game wildly toward folks who have been reconnoitering, breaking, and investigating IP-connected devices for decades. Whereas there was (some) magic and awe around the idea that a cellular phone could manage multiple radio channels, protocols, and various radio frequencies across the world, we’ve now got a simple, unified platform based on extremely useful but easy-to-break technology, as shown here in Figure 2-6.
Figure 2-6 A simplified IMS architecture diagram
In the long-term evolution (LTE) model of the world, there are devices out in the wild that can connect via IP networks to services, protected by gateways, which provide useful features for customers. One of the largest changes from GSM or CDMA to LTE is, of course, the unified bearer protocol—IP—but another, equally large change is the idea that an IMS network can service any IP client. This means that your PC, your laptop, your tablet, or your smartphone could equally well use services provided by an IMS network.
Want to transfer a call between your mobile and your PC when you step inside your house? Want to stream a TV channel to your television when you’re on the couch, and to your smartphone when you’re up and about the house? Want to send text messages from any machine you sit down at?
Technically, all of these features are possible with an IMS core. All you need is some basic client software, network connectivity, and presto, you have a seamless media experience that covers traditional telephony, cable television, instant messaging, and web browsing. That’s the promise, at least. As usual, we have a ways to go before we get there.
Right now, IMS deployments are happening all around the world, and they’re not just being done by mobile network operators—television providers, VoIP providers, and traditional wire-line phone services are trying to jump on the all-IP bandwagon to secure more customers and more revenue. IMS is dependent on a number of cooperating subsystems, however. While we focused on some nitty-gritty detail for the GSM discussion in this chapter, now we want to take a step back so we can direct your attention to some of the more interesting architectural issues that crop up with IMS systems. Rather than reviewing each individual IMS subsystem in detail, we’ll focus on some of the differences between an IMS system and a GSM system.
One of the principal differences between a true IMS system and a GSM deployment is the method by which devices access IMS services. Unlike GSM, which uses a combination of special radios and cellular towers, IMS limits itself strictly to IP-based communication. That’s right; IMS doesn’t really care how you get to it, as long as you understand Session Initiation Protocol (SIP) and a few IMS-idioms. Therefore, just about any Internet-connected device could potentially leverage an IMS deployment for media services; we figure the phone companies already recognize this and have a secret plan to conquer the world with converged service. But we digress. IMS also doesn’t truly care what type of device you’re using; in fact, session setup and initiation is generally handled by individual applications, and each of those applications is expected to know, understand, and honor the limitations of the devices that connect to it.
Every day, all of this technology works quietly behind the scenes for billions of people. The next time you send a text or answer a phone call, we hope you’ll appreciate the complexity and orchestration that goes into making your phone work. As security professionals, we understand intuitively that complex systems often have simple failure modes. As you progress through this book, we hope you’ll see that the mobile environment is truly a jungle—with different radio protocols, channels, mobile network operators, handsets, operating systems, software, and users. The cellular network has become an indispensible and very intimate underpinning of modern society, and we must take measures to protect and secure it whenever possible.
In this chapter, you learned that
• Phones automatically join any available cellular network advertising itself as a compatible mobile network, which is defined by some very simple (and easily spoofable) data elements.
• Cellular network spoofing has evolved over the last dozen or so years from very expensive and complex to simple and cheap. Commercially available femtocell units for under $100 can be modified to trick any in-range phone into joining its network, effectively compromising all communications to and from the mobile device.
• Mobile networks are moving to all-IP protocols, which will expose them to many of the security hijinks that affected the Internet over the last two decades. The silver lining is that we’ve (hopefully) learned from these experiences and are better prepared to get things right this time.
Despite all these shortcomings, you can rest easy: none of it’s under your control anyway, unless you’re one of the major mobile network operators. Let’s hope they’re reading and taking notes.
1 See gsmamobileeconomy.com/GSMA%20Mobile%20Economy%202013.pdf.
2 The paper hacked into the voicemails of a 13-year-old girl who was killed.