 So now this is Nikita Corten who's going to talk about defaults, defaults. So, hello everyone and thank you for joining me here today. My name is Nikita Corten. I'm a software engineer and a security researcher and well what I'm at researching or developing anything usually you can find me training street workout calisthenics. For example, in this picture I'm doing Eiffel handstand in front of an Eiffel tower here in Vegas 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 from multi 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 in the Google for the last statistical data I found that Android holds 72% of the market share of all smartphones in the world which is a little less than I have in the previous years but the absolute number of smartphones increased so much that this is actually more than I have previously. Android OS has 32 distributions or as it 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 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 particular device model that dominates the world completely. Instead it's distributed across multiple API levels, multiple device models but even if you take like one particular combination of version and device model you will let's say that has 1% still 1% of that is tens of millions. 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. So first of all all Android permissions can be divided into 3 permission types or categories if you wish. First it's install time permissions. Now install time permissions basically permission that enabled right after the application is 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 protects the more dangerous abilities, 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 it to do the access the ability it needs or the resource is allowed in 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 like smaller category in that of very few permissions for example location permission. In that case when the alert is triggered then user can not just allow or deny the permission but also allow for one time usage. Anyway above that there is the top highest protection level called special system permissions and this is like very unique and very rare permissions. They are intended for system level interaction and their job is to protect the most powerful actions and for that reason it cannot be you know allowed from the application 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 must be declared in manifest which is basically an XML file. Now in this example you can see a list of different permissions that application used so some of them from a normal protection level some of them from a dangerous protection level 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 like 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 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 know 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 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 the application is using or the higher protection level of these permissions are basically it means that this application can do more thing the more things it can do it more privileged but everything I said until now this is just the documented part 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 don't need to declare anywhere you don't need to get approval from the user they just there you just need to know how to use them and today I'm going to show you how use such default permissions to bypass and get the access for resources and abilities that protected by real permissions. So first example is a permission from a normal protection level called internet permission as the name suggests internet permission is protecting the access for the internet so if you want to send URL request then you obviously need internet permission you cannot do it without it. So I created a few video recordings 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 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 this is how we can see that the basically poc idea just to prove the concept that it works. So let's see the video something is happening android and setting request we can see it in the logs and some random number which we can see also in logs of the server right 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 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 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 android virtual device android logs and server side logs so something is happening we can see logs from both side 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 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 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 browser and we can see here that this POC works without permissions at all okay so how did it work I use implicit intent which is a default service with default action view and in android when you are creating implicit intent 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 default deep link format of home browser 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 giving the custom URI configuration of my own application when it's sent to the server 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 home browser to open an android then I looked in the decompiled code 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 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 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 is just for the simplicity of presentation but as you can see this is the custom URI configuration of my application under category browser now category browser but 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 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 wall flow over a diagram to make it completely clear application is sending implicit intent with the Chrome URI that is wrapping our custom URI Android API recognize the Chrome URI and open the browser the home browser home browser say extracting the URL from the URI and sending the URL request to our server 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 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 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 and above any view in the system so you can imagine why it consider highly sensitive because for example there is let's say a gmail screen and you can create your own screen of a gmail and you know cover it completely or cover a part of it for example now like I explained in the beginning every permission must be declared in the manifest which application is using so this is how any security tool can you know 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 are the most privileged ones so if such a privileged permission appears there they detect it immediately and the suspiciousness of this application automatically increased but even if the application which are very highly privileged permissions are uploaded to to the google play store and let's say successfully downloaded and installed the device and the launched on the device because it's a special system permission it is not enabled yet actually the user need to go outside of the application context and to create and perform some external steps in the advanced system settings let's see the how it works normally like in any case and first the application declared in the manifest but since it's a special system permission the user needs to go externally to the advanced settings either from the setting screen or from the shortcut from app info like I do it here and you can see that in that case there is like you know a completely separate screen just for that like a dedicated screen just for this particular permission 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 there's a very very serious permission because it will allow this application to create the views above any other apps 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 um you know text messages like small pop-ups and we show showing 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 in android so if you remember that big number three billion active devices this service works on every one of them so I noted that because of the nature of this service it doesn't matter how you call it how you invoke a creation of the view with the toast it always appear 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 that it uses and third thing very interesting thing as I say last but not least right toast views they don't receive focus by default so I asked myself is this service when I created views with that is it really limited for a 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 probably android users recognized 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 so knowing that I asked myself okay I can show whatever I want wherever I want there's have some limitations but toast has a limitation appearance duration you cannot for example say show this toast view for two and a 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 and then it disappears 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 you can 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 run somewhere blocking the screen for the user so I created a small recursive method I call it overlay one which takes a integer count and count it down to zero with the delays of one second 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 from the top left corner in the layout configuration the width and height set to much 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 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 the user can click bug 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 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 a clickjacking 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 100 users an average 100 user touched the screen for a little bit more than 2600 times a day and that just an average user so like heavily user do it more by the way the link for that article is a reference in the end of the CFP anyway that makes it very hard to remember you know every time you tap the screen and it makes it easy to trick the user 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 like how many of you have android device let's say for more than five or six years okay with the rays of your hand okay a lot of people definitely more than half I would say like 70 percent so ask yourself how many times in these five six years that you have the device how many times you have seen these alerts right like unfortunately google play service has stopped unfortunately browser stop unfortunate application crashed blah blah blah whatever you can see it all the time right and what do you usually do it's okay something crashed you click okay and you continue with your life you continue with your 2616 other tabs right but what if at that particular time one of these times when you clicked okay button your actual click went through this okay 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 click jacking poc I created some small dummy application I call it click jack victim I use this small dummy examples in not real applications obviously to prevent potential copyrights 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 no button yes button 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 click yes we will see poc yes all right very simple example so I'm running the payload user is using his device and then at some point pump some alert is popping up google play services has stopped he clicks okay doesn't suspect anything uses his device but what actually happened he was just tricked to click the poc yes so how did it work while the user saw this alert pop-up google play service stopped and supposedly clicked on the okay button the actual click went to the yes button that was exactly behind it so what can we do with these techniques what can be real life explo- uh exploitations with different combinations of these techniques so first I showed you a unauthorized a two-way communication so we can communicate with our server 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 around somewhere or when to unblock it when the user paid or which applications to disrupt on which buttons to make the user to click or which applications to uninstall because in android to uninstall a 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 it also need a normal level permission but still this is pretty simple but also it can be used for to bypass even more permissions from dangerous protection level let's see some examples call phone permission in android there is a permission from runtime dangerous protection level called call phone and it protects a particular action it's called action call if you create a implicit intent with action call and you give a uri with a phone number 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 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 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 when i'm going with it right so normal behavior if you're trying to access a action call application 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 using the action dial user see some again some alert clicking okay but what actually happened as you can see the phone call started and no permissions used all right as 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 uh when application need to access device location look all of the location permissions like fine location the coarse location etc they are all a 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 and if not to trigger the alert and i can explain it previously in case of location it will trigger the alert where the user can allow this this permission denied it or allowed for one time usage but this how it works for normal applications not for a browser in the browser when the web page is executing javascript navigator get current position it triggers alert from from the browser and with one single click the user can allow this web page to access device location 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 get current position that will make this built-in alert and then with the click jack and we can allow the access for ourselves so that will look something like that user uses his device a browser has tab blah blah blah clicks okay browser stopped browser restarted nothing suspicious no permissions used right but what just happened the device location was just on right thank you and hopefully at this moment this is clear for everyone why it worked but still when the user saw this alert and supposedly clicked on the okay button the okay button appeared exactly above the built-in alert from the browser where he allowed actually the permission the device location for the web page and this is how it worked okay that's it I see that we still have some time so if you have any questions I'll be glad to answer them