Bypassing Android Permissions From All Protection Levels
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 | 85 | |
| 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/62235 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Software developerDistribution (mathematics)Energy levelAndroid (robot)Default (computer science)Default (computer science)Different (Kate Ryan album)Revision controlCombinational logicService (economics)Mechanism designPresentation of a groupMathematicsGroup actionCartesian coordinate systemType theoryPhysical systemEnergy levelCategory of beingRun time (program lifecycle phase)Moment (mathematics)MereologyInternetworkingAbsolute valueSmartphoneLoginNumberVirtualizationEndliche ModelltheorieNatural numberVideoconferencingMultiplicationInformation securityComplete metric spaceAndroid (robot)Electronic mailing listComputer fileProxy serverField (computer science)StatisticsShared memorySoftware engineeringDigital video recorderCodeRandom number generationNormal (geometry)Uniform resource locatorProcess (computing)Context awarenessSet (mathematics)Multiplication signInstallation art10 (number)TowerComputer animation
08:43
Normal (geometry)Physical systemAndroid (robot)Server (computing)Thread (computing)Exception handlingString (computer science)Revision controlComputer iconGroup actionView (database)VolumenvisualisierungAuthorizationRegulärer Ausdruck <Textverarbeitung>Network socketJava appletReal numberResource allocationPrincipal ideal domainLoginServer (computing)Android (robot)Cartesian coordinate systemInformation securityGroup actionException handlingInternetworkingComputer animationSource code
09:35
Proxy serverPhysical systemAuthorizationAndroid (robot)Server (computing)String (computer science)Graphical user interfaceAndroid (robot)Proxy serverLoginVirtualizationServer (computing)TelecommunicationRandom number generationLetterpress printingInternetworkingXML
10:13
Game theoryPhysical systemAuthorizationServer (computing)String (computer science)Android (robot)Graphical user interfaceLie groupDigital filterGroup actionAbelian categoryDefault (computer science)Revision controlView (database)AdditionCodeRandom number generationServer (computing)Numbering schemeConfiguration spaceCategory of beingCartesian coordinate systemSource codeJSONXMLComputer animation
10:51
Android (robot)AliasingAbelian categoryGroup actionDefault (computer science)Digital filterSimulationMaxima and minimaCodeString (computer science)AuthorizationPhysical systemGraphical user interfaceVideoconferencingHill differential equationDefault (computer science)Service (economics)Web browserLink (knot theory)Cartesian coordinate systemNumbering schemeDataflowDiagramGoogle ChromePhysical systemView (database)Web 2.0Logical constantAndroid (robot)Information securityTouchscreenEnergy levelMechanism designNatural numberMobile appAdditionContent (media)Structural loadComputer wormCategory of beingAddress spaceQuery languageGraphical user interfaceServer (computing)Presentation of a groupSet (mathematics)Keyboard shortcutConfiguration spaceInformationState of matterUniform resource locatorGroup actionUniqueness quantificationImplementationWindowOverlay-NetzInteractive televisionMereology1 (number)File formatConnectivity (graph theory)TelecommunicationInternetworkingCodeLengthVideoconferencingContext awarenessComputer animation
19:57
View (database)Maxima and minimaAndroid (robot)MiniDiscWorld Wide Web ConsortiumIntelTouchscreenComputer wormMarkup languageVacuumReal numberSystem callAndroid (robot)Cartesian coordinate systemCombinational logicEnergy levelSystem callGroup actionCountingLengthInformation security2 (number)GravitationClique-widthPoint (geometry)Message passingRun time (program lifecycle phase)Inheritance (object-oriented programming)DialerOverlay-NetzNumberDifferent (Kate Ryan album)Vector potentialExploit (computer security)View (database)Server (computing)Normal (geometry)TouchscreenLimit (category theory)Multiplication signIntegerComputer wormGame controllerTelecommunicationMobile appLink (knot theory)Video gameSoftware testingWeb browserCrash (computing)Exception handlingTask (computing)AverageFocus (optics)BitTouch typingReal numberDefault (computer science)BuildingComputer animation
28:59
Revision controlAndroid (robot)RAIDComputer iconWeb browserGraphical user interfaceNavigationSystem callWeb pageUniform resource locatorOverlay-NetzCombinational logicDialerCartesian coordinate systemEnergy levelCASE <Informatik>Group actionComputer animation
Transcript: English(auto-generated)
00:00
So now this is Nikita Korten, who's going to talk about defaults, defaults. So hello, everyone, and thank you for joining me here today.
00:22
My name is Nikita Korten. I'm a software engineer and a security researcher. And while I'm not researching or developing anything, usually you can find me training the street workout calisthenics. For example, in this picture, I'm doing Eiffel Henstand in front of Eiffel Tower here in Vegas.
00:45
And today, I want to share with you some work I did in the field of the research of Android permissions, which I call defaults, defaults. As I found how to bypass different permissions from different protection level, actually
01:04
from all protection levels using just default services in Android. So first of all, a little bit of statistics. At the moment I was making this presentation, I looked into Google for the last statistical data.
01:21
I found that Android holds 72% of the market share of Android in the world. Sorry, market share of all smartphones in the world, which is a little less than they have in the previous years, but the absolute number of smartphones increased so much that this is actually
01:41
more than they have previously. Android OS has 32 distributions, or as it's called, officially API levels. And it runs on over 3 billion active devices, 3 billion. Think about it. This is me, by the way, trying to imagine how 3 billion
02:01
active devices looks like. So why it's important? You can imagine that everything that is happening in Android, every technique that works there, every bug, has a very huge impact. Because of the nature of Android, there is no particular version or a particular device model
02:23
that dominates the world completely. Instead, it's distributed across multiple API levels, multiple device models. But even if you take one particular combination of version and device model, let's say that has 1%, still 1% of that is tens of millions.
02:44
So this is how the impact is heavy. So let's dive into permission mechanism. Now, because there were a lot of changes in the permission mechanism in the last few years, I'm trying to focus on this presentation in the most solid concepts.
03:03
So first of all, all Android permissions can be divided into three permission types, or categories, if you wish. First, it's install time permissions. Now, install time permissions is basically permission that's enabled right after the application is
03:21
installed on the device. So you can say that the allowance of this permission is the action of installation. Above that, there is a runtime permission from dangerous protection level. And as the name suggests, this permission protect the more dangerous abilities,
03:41
the more serious resources. Such a permission, it is not enabled right after application is installed on the device. Instead, application needs to check whether the permission that allows to do the access, the ability it needs, or the resource
04:02
is allowed at that particular moment at runtime. And if not, then it will trigger the built-in alert where the user can either allow this permission or deny. And to be even more precise, actually, there is a smaller category in that of very few permissions.
04:23
For example, location permission. In that case, when the alert is triggered, then user cannot just allow or deny the permission, but also allow for one-time usage. Anyway, above that, there is the top highest protection level
04:41
called special system permissions. And this is very unique and very rare permissions. They're intended for system-level interaction, and their job is to protect the most powerful actions. And for that reason, it cannot be allowed from the application
05:00
context. The users actually need to go outside of the application context to the advanced settings and enable this permission for that particular application explicitly in advanced settings. Now, from the API perspective, all permissions that application wants to use from all protection levels
05:23
must be declared in manifest, which is basically an XML file. Now, in this example, you can see a list of different permissions that the application use. So some of them from a normal protection level, some of them from a dangerous protection level,
05:40
and some from special system permission. But you can see that all of them appear in the Android manifest. If they are not declared, they cannot be used at all. This is the most basic thing in the permission mechanism. Now, because of that, since all the permissions that application is using must be declared in manifest,
06:00
that makes it very easy to manage and very easy to check which permissions are used. This is how, when you are uploading your application to Google Play Store, Google Play Store knows which permissions are used. Or when the application is installed on the device, this is how Play Protect can scan, extract the manifest, and know exactly which permissions are used.
06:23
And obviously, any other security external tool doing exactly the same thing. So before you download the app, you can see which permissions are used. For example, in this screenshot, we can see that this application is using this list of permissions. And obviously, the more permissions
06:41
the application is using, or the higher protection level of these permissions are, basically it means that this application can do more things. The more things it can do, it's more privileged. But everything I said until now, this is just the documented part.
07:01
Now, the undocumented part ahead. Below that, there is something I call default protection level, or default permissions. It's not an official name for that. It's just the way I call it. But the idea is that default permissions is basically all these magical permissions, which you
07:21
don't need to declare anywhere. You don't need to get approval from the user. They're just there. You just need to know how to use them. And today, I'm going to show you how to use such default permissions to bypass and get the access for resources and abilities that are protected by real permissions. So first example is a permission from a normal protection level
07:43
called internet permission. As the name suggests, internet permission is protecting the access for the internet. So if you want to send URL requests, then you obviously need internet permission. You cannot do it without it. So I created a few video recordings
08:02
to explain every concept, so how we can understand the setup. Here, we can see the Android device. I'm using a virtual Android device just for simplicity of the presentation. Obviously, the same things can work on the real devices as well. So here, we can see the logs of the Android and the code.
08:22
In this setup, I created basically small Node.js server, which will receive the request from the Android and then respond with some random number. So this is how we can see that basically POC idea just to prove the concept that it works. So let's see the video.
08:40
Something is happening. Android is sending requests. We can see it in the logs. And some random number, which we can see also in logs of the server, was received from the server by the Android. And why it worked? This is the normal behavior. Why it worked? Because the application has internet permission. Makes sense. Nothing special.
09:03
So what will happen when the application is attempting to access something that is protected with permission? In this case, exactly the same thing without the permission. In that case, application is crashing. We see this built-in alert. And why it happened?
09:20
Because there is a security exception. We can see it here. Permission denied. You don't have the needed permission to perform this action. As you can see, I removed it from the manifest. No permissions at all. But now let's see the bypass. Again, the same setup.
09:41
Android virtual device, Android logs, and server side logs. So something is happening. We can see logs from both sides. There is a communication. We can see the prints on the Android logs. The request was sent from the Android, as we can see it here.
10:00
It's coming from here. And we can see the random number that also received from the server by the Android. And we can see the secret, secret string, which I sent from the Android to the server side. So two-way internet communication work. And this is the Node.js server code. We can see how the data is received and how it created the random number.
10:21
Very simple code. And in addition to that, I also send scheme AAA and host BBB params, which also received by the server. And why I did that? Because this is the custom URI configurations of my application under the category browseable.
10:43
And we can see here that this POC works without permissions at all. So how did it work? I use implicit intent, which is a default service with default action view. And in Android, when they are creating implicit intent
11:02
with the default action, you basically give the Android ability to decide who is the receiving component. And how it does it? It basically checks the URI. So I'm abusing this functionality. And I'm giving the URI of a default deep link format of Chrome browser.
11:21
And I'm injecting the URL inside the URI, which basically triggered the browser to send the request for me. And then I receive the data back using exactly the same technique, but vice versa, because I'm given the custom URI configuration of my own application when it's sent to the server.
11:40
So how I created the payload? I basically downloaded the Chrome APK, extracted the manifest. I can see there the unique scheme, Google Chrome. So I can know how to trigger Chrome browser to open in Android. Then I looked in the decompiled code.
12:00
And I founded the implementation of that. So I can see that scheme, Google Chrome, with the host navigate, receives a query param URL. So we can inject the URL inside the URI. And that will trigger the browser to send the request. So this is how I'm creating the payload URI with Google Chrome
12:21
scheme. Host navigate takes the query param URL. This is my URL. I'm giving the address of my Node.js server with the additional query params, scheme AAA, and host BBB. Obviously, it can be anything else. It's just for the simplicity of presentation. But as you can see, this is the custom URI configuration
12:42
of my application under category browsable. Now, category browsable basically means that this link can be triggered from the browser. The browser can communicate back to the application. So the Node.js server receives the request,
13:01
extract the scheme and host from the request, and uses to create the dynamically link on that web page, and then use JavaScript to trigger this link. So let's see the whole flow over a diagram to make it completely clear. Application is sending implicit intent
13:21
with the Chrome URI that is wrapping our custom URI. Android API recognize the Chrome URI and open the browser, the Chrome browser. Chrome browser extracting the URL from the URI and sending the URL request to our server.
13:41
Server receiving the request, processing the request, unwrap the custom URI from it, and creates the URI link dynamically on that web page, and then use the JavaScript to trigger the browser to use this link, which goes back to the Android API that checks who is the receiving component.
14:01
And the receiving component is, again, our application. And this is how I have the two-way internet communication without internet permission at all. Pretty cool, right? Thank you. Next, system alert window permission.
14:23
This permission is coming from the top highest protection level, special system permissions. This permission is very unique. It is intended for a system-level interaction with the user. And what it allows you to do is create an overlay that will appear above any app
14:41
and above any view in the system. So you can imagine why it's considered highly sensitive, because, for example, there is, let's say, a Gmail screen. And you can create your own screen off of Gmail and cover it completely, or cover a part of it, for example. Now, like I explained in the beginning,
15:03
every permission must be declared in the manifest which application is using. So this is how any security tool can scan the application and know which permissions are used. So all of these tools, they are very much aware of the permission mechanism. So obviously, they know exactly which permissions
15:21
are the most privileged ones. So if such a privileged permission appears there, they detect it immediately. And the suspiciousness of this application automatically increases. But even if the application, which are very highly privileged permissions, are uploaded to the Google Play Store and, let's say,
15:44
successfully downloaded and installed on the device and then launched on the device, because it's a special system permission, it is not enabled yet. Actually, the user needs to go outside of the application context and perform some external steps in the advanced system settings.
16:05
Let's see how it works normally. Like in any case, first, the application declares in the manifest. But since it's a special system permission, the user needs to go externally to the advanced settings,
16:21
either from the Settings screen or from the shortcut from App Info, like I do it here. And you can see that in that case, there is a completely separate screen just for that, like a dedicated screen just for this particular permission
16:40
for that specific application. And the user can either enable or disable it. And the Android states very clearly here, as you can see, hopefully you can read it from there, that a user needs to be aware that this is a very, very serious permission, because it will allow this application to create the views above any other apps.
17:03
But like I said, we're going to bypass everything, right? So I found that exactly the same ability can be achieved by a default service called Toast. Now, Toast is a very interesting service. Originally, it was created to show just small text
17:23
messages, small pop-ups, which show in some small text. And it was created in the first API level. And today, like I said in the beginning of the presentation, there are 32 API levels. Means that this service is available on all API levels
17:45
in Android. So if you remember that big number, 3 billion active devices, this service works on every one of them. So I noted that because of the nature of this service,
18:01
it doesn't matter how you call it, how you invoke a creation of the view with Toast. It always appears on top of everything, because this is just how it works. But in addition to that, I also noticed that it can be triggered by any application with no permissions at all, as opposed completely to the special system permission
18:24
that it uses. And third thing, very interesting thing, as I say, last but not least, Toast views, they don't receive focus by default. So I asked myself, is this service,
18:42
when I create in views with that, is it really limited for small text messages? And I found that it is not. You can actually customize completely the views, and they can show wherever you want, wherever you want. So let's see this small example. The simplest Toast example will look something like that.
19:03
Probably Android users recognize it already. But you can also show images with that. You can also show videos with that. You can even load web content with a web view with that. And you can even cover the entire screen with that.
19:24
So knowing that, I asked myself, OK, I can show whatever I want, wherever I want. It does have some limitations, but Toast has a limitation, appearance duration. You cannot, for example, say, show a video You cannot, for example, say, show this Toast view for 2
19:42
and 1 half minutes. It just doesn't work this way. Instead, you need to pass one of these constant values, either length short or length long. Length short will make it appear approximately for two seconds, and length long will make it appear for approximately four seconds, and then it disappears.
20:02
Actually, exact time can be different between different devices, but this is pretty much accurate. But this limitation can bypass also very easily. Simply by calling recursively again and again and again with the same Toast view configuration,
20:22
as long as the delay between the calls is shorter than the appearance time, you can make it appear before it disappears. So the overlay will remain on the screen theoretically forever. Let's consider the next example.
20:41
Ransomware blocking the screen for the user. So I created a small recursive method. I call it overlay one, which takes integer count and count it down to zero with the delays of one second.
21:01
As you can see, the duration is length long, which approximately four seconds. So I create the view, customized view, with the resource layout file, which is this file. And I set the gravity of it to fill the screen from the origin point zero and zero. Basically, it filled the screen entirely
21:21
from the top left corner. In the layout configuration, the width and height set to match parent with the background black. Basically, black screen completely covering the entire screen of the user, with a message saying, well, your screen is blocked.
21:40
And if you want to unblock it, you just need to pay zero, one Bitcoin. Not a lot. So let's see it running. The user uses his device and overlay appear with no permissions at all. And as you can see, overlay doesn't disappear.
22:01
The user can click back button, home button, tasks button. It doesn't matter, because it will always stay on top, as much as we want. Cool, right? Thank you. And please notice that there are no permissions at all used.
22:25
Now, creating an overlay to block the screen entirely, it's cool, but this is not the only thing we can do. If you remember the third ability of TOS, that the views, they don't receive focus by default, it means that this technique can also be used for clickjacking.
22:43
And sometimes, to make something crucial to happen, you just need one single click from a user. Now, according to some article I read about the usage behavior of Android users, an average Android user touches the screen for a little bit more than 2,600 times
23:03
a day. And that's just an average user, so like, heavily users do it more. By the way, the link for that article is referenced in the end of the CFP. Anyway, that makes it very hard to remember every time you tap the screen. And it makes it easy to trick the user
23:21
to tap in the specific spot using the common alert pop-ups. I mean, think about it for a second. Let's test it a little bit. How many of you have Android device, let's say, for more than five or six years? OK, with the raise of your hand, OK, a lot of people,
23:41
definitely more than half, I would say like 70%. So ask yourself, how many times in this five, six years that you have the device, how many times you have seen these alerts, right? Unfortunately, Google Play service has stopped. Unfortunately, browser stopped. Unfortunately, application crashed, blah, blah, blah, whatever.
24:00
You see it all the time, right? And what you usually do is, OK, something crashed. You click OK, and you continue with your life. You continue with your 2,616 other tabs, right? But what if, at that particular time, at one of these times, when you clicked OK button, your actual click
24:23
went through this OK, because the view didn't receive the focus, to some other clickable element, which you didn't even see? Let's consider the next example. Clickjack in POC. I created some small dummy application. I called it Clickjack Victim.
24:43
I used these small dummy examples in not real applications, obviously, to prevent potential copyright issues for me and Defcon. But as you can understand, it will also work with any other applications. So anyway, this application is very simple. You have two buttons, a No button, a Yes button.
25:04
And here, in the logs, we can see what exactly happened. So if the user will click No, we will see POC No. And when the user clicks Yes, we will see POC Yes. Very simple example.
25:21
So I'm running this payload. User is using his device. And then at some point, pam, some alert is popping up. Google Play Services has stopped. He clicks OK. Doesn't suspect anything. Uses his device. But what actually happened? He was just tricked to click the POC Yes.
25:43
So how did it work? Well, the user saw this alert pop-up. Google Play Service stopped and supposedly clicked on the OK button. The actual click went to the Yes button that was exactly behind it.
26:03
So what can we do with these techniques? What can be real-life exploitations with different combinations of these techniques? So first, I showed you unauthorized two-way communication. So we can communicate with our server,
26:22
for example, for command and control. And the server can tell the Android app what to do and when to do it. For example, when to block the screen for ransomware or when to unblock it when the user paid or which applications to disrupt,
26:40
on which buttons to make the user to click, or which applications to uninstall. Because in Android, to uninstall an application, it's basically a built-in alert with just one click, and then the application is uninstalled. I mean, yeah, in the latest API levels,
27:02
it also needs a normal level permission. But still, this is pretty simple. But also, it can be used to bypass even more permissions from dangerous protection level. Let's see some examples.
27:21
Call phone permission. In Android, there is a permission from a runtime dangerous protection level called Call Phone. And it protects a particular action. It's called action call. If you create implicit intent with action call and you give a URI with a phone number,
27:43
the Android will open a dialer. It will parse the URI and put the phone number in the dialer. And then it will start the phone call. But that will work only if the application has the needed Call Phone permission.
28:00
If it doesn't have it, then, as we have seen previously, security exception, it cannot work. But at the same time, in Android, there is another action called Action Dial, which work with the default permissions. And it does exactly the same thing, or almost exactly the same thing. It will also trigger the dialer.
28:22
It will also parse the URI, take the phone number, put in the dialer. But it will not start the phone call. That's the difference. You just need one single click from a user to start it. So you see where I'm going with it, right? So normal behavior. If you're trying to access, say, action call, application
28:43
crashing, alert, blah, blah, blah, security exception is strong, permission denied. You cannot access ability that is protected by permissions normally. But a combination of these techniques,
29:05
using the action dial, user see some, again, some alert, clicking OK. But what actually happened, as you can see, the phone call started. And no permissions used.
29:21
All right, as you can understand, obviously, I purposely removed the overlay so we can see the dialer. But like I showed previously, the overlay can remain if needed. Another example, location permissions. Now, when application need to access device location,
29:45
all of the location permissions, like find location, the course location, et cetera, they are all runtime permissions from a dangerous protection level. So application needs to check before it tried to access the device location, need to check whether this permission is given.
30:02
And if not, to trigger the alert. And I explained previously, in case of location, it will trigger the alert where the user can allow this permission, denied it, or allow it for one-time usage. But this is how it works for normal applications,
30:20
not for a browser. In the browser, when the web page is executing JavaScript Navigator getCurrentPosition, it triggers alert from the browser. And with one single click, the user can allow this web page to access device location.
30:40
So using the first technique, with the URI of Chrome browser, we can trigger the Chrome browser to open a malicious web page that will trigger the needed JavaScript Navigator getCurrentPosition that will make this built-in alert. And then with the click jacket, we
31:01
can allow the access for ourself. So that would look something like that. User uses his device. Browser has stopped, blah, blah, blah, clicks OK. Browser stopped. Browser restarted. Nothing suspicious. No permissions used, right?
31:21
But what just happened? The device location was just stolen. All right. Thank you. Thank you. And hopefully, at this moment, this is clear for everyone why it worked. But still, when the user saw this alert
31:45
and supposedly clicked on the OK button, the OK button appeared exactly above the built-in alert from the browser, where he allowed actually the permission. The device location for the web page.
32:00
And this is how it worked. OK. That's it. I see that we still have some time. So if you have any questions, I'll be glad to answer them. Thank you.