Traffic Interception and Remote Mobile Phone
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
DePerry, Doug
Ritter, Tom
I have a box on my desk that your CDMA cell phone will automatically connect to while you send and receive phone calls, text messages, emails, and browse the Internet. I own this box. I watch all the traffic that crosses it and you don't even know you're connected to me. Welcome to the New World, where I, not them, own the towers. Oh, and thanks for giving me the box... for free. This box is a femtocell, a low-power cellular base station given or sold to subscribers by mobile network operators. It works just like a small cell tower, using a home Internet connection to interface with the provider network. When in range, a mobile phone will connect to a femtocell as if it were a standard cell tower and send all its traffic through it without any indication to the user. The state-of-the-art authentication protecting cell phone networks can be an imposing target. However, with the rising popularity of femtocells there is more than one way to attack a cellular network. Inside, they run Linux, and they can be hacked. During this talk, we will demonstrate how we've used a femtocell for traffic interception of voice/SMS/data, active network attacks and explain how we were able to clone a mobile device without physical access. Doug DePerry is a Senior Security Consultant at iSEC Partners in New York City. In addition to his day-to-day consultant duties, Doug is also responsible for helping manage employee/new hire training as well as the summer intern program. At iSEC Doug has recently taken a deeper interest in iOS and crypto assessments as well as architecture reviews and embedded systems. He has also written a whitepaper on HTML5 titled, 'HTML5 Security:The Modern Web Browser Perspective'. Prior to joining iSEC, Doug worked for various defense contractors and the US Army. Tom Ritter is a Senior Security Consultant at iSEC Partners, a frequenter of @nysecsec, and has far more ideas than time. He is interested in nearly all aspects of cryptography, privacy, anonymity, and pseudonymity; security; and traveling. He is located corporeally in New York City, virtually at, and meta- physically has been lost for quite some time.
 We're going to be talking about femto cells. A femto cell is a low cost, low power, consumer product designed to increase cellular signal coverage. It's basically a mini cell tower. It's also a Linux box. If you hack it, you can intercept the phone calls, text messages and web surfing of nearly anyone within range. We're not going to talk about prism or Snowden or any other political stuff. This presentation is going to focus on technical facts. Mostly technical facts. There's been many conversations over the last few days and after lengthy discussions, Verizon has asked us to include these bullets. And moving on. Before we go too much further, quick note on handset pairing. Your phone will associate to a femto cell automatically and without your knowledge. It's not like joining a Wi-Fi network. You don't have a choice. In fact, there may be some members of the audience connected to our network right now. Those signs out front are not just for show. You might want to put your phone in airplane mode. And one more thing. This research has everything to do with the tower and very little to do with the actual phone. We don't break or alter anything on your phone at least not yet. We also want to clearly state before we go too much further that the vendor has addressed the vulnerabilities that we used to get root on the device. We originally disclosed to the vendor just about eight months ago and they worked very quickly over Christmas to release a patch. It bears mentioning that the security issues will be discussing applied to more than just one carrier. And as you all know, nothing is 100% secure and we do have some architectural concerns related to femto cells. And this should come as no surprise to you but we're not the first people to have these concerns. As you can see, researchers have been popping femto cells since at least 2010. The latest example was here in Las Vegas at Black Hat in 2011 where a group of hackers on the crap out of a femto cell from a French carrier. Prior to them, the hackers' choice picked on a Vodafone box. We also want to mention that RSAXVC and Doug Kelly and their tear down hacking of the same model femto cell was very helpful to us during our earlier testing. As it turns out, someone looked at these things and didn't immediately think let's use this for evil. A team from LNG security will be presenting a talk using the same model femto cell as a cellular IDS. And I believe that happens tomorrow. So we're going to cover some similar topics but on a carrier that affects one in three Americans. To the best of our knowledge, no one has publicly presented an attack on a femto cell on a North American CDMA carrier. If you haven't figured it out yet, we're talking about Verizon. By the numbers, we're talking roughly 300 million people in the U.S. and roughly 100 million Verizon subscribers. I'm really not that good at math but if my calculations are correct, that's about a third of the country. We will hopefully demonstrate how we can record and listen to phone calls, text messages, picture messages and data. We perform active man in the middle attacks on data connections as well as SSL stripping. If that weren't enough, we throw in some cloning fraud for good measure. So to break it down further, we will discuss how we obtained access to the femto cell, what we did once we got on it, the custom code we wrote to get the traffic we wanted and our thoughts on how to fix these things. For those of you that may not be familiar with the femto cell architecture, here's a high level diagram. Your phone connects to the femto cell over cellular radio. In this case, it happens to be CDMA. The femto cell then uses a broadband internet connection to create an IP secton back to the carrier's internal network. Verizon currently has two models of consumer grade femto cells, the SCS26UC4 and the SCS2U01. The UC4 was released in early 2009 and only supports three simultaneous users at 1X speeds. The 2U01 was released in late 2010 and supports six simultaneous users at 3G speeds. We were able to route both of these devices, but we created most of our proof of concept code on the 2U01 because it's newer, faster and better looking. As we were doing some high level due diligence, we discovered that sprint has a femto cell too. As it turns out, both Verizon models and one sprint model are made by the same manufacturer, Samsung. We really didn't have that much time to do a ton of testing on the sprint model, but the one on the left is very similar to the UC4 and is vulnerable to similar attacks. However, we are told that sprint is end of life in this model of femto cell next month and replacing it with a newer model. We took a quick look at this newer model and we can say it's not vulnerable to the exact same attacks. So let's talk about the femto cell we spent most of our time on. The 2U01 has an ARM processor, one NAND flash memory and a Lattice FPGA, which we assume is for a digital signal processor. Externally, it's got a GPS antenna, a CDMA antenna, as well as Ethernet and HDMI ports. I know what you're thinking. Did he just say HDMI port? Yes, I did. It's a little tough to make out in this picture, but on the bottom of this device hidden under a rubber plug is an HDMI port. So we knew it could possibly be used for video, so we figured it has to be a console port and we were right. Why is it HDMI? We don't really know, but I do know that Samsung makes a crap load of TVs. So how does one connect to an HDMI console port? Well, you cut an HDMI cable in half, you stick it on a USB FTDI cable and you use a company branded pen to protect the connection because you're really not that good at soldering. We really have to thank RSAXVC and Doug Kelly for figuring this one out. One more thing, I'd like to talk briefly about the range of this thing since it's a question we get quite a lot. The device documentation states that a phone must be within 15 feet to register to the femtocell and must stay within approximately 40 feet to stay connected, but in reality it depends. Your phone will connect to the tower that's got the strongest signal, so if you're in an area with very good cell coverage, the real towers tend to drown out this small base station. We think there's some tweak and that can be done in the software to boost the signal, but probably the easiest thing to do is just buy a big-ass amplified antenna. Of course, if you're in an area where you actually need something like this, then we imagine the capture range would probably be pretty good. We did purchase an aftermarket directional antenna, mostly because we want to minimize the number of phones that we capture and this antenna creates a nice tight cone. All right, so I wasn't entirely truthful. One last mention of the older model femtocell. On the UC4, you can get root by interrupting the boot process. That was patched a while ago and is fixed in the 2U01, so we had to find our own way in. On the newer model, we found that we could abort the boot process using the magic sysret key, which drops you to a prompt where you can log in as root. Because we're interrupting the boot process before the device is fully functional, we then had to manually run some startup scripts. Once at the proper run level, the device will start custom UB cell binaries and connect the device to the carrier's network. And as we mentioned, these techniques will no longer get you root on a patched device, but they're pretty handy and could probably come in, will probably be very useful when testing other embedded devices. So, now that we've established a presence on a mini cell tower, let's poke around this device and see what we can see. The 2U01 runs a customized version of Monovista Linux 5, kernel version 2.6.18. It includes a very stripped-down Linux system, a few device divers, and proprietary software to control its operation as a base station. It also includes Authentic's QuickSec VPN client, which is packaged as a kernel module. And I'll get more into that later. So, this is great. We're root, but it's a pretty bare-bones Linux system, and there's not too many helpful commands available. There's no text editor. If you started a long-running command, you can't control C to kill it, stuff like that. It's very annoying. So, said, it's a little unwieldy, but we can use it to edit SSHD config to allow interactive password root login. So, we did that. We flushed IP tables, and it made things much easier to work with. So, great. We can SSH in, but we still have to run the said command on every boot because the file system is pulled fresh every time you power cycle. So, we figured we could edit and reflash the firmware, but we really didn't want to run the risk of creating a doorstop. So, we continued looking around, and eventually we noticed a persistent file system location. Things are starting to get a little more interesting, right? We found a persistent place to store files, but that doesn't necessarily give us persistent root access, right? So, we just catted all the things and spent a lot of time in slash Etsy, and we finally came across a script that appears to control some kind of debug mode. And for the record, that's not our typo in the echo statement. So, I want to make that clear. We created a file named dot UBRC, put it in the mount own end directory, and we're rewarded with a typo in the boot output. It worked. More importantly, since this dot UBRC file gets executed on startup, we can put our own commands in there, and they'll be executed by root every time the unit boots. So, it's an incredible time saver. We use it to patch SSHD, flush IP tables, and then drop us in a root shell automatically. So, we overcame the next hurdle. We now have persistent root access, so let's get some packets and do some eavesdropping. Should be easy, right? We'll just run TCP dump on the tunnel interface and nothing. All we see are encrypted IP packets everywhere. What the hell? So, it turns out that QuickSec is implemented as a net filter kernel module. It steals the packets before they ever hit a regular network interface, does encryption decryption, and sends the traffic so you can't see anything good using a normal packet capture utility like TCP dump. So, seems like the fun is over. Now what? Well, luckily, it's all just engineering, and with that, I'll turn it over to Tom. That's a pretty good representation of how the programming worked on this project. So, setting up the cross compilation environment for this was a real pain in the neck, but it's not a good look. So, it's a good look. So, it's a good look. So, it's a good look. So, setting up the cross compilation environment for this was a real pain in the neck, but that's why we have interns. Sorry, Andrew. We were finally able to find the right version of the Montevista Linux tool chain, and then we could compile our code against that to make binaries and kernel modules that would run on the FEMTO cell. So, we figured out that we needed to write our kernel module and insert it in such a way, we'd be able to copy the packets before they were encrypted going out and after they were decrypted on the way in. Took a little trial and error, but with that module loaded, we can pass the packets out to userland for logging to a P-CAP. So, with that hurdle over, we can go after the fun stuff. So, we've got some plain text packets, but it's a mess. Wireshark doesn't really parse much that helps us, and the ports shown are completely foreign. We can surmise that a phone call generates lots of small UDP packets as any protocol will do, but who's talking to who and where's the audio? We can tell Wireshark to interpret the data as RTP, which gets us a small step closer, but as you can see circled here, the RTP payload type is in the dynamic range, and according to the spec, dynamic is code for do whatever you want and don't expect to interoperate with anybody. So, we had to try and figure out what type of codec we were dealing with, which we did by downloading every single RFC and grepping through them en masse for codecs whose frame sizes matched what we saw. And we eventually found one we thought it might be, EVRC. Now, EVRC is one of those random cellular codecs that no media player implements, so we couldn't just pop it into VLC. So, what do you do when you can't figure something out and you've hit a dead end? You go to Stack Overflow. But this had already been asked and received no answers. So, here's the real secret of productive hackers. It's not asking questions on Stack Overflow, it's bountying questions on Stack Overflow. So, what we got was a link to the actual reference implementation of EVRC that was published by the 3GPP2 multi-carrier working group thingy. And it took some endian and bite fiddling, but after passing it through the reference implementation and the Linux utility socks, we were able to get some audio out of it. And with that, let's hopefully go for the live voice demo. So, Doug is placing a call on a phone that is associated to the FemtoSol. And hopefully Andrew's phone will ring in just a moment. Hello? Hey, Andrew, do you hear about that new phishing scheme? It's off the hook. Talk to you later, Doug. All right, so the call is complete. So, I need to switch over, actually. Okay, so Andrew is going to pull it off of the FemtoSol and pass it through the... Boy, I hope this works. So, that was before the call was placed. Did you know your mic was active then? Now it's ringing. Hello? Hey, Andrew, do you hear about that new phishing scheme? It's off the hook. Talk to you later, Doug. And there's live voice interception. And this was the backup video. So, for SMS, it took us a while to figure out SMS also, but we'll spare you the gory details this time. The text message itself is encoded in seven-bit blocks, so it's a bit of a pain, but we can get the data out. And in fact, we made a wire shark disector, but that's not nearly as interesting as doing another live demo. So, let's try for that. So, we should be displaying a couple of text messages that we've asked people to send us. Is that them right there? Okay, so they've already gone through at the bottom, so they just kind of popped right up. Can we get another couple sent real quick? There are a lot of encoding formats for SMS, and we don't parse all of them. Okay, there's a couple more. All right, so that's SMS. All right, so we've got voice calls in SMS, but we live in the smartphone era, so let's see some actual data. And thankfully, it was plain text. So much easier. Everything is parsed and displayed in wire shark. There are some layers and tunnels that encapsulate the data they'll talk about in a sec, but overall, it looks like pretty much any other LAN capture. So, with passive interception, we can pick up your MMS. You did know that didn't go over SSL, right? So, we took a photo of the audience and sent it because it takes a little bit for MMS to go out in DefCon, and we will show it to you right now. And there you all are. Okay, so we can view all the plain text. Passive interception is done and working. Let's do some active attacks. And the easiest thing to do with data is to drop it on the floor. Now, there's a lot of debate about how iMessage works, just how secure it is. But what's certain is that it uses SSL to talk home to Apple. So, we can't see those messages with passive interception. But if you block the SSL connection back home to Apple, iMessage fails over to SMS. And SMS is plain text, and we can see that just fine. Okay, so it is plain text, but it's encapsulated all up and down. And we can see that just fine. Okay, so it is plain text, but it's encapsulated all up and down. If we're lucky, it's a fairly nice encapsulation that Wireshark will handle for us. If we're unlucky, the normal IP, TCP and HTTP that you're used to gets encoded and then split across GRE packets. And this is what it looks like when you're unlucky. In the lower right, you can see some normal HTTP. The bytes in front of that are the IP and TCP headers. But that's actually the data section of the upper left-hand inset. And then if you can read the Wireshark part, there's these PPP fragments. That's the IP fragment split across multiple GRE frames. So, our goal is to edit a web page in the simplest way possible. And changing anything in HTTP means changing the TCP checksum. And since we're encapsulated in PPP, changing anything also means changing the PPP checksum. TCP checksum is at the beginning, PPP checksum is at the end, and the frames might be out of order. So it's going to be a little tricky. The first thing we tried doing was doing it in line in the kernel. Really quickly, we figured out that the carrier has a transparent proxy on all your web browsing on your phone. Let me repeat that. Verizon has a transparent proxy on all the web browsing on your phone. It's kind of creepy doing this without your knowledge, but frankly, we weren't really surprised. One of the things that they do with this transparent proxy is apply HTTP compression to anything that doesn't already have it, which makes sense because HTTP compression does actually speed things up. We didn't detect any SSL man in the middleing or JavaScript injection. And I don't think that Verizon is alone or the only carrier doing this, but nonetheless, it's there and from a technical standpoint, we had to work around it. We tried disabling the compression, but no dice. So we tried doing DNS hijacking, but the transparent proxy ignores the IP address that you actually try and talk to and does their own DNS look up on the host header. So then we tried something crazy, and this got us pretty close. We did the DNS hijacking, and in the kernel, we rewrote the traffic from port 80 to port 81 so that the carrier wouldn't proxy it. Our server listens on port 81 and responds back, and then on the inbound, the kernel module rewrites it back to 80. And this worked most of the time. The problem was there were a couple of corner cases and on hundreds or thousands of packets for a web page load, that's enough to sync it. So what ended up working was doing all of that except the server that listens on port 81 will redirect the browser to port 8080, which the carrier also doesn't proxy. So in the end, what ends up happening is you open a website, say CNN.com. We DNS hijacked you. You try to talk to our server on port 80, but the femtocell kernel module rewrites your connection to our server on port 81 to bypass the proxy. We listen on 81, respond, and the kernel rewrites it back to port 80. Now, our response actually redirects you to CNN.com on port 8080, which you don't notice because mobile UI sucks. So then you talk to our server on port 8080 directly, bypassing the proxy with no port rewriting. And then we command in the middle the user pretty effectively. We strip off SSL, pass along the cookies. It's a little bit slow, but cellular is a little bit slow. So because it is a little bit slow, we're going to show a video of this one. Okay, so in the bottom right-hand corner, we are typing in a bank, wellsfargo.com. In the lower left-hand corner, you can see the resource loads. So a couple from Google, and then we'll see the wellsfargo resources. In the upper left-hand is where the username and password will show up. So there's wellsfargo, and we're going to click on sign in. And then we will type the username character by painful character. And then the password. And there is the username and password in the upper left. All right, so that is data middling. And with that, I'll turn it back over to Doug. So this is all really cool, and we were very excited about it. But these things are mini cell towers. So it's got to be possible to do more with them, right? So if there's anything cooler than intercepting and modifying phone calls and text messages, it's becoming the person holding the phone. For those of you familiar with GSM terms like IMEI or IMC, CDMA has their own slightly different identifiers that serve the same purpose. The key difference here is that SIM cards aren't typically used in U.S. CDMA networks, so instead of an IMC, the MIN is just a 10-digit phone number. This is sometimes the same as your actual phone number, but not always because of porting numbers between carriers. This is an important distinction, because we discovered that most, but not all, of the communication between the handset and the carrier uses the ESN and MIN for identification. And unfortunately, there's not really any obvious correlation between the MIN and the actual phone number. The ESN is an analog of the IMEI. It was previously used as a unique number, but carriers ran out officially in 2010. ESNs have since been superseded by MEIDs. Pseudo ESNs are always prefixed with the 8-0. The remaining bytes are the 24 least significant bits of the Shaohuan hash of the handset's MEID. Pseudo ESNs are not guaranteed to be unique since the MEID is the unique identifier for those handsets that have one. Older model phones use the ESN to identify themselves to the network. Newer phones use the MEID, but still retain a pseudo ESN since it is required for compatibility reasons. So to clone a phone, all you have to do is grab somebody's phone, write down the ESN or MEID in their phone number, then copy these numbers to another handset to get a valid clone. Well, years ago, this used to be all it took. Since the MIN was usually the same as the phone number and the ESN was printed on any given device, it was trivial for an attacker to get these values and use someone else's expensive wireless minutes to make calls. So Qualcomm and the CDMA carriers had to come up with a solution. We won't get into a ton of detail, but the cave authentication mechanism makes it very difficult to successfully clone a CDMA phone. Additional keys are used in a challenge response protocol to authenticate the customer and the call. Manufacturers of CDMA devices are supposed to make these keys difficult to obtain so that a full clone is not possible. All that being said, let's see if our rogue Femto cell has any more secrets it wants to give up. Hint. As we mentioned earlier, the Femto cell acts like a typical cell tower, except with at least one key difference. The Femto cell only uses the ESN and MIN to authenticate handsets. We're not entirely sure why we really have no idea, but it may suggest a legacy CDMA implementation. But the real problem here is that we discovered that the Femto cell did not have cave enabled. It behaved like a legacy tower and just ignored those keys relying solely on the ESN and MIN for authentication. So cloning becomes extremely easy, just like the good old days. Note that the cloned phone will only work while connected to the Femto cell, but it can be any Femto cell, not necessarily one that's been modified. So we just need to somehow obtain the ESN and MIN of our victim and program those numbers into another handset. You're generally not supposed to be able to write the ESN, but some phone models do allow it. So it's just like the movies, right? We wait until our victim runs to the bathroom, you grab their phone, write down the ESN and MIN and clone the phone, right? But it's just so messy. We have to invite our victim out to eat. We have to wait until they go to the bathroom. We have to risk getting caught going through their phone. And what happens if they take their phone with them to the bathroom? And trying to play shit and spell or words with friends, whatever that game is. But listen, it's just not worth it. There's got to be an easier way to defraud my friends. So remember that time I told you that we can see every packet that goes through the Femto cell? Well, that includes handset registration packets that contain the ESN and MIN of the phone associated to the Femto cell. So all I have to do is capture packets on my rogue Femto cell, wait for an unsuspecting mobile phone to come within range. When the phone associates to the Femto cell, I catch the ESN and MIN without physical access to the phone and without any indication of the user. So picture is worth a thousand words, right? Here it is step by step. The victim phone comes within range of a malicious Femto cell and as the handset registers the carrier network, the ESN and MIN are captured and written to a separate target handset. The target handset can then be used as a perfect clone of the victim as long as it is associated to the Femto cell. It would be possible to capture phones in New York City using a rogue Femto cell and email the numbers to an accomplice in Seattle who is using a stock Femto cell. It's almost the perfect crime. While we were testing for cloning, we noticed our results were a little inconsistent. It wouldn't work too well if you were trying to use it as your personal cell phone. But if your aim was to make money through toll fraud, you could probably make enough money to buy a boat that has smaller boats inside of it. We suspect our problems may have something to do with a relative signal strength of neighboring cell towers as we saw slightly different results when testing in a urban environment as opposed to a more rural one. But the short answer is we just don't know. So we tested cloning with voice, SMS and data. Some of the results were expected and some were not. But probably the most interesting thing we saw was the not quite three way call. So I'm going to describe a few scenarios with the next few slides and the following definitions will be helpful. Our victim is the person with a shiny new iPhone whose phone that we want to clone. The target is the bad guy running this old crappy flip phone and that's been modified to act like a copy or clone of the victim phone. So the easiest scenario is if the victim's phone is turned off, jammed, otherwise not connected to any cell towers. Everything works as expected, there's no issues with service, you've got an exact working copy of the victim's phone for all intents and purposes. So when both phones are associated to the same femto cell, we noticed a few different things. Of course the clone phone, the target, must be associated to the femto cell in order to work properly. It is only possible to place outgoing calls one at a time. No matter which phone initiates the outgoing call, any subsequent call placed will force that call to drop. Doesn't matter which phone is which, either the victim or the target can cause each other to drop calls. We didn't notice any issues with outgoing text messages and for incoming SMS, the usual behavior seemed to be that both phones would get the text message. So with incoming calls, sometimes one of two behaviors is possible. The first is that only one of the two phones rings. It could be the victim or the target, it doesn't matter. Other times, both phones will ring at the same time. The phone that picks up the call first usually wins, which means it gets to stay on the call. But the coolest part is that sometimes if the two phones answered within a few seconds of each other, we got what we're calling a two and a half way call. So what would happen is both the target and the victim phones would connect and each would be able to hear the inbound caller, but not each other. So the eavesdropping scenario here is pretty clear. Bad guy can clone a phone and as soon as an incoming call comes in, picks up the call, mutes his mic and can hear everything said by the incoming caller. In our second scenario, the target is associated to the femto cell as required, but the victim is out and about connected to an actual cell tower. The phone that gets the incoming call appears to depend on which phone has had more recent communication with the carrier network, like a call or text message. We couldn't reproduce the two and a half way call since both phones never rang at the same time. SMS was pretty similar, we never got an SMS on both phones at the same time. So outgoing calls are a little more interesting. So let's say the target, the cloned phone, is on an active phone call. This works fine until our unsuspecting victim places an outgoing call to another party. The bad guy's call gets dropped and the call of our innocent victim is allowed to connect reliably. However, if the victim is on an active call, like pictured, and the target places an outgoing call, the call will connect and the call will connect allowing two independent phone calls. So these implications are clear as well. Why use your own minutes when you can use someone else's to call 1-900 numbers and run up a huge bill? Which is especially awesome if you're the one who owns the 1-900 number. So I said earlier we were going to talk about cloning data and here we are. It appears to be slightly more difficult to establish a data connection on a clone than it is to clone voice and text services. Data services on Verizon's network are required for MMS, account management features and internet connectivity. Long story short, the carrier network requires more numerical identifiers for data connection than for voice and SMS. We're not saying it's impossible, but it's just more difficult. We didn't really dig too deep into it. So we have a video to demonstrate a two and a half way call. Whoops. Maybe not. Okay. There we go. All right. So that's me making a phone call to a single number. Both phones are ringing. The victim phone is the one on the left and the target is the one on the right. We're going to fast forward obnoxiously. Both calls get answered. Both calls connect and stay connected. And now we're going to do some very sophisticated voice testing. Stand by. To prove that the two calls are connected. There it is. Just on inside secret to phone testers. It's very tactical. All handle that. All right. And so that's that. So we mentioned this at the beginning, but this issue was resolved by Verizon on the back end many months ago. Which is great because authentication should be checked on the internal network that the carriers control, not on the small box that they don't. And with that, I'll turn it back over to the code, Tom. Okay. So it would be easy to think that this is all about Verizon, but this is really about everybody. There are over 30 carriers worldwide who have femto cells and three of the four major U.S. carriers. And clearly there are issues here. So what's a multi-billion dollar multinational corporation to do? Well, you can harden the actual device, but as we all know, there's nothing you're going to be able to do on the platform to prevent people with physical access from breaking in. Root is always possible. We didn't have to do more sophisticated attacks, but obviously you shouldn't rule them out. There are lots of ways onto an embedded device and frankly we went in through the door. So what else can a vendor do? Well, you can force registration. Make the femto cell owner list the phones allowed to connect through their femto cell and then confirm with the phone owner that they're cool with allowing that. And if they try connecting through any other femto cell, don't let them. And do this whitelisting inside the carrier network, of course, not on the actual device. And this would make it a lot harder to take one of these down to Times Square or Las Vegas and just start gobbling up everyone around them. So device registration clearly reduces the attack service. Here's a breakdown of the major U.S. cell carriers and how they handle handset registration on their femto cells, at least according to their documentation. Besides T-Mobile who doesn't have a femto cell, AT&T is leading in this category because they require registration. The other carriers, Sprint and Verizon, do not. So phone registration does prevent the easiest attack, but it doesn't win us over completely. It doesn't prevent attacks where I isolate you from the carrier network. You'll still see four bars, send beacons with your MIN and ESN, try and make phone calls and send text messages. And even though I never deliver any of that up to the carrier, I'll still see them. I can track you and read your SMS. And we verify this experimentally. It's actually what we're doing right now. We isolate any phone that's not whitelisted so we don't receive inbound text messages or data sessions or actually see what you're sending because we whited out. With more engineering, it'd be possible to connect these phone calls to our phone line, spoof SMSes for you to receive, and even route the data traffic out the femto cell on the normal internet connection and let you browse the internet all without connecting to the carrier network. So the carrier never knows that you're attached. So device registration where the phone opts into using a femto cell and the femto cell opts into using a phone, it's a good minimum level security, but we don't think it's enough. Really what you should be doing is ditching them all together. You guys know that there will be bugs in everything, but that said, we like Wi-Fi calling. If the handset is on Wi-Fi, not even your own Wi-Fi, but untrusted Wi-Fi, and it IP sex or SSL tunnels into the carrier network, doing certificate pinning, and the phone is appropriately distrusted from a network perspective so you can't just go end mapping all their crap, we think you get a much stronger architecture. You have to do the same type of cell phone authentication you do with the tower to avoid theft of service, but that's no weaker than what we have here. And what you get is not needing femto cells, that's a win, being able to make calls on any random Wi-Fi, and that's a win, and those calls are encrypted against the Wi-Fi operator, which is a win and pretty necessary. So going even further, you can build in end-to-end encryption to protect the contents of the call against both untrusted Wi-Fi operators and the carrier. And as you all know, there are individual apps that do this, but they all require the recipient to have the same app. If Google and Apple and BlackBerry built this into their phones and carriers supported the model, we think there would be a huge increase in adoption. So I was just talking about this, but let's sum up and present a couple of other band-aids that you can try. Hardening the femto cells is due diligence, but ultimately a losing proposition. Requiring registration prevents untargeted attacks to some degree, but long-term we're pretty nervous about giving random people, like yourselves, small cell phone towers and just hoping you don't break into them. Now, can you tell if you're connected to a femto cell? We said in the beginning, no, but it had an asterisk. We noticed that some Android phones have an icon indicating they are connected to a femto cell. Now, this was only in phones that Verizon had modified. It's not in the Android source or any stock or flashed ROMs. An iPhone for the record has no visual indicator at all. There's a short beep at the beginning of phone calls, but it's really easy to notice and you have to make a phone call. But somehow these Android phones were detecting femto cells and showing an icon. So we reverse engineered that and then we're halfway done with our own app. The femto catcher. So we noticed that the network ID indicates if it's a femto cell. And although it's possible to lie about that, we didn't really investigate how hard it would be. So using this, we can write a tool to put a phone into airplane mode when it detects itself being connected to a femto cell. Now, to be clear, we're not marketing this widely or to your extended family. We're building this because we want it. We would rather not have service than be connected to one of these, especially at DEF CON. And we're going to be sharing it because we thought that you folks in this room might also want that option. And this is going to be available soon. We have a few kinks to work out. We have to thank Mira, a lot for doing all the work on this. So what else can you do proactively? Well, you can encrypt what you do on your phone and there are a multitude of free and paid apps to do so if you can convince your communication partner to use the same app. So what else can you do if you route this or another femto cell? And you are operating a small cell tower. Well, there's WAP. WAP is basically web browsing for flip phones. It uses custom protocols. It's heavily proxied. It does SSL, middling, whether they tell you that or not. I'm looking at you, Nokia. And you might think that WAP is dead, right? But it's actually used by a couple billion people in the developing world. And smartphone manufacturers and carriers are still developing and investing heavily in it. So we think it's a worthwhile research target. And of course there's that binary blob that has complete control over your entire phone that nobody's been able to inspect in any straightforward way, at least not that we can actually see the results of. You could totally fuzz the baseband with a femto cell and it probably let you get a little bit deeper into any carrier specific stuff that they're doing than just using a general software defined radio. And since the device makes a VPN into the carrier network, you can poke around inside of their network. You can look at attacking other femto cells from your femto cell or look at the carrier's network itself. And the talk from two years ago at Black Hat did this with fantastic results. They were actually able to wiretap not just their femto cell, but every single femto cell that was on the French carrier. And that's a little bit farther than we wanted to go without permission from the carrier. So we worked hard to wrap up a little bit early because we wanted to leave time for questions and hopefully another demo. But before questions, we have to thank a lot of people. Andrew is one of the interns who worked on that really painful cross compilation, but now is full-fledged member of ISEC and operating this demo and all the hard stuff. RSA, XBC, and Doug Kelly who helped us with a lot of the initial work. We use their research. Davis and Tim who also helped us when we got stuck. Mira, Michael, Peter, our CEO, Joel, really all of ISEC and of course last but not least our external and internal legal counsels. So I really have no idea if this is going to work, but we are going to try and do another demo. So if you want to send a text message that shows up on the screen, there is the number have at it. And I will take questions while that happens. How did we get around the GPS? So the device needs a GPS signal. Long, just a long GPS cable will work. So I'm going to try to get my hands on it. And I will take questions while it is working. Do the customer arms have the transparent proxy? It's a long GPS signal. So I'm going to try to get my hands on it. When we were testing, all phones were sent through the transparent proxy. It doesn't have to do with the ROM. The question was did we try flashing a phone to prefer femto cells? We are waiting for that. So the question was did we try flashing a ROM to prefer femto cells to wire tap people more easily? No, we did not. Custom PRL. We looked into it but we didn't get any success. Have you been inside a real cell tower and seen what possibly comes with it? Have we been inside a real cell tower and seen if any of this might apply to the real keys to it? So the device allows up to six. I don't think we have more than six. I'm sorry? Okay. You can have more passively associated but only six simultaneous voice calls. I forgot the two volunteers, please come up and see if your phones are associated and send some text messages. So the device allows up to six. I don't think we have more than six. I'm sorry? Okay. You can have more passively associated but only six simultaneous voice calls. I forgot the two volunteers, please come up and see if your phones are associated and send some text messages. Any other questions? Yes, you are standing up. You are going to have to shout, sorry. Would a sprint device also connect to our femto cell? We don't believe so. And yeah, if anyone has a sprint device. We don't believe so and really we just created our proof of concept code on Verizon. This is applicable to like most femto cells. How does Verizon deploy the patches? They push the patch down to the unit. It's auto updates itself. The question was the mics are active before you place a phone call. Is that the truth even if you are not connected to a femto cell? I don't know. The question was about 3G and 4G. In our testing, our experience was that if you have a 4G data connection, we won't see your data but we will see your SMS and your phone calls. Any, yes. Yes, it's the phone that is associated to the femto cell that we intercept, not the sender. We are just showing the text messages that are coming in. Try sending a text message. We will see an outgoing one. I'm sorry. I still can't hear you. We have an external antenna, a directional one. You could hook up more antennas, powered antennas. We didn't really try. We were trying to minimize the number of phones we were getting. The question was about the key for the IPsec tunnel. We did look at multiple devices. The key is not the same across them. We have not tried getting a MiFi device onto it. So have you ever known what the software process is for us? We have never known what the software process is. We did look at that a little bit. If there are no other questions, we will back up. Thank you very much.
 We're going to be talking about femto cells. A femto cell is a low cost, low power, consumer  product designed to increase cellular signal coverage. It's basically a mini cell tower.  It's also a Linux box. If you hack it, you can intercept the phone calls, text messages  and web surfing of nearly anyone within range. We're not going to talk about prism or Snowden  or any other political stuff. This presentation is going to focus on technical facts. Mostly  technical facts. There's been many conversations over the last few days and after lengthy  discussions, Verizon has asked us to include these bullets. And moving on. Before we go  too much further, quick note on handset pairing. Your phone will associate to a femto cell  automatically and without your knowledge. It's not like joining a Wi-Fi network. You don't  have a choice. In fact, there may be some members of the audience connected to our network  right now. Those signs out front are not just for show. You might want to put your phone  in airplane mode. And one more thing. This research has everything to do with the tower  and very little to do with the actual phone. We don't break or alter anything on your phone  at least not yet. We also want to clearly state before we go too much further that the  vendor has addressed the vulnerabilities that we used to get root on the device. We originally  disclosed to the vendor just about eight months ago and they worked very quickly over  Christmas to release a patch. It bears mentioning that the security issues will be discussing  applied to more than just one carrier. And as you all know, nothing is 100% secure and  we do have some architectural concerns related to femto cells. And this should come as no  surprise to you but we're not the first people to have these concerns. As you can see, researchers  have been popping femto cells since at least 2010. The latest example was here in Las Vegas  at Black Hat in 2011 where a group of hackers on the crap out of a femto cell from a French  carrier. Prior to them, the hackers' choice picked on a Vodafone box. We also want to  mention that RSAXVC and Doug Kelly and their tear down hacking of the same model femto  cell was very helpful to us during our earlier testing. As it turns out, someone looked at  these things and didn't immediately think let's use this for evil. A team from LNG security  will be presenting a talk using the same model femto cell as a cellular IDS. And I believe  that happens tomorrow. So we're going to cover some similar topics but on a carrier that  affects one in three Americans. To the best of our knowledge, no one has publicly presented  an attack on a femto cell on a North American CDMA carrier. If you haven't figured it out  yet, we're talking about Verizon. By the numbers, we're talking roughly 300 million people in  the U.S. and roughly 100 million Verizon subscribers. I'm really not that good at math but if my  calculations are correct, that's about a third of the country. We will hopefully demonstrate  how we can record and listen to phone calls, text messages, picture messages and data. We  perform active man in the middle attacks on data connections as well as SSL stripping. If that  weren't enough, we throw in some cloning fraud for good measure. So to break it down further,  we will discuss how we obtained access to the femto cell, what we did once we got on it, the  custom code we wrote to get the traffic we wanted and our thoughts on how to fix these things.  For those of you that may not be familiar with the femto cell architecture, here's a high level  diagram. Your phone connects to the femto cell over cellular radio. In this case, it happens to  be CDMA. The femto cell then uses a broadband internet connection to create an IP secton back to  the carrier's internal network. Verizon currently has two models of consumer grade femto cells,  the SCS26UC4 and the SCS2U01. The UC4 was released in early 2009 and only supports three  simultaneous users at 1X speeds. The 2U01 was released in late 2010 and supports six  simultaneous users at 3G speeds. We were able to route both of these devices, but we created most  of our proof of concept code on the 2U01 because it's newer, faster and better looking. As we were  doing some high level due diligence, we discovered that sprint has a femto cell too. As it turns  out, both Verizon models and one sprint model are made by the same manufacturer, Samsung. We really  didn't have that much time to do a ton of testing on the sprint model, but the one on the left is  very similar to the UC4 and is vulnerable to similar attacks. However, we are told that sprint is  end of life in this model of femto cell next month and replacing it with a newer model. We took a  quick look at this newer model and we can say it's not vulnerable to the exact same attacks.  So let's talk about the femto cell we spent most of our time on. The 2U01 has an ARM processor,  one NAND flash memory and a Lattice FPGA, which we assume is for a digital signal processor.  Externally, it's got a GPS antenna, a CDMA antenna, as well as Ethernet and HDMI ports. I  know what you're thinking. Did he just say HDMI port? Yes, I did. It's a little tough to make  out in this picture, but on the bottom of this device hidden under a rubber plug is an HDMI  port. So we knew it could possibly be used for video, so we figured it has to be a console  port and we were right. Why is it HDMI? We don't really know, but I do know that Samsung makes a  crap load of TVs. So how does one connect to an HDMI console port? Well, you cut an HDMI cable in  half, you stick it on a USB FTDI cable and you use a company branded pen to protect the  connection because you're really not that good at soldering. We really have to thank RSAXVC  and Doug Kelly for figuring this one out. One more thing, I'd like to talk briefly about the  range of this thing since it's a question we get quite a lot. The device documentation states  that a phone must be within 15 feet to register to the femtocell and must stay within  approximately 40 feet to stay connected, but in reality it depends. Your phone will connect to  the tower that's got the strongest signal, so if you're in an area with very good cell  coverage, the real towers tend to drown out this small base station. We think there's some  tweak and that can be done in the software to boost the signal, but probably the easiest thing  to do is just buy a big-ass amplified antenna. Of course, if you're in an area where you  actually need something like this, then we imagine the capture range would probably be  pretty good. We did purchase an aftermarket directional antenna, mostly because we want to  minimize the number of phones that we capture and this antenna creates a nice tight cone.  All right, so I wasn't entirely truthful. One last mention of the older model femtocell. On  the UC4, you can get root by interrupting the boot process. That was patched a while ago and  is fixed in the 2U01, so we had to find our own way in. On the newer model, we found that we  could abort the boot process using the magic sysret key, which drops you to a prompt where you  can log in as root. Because we're interrupting the boot process before the device is fully  functional, we then had to manually run some startup scripts. Once at the proper run level,  the device will start custom UB cell binaries and connect the device to the carrier's network.  And as we mentioned, these techniques will no longer get you root on a patched device, but  they're pretty handy and could probably come in, will probably be very useful when testing  other embedded devices. So, now that we've established a presence on a mini cell tower,  let's poke around this device and see what we can see. The 2U01 runs a customized version of  Monovista Linux 5, kernel version 2.6.18. It includes a very stripped-down Linux system, a  few device divers, and proprietary software to control its operation as a base station. It  also includes Authentic's QuickSec VPN client, which is packaged as a kernel module. And I'll  get more into that later. So, this is great. We're root, but it's a pretty bare-bones Linux  system, and there's not too many helpful commands available. There's no text editor. If you  started a long-running command, you can't control C to kill it, stuff like that. It's very  annoying. So, said, it's a little unwieldy, but we can use it to edit SSHD config to allow  interactive password root login. So, we did that. We flushed IP tables, and it made things much  easier to work with. So, great. We can SSH in, but we still have to run the said command on  every boot because the file system is pulled fresh every time you power cycle. So, we figured  we could edit and reflash the firmware, but we really didn't want to run the risk of creating  a doorstop. So, we continued looking around, and eventually we noticed a persistent file system  location. Things are starting to get a little more interesting, right? We found a persistent  place to store files, but that doesn't necessarily give us persistent root access, right? So, we  just catted all the things and spent a lot of time in slash Etsy, and we finally came across a  script that appears to control some kind of debug mode. And for the record, that's not our  typo in the echo statement. So, I want to make that clear. We created a file named dot UBRC, put  it in the mount own end directory, and we're rewarded with a typo in the boot output. It worked.  More importantly, since this dot UBRC file gets executed on startup, we can put our own  commands in there, and they'll be executed by root every time the unit boots. So, it's an  incredible time saver. We use it to patch SSHD, flush IP tables, and then drop us in a root  shell automatically. So, we overcame the next hurdle. We now have persistent root access, so  let's get some packets and do some eavesdropping. Should be easy, right? We'll just run TCP dump  on the tunnel interface and nothing. All we see are encrypted IP packets everywhere. What the  hell? So, it turns out that QuickSec is implemented as a net filter kernel module. It steals the  packets before they ever hit a regular network interface, does encryption decryption, and sends  the traffic so you can't see anything good using a normal packet capture utility like TCP dump.  So, seems like the fun is over. Now what? Well, luckily, it's all just engineering, and with  that, I'll turn it over to Tom. That's a pretty good representation of how the programming  worked on this project. So, setting up the cross compilation environment for this was a real  pain in the neck, but it's not a good look. So, it's a good look. So, it's a good look. So, it's a  good look. So, setting up the cross compilation environment for this was a real pain in the  neck, but that's why we have interns. Sorry, Andrew. We were finally able to find the right  version of the Montevista Linux tool chain, and then we could compile our code against that to  make binaries and kernel modules that would run on the FEMTO cell. So, we figured out that we  needed to write our kernel module and insert it in such a way, we'd be able to copy the packets  before they were encrypted going out and after they were decrypted on the way in. Took a little  trial and error, but with that module loaded, we can pass the packets out to userland for  logging to a P-CAP. So, with that hurdle over, we can go after the fun stuff. So, we've got some  plain text packets, but it's a mess. Wireshark doesn't really parse much that helps us, and the  ports shown are completely foreign. We can surmise that a phone call generates lots of small UDP  packets as any protocol will do, but who's talking to who and where's the audio? We can tell  Wireshark to interpret the data as RTP, which gets us a small step closer, but as you can see  circled here, the RTP payload type is in the dynamic range, and according to the spec, dynamic is  code for do whatever you want and don't expect to interoperate with anybody. So, we had to try  and figure out what type of codec we were dealing with, which we did by downloading every single  RFC and grepping through them en masse for codecs whose frame sizes matched what we saw. And we  eventually found one we thought it might be, EVRC. Now, EVRC is one of those random cellular  codecs that no media player implements, so we couldn't just pop it into VLC. So, what do you do  when you can't figure something out and you've hit a dead end? You go to Stack Overflow.  But this had already been asked and received no answers. So, here's the real secret of productive  hackers. It's not asking questions on Stack Overflow, it's bountying questions on Stack  Overflow. So, what we got was a link to the actual reference implementation of EVRC that was  published by the 3GPP2 multi-carrier working group thingy. And it took some endian and bite  fiddling, but after passing it through the reference implementation and the Linux utility  socks, we were able to get some audio out of it. And with that, let's hopefully go for the live  voice demo. So, Doug is placing a call on a phone that is associated to the FemtoSol. And  hopefully Andrew's phone will ring in just a moment.  Hello?  Hey, Andrew, do you hear about that new phishing scheme? It's off the hook.  Talk to you later, Doug.  All right, so the call is complete. So, I need to switch over, actually. Okay, so Andrew is going to  pull it off of the FemtoSol and pass it through the...  Boy, I hope this works.  So, that was before the call was placed. Did you know your mic was active then?  Now it's ringing.  Hello? Hey, Andrew, do you hear about that new phishing scheme? It's off the hook.  Talk to you later, Doug.  And there's live voice interception.  And this was the backup video.  So, for SMS, it took us a while to figure out SMS also, but we'll spare you the gory details  this time. The text message itself is encoded in seven-bit blocks, so it's a bit of a pain, but we  can get the data out. And in fact, we made a wire shark disector, but that's not nearly as  interesting as doing another live demo. So, let's try for that.  So, we should be displaying a couple of text messages that we've asked people to send us.  Is that them right there?  Okay, so they've already gone through at the bottom, so they just kind of popped right up.  Can we get another couple sent real quick?  There are a lot of encoding formats for SMS, and we don't parse all of them.  Okay, there's a couple more.  All right, so that's SMS.  All right, so we've got voice calls in SMS, but we live in the smartphone era, so let's see some  actual data. And thankfully, it was plain text. So much easier.  Everything is parsed and displayed in wire shark. There are some layers and tunnels that  encapsulate the data they'll talk about in a sec, but overall, it looks like pretty much any other  LAN capture. So, with passive interception, we can pick up your MMS.  You did know that didn't go over SSL, right?  So, we took a photo of the audience and sent it because it takes a little bit for MMS to go out  in DefCon, and we will show it to you right now. And there you all are.  Okay, so we can view all the plain text. Passive interception is done and working.  Let's do some active attacks. And the easiest thing to do with data is to drop it on the floor.  Now, there's a lot of debate about how iMessage works, just how secure it is.  But what's certain is that it uses SSL to talk home to Apple. So, we can't see those messages with passive interception.  But if you block the SSL connection back home to Apple, iMessage fails over to SMS. And SMS is plain text,  and we can see that just fine. Okay, so it is plain text, but it's encapsulated all up and down.  And we can see that just fine. Okay, so it is plain text, but it's encapsulated all up and down.  If we're lucky, it's a fairly nice encapsulation that Wireshark will handle for us. If we're unlucky,  the normal IP, TCP and HTTP that you're used to gets encoded and then split across GRE packets.  And this is what it looks like when you're unlucky. In the lower right, you can see some normal HTTP.  The bytes in front of that are the IP and TCP headers. But that's actually the data section of the  upper left-hand inset. And then if you can read the Wireshark part, there's these PPP fragments.  That's the IP fragment split across multiple GRE frames. So, our goal is to edit a web page in the  simplest way possible. And changing anything in HTTP means changing the TCP checksum. And since  we're encapsulated in PPP, changing anything also means changing the PPP checksum. TCP checksum is at  the beginning, PPP checksum is at the end, and the frames might be out of order. So it's going to be a  little tricky. The first thing we tried doing was doing it in line in the kernel. Really quickly,  we figured out that the carrier has a transparent proxy on all your web browsing on your phone. Let  me repeat that. Verizon has a transparent proxy on all the web browsing on your phone. It's kind of  creepy doing this without your knowledge, but frankly, we weren't really surprised. One of the  things that they do with this transparent proxy is apply HTTP compression to anything that doesn't  already have it, which makes sense because HTTP compression does actually speed things up. We  didn't detect any SSL man in the middleing or JavaScript injection. And I don't think that Verizon is  alone or the only carrier doing this, but nonetheless, it's there and from a technical  standpoint, we had to work around it. We tried disabling the compression, but no dice. So we  tried doing DNS hijacking, but the transparent proxy ignores the IP address that you actually try  and talk to and does their own DNS look up on the host header. So then we tried something  crazy, and this got us pretty close. We did the DNS hijacking, and in the kernel, we rewrote the  traffic from port 80 to port 81 so that the carrier wouldn't proxy it. Our server listens on  port 81 and responds back, and then on the inbound, the kernel module rewrites it back to 80. And  this worked most of the time. The problem was there were a couple of corner cases and on  hundreds or thousands of packets for a web page load, that's enough to sync it. So what ended  up working was doing all of that except the server that listens on port 81 will redirect the  browser to port 8080, which the carrier also doesn't proxy. So in the end, what ends up  happening is you open a website, say CNN.com. We DNS hijacked you. You try to talk to our  server on port 80, but the femtocell kernel module rewrites your connection to our server on  port 81 to bypass the proxy. We listen on 81, respond, and the kernel rewrites it back to  port 80. Now, our response actually redirects you to CNN.com on port 8080, which you don't  notice because mobile UI sucks. So then you talk to our server on port 8080 directly, bypassing  the proxy with no port rewriting. And then we command in the middle the user pretty effectively.  We strip off SSL, pass along the cookies. It's a little bit slow, but cellular is a little  bit slow. So because it is a little bit slow, we're going to show a video of this one.  Okay, so in the bottom right-hand corner, we are typing in a bank, wellsfargo.com. In the  lower left-hand corner, you can see the resource loads. So a couple from Google, and then we'll  see the wellsfargo resources. In the upper left-hand is where the username and password will  show up. So there's wellsfargo, and we're going to click on sign in. And then we will type the  username character by painful character. And then the password. And there is the username and  password in the upper left. All right, so that is data middling. And with that, I'll turn it back  over to Doug. So this is all really cool, and we were very excited about it. But these things are  mini cell towers. So it's got to be possible to do more with them, right? So if there's  anything cooler than intercepting and modifying phone calls and text messages, it's becoming the  person holding the phone. For those of you familiar with GSM terms like IMEI or IMC, CDMA has  their own slightly different identifiers that serve the same purpose. The key difference here is  that SIM cards aren't typically used in U.S. CDMA networks, so instead of an IMC, the MIN is just a  10-digit phone number. This is sometimes the same as your actual phone number, but not always  because of porting numbers between carriers. This is an important distinction, because we  discovered that most, but not all, of the communication between the handset and the carrier  uses the ESN and MIN for identification. And unfortunately, there's not really any obvious  correlation between the MIN and the actual phone number. The ESN is an analog of the IMEI. It was  previously used as a unique number, but carriers ran out officially in 2010. ESNs have since been  superseded by MEIDs. Pseudo ESNs are always prefixed with the 8-0. The remaining bytes are the 24 least  significant bits of the Shaohuan hash of the handset's MEID. Pseudo ESNs are not guaranteed to be  unique since the MEID is the unique identifier for those handsets that have one. Older model phones  use the ESN to identify themselves to the network. Newer phones use the MEID, but still retain a  pseudo ESN since it is required for compatibility reasons. So to clone a phone, all you have to do is  grab somebody's phone, write down the ESN or MEID in their phone number, then copy these numbers to  another handset to get a valid clone. Well, years ago, this used to be all it took. Since the MIN was  usually the same as the phone number and the ESN was printed on any given device, it was trivial for an  attacker to get these values and use someone else's expensive wireless minutes to make calls. So  Qualcomm and the CDMA carriers had to come up with a solution. We won't get into a ton of detail, but the  cave authentication mechanism makes it very difficult to successfully clone a CDMA phone. Additional  keys are used in a challenge response protocol to authenticate the customer and the call. Manufacturers of CDMA  devices are supposed to make these keys difficult to obtain so that a full clone is not possible. All that  being said, let's see if our rogue Femto cell has any more secrets it wants to give up. Hint. As we  mentioned earlier, the Femto cell acts like a typical cell tower, except with at least one key  difference. The Femto cell only uses the ESN and MIN to authenticate handsets. We're not entirely  sure why we really have no idea, but it may suggest a legacy CDMA implementation. But the real  problem here is that we discovered that the Femto cell did not have cave enabled. It behaved like a  legacy tower and just ignored those keys relying solely on the ESN and MIN for authentication. So  cloning becomes extremely easy, just like the good old days. Note that the cloned phone will only work  while connected to the Femto cell, but it can be any Femto cell, not necessarily one that's been  modified. So we just need to somehow obtain the ESN and MIN of our victim and program those numbers  into another handset. You're generally not supposed to be able to write the ESN, but some phone  models do allow it. So it's just like the movies, right? We wait until our victim runs to the  bathroom, you grab their phone, write down the ESN and MIN and clone the phone, right? But it's  just so messy. We have to invite our victim out to eat. We have to wait until they go to the  bathroom. We have to risk getting caught going through their phone. And what happens if they take  their phone with them to the bathroom? And trying to play shit and spell or words with friends,  whatever that game is. But listen, it's just not worth it. There's got to be an easier way to  defraud my friends. So remember that time I told you that we can see every packet that goes  through the Femto cell? Well, that includes handset registration packets that contain the ESN and  MIN of the phone associated to the Femto cell. So all I have to do is capture packets on my rogue  Femto cell, wait for an unsuspecting mobile phone to come within range. When the phone  associates to the Femto cell, I catch the ESN and MIN without physical access to the phone and  without any indication of the user. So picture is worth a thousand words, right? Here it is step by  step. The victim phone comes within range of a malicious Femto cell and as the handset registers  the carrier network, the ESN and MIN are captured and written to a separate target handset. The  target handset can then be used as a perfect clone of the victim as long as it is associated to  the Femto cell. It would be possible to capture phones in New York City using a rogue Femto cell  and email the numbers to an accomplice in Seattle who is using a stock Femto cell. It's almost the  perfect crime. While we were testing for cloning, we noticed our results were a little inconsistent.  It wouldn't work too well if you were trying to use it as your personal cell phone. But if your  aim was to make money through toll fraud, you could probably make enough money to buy a boat that  has smaller boats inside of it. We suspect our problems may have something to do with a relative  signal strength of neighboring cell towers as we saw slightly different results when testing in a  urban environment as opposed to a more rural one. But the short answer is we just don't know. So we  tested cloning with voice, SMS and data. Some of the results were expected and some were not. But  probably the most interesting thing we saw was the not quite three way call. So I'm going to  describe a few scenarios with the next few slides and the following definitions will be helpful. Our  victim is the person with a shiny new iPhone whose phone that we want to clone. The target is the bad  guy running this old crappy flip phone and that's been modified to act like a copy or clone of the  victim phone. So the easiest scenario is if the victim's phone is turned off, jammed, otherwise  not connected to any cell towers. Everything works as expected, there's no issues with service, you've  got an exact working copy of the victim's phone for all intents and purposes. So when both phones are  associated to the same femto cell, we noticed a few different things. Of course the clone phone, the  target, must be associated to the femto cell in order to work properly. It is only possible to  place outgoing calls one at a time. No matter which phone initiates the outgoing call, any  subsequent call placed will force that call to drop. Doesn't matter which phone is which, either the  victim or the target can cause each other to drop calls. We didn't notice any issues with  outgoing text messages and for incoming SMS, the usual behavior seemed to be that both phones would  get the text message. So with incoming calls, sometimes one of two behaviors is  possible. The first is that only one of the two phones rings. It could be the victim or the target, it  doesn't matter. Other times, both phones will ring at the same time. The phone that picks up the call  first usually wins, which means it gets to stay on the call. But the coolest part is that sometimes if the  two phones answered within a few seconds of each other, we got what we're calling a two and a half  way call. So what would happen is both the target and the victim phones would connect and each would be  able to hear the inbound caller, but not each other. So the eavesdropping scenario here is pretty  clear. Bad guy can clone a phone and as soon as an incoming call comes in, picks up the call, mutes his  mic and can hear everything said by the incoming caller. In our second scenario, the target is  associated to the femto cell as required, but the victim is out and about connected to an actual cell  tower. The phone that gets the incoming call appears to depend on which phone has had more recent  communication with the carrier network, like a call or text message. We couldn't reproduce the two  and a half way call since both phones never rang at the same time. SMS was pretty similar, we never  got an SMS on both phones at the same time. So outgoing calls are a little more interesting. So  let's say the target, the cloned phone, is on an active phone call. This works fine until our  unsuspecting victim places an outgoing call to another party. The bad guy's call gets dropped and  the call of our innocent victim is allowed to connect reliably. However, if the victim is on an  active call, like pictured, and the target places an outgoing call, the call will connect and the  call will connect allowing two independent phone calls. So these implications are clear as well.  Why use your own minutes when you can use someone else's to call 1-900 numbers and run up a huge  bill? Which is especially awesome if you're the one who owns the 1-900 number. So I said earlier we  were going to talk about cloning data and here we are. It appears to be slightly more difficult to  establish a data connection on a clone than it is to clone voice and text services. Data  services on Verizon's network are required for MMS, account management features and internet  connectivity. Long story short, the carrier network requires more numerical identifiers for  data connection than for voice and SMS. We're not saying it's impossible, but it's just more  difficult. We didn't really dig too deep into it. So we have a video to demonstrate a two and a  half way call. Whoops. Maybe not. Okay. There we go. All right. So that's me making a phone call  to a single number. Both phones are ringing. The victim phone is the one on the left and the  target is the one on the right. We're going to fast forward obnoxiously. Both calls get  answered. Both calls connect and stay connected. And now we're going to do some very sophisticated  voice testing. Stand by. To prove that the two calls are connected. There it is. Just on inside  secret to phone testers. It's very tactical. All handle that. All right. And so that's that. So we  mentioned this at the beginning, but this issue was resolved by Verizon on the back end many  months ago. Which is great because authentication should be checked on the internal network that  the carriers control, not on the small box that they don't. And with that, I'll turn it back over to  the code, Tom. Okay. So it would be easy to think that this is all about Verizon, but this is  really about everybody. There are over 30 carriers worldwide who have femto cells and three of the  four major U.S. carriers. And clearly there are issues here. So what's a multi-billion dollar  multinational corporation to do? Well, you can harden the actual device, but as we all know,  there's nothing you're going to be able to do on the platform to prevent people with physical  access from breaking in. Root is always possible. We didn't have to do more sophisticated attacks, but  obviously you shouldn't rule them out. There are lots of ways onto an embedded device and frankly we  went in through the door. So what else can a vendor do? Well, you can force registration. Make the  femto cell owner list the phones allowed to connect through their femto cell and then confirm with  the phone owner that they're cool with allowing that. And if they try connecting through any other  femto cell, don't let them. And do this whitelisting inside the carrier network, of course, not on the  actual device. And this would make it a lot harder to take one of these down to Times Square or  Las Vegas and just start gobbling up everyone around them. So device registration clearly reduces the  attack service. Here's a breakdown of the major U.S. cell carriers and how they handle handset  registration on their femto cells, at least according to their documentation. Besides T-Mobile who  doesn't have a femto cell, AT&T is leading in this category because they require registration. The  other carriers, Sprint and Verizon, do not. So phone registration does prevent the easiest attack, but  it doesn't win us over completely. It doesn't prevent attacks where I isolate you from the carrier  network. You'll still see four bars, send beacons with your MIN and ESN, try and make phone calls and  send text messages. And even though I never deliver any of that up to the carrier, I'll still see them.  I can track you and read your SMS. And we verify this experimentally. It's actually what we're doing  right now. We isolate any phone that's not whitelisted so we don't receive inbound text messages or  data sessions or actually see what you're sending because we whited out. With more engineering, it'd be  possible to connect these phone calls to our phone line, spoof SMSes for you to receive, and even route  the data traffic out the femto cell on the normal internet connection and let you browse the internet  all without connecting to the carrier network. So the carrier never knows that you're attached. So device  registration where the phone opts into using a femto cell and the femto cell opts into using a phone, it's a  good minimum level security, but we don't think it's enough. Really what you should be doing is ditching  them all together. You guys know that there will be bugs in everything, but that said, we like Wi-Fi  calling. If the handset is on Wi-Fi, not even your own Wi-Fi, but untrusted Wi-Fi, and it IP  sex or SSL tunnels into the carrier network, doing certificate pinning, and the phone is  appropriately distrusted from a network perspective so you can't just go end mapping all their crap, we  think you get a much stronger architecture. You have to do the same type of cell phone  authentication you do with the tower to avoid theft of service, but that's no weaker than what we have  here. And what you get is not needing femto cells, that's a win, being able to make calls on any  random Wi-Fi, and that's a win, and those calls are encrypted against the Wi-Fi operator, which is a  win and pretty necessary. So going even further, you can build in end-to-end encryption to protect the  contents of the call against both untrusted Wi-Fi operators and the carrier. And as you all know, there  are individual apps that do this, but they all require the recipient to have the same app. If Google  and Apple and BlackBerry built this into their phones and carriers supported the model, we think there  would be a huge increase in adoption. So I was just talking about this, but let's sum up and present a  couple of other band-aids that you can try. Hardening the femto cells is due diligence, but  ultimately a losing proposition. Requiring registration prevents untargeted attacks to some  degree, but long-term we're pretty nervous about giving random people, like yourselves, small cell  phone towers and just hoping you don't break into them. Now, can you tell if you're connected to a  femto cell? We said in the beginning, no, but it had an asterisk. We noticed that some Android phones  have an icon indicating they are connected to a femto cell. Now, this was only in phones that Verizon  had modified. It's not in the Android source or any stock or flashed ROMs. An iPhone for the record  has no visual indicator at all. There's a short beep at the beginning of phone calls, but it's really easy  to notice and you have to make a phone call. But somehow these Android phones were detecting  femto cells and showing an icon. So we reverse engineered that and then we're halfway done with  our own app. The femto catcher. So we noticed that the network ID indicates if it's a femto cell.  And although it's possible to lie about that, we didn't really investigate how hard it would be. So  using this, we can write a tool to put a phone into airplane mode when it detects itself being  connected to a femto cell. Now, to be clear, we're not marketing this widely or to your extended  family. We're building this because we want it. We would rather not have service than be connected  to one of these, especially at DEF CON. And we're going to be sharing it because we thought that you  folks in this room might also want that option. And this is going to be available soon. We have a few  kinks to work out. We have to thank Mira, a lot for doing all the work on this. So what else can you do  proactively? Well, you can encrypt what you do on your phone and there are a multitude of free and  paid apps to do so if you can convince your communication partner to use the same app. So what  else can you do if you route this or another femto cell? And you are operating a small cell  tower. Well, there's WAP. WAP is basically web browsing for flip phones. It uses custom protocols.  It's heavily proxied. It does SSL, middling, whether they tell you that or not. I'm looking at you,  Nokia. And you might think that WAP is dead, right? But it's actually used by a couple billion  people in the developing world. And smartphone manufacturers and carriers are still developing and  investing heavily in it. So we think it's a worthwhile research target. And of course there's that  binary blob that has complete control over your entire phone that nobody's been able to inspect in  any straightforward way, at least not that we can actually see the results of. You could totally  fuzz the baseband with a femto cell and it probably let you get a little bit deeper into any  carrier specific stuff that they're doing than just using a general software defined radio. And  since the device makes a VPN into the carrier network, you can poke around inside of their  network. You can look at attacking other femto cells from your femto cell or look at the carrier's  network itself. And the talk from two years ago at Black Hat did this with fantastic results. They  were actually able to wiretap not just their femto cell, but every single femto cell that was on  the French carrier. And that's a little bit farther than we wanted to go without permission from the  carrier. So we worked hard to wrap up a little bit early because we wanted to leave time for  questions and hopefully another demo. But before questions, we have to thank a lot of people.  Andrew is one of the interns who worked on that really painful cross compilation, but now is  full-fledged member of ISEC and operating this demo and all the hard stuff. RSA, XBC, and Doug  Kelly who helped us with a lot of the initial work. We use their research. Davis and Tim who also  helped us when we got stuck. Mira, Michael, Peter, our CEO, Joel, really all of ISEC and of  course last but not least our external and internal legal counsels. So I really have no idea if this  is going to work, but we are going to try and do another demo. So if you want to send a text  message that shows up on the screen, there is the number have at it. And I will take questions while  that happens. How did we get around the GPS? So the device needs a GPS signal. Long, just a long GPS  cable will work. So I'm going to try to get my hands on it. And I will take questions while it  is working. Do the customer arms have the transparent proxy? It's a long GPS signal. So I'm going to  try to get my hands on it. When we were testing, all phones were sent through the transparent  proxy. It doesn't have to do with the ROM. The question was did we try flashing a phone to  prefer femto cells? We are waiting for that. So the question was did we try flashing a ROM to  prefer femto cells to wire tap people more easily? No, we did not. Custom PRL. We looked into it but  we didn't get any success. Have you been inside a real cell tower and seen what  possibly comes with it? Have we been inside a real cell tower and seen if any of this might apply  to the real keys to it? So the device allows up to six. I don't think we have more than six. I'm  sorry? Okay. You can have more passively associated but only six simultaneous voice  calls. I forgot the two volunteers, please come up and see if your phones are associated and send  some text messages. So the device allows up to six. I don't think we have more than six. I'm  sorry? Okay. You can have more passively associated but only six simultaneous voice calls. I forgot  the two volunteers, please come up and see if your phones are associated and send some text  messages. Any other questions? Yes, you are standing up. You are going to have to shout,  sorry. Would a sprint device also connect to our femto cell? We don't believe so. And yeah, if anyone has a  sprint device. We don't believe so and really we just created our proof of concept code on Verizon.  This is applicable to like most femto cells. How does Verizon deploy the patches? They push the  patch down to the unit. It's auto updates itself. The question was the mics are active before you  place a phone call. Is that the truth even if you are not connected to a femto cell? I don't know. The  question was about 3G and 4G. In our testing, our experience was that if you have a 4G data  connection, we won't see your data but we will see your SMS and your phone calls. Any, yes. Yes, it's  the phone that is associated to the femto cell that we intercept, not the sender. We are just  showing the text messages that are coming in. Try sending a text message. We will see an outgoing one.  I'm sorry. I still can't hear you. We have an external antenna, a directional one. You could  hook up more antennas, powered antennas. We didn't really try. We were trying to minimize the  number of phones we were getting. The question was about the key for the IPsec tunnel. We did look  at multiple devices. The key is not the same across them. We have not tried getting a MiFi device  onto it. So have you ever known what the software process is for us? We have never known what the  software process is. We did look at that a little bit. If there are no other questions, we will  back up. Thank you very much.
DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_0_1907.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_1908_5051.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_5052_5867.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_5868_7451.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_7452_7943.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_7944_11723.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_11724_12263.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_12264_12899.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_12900_14255.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_14256_15923.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_15924_17111.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_17112_18659.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_18660_19055.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_19056_19715.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_19716_20231.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_20232_20603.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_20604_20735.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_20736_21527.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_21528_21587.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_21588_22139.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_22140_22403.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_22404_24203.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_24204_24335.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_24336_30791.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_30792_32411.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_32412_32543.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_32544_34775.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_34776_36179.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_36180_38219.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_38220_38951.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_38952_41687.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_41688_43787.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_43788_45503.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_45504_46391.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_46392_46475.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_46476_46871.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_46872_47783.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_47784_48167.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_48168_48467.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_48468_48743.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_48744_48827.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_48828_49007.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_49008_49307.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_49308_50075.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_50076_54011.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_54012_57023.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_57024_57335.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_57336_57707.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_57708_58967.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_58968_60287.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_60288_60383.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_60384_66767.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_66768_67919.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_67920_68459.png DEF_CON_21_-_Doug_DePerry_and_Tom_Ritter_-_I_Can_Hear_You_Now_886kXEhE90I_68460_70162.png