 All right, thanks everybody for coming out here today. So we are three researchers from Lookout Mobile Security. We like to do a lot of nerdy things on cell phones and poke around with them. So we're going to be talking on Android permissions today and some of the fun things that we can do with and without them. So the things we're going to talk about today, we're going to do a brief boring overview of the Android internals just to get people who don't have any context of what some of these components are up to speed a little bit. Then we're going to talk about the security and permission model and a little brief overview on that and how the sandboxing works. At that point, then we'll talk about some of the fun things that we can do with permissions and without permissions and then talk about how we can use the system logging to leverage a lot of stuff as well. And then we're going to talk a little bit about rooting Android phones and some of the fun things with that. And then, of course, mitigation and what we can do to approach these problems. So first thing, Android internals. So the Android manifest is basically just a big XML file that every Android application needs to have. The manifest is going to define your package name, which is a unique identifier for every application that's going to be in the market. And this is going to be your com.android.whatever. That's your package name that you usually see. Also, it's going to describe all the various components within the application itself. Any receivers, broadcast receivers, it's going to have activities that it has, any services, that kind of stuff. Also, this will declare all the permissions, both permissions that your application needs to access a lot of the protected APIs, and also permissions that your application requires for other applications to interact with its components. Activities are basically just UI screens for Android, a way for the user to interact with the application. The activities themselves are just composed of a bunch of UI widgets called views, which are your button views, text views, that kind of stuff. The activities themselves are managed in what's called an activity stack, basically meaning that any new activity created is going to be at the top of that stack on the screen, and all any other UI screens are going to be down below that on the stack. The most foreground activity is going to be the running activity in an active state, and any activities down below it on the stack are going to be in a pause states, where they're not running, not doing anything, and just saving state. The activities will remain in that stack until they finish, or the system can yank them out and kill them if memory is running low. Applications can also start other applications activities remotely. The activity itself is going to run within the process of the remote application, so in a situation where you've requested location permissions, and you want to have the user turn on their GPS, and you detect that that's not enabled, you can start the settings activity with all the location settings, so they can enable that, and then once that activity finishes, they'll be back at the previous screen. Since that's running in the remote, it's running in its own applications process. The callee won't necessarily have access to any of the data in that activity. If you're starting your own activities within your own application, then you'll of course be able to have access to that. Activities themselves can have permissions enforced on them so that other processes can't start activities within your application without having requested whatever permission that you set. Intents for Android are basically a way for applications to do simple IPC so that they can send an event or an action along with data, which is usually in the form of a URI. So if we want to start up a browser, we can send an action view intent with a URL as our data, and that will fire up the browser using that intent. Okay, as you said, they can be used to start activities to start activity. We can also broadcast intents using send broadcast, and this basically just sends out an intent in mass. So for instance, anyone that would want to be notified about an SMS being received, an intent will be fired off across the system to anyone that wants to know about that event. There will be two types of intents that you can receive that way. There are just normal regular intents which are just sent out in mass, no particular order all at once, and you can't actually abort those intents or use the result from those. And then you also have, I'm not even on the right side for that, so yes, the normal, and then you also have ordered broadcasts which are, okay, I'm sorry, I'm mixing this up. Okay, so those are the intents, use those to communicate those, and then the broadcast receivers are what are going to be receiving those, and that's what I was talking about with the intents firing in a broadcast way. So we can do an ordered broadcast, which is sending them out sequentially to each of the different receivers where when one receives it, it'll get the result from the previous one, be able to do whatever kind of processing wants on that. It can also abort the intent if it wants to, abort the broadcast so that no one else further down the line will be able to receive that, and then they can also send their result to the next receiver down the line. We can declare our broadcast receivers in two different ways. We can either register them dynamically within our application, or we can have a static receiver tag within our manifest. Also, our broadcast receivers can also have permissions enforced on them so that you can either request that you need to have a certain permission if you want to send something to me, or that if you're sending out a broadcast, only broadcast receivers that have requested this permission can receive that. Services are a component that sounds just like what they are. They do work in the background. They aren't actually a separate process or running in a separate thread. Any processing is going to run in the main thread of the application. So if you're gonna do any kind of CPU intensive work or blocking, you're going to want to spin off your own thread from your service. But this essentially just acts like an activity without any UI for it. And like all the other components, these can also enforce permissions for access to them. With the security and permission model. So we all know that Android is, all the processes are running in a sandbox and everyone's aware about the security around that. The sandbox itself is not the VM. A lot of people think that the Dalvik VM is the sandbox. This is not the case. The sandbox is actually just Unix user permissions that Linux uses and all that kind of stuff. Basically that you have your UID and GID for every process and every application is essentially a different user on the system. So they don't have access to each other's data on the file system and then they're also just running in a multi-process environment where they're gonna have segregated address spaces. Each process running or each application running is going to have its own lightweight VM which is the Dalvik VM. Which is just a Java-like VM that is based off of passing through registers rather than on the stack. And if you're able to break out of this VM, you gain nothing. If you're able to get a native code execution, you're still gonna be running the same process with the same user privilege that the VM itself had. Applications can both request to share a UID so that they're essentially both running as the same user and then they can share data on the file system and some other things. Both applications need to request that explicitly and both applications would need to be signed with the same signer key. Permissioning is essentially just a more fine-grained enforcement of access to various protected APIs on the system or content. So any application that wants to be able to access the internet or receive SMS or look at your contacts, they're gonna have to request specific permissions to be able to do that. And these are, as I said, declared in the manifest. So with that, David's going to talk about some of the phone things that we can do with these. Thanks, Anthony. So yeah, so now I wanna talk about a little bit of Android development and why permissions are important, why you asked for them in the first place and do we need to ask for them? So the motto here, why ask for permission when you can ask for forgiveness. So the reason why permissions matter is because they gate what an app can do and the user is displayed them when they install an application. So you install Pandora Radio from the Android market. You see this screen here that tells you different things it can do. It can access the network, so that seems appropriate. It's Pandora, it's internet radio. It should be able to. It can read your phone state. That's presumably to pause playing of the radio when you get a phone call. So users can look at a screen like this and they can decipher to some degree whether or not those are appropriate permissions for the application. So let's go to another example. Here are two different Tic Tac Toe apps. One of them only requests internet and to be able to view the network state. So maybe it has a high score, maybe it has a multiplayer. But this other one requests system tools, mount and unmount file systems, which just sounds strange. So if I were you, I would download the one that only accesses the internet. And so what does it mean if you request zero permissions? That means when you click install from the market, it just starts downloading the app. There's no warnings, it doesn't warn you at all about what an app can or can't do. And so I think that a lot of users will probably assume if they don't see that screen that they shouldn't worry about that app. That app can't do anything harmful to me because it's not requesting any permissions, the OS isn't warning me at all. So we're gonna show all sorts of fun things you can do with zero permissions. So some of these are silly and some of them have more serious ramifications. So the first one is reboot. There's a reboot permission that's actually marked as signature or system. And what that means is that it's not actually grantable to apps from the marketplace. This permission would be denied if you requested it. You have to either be signed by the device signer or be in the system directory in order for you to be able to be granted this permission. You could say that Bob the Guardian is protecting this permission. A reboot joke fell flat on this audience. All right, thank you. But Bob isn't gonna stop us. So there are a couple different approaches to do this. The easiest one involves toast notifications. So here a toast notification is a way to notify you of something that goes on in the background. So in this case, you're in the keypad activity and the toast pops up to tell you about something else that's going on in the OS that some other app is doing. So here's just the basic hello world for toast and then I've thrown it inside a while true loop. So we're just gonna create as many toasts as we can and see what happens. Every time that you create and display a toast it creates a weak JNI reference in the Android system server. And when you get to 2001 global references, the system says, I can't let you do that, Dave. And throws a sig segvi and crashes the phone. So that's cool, you can get the OS to reboot. That's pretty fun, but during this process it would display a little toast on the screen that would say something like hello world. Now you could do something fun with this, like display a countdown timer to when your phone was gonna reboot. But you could also, maybe we can make this even more hidden. So there's also this idea of a custom toast. So a custom toast is any view I can display on the screen. So here this custom toast is powdered toast man, just an image of powdered toast man appears, fades in, would fade out. But you could also just create a view with nothing in it. So you just create an invisible view, you pop it up and after about 20 seconds of this loop running the phone reboots. So that's one cool thing that we can do that any app can do because this requires zero permissions. So without any warning an app could reboot your phone if they wanted to. So now that your phone is rebooting and it starts to boot up, there's a permission called receive boot complete. And this shows up in the Android permission screen it says allow app to start at startup or something along those lines. But the idea here is that the app would automatically start, right? So this one is a little embarrassing because you can just comment out the request for the permission and it still works. Works in all Android versions. So any app can start on boot regardless of whether or not they ask for permission. And so you can imagine you could combine that with the previous toast in a loop and you would have a phone that would be rebooting every 20 seconds. So then another thing, this one there's not actually permission for but another interesting thing that developers of malicious and non-malicious applications would like is to be able to start their app on installation. So you can imagine that you could use this with a couple other attacks. Maybe you don't want them to know that running your applications caused it to reboot. So instead you just reboot 20 seconds after they install the app. Or you could imagine this would be while you're in the Google market and you've just finished installing an app and you're kind of used to the fact that an app can't run until you launch it. So you could also maybe pop up a phishing dialogue at this point asking for their username and password. And they totally wouldn't see it coming because apps aren't supposed to be able to run until you run them for the first time. So there's not a permission for this but Google Analytics does this. So this snippet of code here to add to the Android manifest is actually from the Google Analytics for Mobile SDK. And you just throw that in there and this is to track the refer from the market. So say whether I clicked on some AdMob link or something like that. And then this would send it off to the Google Analytics server. But we don't need to use their receiver. We can just write our own receiver. So here we just created our own receiver instead of using theirs. And now we can launch on install. But there are some caveats with this. It actually does require a refer to be included in the URL. So you can imagine two main scenarios where that would happen. One, they click on an AdMob link inside another application or on the internet. And you can see there's all this refer data that's attached to it that tells you what campaign it was a part of and things like that. Another way is if they clicked on just any old link in a browser, you could just append your own refer info on it just so that this would happen. However, on Android 2.2 on Froyo, the Android market now always includes refer info. So this now always works. They include refer info of things like in this example, it says that we downloaded it from the games tab, the free section and it was row index 34. So it gives you all sorts of cool info but we can also use it here to start on install. So the next thing that I wanna talk about, I like to call the circle of death. And this is basically just a hostile takeover of the UI. So it's pretty simple. You just launch an activity, consume all key press events. So here in the on key down method, we're just returning true, which says we handled this key press. Don't pass it on to anyone else. So this allows us to catch every key press except for the home button and a long press of the home button which is a shortcut to allow you to switch between applications. So we need to do something else also. So what can we do? We can just relaunch our activity when it exits. Now, unfortunately it's not as easy as just starting the intent for our activity and it's on destroy event. We have to be a little more clever than that because Android detects that and doesn't fire off the intent in that case. So what we can do instead is create a circle of death. So just when our activity is destroyed, we just launch a service and this service just launches our original activity. So all we have to do in the on destroy event, we start a service and all that service does start an activity and then can just finish itself. And you can imagine the ramifications here. It's actually pretty easy workaround to get something like this off your phone. You can actually boot up into what's called Safe Mode on Android. You usually just hold in the track ball while you're starting up your phone and all non-system apps aren't allowed to run. And so here, I just wanna show a quick demo. Hopefully this will work. I know that you guys can't really see this, but hopefully you'll be able to hear it. So here's an application that I've installed on here and you can imagine that you could use this in all sorts of different ways, right? You could force someone to pay $5 on PayPal to get rid of this. If I can mash all the keys I want, I can't get out of here. All I can do is turn the screen off, but I'm still here. So let me just pull the battery out there. And once again, you can imagine that it's very easy to combine that with something like the start on boot and you've created some serious mayhem. But all of this is just kind of for fun. It's, there's not, none of that is all that serious, but let's talk about something that's a, that might be a little cooler. So let's say there's an application that doesn't request permission to use the internet. Maybe you would assume that it's fairly safe and that it can't contact a server. So you're not so worried about the fact that it's requesting your location or all sorts of other things. You say, oh, that can't access the internet. I'm not so worried about it. I don't care that it can read my contacts. But just because it doesn't request the internet doesn't mean that it can't expulterate some data anyway. So even though its sandbox can't access the internet, that doesn't mean all of the other sandboxes around it can or most of them can't. So you can just ask your neighbor. So the easiest way to do this would be to just pop open a browser and point it at some URL and include some parameters in it. So here you can imagine that you send your latitude and longitude off to some server. But there's a problem with this. It does pop open a browser. The browser would appear and the user would be like, huh, that's kind of strange. Why is there a browser on the screen? So then the question is, is there a way that we can do this secretly? If you attempt to pop open the browser and then pop open another activity on top of it, obscuring the activity actually causes the on pause event to happen, which stops the page from loading. So that won't actually work. We have to do something a little more clever. So how about we only pop up the browser when the screen is off? Your screen is off for what, 16 hours a day anyway. It's okay if we only get internet during those times. So let's say, so there's a couple things that you need to keep in mind here. You need to be able to close the browser when the screen turns back on. And you probably want to redirect to a safe URL. So when the user does launch their browser again later, they're not on some weird page. So here's the basic code that does that. You just ask the power manager if the screen is on, if it is, or if it's not, then you send off data to some server. And if it is on, then you, and the browser is displayed, then you've launched the home activity. So you just send an intent to launch the home screen. You don't even need to kill the browser because that would actually require some permissions. We can launch the home screen for free, no permissions. But so this is cool and it allows us to send data out from our application even though we haven't requested permission to do so. But what if we want to be able to receive a response too? So what about two-way communication? So there's a couple approaches here. The simplest would be to just pop open a browser to a page with a downloadable content type. So we just send it off, point it, this is it, downloads it, it puts it in the SD card, downloads directory, anyone can read the SD card, there's no permission to do so. So, but there are some downsides here. One, it creates all these notifications. So if you put your phone in your pocket and you pulled it out later, you'd have like 800 notifications or something like that. And then the other thing is that it creates all of these, it actually creates all of these files on your SD card. In order to clean that up, you need to request the write external storage permission, which isn't actually that big of a deal because if your target SDK is three, that permission didn't exist yet and you automatically request it. So if you go through the market, a lot of applications request this. So I think most people just tune this permission out. But I think we can do a little better. So how about a custom URI receiver? So Google Maps uses the Geo protocol. They just register on this Geo protocol. So like Geo, call in latitude, longitude. If you click on a link that's of that format, it pops open the Google Maps application. Now we can do the same thing with our application with no permissions. So we just request the NetHack scheme. So the NetHack protocol, the host here is data, which is basically another way to think about this. If this was the YouTube activity, the scheme would be HTTP and the host would be YouTube.com. And that allows it so when you click on a YouTube link inside the browser, instead of showing you the webpage, it pops open the YouTube app. So what we would do on the server side is we would just redirect that page that we're pointing the browser to to something like NetHack, call in data, and then append any additional information that we want to the end of it. Now I'll note that this is actually an activity and not a receiver, even though we're using it like a receiver. The reason why is because activities are meant to be things that happen in the foreground and this is meant to be used for something that happens in the foreground. This is supposed to be, you click on a link or something like that. It's not supposed to be a page redirecting while your phone is off in your pocket. So here's just the basic receiver code, because it's actually an activity. We can just log the URI and you see all the data that's associated in it. The data is available in the intent. This activity is actually, it's not seen as long as we call finish inside the onCreate. We've never created anything on the screen. The user doesn't know anything's up. And even if they did, their phone's off in their pocket. So once again, send caveat from before. You probably want to send the user to a safe page afterwards. So when they open their browser, they don't see something funky. So let's see if it works. So on the top here, I have my Apache logs. I know this is dangerous to be showing. And on the bottom here, I have ADB logcat output for my emulator here. So as you can see on the Apache logs, nothing is going on. And then if I, let me go to the home screen. If I turn the screen off, and I'll note that the emulator, this is as off the screen gets on the emulator, but really this would be a black screen. We can see here already that there's some activity happening in logcat down here. And we've got, we've got data. We are, so that's the upload. That's the upload. And then let's see if we got the response. And here we go. There's the response. My secret. So there you have it. Two-way communication with an app with zero permissions. So now that I've told you all the cool stuff that you can do with zero permissions, I'm gonna turn it over to Tim, who's gonna tell you lots of cool stuff you can do with just one permission. How many of you guys have written Android code before? All right, so I'll try to go through the, the, the interior here pretty quickly. But this is a, you know, typical example of how you, how you write data to the system logs. Most applications are doing this. And you know, it's relatively simple. It's an easy use framework. And this is how we debug a lot of stuff. So there are actually four, four different log devices that are, that are available on a typical handset. In fact, up until 2.2, there were three. And now we've seen the appearance of a fourth in 2.2. So devlog events is, is not the main application debug log. This is actually supposed to be for diagnostic events that are typically used by integrators or, or you know, people working on the core system. Devlog radio is actually a lot of, you typically see a lot of radio command stream data flying around in here. And also some interesting events about registering and unregistering from networks and that kind of stuff. And then we have devlog main is actually where you're typical, you know, log.d, log.e, whatever output from a, from an application is gonna go. So you access these logs using the log cat utility. A lot of people would probably use that and just seeing that, that typically you're gonna see a big stream of data because there's an awful lot of chatty stuff that's going on the device at any particular point in time. So ability to read the system logs is actually gated by the read logs permission. The shell account is granted this permission so that when you have ADV debugging enabled, you can do ADV log cat from a host system that's tethered through USB cable and see things. But you can kind of think of read logs as an alias for read everything as we're gonna show here in a second. And it's worth noting that the documentation on the read logs permission actually recommends that developers be careful about what they disclose in the system logs. So we put a client together and this is an Android service that only requests read logs and internet. And as you guys have just seen in this room, internet is actually just to make it easier to write the POC here. David demonstrated that that's not really required. So the client downloads a set of policies from the server and they're basically regular expressions that script the logs and feed interesting stuff back to the server component for analysis. So just to kind of flip through the structure of the client here quickly, we have a log cat device class that wraps basically the log cat command and opens that channel, sets up line oriented reader. We have a log monitor, which is kind of the core event loop here going through processing that data, matching against the filter sets and deciding what to actually deliver back to the backend. And this is all set up as a service so that it can run in the background so that we don't have to keep an activity up in order to actually do useful work. So the server is a Rails server. Basically supplies policy command and control and process the device data. So we have per device policies and it's the receiver for stuff that we're sending back to the backend. Provides an interface to explore the logs that we've collected and in a couple of cases does some interesting extraction of particularly interesting bits of data and post-processing on that. So what do I mean by policies and what are we actually doing with this stuff? Well we basically decided to kind of do a survey of what kind of data we could find in logs. Started with just a few random keywords, things like insert, update, delete. These are things that you're gonna see in SQL statements and that might be an interesting target looking for stuff that's going through SQLite. Intent, that's a core concept in the system. Content, we have content providers that are throwing a lot of data around. HTTP, anything that's protocol related. And we also put together a couple of pieces of targeted data. So things like first name, last name. A particular targeted made up phone number. Things that might be pushing through applications. And we set up this initial set of expressions and started pushing data through channels that are commonly used, different applications and then started to dig into what we found on the other side. So one of the first things that we tripped over with SQL keywords is that actually in 2.2 there's kind of a new series of log data that appeared in, excuse me, that actually appeared in the event log. And the event log for the most part at least in 2.1 doesn't seem to contain anything that makes a lot of sense when you're just kind of looking it over. But this data is a little bit more interesting. So there's apparently a hook in the SQLite driver that actually logs the first 64 characters of a sampling of queries that are run through that driver. And the sample rate is based on query execution time. We don't see every single query, but we do see some subset of queries accessing databases really all over the system. Now we didn't find any major smoking guns here, but it's something that developers should really be aware of. Don't put sensitive data directly into your SQL statements, parameterize them because they may show up in places that you didn't intend. There's a similar hook that does the same thing for content providers. And here's an example, not terribly interesting, but some data that actually is disclosed. For instance, when you're actually doing a phone number lookup in the main contact application. But like I said, we have this series of permissions that gate access to different pieces of system data. And a lot of these things actually end up turning up in the system logs. So there's actually a get tasks permission. That allows you to retrieve a list of the most recently accessed activities in the system. As it turns out, those activities, when Intense Fire the launch of those activities, those are also logged. So if you're just scanning the system logs you can put that data together and construct the same thing. There's actually a dump permission that gates access to crash dump data about applications. And lo and behold all that data also happens to be in the log so you can pull it up too. But there's some more interesting things. So there's a permission read history bookmarks which actually gates access to browser history on the device. And as we can see here, when the browser activity is launched you actually get some log data about the URL that was accessed. Furthermore, there are other applications that are on some devices. And a lot of this stuff is a bit variable between the different OEM system images that may actually log quite a bit more data. So here we can see an example of a bookmark activity which takes screenshots of pages that are accessed and keeps them in the browser UI of a Google search for something embarrassing. And also, by the way, you can see things like authentication token data here too. And Kevin and John also from Lookout talked about a pretty serious authentication disclosure vulnerability that was found out there. And this is another channel where the same kind of thing can happen. So when you're developing backends for mobile applications, be aware of the data that you're sending out may end up where you didn't expect it. Another interesting thing, there's a permission that gates of read SMS. And as it turns out, when the debug levels are turned up, which they are on some system images out there, then when you send SMS, we see not only the content, but also the recipient logged. We also found an interesting application out there that had read SMS permissions that was just turning around and logging the content of all received SMS to the system logs. So here we can pretty much scrape out both sent and received conversations only with the read logs permission. There are also components on one system that log the contact data that goes through all the fields of the activity in the contact manager. And so this actually pulls out these pieces of data and logs it here along with the label of the field that was accessing the data. And so we can reconstruct your contact database for any contact that you access. And perhaps most interesting to us in some sense, read logs can be an alias for access course location. So on GSM devices, up until 2.1, this has been fixed in 2.2 by the way, the network location provider would actually log the LAC and the cell ID of the tower that your device hops to when it connects to a new tower. That in and of itself doesn't tell us anything interesting, but we'll get to that in just a second. The CDMA, the CDMA sets, actually log the full latitude and longitude of the tower in many cases. There's a very prominent clock and weather application that runs on a lot of handsets out there that also logs the equivalent of course location data to the system logs on a periodic basis every few minutes. And I mentioned the radio logs before. The radio logs as it turns out also discolors the cell ID and the LAC in addition to the MNC and MCC. So we can actually pin down operator and location and tower identity. So what do we do with that? Well, we take that and we can use a database like the Ericsson cell ID database. And we can actually turn that into a latitude and longitude for the tower that you're talking to. And that gets us equivalent to course location. But we can actually do better because as it turns out, the full fine location data, which should be gated by access fine location, shows up in a lot of places. That same widget that I was talking about logging course location data actually happens to log the GPS coordinates as well. The underlying GPS infrastructure on several devices that we looked at is logging the latitude and longitude out of the GPS location provider and the underlying libraries are as well. Now, one thing to point out is that this only happens when you're actually actively interacting with the GPS. So it's not like you're getting constant foot by foot movement. But it is enough to put together to tell a pretty good story. Like a story about three guys who started at their office in South of Market in San Francisco, walked down to the corner, caught a cab, headed down the 101 to San Francisco International Airport where they checked in the terminal and boarded a virgin flight. And flew Southwest down to Las Vegas arriving at McCarran and you can actually see the, you can see us touching base here in the terminal going out to pick up some bags, taking a cab across town to Caesars Palace where we checked in at the front desk, went up to our room, dropped our stuff off, went over to speakers registration for Black Hat, went back down to our room to work on slides until four o'clock in the morning until we left a few days later and took another cab across town to the Riviera to check in for DEF CON 18. So now that I've talked a little bit about this, I'm gonna turn it over to Anthony and he's gonna talk a little bit about the ultimate permission. Thanks, Tim. So we're gonna rush this a little faster as we're running out of time here. So essentially we know that Android phones aren't necessarily this like perfect utopia of like open source like hardware that we can all do whatever we want with it. A lot of phones are shipping locked right now and a lot of people are forming entire communities around this idea of being able to root their phones and be able to do a lot of modification. I'm just curious, how many people in this room have an Android phone? Okay, how many people in this room with an Android phone have rooted it? Okay, how many people that have rooted a phone have not issued an update or a patch because they didn't wanna lose that method of being able to root their phone? Okay, that's good, that's good. So what are some of the ways that we're able to get root on these phones? Some of the methods that people are using are looking at older Linux kernel bugs. There've been a lot in the past few years. So basically you can look up on lists like full disclosure and see what kind of stuff is available. This is a list of all the various kernel releases for each major version of Android with a 3.0 coming out in the future which should be using 2633 or 2644. Also you can take a look at older unpatched libraries and biners that are shipping on the system. I know one of the first Android vulnerabilities that were found were back when it was still just an SDK before there's actually any hardware. It was in some of the imaging libraries. It was an overflow that Alfredo Ortega on the core team found. So pretty much a lot of the ways that we've been looking for vulnerabilities on Linux applied to Android since it's running on Linux. So let's take a look at this specific case study. This is a vulnerability that came out recently that was very similar to the LibUdevBone CVE-2009-1185 that was discovered by Sebastian Kramer. I would like to point out that we did incorrectly state at Black Hat that this vulnerability was in fact CVE-2009-1185 but Android itself does not use LibUdev but they in their implementation of handling U-Vents proceeded to recreate the exact same bug. And Sebastian took his exploit that he wrote originally for that and was able to port that to run on Android. Upon finding out when the exploit was published Android had that patched within four days which was really good to see. The exploit itself is just a failed check of the net link messages and where they came from. Did they come from the kernel or did they come from user space? So we took this and we patched it, or not patched, I'm sorry, we packaged this exploit back into JNI code to run within an APK so that we could test this on a lot of different phones. So who's vulnerable to this? We ran this APK that would root a phone and added a connect back shell to it and turns out that currently every flagship phone of every major carrier in the U.S. is vulnerable to being rooted by this right now. I would like to point out that it is fixed in 2.2, any devices that we tried with that on it didn't work which is good and as we said Android has patched this within days of finding out about it. Oops. So we feel that this is kind of creating a problem in the community. People are trying to root their phone so that they can do all this modification and they're kind of looking at rooting this as a vehicle for that and kind of ignoring the security aspect of this that while you have this small subset of people that want to do this to their phones, you have this larger population that have Android phones that have no interest in this and they're sitting around with insecure phones because people in these communities don't want to divulge details on their root processes so that OEMs, carriers can't get these things fixed. So yeah, as we talked about, we know why people are modifying their phone or rooting their phones for modification. Also another reason people are doing this is because the patching process is slow. Android is coming out with releases so fast that a lot of these OEMs and carriers that are doing a lot of heavy modification to the system, they can't necessarily pour all the changes to these new releases and make sure they're gonna work. There's a lot of testing that has to go involved. Also people are just doing this for additional features they don't necessarily want to pay for. So what can we do about this? As a user, and we've had great demonstration that using just one single permission to read logs, we would be able to steal all or most of the private data on a phone and be able to ship that off to a server and be able to communicate with that. So don't assume that a lack of permissions means that it can't actually do anything. Keep your phone patched when you have those releases. Also as a developer, the users are trusting you with a lot of this private data. So if you're asking for these permissions to read their SMS because you want to provide some third-party SMS app, don't log their SMS for everyone else on the system to see. Just be paranoid about the kind of things that you're logging. Also make use of the permissions that you can enforce on your activities or intents. Don't send intents with private data in them because anyone else can set up a receiver and be able to read that data. OEMs, you should be doing a lot of the same things that developers are doing as far as being careful about the things that you're logging in your changes to the system. If you guys aren't being a good example for everyone, I mean why should they have to worry about what they're logging if you guys are already doing it? Also keeping libraries and kernels and all that kind of stuff patched up to date would be a really great thing to see. So with that said, thank you everyone for coming. We'll be available in the Track 1 Q&A room for questions.