 So the talk that you're in is, this is really not the joy you're looking for. And I want to thank everybody for coming here during the dinner hour. I'm Nick, and this is my co-presenter, Sean. And we're going to walk you through some fun journey today. I'm actually personally really excited about this talk, and I know Sean is well. And so I'm going to jump in, a brief agenda just to tell you where we're going to take you, what journey we're going to take you on this evening. So we'll go through some introductions, talk about a little bit about primer history. You know, I personally feel it's really important, and it's very often presentations jump into deep technical concepts from the get-go. We're going to sort of build everybody up to the same level, and we dive into some of the technical pieces. And then we're going to talk about some research motivations. Before that, we'll talk about some mobile user interface do's and don'ts, some implications. We'll do a demo. We're going to have a live demo. And then Sean's going to jump into a deep dive on how our demo works. We're going to do a little different in this talk. We're actually going to show you the demo first before we do the deep dive. You'll see why. And then we'll do a second demo, which will be a lot of fun as well. And then we'll conclude. So some introductions. I'm Nick Prococo. I'm the head of the Sputter Labs team at Trustwave. I started my InfoSec career in the 90s, mid-late 90s, and I was really just started out as a pen tester. This is my fifth DEF CON talk. I actually have one more this weekend with Paul Kerr, who's sitting in the audience over there tomorrow, doing a mobile SSL talk called Getting Sizzard. I'm also the primary author of Trustwave's Global Security Report. And so here's Sean. I'm just a backend developer for the SSL team. So this is the first time I've done anything like this, not quite as experienced. I hope you enjoyed anyway. So what did this talk all about? So this is part two from a talk that I was part of last year. Did anybody see that talk last year? Okay, so a handful of folks. So that really focused on, it was a kernel level root kit. So the whole idea was what are the implications of a root kit getting on a mobile device. And so we explored that and really raised awareness about the risk and implications of root kits on mobile devices, what they're capable of. But we didn't really touch on anything in user land at all. This year, and so after the talk last year, I was thinking I really would like to do another Android talk and what are some things we can do. And we'll talk a little bit about how we actually came to start doing this research. But basically this year, we focused 100% in user land. We just wanted to focus on the user interface, 100%. The whole idea is of what tricks we can play using available APIs. Nothing out of the ordinary. All the APIs that are available in the Android SDK. And then really what did Google allow developers to do? What are some sort of bad things can we do with the APIs? And in the process, we discovered basically a Layer 7 ODE in the process. And so we're going to talk about what that is. So just jumping into primer. We're not going to spend a lot of time here. I'm sure everybody knows what the Android OS is. How many people here have Android devices? Okay, that's going to be fun. So basically everybody knows, the majority of you raise your hands. We're not going to spend a lot of time here, but it's a software stack. It's developed for mobile devices. And really, the kernel is Linux. And it's basically all we need to talk about here. And then how has it evolved? Well, they released probably a new OS version a little more than once a year. And a few years ago is when it really started to get good with 2.1, the Donut Declare. And they introduced the slide from write animation that lets them make it seem like you're in the same task even if you're opening different apps. And so that's pretty cool. And then Froyo came out. That one got pretty popular. It was fast and had Flash, which everybody knows is great. And since then, it's been a little tougher than to get updates. They got Gingerbread, and not so many phones have those. And Honeycomb is just tablet only and closed source. So maybe they'll open that one up. Yeah. And so one thing to note here, just to keep in mind that we're talking about on their side, so the percentages we have there is something that, Sean, you pulled from stats from on the... It's from Google. The Google stats, and it's a couple weeks out of date. So it might be percentage points off now. Yeah. So that's the user population. So just something to keep in mind as well. We're talking about updates. So Google actually develops Android closed inside Google. They don't let you look at the code as they develop it. They don't let you submit patches. And then when they release the new version, then they publish a source sometimes. And there's usually... When they do open it, there's a delay anyway. And they give you the stock Android only on a few devices. And usually there's a HTC Sense or other OEM customizations that take a while for them to update. And that's why people aren't getting up on Gingerbread because it's been taking them a while to update that stuff for the newer versions. And they're trying to fix that and work with the carriers to get them to update. But the carriers say they have really no incentive to try that. So we'll see if the updates get better. And they need to because people come up with security updates that need to get pushed out. Right. So what is the Android market? So I'll just take a little bit of this. Basically it's the place where you buy apps. Everybody here in this room has an Android phone or Android mobile device, tablet or whatever they have. That's where you get your apps from. Yeah. And unlike some other app stores that check your apps and have to approve them to get in, which can take some time, the Android market does not approve any apps. And when you submit it, they're available immediately. And they don't check that you're not doing anything malicious before they send it out. They can... If they discover that you are, they can take it out of the market and they can remotely delete it from phones. But it's a less proactive approach to protecting the users. One thing I guess to think about in comparison to Android versus the iOS, Apple devices, I was recently asked, if you were going to have to attack either of those devices, what method would you use? And just sort of interview conversation. And I basically said if I was one of the attack Android users, I would use the marketplace. I would use the Android market. If I wanted to attack iOS users, I'd use a jailbreak vulnerability to go after that user base. So that's a very different model there as well from an attack factor standpoint. So when you're developing for Android, there are just a few basic building blocks that you really want to use to put your stuff together. The most basic unit of an Android app is the activity. That's just a screen that sits in front of the user. All the UI that you build is in an activity. And you can bundle up some data in an intent and publish that intent that other apps can register that they care about that intent, that type of intent. And so, for example, if you open up your email client and you click a link, that link is put into an intent by the email client and the Android system sees, oh, well, I know the app that uses that link so you open directly in the browser instead of requiring the email client to implement their own WebKit view or something. So that's how they implement their goal of having task-based UI with using different apps. And then if you want to run anything in the background, you have these services. So the app itself, once you hit the home button or something and you leave your app, it's not continuing to run unless it registers as a service, which doesn't have any UI in it, obviously, but can perform tasks and network I.O. and play sounds, I think. But when you want to get the user's attention from the background, your service can receive some information from the network and pop up a notification. That shows up in the top bar, and those are pretty easy to deal with. And that's really the primary way that developers should be getting a user's attention when they're not in focus. So when you're making an app, you want to be simple, consistent, and get the user's attention because you want them to use your app. They open up your app to do one thing at a time and really one thing only. So each screen should be focused on one purpose and just do one thing, and it should be obvious what you're doing. Sometimes you're going to be reading a tweet or making a phone call or looking at sports scores. They also need to be consistent. You don't want to have to re-implement everyone else's functionality in your own app because then it wouldn't work the same and it wouldn't look the same. There are other apps to perform the stuff that people are going to be doing in yours and they'll get back to you with the back button and if you send them away then they'll remember that and come back. So you can see on those images there that's a little task. I took a picture and wanted to tweet it and so that's how you do it. You select the share and it lists off everything, all the apps that can receive a picture and act on it and you choose Twitter and then you can go tweet the image. It's also extremely important from a security standpoint because your users, you want them to expect certain activity that are going on in their applications and so there can be security implications of that and we're going to show you some of those. Those images, by the way, that was me tweeting an image of my iPad getting a kernel panic, so that's fine. Google tells all developers not to override the behavior of the back button. They want the back button to behave consistently across everything. So when you send an intent, or someone sends an intent to you and the user expects to hit the back button and go back to the place they came from for this task-based model but in some of Google's own apps they don't really do that very well. This example here is the Google Voice text messaging app. I received a text message from a friend of mine, responded to it and left the app and then got another one. We're having a text conversation with someone else, so I opened up the Google Voice app and they brought me back into this conversation. That's about what I would have expected but then I hit the back button to go back to the list of conversations and select a new one except it brought me back to the same conversation I was already in and I had to hit the back button the same number of times as the number of times I received a text message in that conversation and they probably should fix that. So what's important in getting a user's attention is to use notification and don't just jump in front of them. That's not really what you want to do. A user wants to see and you just really shouldn't do that. But of course that's just a best practice and you don't have to follow best practices on Android. So when we think about sort of research motivation so why did we do this research? This was initially a side effect of some other research that Paul, Paul Kerr and I were doing for the Getting Sizzard talk. We noticed a quirk in one of the apps we were starting to work with and then we started talking to Sean about it. But basically you'll see what we mean when we get further into this presentation but basically a lot of research focuses on breaking things so you want to find some malicious input that's going to cause some bad result. And so the input's malicious, the output's bad and that's a lot of what happens in our industry. But we wanted to raise the question and sort of go down the path of saying what can we do by using good building blocks, good things, good tools, approved, valid APIs and could the output be bad? So that was really a big driver in the motivation. And then the other piece is that mobile often sacrifices security for screen size. So we're going to show you when we show you the demo when you're sitting at your desk and you're sitting and you have a 27 inch screen in front of you and something goes awry from a security standpoint or some application is having a problem you can see that and you can recognize it because you're sitting idle, you're just sitting there. You might be eating some Cheetos and surfing the web. But when you have a mobile device you could be walking down the hall, you could be jumping out of a bus, jumping in a cab, boarding a plane and you glance at your device sometimes very quickly and respond to messages. It could be Twitter messages, you could be on Facebook, you could be any place. And when there's things that go awry it may not be apparent. Sometimes it may not be apparent to security people. It's definitely going to be apparent to your grandma. So that's another piece of the research motivation and then we also want to see how far can we push the end user? How far can we push them using valid APIs to do bad things? And then some of the research implications and so we're going to talk about one of them here and we'll have some more at the end but basically consider the following scenario. An attacker builds an app using approved APIs. These are things that if even if Google was doing some filtering within their app submission process they wouldn't be able to detect. They submit the app to a public app market. In the Google market example it's approved immediately and available for download. The user downloads the app. The apps able to steal credentials from popular apps. The users expect nothing with their device. And so that's exactly what we're going to show you. So Sean's going to do a demo in a few minutes. What we're going to do is we're going to play with an app called Bantha Pudu. I think the original version of the app was a magic eight ball and since this is somewhat of a Star Wars themed talk I told them that we need to call it something like Bantha or Bantha Pudu. And of course you'll see what we put it within this app because it's maybe slightly offensive but you'll see. So we're going to play with some popular apps and you're going to see its credentials be installing while we're actually playing with those apps and logging into those apps. So right over here I have my server over in Russia where I'm trying to steal everyone's passwords. And here this is just some user who went to the market and he downloaded this cool app that everyone was talking about. And so you get a kick out of it. That's a lot of fun. And then you're bored but you're bored and you have to get out of there. So I'm going to go log into Facebook now and Facebook is telling me I have to log in, that's fine. Usually when Facebook tells me to log in I'll just do that. So I'll hit the login button. Facebook seems to be acting weird so I'm just going to leave. And over here in Russia you see device ID on the emulator is always zero. So if this was actually on an actual phone we'd get the real device ID that's unique across all the devices. And then I know that somebody logged into Facebook and here's the username and here's the password I typed in. I guess you're going to have to trust me that that's the one I typed in because they kind of blocked that. And it's really any app that has a login screen. If they can make it, you can make it too. So jump over here on the email. The email client wants me to log in and it's also acting weird. If you wanted to make this a real attack you'd probably not have it attacked so aggressively and as soon as they type in their password you ask them again. You could go away. But here's the one I just typed in there and then jump over Google Voice. Same thing if you want to get someone's Google password. This looks exactly like the Google Voice login screen. And there is that. So any app that wants to let you log in has to ask for your username and password. And if they can do it then someone else can do it. And the problem is that once the user installed Bantapudu or any other app that's trying to be malicious it can run in the background and it can know what app is running in the foreground and it doesn't have to use a notification to get your attention. It can just jump out in front. Yeah, so what we're actually going to do is we're going to do a deep dive. I'm going to run through what you have to do to actually do that. It's painfully not complicated actually. So the first thing is that you need to register the service. You're going to run in the background and the point is to monitor what's happening on the phone. So you register your service and you call it org.android.importantSystemService so if the user goes and looks at their running services they're going to think that's important and it's from Android so I'm not going to quit it. And you see here it's using an intent filter that we'll let it respond to and send some intents. Here I've set up a receiver that receives the boot completed event so every time the phone starts up I receive this and I start the important system service and that way I showed you that I opened up Bantaputa and played with it but you don't have to open it. If you install it and then go away and your phone restarts or whatever and Bantaputa is just sitting in the background you don't have to actually use it but it starts up, it's running and you don't ever need to know that I'm attacking you. So then you decide which apps you want to attack and you just have to look at them and figure out how they built their screen. You take screenshots, you cut their images out you can, in the case of Facebook I decompiled their APK and took their assets, sorry. And then just set up a map of the package name to the activity, the package name of the app to the activity that you're using to attack it with. And this could be any application. So we just chose these four for this proof of concept but this could be an online banking application this could be a VPN credentials it could be any type of application you want and it doesn't necessarily just have to be credentials it could be a data input field in a specific app that you know is always there or always there on startup and you could ask the user to enter that information that you want to gather from them. So then in your service you set up a timer that's going to run every so often this one's running every two seconds it doesn't have to be that aggressive but it's not an expensive task to check this out. So you ask the system service to get the actual Android system service to give you the activity service and that's going to let you monitor what activities are currently being run and so you loop over all the running activities and here importantly you find the one that has importance foreground that means it's running in front and that's what the user is currently looking at. So as soon as you find that one I build a new intent and I put the... I tell the intent that it's going to be an activity new task so it knows it's going to pop up a new screen in a different application in a new task and it's not going to be in the same stack as their actual task. What that'll do for me is that if they hit home and leave and then go back to the app through the app switcher if I didn't do the new task here they would come back in and they'd come back to my app and that would be the one in the foreground but if I do the new task they'll do that and they'll go back to their app where they were before but I won't be the one in front and then I just start that activity. One thing we didn't show in the demo which would mostly be apparent in many users you typically don't log in to your say Facebook app for the first time so in the real world scenario the person would actually launch Facebook see their timeline on the screen for a fraction of a second and the login screen would pop up. But what you're saying is that what you saw in the demo when you hit login and it went away and there was another login screen and then another login screen on top of it normally you're authenticated to Facebook so there wouldn't be a stack of login screen waiting for you. Anyhow, so you have to when you're building these views some of them leave the bar on at the top some of them get rid of it some of them customize the color some of them just use their own image so you just have to mimic that you just ask Android the same way they do when they legitimately make their app you say I want to use a custom title bar or I don't want there to be a title bar at all and if you're using a custom one you pick which custom one that you built you use this one and it's activity specific so each one of my login each one of my attacking screens looks like it wants to just like any other activity can and this one is crucial to override the back button so that when they come to your login screen and they hit back not only do we want to go back to the app they were in before which would be the default behavior of the back button we want to get rid of this task so this move task to back is kind of like a quit it throws the task you were in the new task we created with our intent to the back of the activity stack that it changes behavior pretty pretty starkly and it it's something that Google may actually want to do in their Google voice app so once we have the credentials we get them to type the user and password in and we ship that off in another intent to our service that's running in the background and when it receives that intent it fires up a new thread it just uploads it to a server that's what Google wants you to do they don't want you doing network I.O. on the UI thread so you just spin it off on a background thread in the service so it doesn't delay the user and if your network is slow you're just going to continue and you're not going to worry that you have to wait to send me your password and here in order to do this stuff Google does require you to have security permissions and the thing is you just ask for them and people go to the market and they see this app needs to use the internet and view the phone's state most apps need to do those things and the boot completed event doesn't even show up in the market like I want to know that you started your phone and Google doesn't think you really need to know that so I have a picture here of what you see on the market website when you when you try to download an app with these exact permissions it doesn't it looks it looks a little innocuous and in some ways they want it to be because apps need to use this stuff they don't want to scare you going away from downloading any app for any reason and here in the I just have a couple more a couple more tidbits for you that sometimes you want to make sure that some of the apps resize the elements on the screen when the keyboard pops up and some don't sometimes the keyboard slides up in front of things if they can do it, you can do it too and no history is it kind of a cool one that way when they leave your app like they come to your app and then they leave it normally if you hold down the home button it'll show you all the apps that you've recently run but if we started up and we ran in the background and were attacking you and then they're switching apps with the app switcher and they see Bantapudu in there and they're like I haven't played Bantapudu for two weeks we don't want them to see that so we tell it no history it doesn't show up in the app switcher when it's not when it's not running so it's kind of cool that you can do that too so we have a second demo here and so what we want to do is we're going to modify Bantapudu remove its credential upload capabilities because we don't actually want their passwords and we're going to submit it to the Android market I guess we hope we have internet connectivity here from this laptop here but they're not watching and then you can download it and try it yourself so you can play with it on your phone but we will guarantee you will be annoyed you should uninstall it pretty quickly especially if you use any of those apps that we're jumping in front of so here I've got my ad credentials receiver I don't have a lot of screen space though so as you can see I am uploading here and I'll just comment that line out so it doesn't actually upload now I'm going to build a package and export it like I said the original version was Magigate Ball I think that's why it's still called that I'm going to call it Bantapudu yes I do that's right if they can make it, you can make it there's nothing special about it I mean this is the one we just packaged at 9.27pm central time so if all goes well everybody in this audience can actually go and download this app somebody took my name I tried that one out a little while ago and it was free so I guess that one is in there as recently so it'll take me a little while to rejigger the package name I have to change a bunch of things around in the code but we'll release this to the market later on we wanted to let you download it right now but it'll be this weekend or next week and there actually is a version of it an earlier version of it on the DEF CON DVD so you can play around with it right now if you want to load it on manually so let's go back into the presentation and basically some other thoughts on how to weaponize obviously the functionality in the app that we released it's not the greatest from an attacker's perspective there are some quirks there are some things that would be annoying to end users but basically one of the concepts is being able to phone home to a server and have that server successfully check for the authentication to make sure that authentication is valid and then send a message back to the app to say stop popping in front of the Facebook application we already know their username and password and then a couple other things is showing the login screen after they've been in an app for a while what is it set at? it's every two seconds it doesn't need to be that aggressive and even if it is if it checks every two seconds it doesn't have to put it in front of you every two seconds it can wait ten minutes while you're using the app and if it's open that long maybe the app wants you to authenticate again that could be a legitimate thing it happens actually pretty often in bank applications want to make you re-authenticate so nobody just picks up your phone and uses it so that exact security feature can be dangerous to get people used to that so then we also we're thinking about this and there's some other uses to this design flaw it's not just stealing credentials so unfortunately this may be coming to your phone very soon app targeted pop-up ads so basically what that means is that if you're in one app and you download an app that has this features and functionality in it they can decide that hey you're in Facebook, I'm going to throw ads in front of you while you're in your phone and you're using those applications the other idea is hijacking competitors apps so someone wants to make a new social network or a new app and they want they don't want Facebook to work quite as well for you for example so every time you open up Facebook some crap pops in front of you and then goes away after 3 seconds or doesn't it just gets really annoying you can just screw with other people's apps and there's nothing they can really do to stop you from doing it another thing you can do is say you're an Angry Birds competitor you can embed a really crappy version of Angry Birds into your app and every single time someone Angry Birds your version pops open in front of them and they decide to uninstall Angry Birds and then there's other ways that you probably can think of that you can be a jerk so some conclusions here that we can talk through really approved APIs can be used to create malicious apps and that's basically what we did here this is specifically a design flaw where these APIs are not restricted in this type of use and Google really has to change that because not restricting developers from doing whatever they want to is a disaster waiting to happen that iOS doesn't suffer from this because you can't monitor who is what app is running and you can't put something in front of the user without their direct intervention and they have different animations for switching between different apps versus switching between views in the same app those are the three key differences that allow this and it's not just this that's the problem it's the fact that developers can do whatever they want on the platform that's our talk I guess we have a little bit of time does anybody have any questions