 Hi. And welcome. For the next hour, 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. And 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 we'll be discussing apply 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 LMG 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 even perform active man in the middle attacks on data connections as well as SSL stripping. And if that weren't enough, we thrown 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 sec tunnel 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 digital signal processing. 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 in 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 capsule 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 it's 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 this 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 .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 .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 it 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 IPsec 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 it 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 that's why we have interns. 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 user land 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 VoIP protocol will do, but who's talking to who and where's the audio? We could 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 byte 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 Femto Sal. And hopefully Andrew's phone will ring in just a moment. Alright, so the call is complete, so I need to switch over actually. Okay, so Andrew is going to pull it off of the Femto Sal and pass it through the... Sorry, 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, did 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 Wireshark 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. It's so much easier. Everything is parsed and displayed in Wireshark. 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. 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. And 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 fragments 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 middle 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 80, 80, 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 hijack 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 80, 80, which you don't notice because mobile UI sucks. So then you talk to our server on port 80, 80 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. 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 start seeing the Wells Fargo resources. In the upper left hand is where the username and password will show up. So there's Wells Fargo 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're 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 MC, 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 MC the M-I-N 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 M-I-N for identification. And unfortunately there's not really any obvious correlation between the M-I-N 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 Sha-1 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. Right? Well years ago these 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 till 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? In 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 be possible to capture phones in New York City using a rogue FEMTO cell and email the numbers to an accomplice in Seattle who's 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 maybe a couple jet skis too. We suspect our problems may have something to do with the 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. And 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 of 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. The 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 a 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 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 1900 numbers and run up a huge bill, which is especially awesome if you're the one who owns the 1900 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. Alright. 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. I'm noxiously. 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. Oh, there it is. Just on inside secret to phone testers. It's very, very technical. All handle that. Alright. And so that's that. So we mentioned this in the beginning, but this issue was resolved by Verizon on the back end many months ago. And 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'd 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 could 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 whitelist 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 in to using a femto cell and the femto cell opts in to using a phone, it's a good minimum level of 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 at 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 now. And what you get is not needing femto cells and 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'd 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 miss 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'd like to thank Mira Tamboretti a lot for pretty much 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 root 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 of 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 base band 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 had 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. RSAXVC and Doug Kelly who helped us with a lot of the initial work. We used their research Davis and Tim who also helped us when we got stuck. Mira, Michael Pratik, Peter Ailert, our COO Joel, really all of ISEC and of course last but not least our external and internal legal councils. 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. Do the custom ROMs have the transparent proxy? 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 were 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 we been inside a real cell tower and seen if any of this might apply there? We have not. We would love to get in one if you have 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 folks who are the volunteers, please come up and see if your phones are associated and send some text messages. Any other questions? Yes, you sir, standing up. You're 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 like we just created our proof of concept code on Verizon. This is applicable to people like most FEMTO cells. How does Verizon deploy the patches? They push the patch down to the unit. It's not like you have to plug in a USB stick or anything. 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're 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. Yes, it's the phone that is associated to the FEMTO cell that we intercept, not the sender. We're just showing the text messages that are coming in. Try sending a text message. We'll see an outgoing one. I'm sorry, I still can't hear you. We, I think, something about a single amplifier. We have an external antenna, a directional one. You could certainly hook up more antennas, powered antennas. We're not, I mean 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 tried this with MiFi. We've not tried getting a MiFi device onto it. We did look at that a little bit. If there are no other questions, we will pack up. Thank you very much.