So now this is Nikita Kortin. He's going to talk about defaults, defaults.
So hello, everyone, and thank you for joining me here today.
My name is Nikita Kortin. I'm a software engineer and security researcher.
And, well, while I'm not 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 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 defaults.
So I can bypass different permissions from different protection level, actually 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 Android.
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 more than it had 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 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 three 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, a application is installed
and the application needs to check whether the permission
that allow it to do the access, the ability it needs,
or the resource 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.
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 the application use.
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,
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 it's
using this list of permissions.
And that means that this application can do more things.
The more things it can do, the 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 this
magical permissions, which you 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
you 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
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 is sending request.
We can see it in the logs.
And some random number, which we can see over here.
We can see also in logs of the server.
It 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 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.
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 Browseable.
And we can see here that this
URI 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 a 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,
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 Chrome browser
to open in Android.
Then I looked in the decompiled code
and I found 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.
It's just for the simplicity of presentation.
But as you can see,
this is the custom URI configuration
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,
extracts the scheme and host from the request,
and uses to create 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
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.
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 is considered highly sensitive
because, for example,
there is, let's say, a Gmail screen
and you can create your own screen of 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 increases.
But even if the application,
which are very highly privileged permissions,
are uploaded
to the Google Play Store
and, let's say, it's successfully downloaded
and installed on the device
and 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.
Let's see how it works normally.
Like in any case,
first, the application declares it in the manifest,
but since it's a special system permission,
the user needs to go externally
to the advanced settings,
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 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 this is 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,
you know, text messages,
like small pop-ups,
which show 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,
3 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,
the creation of the view with 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'm creating 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.
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 the 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.
Does it 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 then it disappears.
Actually, exact time can be different
between different devices,
but this is pretty much accurate.
But this limitation can be bypassed
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.
Ransomware.
Blocking the screen for the user.
So I created a small recursive method.
I call it overlay1,
which takes 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 match parent,
with the background black.
Basically, black screen
completely covering
the entire screen of the user.
With the message saying,
well, your screen is blocked,
and if you want to unblock it,
you just need to pay 0.1 bitcoin.
Not a lot.
So let's see it running.
The user uses his device
and overlay appears
with no permissions at all.
And as you can see,
overlay doesn't disappear.
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.
Now,
using 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 Toast,
that the views, they don't receive focus by default,
it means that this technique
can also be used for a click jacking.
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
touch the screen
for a little bit more than
2,600 times a day.
And that's just an average user.
So, like, heavily user 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, 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 raise of your hand.
Okay, a lot of people, definitely more than half.
I would say, like, 70%.
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, browsers stop. Unfortunately,
applications crashed, blah, blah, blah, whatever.
You can see it all the time, right?
And what do you usually do?
Okay, something
crashed, you click okay, and you continue
with your life. You continue with your
2,616
other taps, right?
But what if
at that particular time, at one of
these times, when you clicked okay button,
your actual
click went through
this okay, because
the view didn't receive the focus,
and there was 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 call it ClickJack victim.
I use
this small dummy
examples in not real
applications, obviously,
to prevent potential copyright issues
for me and DEF CON, 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 clicks
yes, we will see POC
yes.
Alright? Very simple example.
So, I'm running this
payload.
User
is using his device, and then at some point
BAM! BAM!
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.
So how did it work?
Well, the user
saw this alert pop up,
Google Play services
stopped, and supposedly
clicked on the OK 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
exploitations
with different combinations of these techniques?
So, first I showed you
unauthorized 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 a ransomware,
or when to unblock it
when the user pays.
Or which applications to disrupt.
On which buttons
to make the user to click.
Or which applications
to uninstall.
Because in Android, to uninstall
an application
is 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 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.
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 an 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 works with 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 it 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 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,
users see some,
again, some alert,
clicking OK, but what actually
happened, as you can see,
the phone call
started.
And no permissions used.
Alright, 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
needs to access device
location,
look, all of the location
permissions, like find location,
coerce location, etc., they are all
runtime permissions from a dangerous protection level.
So
application needs to check
before it tries to access the device
to check whether this permission
is given.
And if not, to trigger the alert.
And like 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.
Not for a browser.
In the browser, when the
web page is executing
JavaScript navigator get current
position,
it triggers alert
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 jacking, we can allow the access
for ourselves.
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? But what just
happened?
The device location was just stolen.
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 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.
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.