This is REALLY not the Droid you're looking for...
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 122 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/40620 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 1926 / 122
3
5
10
11
12
22
23
24
30
31
32
38
43
46
47
49
51
54
56
59
60
62
71
73
76
84
85
88
92
93
96
97
98
104
106
109
112
113
115
119
00:00
WaveAndroid (robot)Computing platformMobile WebUser interfaceSharewareDisk read-and-write headInformationExplosionInformation securityJava appletSoftware developerMereologyKernel (computing)RootkitLevel (video gaming)GoogolProcess (computing)Physical systemOpen sourceSoftwareFlash memoryCharge carrierClosed setGraphics tabletComputer wormBinary fileFrequencyMobile appExecution unitWeb serviceFiber bundleComputer iconTerm (mathematics)Hydraulic jumpMobile WebLink (knot theory)StatisticsInformation securityExecution unitDifferent (Kate Ryan album)BuildingKernel (computing)EmailTouchscreenAndroid (robot)Open setPairwise comparisonClient (computing)Mobile appCharge carrierQuicksortPresentation of a groupData storage deviceOpen sourceMultiplication signTask (computing)WritingBlock (periodic table)Software developerRootkitDivisorProcess (computing)Endliche ModelltheorieSlide ruleBitDeclarative programmingRight angleLevel (video gaming)Traffic reportingMereologyRevision controlSharewareUser interfacePatch (Unix)CodePoint (geometry)Vulnerability (computing)outputContext awarenessAuthorizationSoftwareData conversionFlash memoryType theoryVector spaceTablet computerGoogolSoftware development kitArithmetic progressionWebsiteSoftware testingInformationStaff (military)Computer animation
07:24
ConsistencyFocus (optics)Mobile WebUser interfaceMobile appFunction (mathematics)GoogolElectronic visual displayoutputInformation securityTouchscreenBuildingVirtuelles privates NetzwerkComputer networkServer (computing)SharewareGoogolSharewareSoftwareFacebookMobile appService (economics)Task (computing)Message passingBus (computing)Device driverWeb 2.0Software developerGoodness of fitBlock (periodic table)Functional (mathematics)outputTouchscreenTwitterQuicksortFocus (optics)Presentation of a groupMultiplication signInformationSound effectData conversionWeb serviceAndroid (robot)NumberClient (computing)EmailPhysical systemView (database)Electronic mailing listMedical imagingShared memorySystem callInheritance (object-oriented programming)Information securityProcess (computing)Cartesian coordinate systemWeb browserLink (knot theory)Kernel (computing)PlanningRevision controlBuildingSmith chartConsistencyServer (computing)Function (mathematics)ResultantEndliche ModelltheorieComputer animation
14:25
Online helpSummierbarkeitAreaPasswordView (database)Execution unitEmailMIDIGoogolSign (mathematics)GoogolLoginPasswordEmailMobile appFacebookHydraulic jumpClient (computing)Type theoryBlock (periodic table)Server (computing)Right angleReal numberSheaf (mathematics)EmulatorComputer clusterTouchscreen
17:21
Web servicePhysical systemContext awarenessGroup actionBootingAndroid (robot)Task (computing)Mobile appExecution unitWebsiteSuite (music)Sign (mathematics)Thread (computing)Server (computing)State of matterInternetworkingTelecommunicationComputer networkSystem callIdentity managementModal logicInterior (topology)Keyboard shortcutLoginSharewareInternetworkingKeyboard shortcutPhysical systemTouchscreenSharewareInformationLatent heatoutputTask (computing)GoogolAndroid (robot)Web serviceBootingMobile appCartesian coordinate systemView (database)Medical imagingFacebookLevel (video gaming)CASE <Informatik>State of matterThread (computing)PasswordMultiplication signServer (computing)Fraction (mathematics)LoginReal numberEvent horizonPoint (geometry)Service (economics)Graph coloringBuildingSoftwareInformation securityLoop (music)Telebanking2 (number)Field (computer science)Type theoryGroup actionLaptopConnected spaceElement (mathematics)Engineering physicsWebsiteOrder (biology)Stack (abstract data type)Software testingDefault (computer science)CAN busProof theory
25:50
Gamma functionVacuumOvalPolygon meshNormed vector spaceGoogolComputer fileBookmark (World Wide Web)Duality (mathematics)View (database)WindowTouchscreenLine (geometry)Revision controlMultiplication signSpacetimeMobile appRight angleRoutingCodeComputer animation
28:12
Web serviceInheritance (object-oriented programming)TouchscreenLoginSpywareMobile appSoftware developerAndroid (robot)Decision theoryGoogolFunctional (mathematics)Cartesian coordinate systemRevision controlPopup-FensterFacebook2 (number)Mobile appLoginMessage passingAuthenticationAutomatic differentiationInformation securityPerspective (visual)BitDifferent (Kate Ryan album)View (database)Multiplication signComputing platformSoftware developerServer (computing)PasswordoutputType theorySingle-precision floating-point formatComputer animation
Transcript: English(auto-generated)
00:00
So the talk that you're in is this is really not the droid 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 a fun journey today. I'm actually personally really excited about this talk. I know Sean is as well. And so I'm going to jump in,
00:23
brief agenda just to tell you where we're going to take you, what journey we're going to talk about, a little bit of primer history. I personally feel it's really important. Very often presentations jump into deep technical concepts from the get-go. We're going to sort of
00:41
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. 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 going to show you
01:03
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 we'll conclude. So some introductions. I'm Nick Percoco. I'm the head of the Sputter Labs team at Trustwave. I started
01:21
my InfoSec career in the 90s, mid-late 90s and I was really just started out as a pen developer this weekend with Paul Kerr who's sitting in the audience over there tomorrow doing a mobile SSL talk called Getting Slizzered. I'm also the primary author of Trustwave's Global Security Report. And so here's Sean.
01:42
I'm just a back-end developer for the SSL team. So this is the first time I've done anything like this. Not quite as experienced. I hope you enjoy it anyway. So what is this talk all about? This is part two from a talk I was part of last year. Did anybody see
02:02
that talk last year? Okay. So a handful of folks. So that really focused on it was a kernel level rootkit. So the whole idea was what are the implications of a rootkit getting on a mobile device. And so we explored that and really raised awareness about the risk and implications of rootkits 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
02:27
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 what tricks we can play using
02:44
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
03:03
layer 7 O day in the process. And so we're going to talk about what that is. So just to jump into a 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 raised your hand.
03:24
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 how has it evolved? Well, they released probably a new OS
03:41
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. So that's pretty cool. And then ProYo came out. That one got pretty
04:02
popular. It was fast and had flash, which everybody knows is great. And since then it's been a little tougher 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 just to keep in mind and talk to us on the other
04:25
side. So the percentages we have there is something that, Sean, you pulled from stats from. It's from Google, the Google stats. And it's a couple of 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
04:41
developed 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
05:03
devices. And usually there's an 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
05:23
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? I'll just take a little bit of
05:40
this. Basically it's the place where you buy apps. Everybody here in this room has Android phone or Android mobile device, tablet, whatever they have. That's where you get your apps from. 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
06:03
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. 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 that I guess I
06:22
think about in comparison to Android versus the iOS and 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 an interview conversation. And I basically decided 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
06:43
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
07:04
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
07:25
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
07:42
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 themselves, 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,
08:01
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
08:21
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. But you open up your app to do
08:41
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. It should be consistent. You don't want to have to re-implement
09:00
everyone else's functionality in your own app because then it wouldn't work the same and it wouldn't look the same. So you use 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're going to remember that and come back. So you can see on those images there, that's a little task. I took a picture and wanted
09:22
to tweet it. So that's how you select the share and it lists off everything, all the apps that can receive a picture and act on it. You choose Twitter and then you can go tweet the image. And the consistency of these pieces is also extremely important from a security standpoint because your users, you want them to expect certain activity that are going
09:44
on in their applications. So there could 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 fun. Google tells all developers not to override the behavior of the back
10:03
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.
10:20
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 and another one we're having a text conversation. And then later I wanted to go back and text someone else so I opened up the Google Voice app and it 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
10:43
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 a notification and don't just jump in front of them. That's not really what you
11:03
want to do. That's not what the 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
11:24
initially a side effect of some other research that Paul Cara and I were doing for the Getting Sizzler 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. Basically, you'll see what we mean when we get further into this presentation. But basically a lot of research
11:43
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
12:03
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
12:23
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 on a bus, jumping in a cab, boarding a plane. And you glance at
12:44
your device sometimes very quickly and respond to messages. It could be Twitter messages. You could be on Facebook. You could be anyplace. 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
13:02
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, you know, 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
13:24
that 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. The user downloads the app. The app is able to steal credentials from popular apps. The
13:45
users expect nothing with their device. And so that's exactly what we're going to show you. So Sean is 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 8 Ball. And since this is somewhat of a Star Wars theme talk, I told
14:06
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. I guess 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 some credentials being stolen while we're actually playing with those apps and logging into
14:23
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
14:51
out of it. That's a lot of fun. And then you're bored. You're bored and you have to get out of there. So all right, I'm going to go log into Facebook now. All right, so
15:05
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 log in button. Facebook seems to be acting
15:21
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 is on an actual phone, we 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 user name 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
15:42
that. And it's really any app that has a log in 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
16:08
it's also acting weird. If you wanted to make this a real attack, you'd probably not have it attack 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
16:23
jump over Google Voice. Same thing if you want to get someone's Google password. This looks exactly like the Google Voice log in screen. And there is that. So any app that
16:52
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
17:01
Bantha Poodoo or any other app that's trying to be malicious, it can run in the foreground 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. Yeah, I'm going to run through what you have to do to actually do that. It's
17:24
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.important system service. So if the user goes and looks at their running services, they're going to
17:41
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 will 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
18:03
phone starts up, I receive this and I start the important system service. And that way I showed you that I opened up Bantha Pooda 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 Bantha Pooda is just sitting in the background, you don't have to actually use it but it
18:23
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. You just have to look at them and figure out how they built their screen. You take screenshots, you cut their images out. In the case
18:42
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. 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
19:02
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. 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
19:20
user to enter their 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 is running every two seconds. It doesn't have to be that aggressive. But it's a ‑‑ it's not an expensive task to check this out. So you ask the system service to get the actual
19:43
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 ‑‑ you find the one that has importance foreground. That means it's running in front and that's what the user is currently
20:01
looking at. So as soon as you find that one, I build 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. So it's not going to be in the same stack as their actual task. What that will do for me is that if they hit home and
20:33
leave and then go back to the app through the app switcher, if I didn't do the new task here, it would ‑‑ they would come back in and come back to my app and that would be
20:41
the one in the foreground. But if I do the new task, they'll do that and go back to their app where they were before where I can attack them again. 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
21:03
real world scenario, the person would actually launch Facebook, see their timeline on the screen ‑‑ for a fraction of a second ‑‑ for a fraction of a second and the log‑in screen would pop up. But what he's saying is what you saw in the demo, I Facebook hit log‑in and it went away and there was another log‑in screen and then another
21:21
log‑in screen on top of it. Normally you're authenticated to Facebook so there wouldn't be a stack of log‑in 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
21:42
image. So you just have to mimic that and 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 you built, use this one and it's activity specific. So each one of my ‑‑ each one of
22:05
my attacking screens looks like it wants to. Just like any other activity can. And so this one is crucial. You override the back button so that when they come to your log‑in screen and they hit back, not only do we want to go back to the app they were in before,
22:26
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
22:47
behavior pretty starkly. And 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 password in and we
23:11
receive that intent, it fires up a new thread where it just uploads it to a server. That's what Google wants you to do. They don't want you doing network IO on the UI thread so you
23:22
just spin it off on a background thread in the service. It doesn't delay the user. 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
23:41
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. 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
24:02
the market website when you try to download an app with these exact permissions. 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 everyone away from downloading any app for any reason. And
24:24
here in the ‑‑ I just have a couple more tidbits for you. 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
24:42
do it, you can do it too. And no history is 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 will show you all the apps that you've recently run. But if we started up and we ran into the background and we're attacking you and then they're
25:03
switching apps with the app switcher and they see Bantha Poodoo in there and they're like I haven't played Bantha Poodoo 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 running. So it's kind of cool that you can do that too. So we have a second demo here. What we
25:23
want to do is we're going to modify Bantha Poodoo. Remove its credential upload capabilities. Because we don't actually want your 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. And also hopefully they're not watching. And then you can download it and
25:41
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 add 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
26:05
comment that line out so it doesn't actually upload. Now I'm going to build a package
26:25
and export it. Like I said the original version was magic 8 ball. I think that's why it's still called that. I call it Bantha Poodoo. That's right. I mean if they can make it
26:50
you can make it. There's nothing special about it. I mean so this is the one we just
27:19
packaged today 927 p.m. central time. So if all goes well everybody in this audience can
27:27
actually go and download this app. Somebody took my name. So we're going to do a package name. I tried that a little while ago and it was free. So I guess that one is in
27:41
there as of recently. So it will take me a little while to rejigger the package name. I have to change a bunch of things around in the code and I need a little more space in this. But we'll release this to the market later on. We wanted to let you download it right now. But it will be this weekend or next week. And there actually is a version of it.
28:02
Earlier version of it on the Def Con DVD. So you can play around with it right now if you wanted to load it on manually. So let's go back in to the presentation. And basically some other thoughts on how to weaponize. Obviously the functionality in the app that we
28:21
released, it's not the greatest from an attacker's perspective. There's some quirks, there's 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
28:44
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. We set ours, what is it set at? It's every two seconds. I mean it doesn't need to be that aggressive. And even if it is, if
29:00
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. I mean that could be a legitimate thing. It happens actually pretty often in bank applications that they for security reasons want to make you reauthenticate so nobody just picks up your phone and uses it. So that exact
29:21
security feature can be dangerous. So get people used to that. So then we also were 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
29:41
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
30:03
someone wants to make a new social network or a new app and they don't want Facebook to work quite as well for you, for example. So every time you open up Facebook, you know, some crap pops in front of you and then goes away after three seconds or doesn't. And it just gets really annoying because you can just screw with other people's apps and
30:24
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 goes to play Angry Birds, your version pops up in front of them and they decide to uninstall Angry
30:42
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
31:02
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
31:22
because you can't monitor 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
31:47
just that. Yeah, so that's our talk. I guess we have a little bit of time. Does anybody have any questions?