 Is your phone pwned? We're going to talk about auditing, attacking and defending mobile devices. Smart phones are exploding. It's a pretty exciting time. More importantly, it's a very exciting time to be hacking phones as well. So we're going to start off with what you all wanted to see. We're going to start by attacking some phones. First going to introduce us. My name is John Herring. I'm here with Kevin Mahaffey and Anthony Limeberry. We're with Flexilis. We're a mobile security startup working on software. We started in the research community, actually born out of Def Con in Black Hat, and decided we were going to build software to defend mobile devices. So let's take a look at a real-world attack scenario. So I don't know if any of you have had the pleasure of working with WAP, but it's very, very complicated. Basically what it is, it's an application data protocol for mobile devices, and it was originally designed so you can get things like the internet on your mobile device. They also have a service called WAP Push that basically allows push services to be sent to your device instead of your device having to pull them. So this would save battery life, et cetera, et cetera. So you can see that the WAP protocol stack is fairly complicated and somewhat reminiscent of the TCP IP protocol stack. We're starting to see a lot of attacks targeted towards WAP at Black Hat this year. There were at least three attacks that went towards WAP. In my opinion, the state of WAP security is somewhat poor and not many people have audited it, and we hope to lower the bar to auditing mobile protocols today. So we hope you all take something home and help secure this stuff. So under normal circumstances, the way WAP works is it goes over all sorts of different data channels, but the one we're going to look at today is SMS. So when you get an SMS on your mobile phone, we're going to assume you have a GSM phone. The SMS comes through what the carrier's system called the SMSC. And under normal circumstances when you get a WAP push, the SMSC trusts a specific gateway that connects to other services. So let's imagine the carrier wants to update some settings on your phone. They would use this thing called the Push Proxy Gateway, which is the trusted person who's supposed to send WAP pushes to your phone. And your phone has configuration settings that say, hey, I only trust this Push Proxy Gateway to receive WAP push messages. This is all secure, right, guys? So just like you can send SMS's to your friend on the same network, this routes to the SMSC, you can also send WAP push messages to somebody else on the same network. The device should, of course, say, well, this is not a trusted WAP push initiator, so I'm just going to ignore this message. But on certain Windows mobile devices, they shipped from the factory misconfigured with security policy settings, and this basically says, I will trust WAP push messages from any initiator. This attack has been live in the wild since 2008, and I'm surprised it hasn't gotten more attention than it has. Basically what it does, it allows unauthenticated senders to send these things called service load and service indication messages. And what those are is it's either a way to pop up a URL on a target device, or on a target device you can literally install an application over the air with no user intervention. And I'll let you guys, your devious minds, think about all the wonderful things you could do with that. And so just to be clear, this isn't necessarily a Microsoft issue. It's an OEM issue, so the security policies are misconfigured by the OEMs. They're actually good when Microsoft ships them, and for some reason they misconfigure them. We haven't figured out why that's happening. Also just a heads up that the carrier is absolutely monitoring their networks pretty closely, and this traffic stands above the rest, so it's very easy for them to tell who's sending this type of traffic, so be aware of that. And so as a note, the devices that are vulnerable are Windows mobile devices from a variety of manufacturers, HDC, PanTech, Samsung, Motorola, etc. So let's take a look at the attack. So I know the screen's backwards, but you'll get the idea. So essentially what we're going to do here is Kevin's going to attack my phone. No user intervention whatsoever. I'm not touching anything. We're able to force a browser open with an arbitrary URL. We could combine this with a browser-based exploit. Also what we could do is force an arbitrary URL to point to a file and force it to download and install a file. This could be malware, it could be some kind of malicious piece of hardware. There you go. He just popped open the site. It's loading. And then we see defconn.com is going to load up for us. So this just gives you an idea of exactly what is possible with these types of attacks. I would see this happening, but if this were in my pocket or if I weren't paying attention, essentially I could completely take control of the device remotely with almost no user intervention or no user intervention whatsoever. So it's a pretty cool attack. There's also a lot of speculation. You hear all sorts of WebKit vulnerabilities, and when WebKit gets owned, it owns everything from a PS3 to Android, iOSX, every version of WebKit out there. So this is definitely a vector for drive-by-browser exploits as well. So you pop open a web page and you can initiate that. So we are releasing a fix tool, which will be available shortly at hotfix.flexless.com. So basically what it does, it fixes this. There's two issues related to this, and we're going to talk about some more issues later. It's free, and basically what it does is it patches your security settings on a vulnerable device and keeps you safe. As a note, if you hard reset your device, you'll have to reinstall the fix tool because it doesn't actually hit it in the wrong. And one other note to add is that if you aren't sure if you're vulnerable or not, you can use this tool to detect. It'll scan to detect if you're vulnerable. So go ahead and download that if you're worried. So let's talk about the mobile security environment. What's going on generally with devices, networks, everything that goes into actually attacking these devices to give some context. So we all know mobile devices are essentially PCs today. We were looking back at some of our research in Bluetooth just from a few years ago at DEF CON and kind of laughing at the primitive devices we were attacking just three years ago or so, and these devices have fundamentally changed. I mean, my iPhone is more powerful than my first three computers I ever owned combined, and this is in my pocket, notwithstanding all the mobile protocols and technologies that go into it. So what are the key factors driving the threats? Device advancement, I would say is the number one third-party application adoption. I mean, we saw this on the desktop in the 90s with the shareware movement and malware and SPI were starting to piggyback on applications as they were downloaded, persistent connections and mobile data usage. Data usage is absolutely skyrocketing. So I just read a study, I believe, by 2012. We'll be using the same amount of data on mobile networks as in 2008 on wired networks. And if that gives you an idea of how much data will be flowing over mobile networks, it's pretty staggering in just a short period of time. So in addition to the threat landscape that's being driven by the device enhancement and mobile data, there's incentives for attackers' in-band payment mechanism, as I would say going to be one of the biggest. So how do you monetize an attack on the PC? Well, you could turn the computer into a botnet and leverage that for attacks or spam. You could pull off someone's credit card information or personal information and use that. But there's not a direct monetization path. On mobile, that's not the case. You're directly tied to your cell phone bill. And there's lots of different ways you can spend money. So reverse SMS billing. I'm sure there's, when you buy applications, there's all sorts of different methodologies there. So mobile, for the first time ever, you send a packet. We can actually send a packet and money goes flying. And that's new and that's a really big deal. I mean, if you could imagine a payload that sends a packet and money goes flying to some offshore account, that's a big deal. Sir, I don't know how I can underscore enough how important this is. Imagine if you could just send a UDP packet and like a dollar goes into your account. Like, think about that. I mean, this, you know, from an attack monetization strategy, kids in the mall, you know, large worms, there's a lot of potential for very, very bad things here. And the major fraud mitigation technique is when we see something bad, we'll stop it. Yep. So privilege access to network resources. I don't know how many of you are responsible for corporate networks, enterprise networks. But you can spend a ton of money and a ton of effort securing your actual network perimeter. But then if your mobile device is vulnerable and has a trusted relationship with your corporate network, let's say a VPNN, while I hit this off the spot, use that as a leverage point into the corporate network itself. That's pretty nasty. And then finally, valuable data. I mean, your mobile device is the most personal computer. In my opinion, there's a ton of information relative to your social graph who you're talking to, just running an analysis on your text messages, your calls. You can learn a lot about a person, location data, and then all sorts of other personal information. Mobile is a really hard problem. So we have to deal with performance in terms of battery life processing power and defending mobile devices, and we're constrained on the defensive side, but attackers are not. So the attacks are only getting more advanced and they're not constrained. One of the big problems is also a lot of people argue, oh, there's not going to be big mobile threats because the operating system landscape is very fragmented. I would argue against that, and I'll tell you why. So yes, there's fragmentation between operating systems, but smartphone operating systems are growing all of them so rapidly that they're all extremely large. So I believe there's maybe 17 million iPhones. And yes, that's fragmented, but there's 17 million iPhones. And mobile devices in many ways are more consistent than PCs. So a Windows box is not necessarily a Windows box. There's different ports open, different configurations, different types of software. So phones pretty much as far as the outside world is concerned are all the same. So if I have one attack, I can use that attack against 17 million devices. That's pretty sweet. So you look at the fragmented yet consistent, and that's a nuance that I would point out that's important. And then responding to the threats is really challenging. So the real elephant under the rug here, and I'm not sure if everybody realizes this, is that adding on top of platform fragmentation is update fragmentation. So let's say I have this mobile device from HCC. It's supported by 100 carriers worldwide. If there's a firmware update that needs to go out to patch of vulnerability, every single carrier has to re-qualify the firmware to make sure it doesn't take down devices. They're not getting service calls. It's a huge pain for them. So this is not just like on Windows where we can push out and out of band Windows update an emergency patch. They actually have to go through a lengthy cycle. And if you touch radio code, the respective regulatory body has to re-qualify it. So the FCC in our case. So imagine you find an exploit, then they go to patch it. You have to have it re-qualified by all the carriers and the FCC. This takes months and months. I mean, it's an inordinate amount of time. A great example, we'll talk a little bit more about it. We found a zero day and the iPhone in Bluetooth STP in the right when the iPhone came out worked with Apple. It took about four months from when we first reported to them to get patched. That was actually really, really fast for mobile. So the way that we are approaching this problem is we're trying to do our best to work with vendors, operators to try and give them as much lead time as possible. And I highly advise that everyone else who's doing mobile security research do so as well in the interest of the end user. Yeah, standard vulnerability disclosure timelines, like six weeks or a couple of months just doesn't work in mobile. When you have to deal with 133 internal QA cycles, 133 FCC QA cycles, and 133 carrier quals, four months is freaking flying. So let's talk a little bit about vulnerability discovery. You have context about how we think about the mobile landscape. Let's talk about how we actually discover mobile vulnerabilities and then we can look at auditing and attacking. So auditing a mobile device, it's not really much different. I mean it is, but you kind of start with the code. And there's a lot of the same problems that we had back in the day with desktop software. You're looking for your stir copies, pointer manipulation, stuff like that. Also your execution calls like execve and that whole family system with user-supplied arguments. And we've all known about these problems obviously for the past 10 years. But the mobile industry, security, they haven't had to worry about it before. So they haven't had to program with these things in mind. Another thing that you can check for when auditing this stuff, also the same as desktop software is third-party libraries. There's a lot of stuff like Android alone I believe is using like 70 third-party libraries in their build. iPhone had problems with LibTIF. I know the very first Android vulnerability that was found by Alfredo Ortega was in LibBMP and LibPNG. And this is back when it was still just an SDK and there was no hardware released. And they got that fixed. But it kind of goes back to the patching problem that it's a lot harder for mobile carriers and OEMs and manufacturers to keep their third-party libraries in sync with the latest releases and to keep that stuff patch. So just to add to that point, I mean when you think about, okay, so there's open-source software on a device like an Android device, they have to code freeze to ship to go send it to market and put it in boxes and deal with all this. During that time, if there's a vulnerability in one of the open-source libraries that they leveraged, those devices in the boxes are now sitting vulnerable and until they can issue a patch, there's this complete mismatch of the software that in the real world versus the software on devices, super big problem. So just looking at change sets is an interesting way to find lots of vulnerabilities. But, John, you can just upgrade the libraries yourself, right? So a less traditional route, I thought we'd just add this is interesting. We've actually found some, not directly, vulnerabilities through Twitter. So security researchers love talking and we found a number of folks talking about the types of research that they're doing to look at little snippets of what they're saying, work our way backwards, reverse engineer their research and actually find the vulnerabilities faster. So just looking at different Twitter searches is amazing. Just go in and start searching for different keywords around auditing or mobile vulnerabilities or any type of vulnerabilities in general. You might be surprised what you'll find. So let's talk about how we actually audit mobile devices. So we're really excited. We have a fuzzing tool to release. It's specifically targeted towards mobile devices and we found one of the problems with actually securing mobile devices is the companies who develop a software for mobile devices, the companies who make handsets and the companies who make operating systems, some of them have tools they use internally but it's actually remarkably hard to really get good security coverage on mobile devices. And so we said, you know what? We think we can help this and we are going to release a fuzzing tool. I assume everyone here knows what fuzzing is, hopefully. And really what we mean by a fuzzing tool is not just something that generates bad data but also something that handles the injection, the state management and the result analysis which is one of the hardest parts about dealing with mobile because you have a lot of protocols that you have to inject on the device specifically or through some sort of radio. So we're pretty happy with that. It's going to be free and open source and we really have hopes and dreams that people actually use this and help contribute back to this. Has anyone here heard of the site GitHub? Woo! One guy. At least one guy. So let me paint a picture. You're at Defcon. You go and somebody on stage says, hey we have a really cool security tool. You've probably seen this happen like 20, 30 times and how often does that actually get updated? The answer is maybe once and that's a week after Defcon while they're still interested in the tool. And so that's not what we want to do here. We actually want to have something that you all can take home if you're at a mobile company or any company in general and you like hacking on mobile phones you can contribute stuff back and really what we hope to have is a baseline security that all mobile phones can have before they ship because there are just too many silly vulnerabilities that we find 10 test cases in into the dumbest fuzzer we can possibly write that just do not need to exist. So that's what we hope to do here. So the first thing you'll note is in our fuzzer it's written in Ruby and we can have some arguments over whether this domain specific language is good but the idea is that we want to make fuzzing very, very easy for anyone to do. You don't want to have to think about all the underlying goo you just want to say here's what a protocol looks like and here's this phone so just do your worst and do it all automatically and tell me what happens. So basically we have a domain specific language that generates fuzzers and automatically handles generating all of the bad data that you would inject to actually elicit vulnerabilities in mobile devices. So some of the problems and you might ask well why did you create a new fuzzer? There's a whole bunch of wonderful fuzzers out there. Mobile devices use a lot more than TCPIP. You have Bluetooth, Wi-Fi, NFC, et cetera, et cetera. There's all sorts of different protocols that are fairly difficult to deal with normal fuzzers. Injection constraints, the protocols themselves are kind of nasty and so we'll talk about that. The first thing that is important in building a mobile fuzzer is everything has to be over-rideable. You might just say this is good software architecture and you really want anything to be swapped out because I can't tell you how many times we're auditing some weird strange phone and it doesn't support XX or X and it's just really annoying and so being able to swap everything out is important. Go ahead. So basically the way this fuzzer is built is if you're familiar with fuzzers there's a block and there's elements inside of the block and so basically you just describe protocols like this. So let's imagine you have a type length value protocol. You would say, hey, the type's an integer, the length is a length, which is also an integer over this binary value and you describe that and all of your test cases are just generated for you. The other thing that's nice is that we want to make it very, very easy to mix and match protocols so basically once you define a given protocol you add it to this registry and you can basically reference it later and protocols use something called an abstract data element that allows them to attach together so you may describe TCPIP but you want to fuzz HTTP on top of that the TCP protocol will have a data element and you just attach HTTP to that and what this buys us is you can do things like this so straight from the command line you can just combine protocols together and on the fly a test case will be generated in this whole fuzzing suite and so our goal is to say at some point you say I want to audit this iPhone and it will take all the protocols it knows about and throw everything it does at the iPhone which is pretty neat and so if you want to add one more thing to your test case it will add that protocol you can leverage say somebody's already done all the crazy GSM SMS stuff and you want to audit one WAP protocol all you do is have to write that WAP protocol and say hey fuzz iPhone GSM SMS WAP WTLS for example and everything is just done for you so a lot of mobile phones have emulators and simulators if anyone's done iPhone development the simulator runs on x86 so it's not really going to do much for us Windows Mobile is a pretty good emulator and Symbian I don't think is a very good simulator but really we need to touch physical hardware if you're fuzzing Bluetooth or SMS or Wi-Fi or even just things that are on the device different OEMs put different pieces of software on their phones and you never know what's going to happen the Broadcom Bluetooth stack on one phone and then the southern phone uses the Microsoft Bluetooth stack so we really just need to touch physical devices and so the solution here is we have these pre-built injectors that will work on each platform and interface and what you can see is that just from the command line you can say I want to fuzz these protocols and here's the injector you want to use to inject it and so we have a common injector protocol and so there's basically two types of injectors we use one is the hey, here's a local injector that interacts with the radio and that radio will inject all this data at a phone but the other type is let's imagine you have an iPhone and you want to fuzz the LibTiff library for example how do you do that? One way is to set up an HTTP server and just have it hit it all the time the other way is to have a piece of software running on the phone that takes input from the fuzzing server and will actually load all those libraries with LibTiff and even better you can have local debugging resources so you can run GDB locally for example so you can actually get really really good result analysis and basically what we've built is a standard protocol by which anyone can write an injector for a phone so right now we have iPhone and Android injectors and more are coming soon we have a Bluetooth one just about ready and so we're going to release all this and basically because it's a common protocol anyone can write their own injector it's super trivial so basically what happens is the fuzzing host says hey here's a type of data for example an SMS or an image or audio so the injector knows what to do with it here's the length and we just let's assume you're not going to play with that and the data that you're going to fuzz the injector that runs on the physical device takes that, runs it and will return a result so one of the injections we wrote for the iPhone we wanted to fuzz SMS PDUs so just to give you an idea of how these things work on the iPhone we wanted to fuzz the comm center binary which basically it's actually what runs as root and it does all the parsing of the SMS PDUs so what we did was we wrote a dynamic library to basically do kind of essentially like an LD preload on Linux type thing and we would intercept all the reads, writes and the select calls on all the base bands the SPI base bands 2, 3 and 4 are the ones that handle the SMS coming in so the way we did this was we had a name pipe so we had a standalone binary running as the injector we would send our fuzz packets at that that would stuff them into a name pipe and the dynamic library that was hooking all of these calls it would basically take that name pipe file descriptor that it had opened and stuff that into the FD set for select along with all the baseband file descriptors so when data was coming in on that select would unblock and then we would look that and say ok it's our name pipe set and at that point we could flip the bit and say that there's data coming in off the baseband when there really wasn't at that point then we would pass that on to the comm center, comm center would try to do a read on that baseband and then we would intercept that as well and actually read from our name pipe rather than the baseband device so from there we could stuff that all in the buffer and then comm center would think that it got the data that it wanted and then we could fuzz everything through that and then we just use a simple state machine to keep track because there's the three different baseband that it's reading from that it basically reads from to with a ATXD VRI and a CMT and then it writes a ATC NMA to check if it actually got one so with our hooked right we would actually swallow that and say that we wrote that to the baseband and then fake a reply back rather than letting it actually reply so basically we man in the middle the radio on the iPhone. Yes, simple terms. And a nice side effect of this too once we release this you can use this to actually monitor all the activity that's going on on these basebands with this code and have that log it out or log that to the screen. And if Tom Robinson from 280 North is here he pioneered this original technique we were doing with some Bluetooth stuff so thanks a lot Tom the code is good. I would also recommend checking out a couple of the talks from Black Hat. Colin and Charlie did some similar research on SMS and they had a pretty good prezo so I checked that out too. So let's take a look at a fuzzing demo of the iPhone. That's not how it's supposed to look. This is good so Anthony. Okay so just to give you an idea this you can hear the SMS is coming in incredibly fast so instead of manually testing we can just send obscene amounts of SMS traffic at the device without going over the SMS network. So it sounds like we're winning every time it pings and let me tell you the carriers don't really like it when you fuzz SMS over the real network. Yeah don't do that. That's a bad idea. You might take down a cell tower. You're probably more likely to take down the network. Keep it local. So we just sent 300 PDUs this test suite has about 300,000 there are 7 test suites and it's telling me there's about 500 minutes left on this test. Cool. So fuzzing can you turn the fuzzer off it's going crazy. Yeah. So this software that we're releasing can run basically anywhere on a laptop on a desktop but we run into problems in terms of actually power and throughput and also we want to be able to massively parallelize protocols so if we're doing SMS we want to be able to fuzz Bluetooth and Wi-Fi at the same time we built a distributed fuzzing cluster I'll note in a TSA friendly compliant case but traveling with it's an adventure. Not a bomb. So it works it works extremely well at fuzzing devices massively concurrently so we can you can see in the picture there's maybe 10 devices there we have a bunch set up here we can have 50 phones plugged into this thing be simultaneously fuzzing Bluetooth Wi-Fi SMS a bunch of protocols all at the same time there's 16 cores in this thing it's super powerful so it's just a hardware implementation and we like hardware a lot so this is an example of taking the open source project that we're going to be releasing and extending it to something even more powerful and this wasn't that we did this in a weekend so this is pretty easy to set up. Mobile protocols are in fact evil. If you've ever had a chance to read some of the ETSI specs or the 3GPP specs or the OMA specs my condolences the reason for this is basically we need a lot of efficiency on mobile networks because bandwidth equals money and lots of it so there's all sorts of really weird techniques and there's a lot of bit masking involved for like arbitrary width length fields with a high bit set and it's just crazy there's a lot of state transitions like for example if you ever had a chance to look at the L2CAP connection state transitions there there are way too many states in that diagram it's almost nuts and so one of the reasons for developing this mobile fuzzer is actually to be able to deal with all of these crazy protocol elements and state transitions and things like that in a way that will not make us go crazy trying to override this, that or the other. So important first of all is intelligent defaults you create an int element it says you know what I'm going to be a one byte int element not that Indianness matters but if you said hey I want a two byte int element that's a big Indian too I'm kind of a Ruby on Rails junkie so the concept of convention over configuration speaks very truly to me so second of all let's imagine you want to for some reason have a three byte little Indian integer it will create that for you the other nice thing is that you notice that we don't actually have to define what values we're fuzzing right if you've looked at fuzzers such as sully or other fuzzers they usually have a corpus of data so for example if I'm fuzzing an integer you want to try to trigger boundary condition issues so this is the standard 007F80 FF et cetera and then you probably want to do off by ones on that and you know from fuzzing history that's what's most likely to cause errors but nobody wants to define that every time oh I have to do a three byte integer I have to redefine all those values the system will automatically figure out how big your thing is and make the Indianness all just work so overriding thing so overriding anything is certainly important this specific overriding is this crazy way it's called lacing but it's basically a glorified length field system there is a typo on here so just assume that v is the same as value basically if you have an integer there are umpteen different ways you need to encode it and if we had to write a whole different block a whole new class to handle that integer we'd just go crazy so basically the system allows you to dynamically override the encoders and there's also some kind of pre-built hooks that make it easy to just inject some extra logic and because we know in mobile protocols you always have to change this stuff so the thing we're actually really excited about is there's this concept of how deep do you fuzz versus how long does it take and the two degrees of freedom there are I have an element how many values can it take for example an integer 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 you know et cetera and then the other is if I have 10 elements how do I combine those two values together for example I have do I fuzz all of the first element then fuzz all of the next element if you do that it can take a really long time so there are two ways that fuzzers have dealt with this in the past the first is the one at a time method and so basically what that means is you take a good PDU let's imagine an HTTP request and you break that into blocks you say okay here's the verb you know the post get, delete, put, et cetera here's the URL here's the version of HTTP here's all the headers and what you would do is each one of those blocks has all sorts of fuzz values and you one at a time you manipulate that block and say I'm gonna try this bad value this bad value this bad value this has the advantage of you can go really really deep in any given value but the problem is that it doesn't uncover values where you have two things you're fuzzing at the time for example let's say you had a type length value protocol and you just fuzz the length but the vulnerability lies in fuzzing both the type and the length at the same time you're not gonna find that bug so the other type of ways is basically you combine all the different types of blocks together and so basically what this means is if you have three values you combine all possible values of all the three elements together but when you combine lots and lots and lots of elements together you know imagine multiplying 10 times 10 times 10 times 10 times 10 times 10 times 10 you know you see where this goes and you have like 14 quadrillion test cases and basically you know it'll finish somewhere near the lifetime of the universe and we found this we just a simple protocol can just explode also if you're only limited to 10 values for a given element you know you're not fuzzing that much so the technique we're introducing here is progressively incrementing the amount of combination we're doing and so basically what that means is we have two sets of values for any given element there's a expected value for example with HTTP that would be you know put, get, delete, etc and a set of fuzz values which would be all of the crazy wonderful strings that you're trying to do to elicit fail in what you're testing as we test we want to increase the amount of elements we're combining together with their fuzz values and here's a little example so imagine you have a protocol of four elements you start with fuzzing one thing at a time and the rest take their normal values and it'll iterate through all that after you exhaust all of those that is what we're saying is the most likely to find a bug is just fuzzing one thing but then after we exhaust those then you go to two at a time and so you fuzz two values and iterate through all that and the cool thing is is that you could technically leave this indefinitely you can go three at a time, four at a time, five at a time and you know somewhere around six at a time it's a reasonably complex protocol you're never going to finish but you know that's why we build things like this so we can just kind of leave it going all day long and also don't worry that the math is a little scary when you have lots of elements and then they have different numbers of values and fuzz values so just don't open the fuzzer class if you don't want to look at that math okay TCP IP is very well encapsulated what's the last time you've seen an HTTP vulnerability resulting in some mobile protocols are very very leaky one example of this is WAP authentication mechanisms way up the stack are based on addresses way down the stack similar with Bluetooth authentication mechanisms way up the stack are based on things way down the stack and so in fuzzing mobile you don't just want to fuzz the top level protocol you want to talk about you want to fuzz this entire thing and ordinarily if you couldn't do that because it would take forever but with this progressively combinatorial system you can actually in reasonable time fuzz a lot of these protocols together another really cool thing we're excited about is let's imagine you're fuzzing a complicated protocol with lots of state transitions you actually have to implement that protocol and that that's usually not fun but because we have fuzzers we've already implemented that protocol so you can we just reuse these data structures to actually generate and parse data the data structures for the protocol and it makes life easy you know I don't want to rewrite an entire protocol and I don't think any of you guys do either so around iPhone 1.0 time we took an early version of this fuzzer and targeted against the iPhone and there were some interesting issues you know this is this was a STP vulnerability STP and Bluetooth is a way for enumerating services that are on a Bluetooth device and we found that in this one specific case a weird element type so there's this concept in STP where you have one byte that specifies both the length and the type of the data to follow and it's kind of funny when you're writing fuzzers it's usually a good idea to put yourself in the mindset of somebody who's writing the protocol and what you would probably screw up and you know that's what we did and look they screwed up the same thing we thought we would screw up I think we found this vulnerability in the first five minutes of fuzzing it was a little bit longer that but yeah it was very really what this was is we would get a kernel read to fffffff and we disclosed this to Apple and we didn't actually try to weaponize this but the feedback we have is that it could have been bad had this been found so that took about four months to fix as John said if something like this were to be found and weaponized four months is quite a long time to be vulnerable so there's another vulnerability we found this is similar to the vulnerability we demonstrated earlier it's also in WAP it's also a result of misconfigured security policies coming from the carrier and basically what this allows you to do is push something called a WAP provisioning document this is something that the carriers use to do everything on the phone this is configuring proxy settings this is hard resetting your device accessing your files there's basically nothing you can't do yeah the good thing about this attack is that basically it's the same sort of idea that it doesn't validate the source of the push message and what we speculate is that carriers say you have two giant carriers to come in together and they had different push proxy gateways and if they had to change the trust model on all their phones it would just be a really hairy nightmare and so they just said oh we're just going to trust all WAP push at all and so what this vulnerability requires is that you need to sign the message with a network pin which is the IMSI of your phone it's a number that's written on the back of your SIM card or oftentimes the receipt when you go to your carrier store so make sure that sort of information doesn't get out we do recommend that people do your run the fix tool that will patch this and you won't be vulnerable we disclose this to Microsoft in late 2008 and the OEMs are aware of this and it's very, very prevalent so let's talk a little bit more about attacking mobile devices now so we're going to paint a picture of the mobile landscape as far as attacking goes it's what we like to call the 1999 factor because the state of mobile security right now as far as the code goes is very, very similar to how code was back in the late 90s if any of you did any hacking back then so we didn't have the heap in stack protections back then x86 back the day did not have non executable bits for pages ARM does they have the XN bit the execute never bit but a lot of mobile operating systems are not using this currently there's in fact the only one I could think of actually we have so here's our obituary matrix of what is and isn't on these things address space layout randomization currently android is the only one using that on their stack no one else is randomizing their heap stack or library loading windows mobile uses stack cookies but it's only a 16 bit cookie on the stack so I can't imagine it would be terribly hard to brute force that cookie android does use stack cookies and then the iPhone is using like non executable permissions on their pages for the stack and the heap and they actually have extremely strict permissioning with their memory to the point where you cannot have a page that is both writable and executable at the same time it'll cause an exception but you can still get around that with return to libc as far as signing code goes iPhone obviously we all know that they require it to be signed windows mobile they do have a they do use sign code for their applications but they will allow the unsigned code to run but it will present you with some user interaction prompt yes or no if you want to install this whereas I believe sign code will just install without that android it doesn't use sign code for their applications in the market but and they use kind of a block known bad not allow known good type thing but the good thing is that things are getting better within the past year or so the iPhone I know they've gone from having everything running as root with no permissioning in their memory to their segregated mobile user account and these strict memory permissions but for the most part security is kind of an afterthought for a lot of mobile developers they've never had to worry about this problem before and it's understandable no one's been attacking it in the past because there's been nothing to gain so we'll talk about some specific things on each platform on the iPhone unlocking is very common a lot of people don't want to use an iPhone on AT&T and we now have the push notification services that everyone's using for a notification of IMS coming in because iPhone doesn't allow background processing or background processes push notifications based on the XMPP publish subscribe protocol which is based on the IMS and they use SSL certs basically as user IDs for each device when you activate your iPhone it generates a public-private key but the problem with these is that with these unlocked phones when you activate them it's not generating a key for you to use the push notifications and so the way they solve that was basically copying the private key that was generated onto all these unlocked phones so this is the problem that was all over the internet for a little while everybody thought it was Apple's fault at first but then they realized it was the fault of these unlocked phones and people started getting instant message push notifications that were destined for other people and it's been speculated they used this for like spamming mass push notifications another problem with the iPhone is well I guess the App Store which is basically a centralized location for getting applications on your phone they released their SDK so that everybody could start developing applications for it but the SDK basically it encouraged a lot of first time developers to start jumping in and working on this and a lot of these first time programmers have no concept of security whatsoever all the code for the iPhone is running native luckily it's running as the mobile user so it doesn't have root privileges another thing is the jail breaking a lot of people were doing this back in the day not so much recently because of the App Store but jail breaking actually turns off code and it makes it a lot easier to do a lot of exploitation on the iPhone so with Android everyone was stoked that Android was well it's kind of stoked that everything was running in a VM each process is a sandbox basically Java gets compiled down to Dalvik bytecode but not everything on Android is actually running as Java the VM itself is native code and it all supports JNI the Java native interface to be able to run native compiled code for optimizations till recently it was unsupported then they just released their NDK so now everybody can start using that it doesn't really support the many libs but it's pretty easy to compile your own libraries and that kind of goes back to the problem of third party libraries of a lot of these first time developers to conclude about these problems so we did look for some vulnerabilities in the Dalvik VM because we figured that's a good place to get some code execution one of the ones that we found that we can disclose is in the JDWP which is the Java debug wireless protocol it's in a DVM debug output array which basically just outputs an array to the console it was basically just a textbook integer overflow in it and it's not really a problem because it is in the debugging stuff but a lot of the dev phones which was the first hardware released with Android on it they actually have a lot of listening processes with listening JDWP ports that are just sitting there but luckily this vulnerability we found isn't actually exploitable in the wild because of the amount of memory that's required to copy in the future there's a lot of talk about having Android on netbooks and that could actually become a problem it's also pretty interesting Android's permission model is such that the process is the isolation not the JVM so a lot of times Java security is based on like if you can break out of the JVM you win that's not so in Android they just assume you're just the UNIX process so it's good also the same thing with the Android market they have a lot of similar things with the iPhone just like first time developers that really have no concept of security and they don't really have to worry about that and also without sign code yeah so Windows Mobile current versions of Windows Mobile since I think it's 5.0 at least based on the WinC5 kernel and basically what this means is it's one giant 32 bit address space there's actually no process level memory isolation it's kind of neat what this stuff you can do threads migrate from process to process of particular note is that SMS parsing is done in the kernel in a privileged process you know similar to iPhone and that's usually not a good thing if you were to exploit that you can basically touch any memory on any process in the entire system including the kernel so yikes Windows Mobile 7 is getting actual true process memory isolation so that is good so there have been a few Windows Mobile vulnerabilities we can talk about we found vulnerability in Broadcom's Bluetooth stack we actually drove down to San Diego and sat with their engineers and like showed them how and got them to fix it that was pretty cool but basically it allowed I think it was just a really textbook buffer overflow it just you know it's silly that we're still seeing these types of things in code you know in what 2006 2007 we discovered that Colin Mule and a couple years ago at DEF CON if any of you guys saw that MMS vulnerability basically was able to get remote code execution on one mode device by sending it a carefully crafted MMS and if you guys pay attention to the news there was a Bluetooth phone and some HTC devices recently basically that directory traversal on the FTP so basically you just get out of the FTP jail you know we're starting to see vulnerabilities in mobile phones and like I said that vulnerability was not actually in Windows Mobile it was in the drivers that HTC was shipping so that's a really important point OS vendors OEMs ISVs they all have software on the phones and any one of them can be vulnerable so it's important to just don't blame the carrier vendor etc it's not always their fault cool so let's wrap up with talking about defending mobile devices what we can do so there's four pieces of the puzzle and the way we like to think about it there's absolutely no silver bullet to defending mobile devices software security, device security network security and end user security are all going to be super important if we actually want to make an impact on keeping these things safe so it absolutely all starts with the software and this isn't just OEMs or OS vendors or the operators this is also application developers so I'm sure a ton of you have built iPhone or Android apps it's super important that everybody involved is aware of developing secure code it's really really important it's the whole death by a thousand cuts idea is that if we have tons and tons of apps that are insecure it's going to expose the devices themselves to vulnerabilities device security also something that's incredibly important the OEMs and the OS vendors are going to need to take that really seriously network security is tied to device security so we're going to see the carriers filtering a lot of SMS type attacks which is good but at the end of the day things will still slip through so if the devices themselves are vulnerable that's not going to help us and then end user security so there's this interesting concept we found that there are lots of vulnerabilities for mobile that do get patched we're seeing it more and more with the iPhone for example almost every update that you see if you go look in the documentation there's vulnerabilities but then there's a ton of folks who charge their iPhone in the wall at night and don't sync with iTunes that often so in fact stay out of date many versions behind they're not as excited as many of us are to upgrade to the and hence are vulnerable to scores of vulnerabilities and this is more common than you would think actually keeping the firmware on your mobile device up to date patched and most people really don't think about this it's extremely important so everybody else software developers device security network security everybody can do their job and then the end user doesn't do their job and is vulnerable so at the end of the day we have to make sure that we keep our own devices safe as well and participate so what you can do to take action like I said ensure your latest firmware software is up to date that's really important enable only essential services and protocols while you're here at DEF CON my advice is airplane mode or just don't bring your phone that's probably the safest bet but if you have to leave bluetooth off, leave wifi off be cognizant of your surroundings I would say that this is definitely probably the most hostile environment for a mobile device you could possibly be in in any short period of time verify any software you have deployed this matters less for end users but if any of you guys are IT admins watch out for software that your users are actually installing on their own because that can cause a lot of problems and introduce vulnerabilities into your deployment and establish a system to monitor mobile vulnerability disclosure and information we've built some pretty cool tools just to keep up with the variety of information that's flowing out there on mobile vulnerability so we have twitter feeds we have things that scrape all the different disclosure areas and aggregate them into a single place so we can actually see what researchers are talking about mobile what vulnerability disclosures are happening everything in one place and be super on top of what's going on so thank you very much we appreciate all of it I want to thank Microsoft the BlackBerry security team Google Android and Apple