Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/855 Thanks!
Welcome, everybody, to this next talk
inside Android safety net, attestation
attack and defense.
First of all, I would like to see a show
of hands. Who among you has already
developed an Android app?
That's almost everybody I would say
something between 90 and 98
percent of you and who
of you has already used the safety net at
a station API, please, another show of
hands that feels more like five
or six. And who of you has already
heard about this API before coming
here today?
That's more perfect.
That's why you are all here.
I guess.
So gear up for a very informative
talk by Colin Madlener, an expert
in the field of security research, and
he's also the coauthor of the Android
Hackers Handbook.
I'm very excited for his talk.
Please give him a warm round of applause.
Right, and this is basically
just something I did a bunch
of like mobile security and development
some years ago, wrote
a bunch of guides
and helped on this book.
But let's get right to the talk.
So what are the goals for this target?
The main goal for this talk is, of
course, understanding what Android
safety net and especially that gestation
appears and actually how to really
implement and deployed, as
you will see throughout the talk.
It's not like that straightforward,
unfortunately.
And then we just kind of look at that
station API, really what kind of do
for you and what can we do for you?
And I guess what's most like with most
security systems or
or features?
It's very interesting, though.
The part of what it can do is the most
interesting part.
And then we're going to look at some
attacks and bypasses from other
people and some of my own work.
And the second main
goal of this talk is like basically
documenters API because do Google's
documentation is not very good.
And that's like how I thought like,
hey, let's let's talk a little bit about
this.
So, of course, this entire enterprise
system and this entire talk about
app security and back in the day
apps, there's not a lot of apps that not
communicate. But these days, if your app
doesn't communicate, like who cares?
And most it communicates with like an app
specific background.
And if the app and the back and
everything works, the user is happy,
everybody's happy.
And if it doesn't work,
everybody's unhappy and the company will
not make any money and likely
will discontinue their service.
So mobile app security
is really, really interesting because
these days at an app or like a mobile
app, it's really just the gateway to like
the backend service.
And these days there's a lot of like
online service which are basically
mobile only or at least mobile.
First, if you think about something like
Snapchat, they don't even have like
a website or anything.
And if security is also about
basically controlling data, so who
is displaying data and managing data
about the app and making sure somebody
like is not allowed to copy our
data that is like managed by the app
and altogether, basically mobile app
security is really about protecting, like
your servers, your revenue, your brand,
and hopefully really hopefully your
customer or like the consumer.
So if you look at our hacks in general,
what are you looking at?
There's the main part.
It's like always modification basically
on Android would say, like rooting and
rooting is basically just like the break,
the assumptions of the security model
because of your root, like your phone,
you're suddenly able to, like, basically
take content from apps that didn't
want their content to be taken in the
first place.
And you can do this by just like reading
data or like taking screenshots
or like instrumenting the app and pulling
data out of it.
And of course, you can also just modify
the app directly and then you can just
like change whatever the app is doing or
like what the app isn't forcing.
And of course, there's also a network
traffic.
But in this talk, I'm not going to like
look at network traffic at all.
So if you look at looting,
what is looting actually is basically
regaining full control over your device,
because these days any kind of
phone or tablet, basically
you don't have root anymore, like you
don't have full access to everything,
like on your computer.
And with looting, you gain like us access
again. You gain access to resources.
You can read and write any file and
modify parts of the S or like
the software framework.
And all of this routine capabilities
really highly depend on Android versions
and really newer Android versions
of much, much more hardened
due, for example, as the Linux policies.
But I'm not going to jump into that part.
So if you look at security in the old
days, what what do you have?
There were like basic routine checks.
So apps would implement something like,
hey, is the system the system X
as you exist?
If so, there was just checking, hey, did
somebody read the file and reinstall
Asou? And if that was true, they would
just say, like, are you devices likely?
This app is not going to work.
And the same apps, they would just like
check if like a specific package
was present.
Or they will check if, like explosions
installed and
maybe try to detect emulators
by just seeing what device idea
returns and if it returns zero as
often like an emulator.
So that's like really the old days
and the old days.
It was for the developers really, really
easy to implement because it was they
knew there they
they can just like check for certain
files or certain packages and it's
like really easy to implement.
You don't have to be like a
genius. You just have to like check for
this file and then you can very easily
deploy deploy those kind of checks.
But of course, for the attacker, it's
the easy as well, because
they also understand how this works.
So they could just like rename some files
or move files around and then
they can again abuse those applications.
So modern mobile app security really
works by collecting data.
Basically, you have some some piece
of code that just like collects data
and send it to the back end on your back
and will make the decision if a specific
security, like a specific thing happened,
for example, if your device
is routed and the idea behind
us that the attacker cannot just like,
patch out your app like petrol checks on
you, because, um,
yeah. Imagine if you just like to
file access, check to like a
system business, you you can just like
remove that and then the apple just work.
But if you collect really a
lot of data on the device, you really
don't know what is used for what.
And you basically have to fake all the
data. And if you collect a really
a lot of data, you can't really do
that.
Um, that's basically what
all modern apps
that have like a high demand or higher
demand for security do these days.
Um, and also that is what safety
legislation will do for you.
So just go
a little bit back to like Android.
So in the early days, Android
was very I would say.
Very open, but these days, a
lot of openness and the ways they have
like secret about now and
which is basically the trust anchor,
basically, they just like they are
able to tell if you like,
unlock the bootloader and things
like that. And, of course, as meanwhile
as a Linux restrictions.
So they have like much stricter
sandboxes.
And then Google added this platform
security service called safety net.
And safety net is really.
Just a brand name for like security
services on Android, they have a bunch of
different services
from verified apps to check on them to
check for a which is Google's
nicer term for like malware.
And then you have attestation and you
have like a CAPTCHA service.
And safety in general is designed
to run on any Android device that has
Google Play.
So it's like part of Google Play services
and the nice part, it's like independent
from the manufacturer. So this exists on
any on any Android device,
not only unlike the Google devices
and with attestation, you can do
remote device on at the.
So and of course, Google also
heavily uses their own API,
for example, if you ever use Android pay
and saw
this nice pop up, that meant
safety net actually failed to validate
or a test your device or
like your or like, I guess
the Android pay up.
And they said, like, oh, yeah, you
modified something,
and one of the intentions, I think,
behind the attestation part was
they can't really control security
of like other manufacturers devices,
but they wanted to support Apple pay on
them. So what do they what did they
do?
They basically
found a way to like measure, if
you like, your device or the
device.
Apple Android Pay
is running on.
It was modified.
And the nice part is they can really
change safetynet
like the attestation part on the fly,
so you don't have to like wait for like a
system software update.
It's like basically they can push
code to the device at any point to like,
check for.
Yeah.
Modifications and
that they can, like, really fast
react to, say, new
routes or something without like having
any like software updates being
delivered to the devices.
So so what what
is actually the attestation part?
It's really the attestation of the device
and the specific app that called the API,
that's basically all of the things
people use to implement themselves.
And as I said, it's like part of the
Google Play services.
And basically you just call an API and
validated your app and devices like
the idea of the device of the the user
was not modified.
Unfortunately, the documentation,
as I said in the introduction, is not
not super detailed.
And they leave a lot of things to like
your interpretation or just like
you have to basically use it to find out
how this really works.
So over time, it got much better.
But when I started looking at it, which
is why I guess one and a half, two years
ago, some of the documentation
was like really bad. And they add new
features without really documenting them.
They have like a private mailing list
where they announce some stuff.
But yeah.
Yeah, this is, I guess, the only piece of
code, actually, I'm going to show, it's
basically just like how you call it.
So safety net as part
of the Google API client.
And you basically just say, I want the
connection to the safety net API
and then you just like call it.
So how does it how does it actually
work? So here in
the middle of the box in the Middle East,
basically, that's the software that's
running on the phone.
You have the background, the Google Play
background and your applications
background. So if you if your app doesn't
have its own back end, you really can't
use safety net at all.
And you will see in a second why that is
so basic. What happens if your
app, like, talks to you back and for
maybe maybe wants to log in or do like
some very specific
operation and then you're back and will
say, hey, your application,
I need you, I request you
to like a test yourself.
So the back end will basically send a
request to its app, The Apple, and I
call the safety net at the station API.
And in this in this step, we actually see
the the attestation
code on the device will inspect the
device itself.
So the operating system, how was it
routed? And then it also also inspect
the actual application,
some minor detail, like in the
in the call, it should be Anon's to
prevent replays.
It's just like for documentation.
So that's basically
you instead of having you implement
everything yourself,
you can just call this API and
you will have
all all the work done by Google
engineers to do your.
You secure your security configurations
are security attestations.
So what happens after the after
after station has checked you up and the
device will send the data back to Google?
Google will actually analyze it and
then will determine the
state of your device and your app.
And actually forward the response to your
app and in
order to to make sure the app,
because if you modify the app in this
case and if it would not be signed,
you could just like temporalis like this
attestation response.
So this is signed some
on the back end.
You should validate that signature and
then validate the attestation and then
you actually know what you're dealing
with. That's basically what you get back.
It's really, really, really simple.
Just some blobs of basics
for encoding.
So Google has the signature validation
API, which is basically just for
development purposes.
But yeah, that part is actually pretty
well documented.
I guess they do that
a lot like SSL cert validation.
But let's look at the attestation data,
so data station data, that's basically
the main blob you get back.
Everything else is just like a chain on
the signature.
So you see
the CTS profile match and that
refers to that's basically the car,
the car, the car device integrity
measure and CTS
refers to the Google.
Compatible, compatible compatibility
test suite.
So basically, whenever you build an
Android device, you have to run this like
test suite and give Google the results.
And basically, what does a lot of
apparatus basically collect data from
your phone and then it compares it to
the data the manufacturer provided.
And by those they can determine if your
modified contents of like your system
system and then you see like
which which RPK called the API
and then you get a digest of the app
itself.
You get your back.
And then you also have
like timestamps and the basic integrity
as an indicator about
routine.
So this is this nice table that was
actually only, I guess
probably added to like their
documentation maybe like seven
months ago and before it was like,
yeah, there's a true or true and false
field. And yeah.
So basically here you can see
CTS will only be true if your device
is like genuine and like
the city, the CTS data kind of
corresponds to the data that was
collected.
As soon as you unlock the bootloader that
goes to falls and but basic
integrity will still be there.
So if you're just unlucky bootloader
but didn't modify actually the content of
your filesystems, your basic integrity
is true.
And that's basically those two different
indicators will basically help you to
understand the state of the device.
And this is nice table.
You can do some
basically implement like here checks.
So I wrote this like small
like I actually implemented that for like
a bigger company.
But I also built
like a small demo of which I'm going to
show you at the end.
And you see some you
know, it will basically just like run at
the station and it will tell you, like if
your device is routed and what the app
integrity is and you see
the blob of data below
and you see like everything is
Postles, all of the checks.
And you're going to have some some more
fun with this later.
Yeah. The big the big issue with
SafetyNet and attestations apps
like Aromasin or like Arab states,
there's a ton of different errors.
And if you don't know what you're dealing
with, you can basically very easily
bypass the entire system.
If you guys and Implementor don't, don't
or aren't aware of, like, error messages.
So, for example, this is
one of the nice and
basic errors. Basically, if for some
reason the API ran,
the API call actually worked.
But somehow the
the the code inside the API,
like, just like encountered some random
error, you will get this.
And they basically say, oh yeah, we just
like have this like random error message.
And you're then like, yeah, you're going
to find out like what how this actually
looks like because this is not really
documented.
And those are basically just means just
called the API again and try again.
Most of the time it will just like go.
Yeah, this is one of the more interesting
errors. This basically says we can't
really determine which API called
GVK called the API, also
that kind of thing, the devices
generally untrusted.
So they just like removed a bunch of
fields from
this JSON response, which is also
very confusing, if you like implementors
the first time, because you suddenly get
like broken data
blob's back.
And of again, of course, this was
like not not really documented.
So now, you know, like basically
are we have we have this API
and like there may be the adjacent field
looks strange.
So basically now you can go and just like
implement your app and
have the interaction between your and
your back and and you have running the
attestation.
But unfortunately, it's still not that
simple.
So also, all
of the API calls can kind of fail and
they actually will fail in the wild, like
like all of the every every
API you call will actually fail
at some point if you
depending on your user group, if you have
if you're playing at home with one of
your devices, you will never see any of
those errors.
But if you like, Seyran,
if your app runs on like a hundred
thousands or millions of devices, you
will see every every error eventually
when you have
things like of like Google
Play Services doesn't support safety net
yet. So what should you do?
And one part is you can, like, just
update forces to update their
place services.
Or.
And then there is like just like general
error, connection errors, and in those
cases, you just really have to retry.
If you forget to, like,
handle one of those errors, that either
means some
for some client will basically not work
on your network or some client will be
allowed to, like, connect to your service
even if it was tampered with.
And like the lower three cases, that's
like really something you should actually
be able to to see during development
because of your nonsense to sharded.
Well, actually, just like fail even.
Yeah. It was just like directly fail.
Um, yeah, some some more examples
I just like and I just, like, uninstalled
the all place services updates on
this like Nexus seven, which is
like an Android forum, which also doesn't
have secured. And then if you like to
start the application, you'll just like
nothing will work, like because you
really need to update those place
services.
So a lot of a lot
of the API failure things are
basically a temporary failure, so you
basically have to start with retrying
everything, generic
arrows, networking errors.
And in general, you should be like a good
citizen and basically do an exponential
take off after
each failed to try.
Also, you can look into
this adjacent field.
Others chase and blow up on the device
itself and then determine if you do if
you want to do a retrial and you don't
have to do a full
round trip to your back end.
But basically what you really need to do
is report any of the failures to your
back end
and really plan what you're
going to do if, like, some device
keeps just like throwing errors, because
that's and the worst case, a
customer of a user of your app that
can never use the app because if they
have some random error,
so you have to be like, really
we have to really think hard about what
you're going to do.
Unfortunately, this, of course, is an
obsessive behavior because in some cases
like, oh, maybe it's because I let the
person use it like once or twice,
but maybe it's like we never want anybody
who fails us
to ever use our service.
And this is like really more specific
decisions.
So let's look at.
Yeah, so the first and the main
function or one of the two
functionalities like the OS and Device
Integrity Check, and that's basically
just like those two fields which give you
like true or false.
But app integrity works a little bit
different because they actually Google
can actually can't really tell you of
your app. And the app integrity
is is there
and you have those two fields, the app
Digest and the app Digest.
And the Digest is really like the digest
of your the key is
saying to your app.
So in the easy mode.
So if you resign, an application
gets the search digest will be
of course, different.
So if somebody just like uses a
tool on the app, modifies the app,
reinstalled it, the API
digest will be different.
So the most easy check to check for
up integrity is basically just
like compare the RPK strategist
and you kind of say if you have five
different abs and you can
kind of most likely they will all be
signed with the same search.
He basically only have to like hot
just like digestion to your back once.
And you can just like, always compare
that. Um, yeah.
That's like really, if you like, done
this, like, it's basically a very
a very, very simple comparison.
But with that you can always like yap,
yap, it's like not
tampered with, but you can also
go into advanced mode and
basically also compare the APIC
Digest.
But that's, of course, a little bit
different or a little bit more difficult,
because that means
for every single APCO you ever released
to the App Store,
you basically have to record the digest
of the file, because if you didn't do
that, you will just like reject people
and say, like, hey, we don't recognize
this app.
Yeah, you've probably modified your app,
but in reality, maybe you just, like,
forgot to collect the data.
So you have to we have like, very tight
control over your release process, but
you can do cool stuff like revokes the
specific app conversions at this
like very early part of the communication
with your server by just like deleting
that specific digest from your database
and then safetynet will basically block
this app for you.
Yeah.
So, yeah, basically
so to do the implementation and
deployment,
yeah, on the client side, you really have
to check for error conditions.
We try and report failure codes and
the back, and you really have to make
sure to validate the signature and the
other station data check
really all fields, timestamps, Norns,
and really make a decision about
failures and what you want to do.
And especially like things like
do we want to force users to update
the place services and maybe have
something like a white listing mechanism
where you can lightless, maybe specific
kind of devices because you will run
into problems and you probably don't want
to prevent
a like a specific user group from not
using being able to use your service.
So until yeah, so that's basically
the the part about
what does that safety net attestation,
how does it work? What what you should
look out for? And they're trying to
implement and deploy it.
But of course, as
I guess anybody who is interested in
security and if you like,
implement or a new security
system, you really want to know
if you can actually trust the system or
if it's just like does nothing.
So when I when I first looked at it, I
was like, let's see how good
this actually is. And can we do
like bypasses?
And also what are the limitations?
Obvious limitations, I guess,
were Android different
Android versions because on Android
phone, if you really don't have like this
secure good state like
applications, kind of
determine the
state.
So anything that would be based
on unlocking your bootloader
would but basically work because if you
can't detect the bootloader was unlocked,
you can block an unlocked
bootloader.
Yeah. And another Android six.
Yeah, of course they can detect
the Bush state and then you can actually
rely on everything that is
based on the secure
boot mode.
But there's of course, already shows you
that all devices
kind of.
Yeah. Are very much harder
to like judge in terms of
the attestations system because of
certain limitations of the actual OS.
So in your in your security policy,
in your background, you basically have to
to know that, hey,
if something like Android four or five
devices, we might not be able to see
certain things if you just use safetynet.
And you have like other things with
Android phones, so you don't have
diversity, that means you can just
rebound and write or change files
and on the system partition.
So like, you can do fun things like.
Change or rename or move like
a system exponential to some other
directory, and then if you just run your
safety net enabled application, you will
totally bypass
or you will actually not you will not
bypass what you will just pass that
station because the system will say,
yeah, fine, nothing was modified.
And and then after
using that, you can basically restore
you to like by copying it back,
you could also and that also is like
another another basically indicator of
what you should do if you only like,
basically run safety net on on
start up, you can do with things like
that. But say if you use it more often,
like at random intervals, just the back
and the conservatives like at random
intervals, just like says hey, can you
rerun this at the station.
For me, those things become a little
bit harder.
Of course, none of this is documented
at all.
So does my
small demo application, again,
looks like this was like a Nexus five
X with Android six and I just
unlock the bootloader and then if you
like, run that station, you'll see
something like this like secu mode that
actually doesn't come from the
attestation API.
They just like read that from the system
properties, but it basically
detects unlock bootloader and
so it will change.
Yeah.
Yeah. The CTS profile in the middle to
false and will also give you like an
advice which like hey, you should relock
your bootloader.
And this advice philos also something
that just like added I think earlier
this year just under just like this, just
added it. And you were like you were
looking, I was looking at the Jasen
fine. I was like, hey, there's a new
field and it's like undocumented.
Nice.
So
Sue, Hide and Majles.
So
obviously, if a system like that
exists, people will try to bypass
it. And one of the first bypasses
for the system for those was as you hide
basically at some, you can call
it a rootkit because it's
really just hiding it, trying to
hide that,
basically that you rooted your device
from safety net.
And that was the
issue, suicide, it was very simple and
Google very easily actually detected
it and you could actually read on forums
like that. People would post all I
can, like, use to hide anymore.
They did not take that in like two weeks
later. It was like, oh, you maybe like
two days later there was like an update
and it worked again. And then it was like
detected again.
And that's really where those like
short iteration
cycle due to like code pushing comes into
play. They Google just like really fast,
react to whatever changes
there.
And then Suhad was discontinued
because the guy basically said like, oh,
I give up like they they can, like,
change their detection so fast and
I want to do something else with my life
then just like updating.
But then there's magic,
which is more
a more modern way of like
basically hiding root.
But metrics is based on unlocking the
bootloader and pitching as a Linux
policies and so on.
Actually, this is, as far as I know,
completely undetectable, undetectable
at the moment.
Due to safety, not actually not running
the full system privileges,
but this
faces right, you really have to like
unlock and modify or like unlock.
It would louder and do like heavy
modifications.
So it's like not probably done by
a lot of users, but
basically all those tools are basically
real, real root to like hide
from security services on Android.
And Google is playing a nice cat
and mouse game.
So, yeah, and
also those to basically just
try to hide system modifications sort of
routine, which is only one aspect of
of safety net or the safety of the rest
API.
Um, so I was more interested
in integrity.
Yeah, because the other the other
two the other two like checks can
obviously be bypassed and really
nobody ever looked at integrity and I was
really wondering why.
And I was like, yeah, that's kind of
interesting for us.
So, look, I was looking into eventuality
and basically the the the the goal behind
integrity is like we needed to really
to detect if somebody
modified
your application
and you do that by looking at the APK
Digest and the sort digest.
Because if he could modify the APJ, you
can do something like remove like
the let's start printing and like modify
traffic and things, things like that.
So and you probably don't want that
to happen.
So that integrity is like very
interesting,
um.
So how does how does everyone
here or how just like the Digest's
actually work or the effect?
Just the interesting part is
they're those two values are calculated
on the on the APK file
that are stored on disk.
But if you know how Android actually
works, you know, like Android doesn't
actually execute.
The app came because APACS
contained X Files
and until Android for the X Files
would be converted to objects like
optimized text file like a bytecode
and Android for four and five
and later would just like compile the
tax code to native code.
And there was
three years ago, there was like some work
done on unpegging old
X Files.
So this looks like problem of
calculating, checksums on
on our Digest's on one on one
file, but executing another Filkin,
I would say obviously we attacked.
So if you like, rehash
the cold running again, so
an Android phone five, you basically have
the data directly and you have other data
you have every year like apexes,
and then you have like
the program, the program data,
and then you have the coat on and
data dalvik cache.
And then you have this like super long
filename, which is basically very like
the optimized since.
An Android six and later, you have
just like your package directory and in
the package directory, you have an app,
okay, and you have the base or
the base or text file.
But in this case, it's actually not an
old text file. It's like an old text
file, but it contains native code.
The interesting part is those files are
all owned by the system and
they can only be read and
written by actually installed
and zygote.
So your own app can actually not read
it's own like binary.
Which makes us very interesting.
Yeah, yeah, because I got
that, like, I just, like, loaded into
memory and and executed.
So you doesn't really need to be able to
read its own code.
So if you go back and look at
generic modification, how
does this actually work?
Normally you would do something like APIC
Tool and use like unpack the file,
modify the Somali code and use
Apicultural to like rebuild the book
and use Joss to like sign
the file.
And then you can just like run the
modified HBK. Of course, in this case the
signature would be broken because
you don't have the authoress like
keys.
On the device
Apricus compiled using to always
kind of say this is the X Files is the
old file, and then you have
the modified APIC.
So what then, what you do with
this X file,
you have you still have to, like patch
the objects, the modified objects file
to be the
objects file contains like a 60 32
of the text file that was generated from
this is not a security check at all.
It's just for the VM.
So the VM can see, though, that maybe
the AP was updated and now the CRC
doesn't match the
text file and just like recompile it,
that's just like a pure let's not run
old code feature.
It's not a security feature.
And in order to Petroskey file, I made a
small tool. It's like really tiny.
And that's also open source where you can
just like patch patches here, see
of the X File.
So what you can do with basically, which
will work on any Android version,
you can just like.
You need to override the optics file
of the specific app, so if your device
is routed, you can just let go and like
overwrite that specific file.
And so either in the Dalvik cache or
in the app, in the app
out cache.
And interests like stop the app and
restarted and
you just have this modified app
and it will actually bypass all of the
all of the checks because you only modify
it, only modify the code
that it's executed, but not the actual
original APIC.
And then, of course, you have to like
unroot because you want to still
pass like the good general device
integrity checks.
So if you go back to
if you think back about earlier slights,
I like, oh, on Android phone, you can
really you can't really detect
if a bootloader is unlocked.
That basic means on Android for you can
trivially trivially bypass app
integrity checks because,
yeah, if you have a router that's based
on an unlocked bootloader, you can just
do that.
Yeah, so that is that is bypassed,
so but I
was like, yeah, so I
bet we can also find other ways to do
this. So
the main goal for this attack is like
as before, if you really want to
overwrite this one or the X File,
but we know only
basically two to two
demons can actually like.
Right. To two binaries to actually have
the SLA privileges to write
to this file or this class of files was
just installed and they got.
But who else can write to any file
on the file system? Of course, the
kernel, the Linux kernel, because
access privileged access,
any anything that's like like
said Linux on file permissions do not
exist for the kernel itself.
And uh, yeah, two years
ago, one year ago, there was this like
nice kernel bug, um,
by the name of the article
which in for this talk I was like,
yeah, you basically allowed you to like
overwrite any file in the file system
then that you can read.
So as a shell
user, you can obviously read all our X
Files.
So now we can go and
basically, since you can read any old
text file without
rooting the device, we can actually
do this attack without rooting a phone.
So basically the same procedure, the
actual the file
modify the text file and patch
everything.
Um, but the one the one small
issue is like dirty, cannot lie, can
only overwrite files, but
basically not a pen like or increase the
size of a file.
And the one easy trick that I found
is so normally text to old
runs was like
the processor. Specific optimizations, as
you can see down here, it's just like
cortex a 53
and optimizations can usually make
files much bigger.
So if you just like if you just like
compile, if you're just from
Dexter to odd without optimizations,
you will actually get a much smaller
file. So even if you add like a lot of
code to like the patched app, you
file will still be smaller and you can
very nicely overwrite
the text file using dirty code.
Um, yeah, I'm actually going to show you
do a little life demo, because it's
actually that that simple.
First, I'm going to show you.
So let's see
until.
Just have to wait a little bit until the.
The camera just to the right.
There you go.
So this is like the stemmer up the road.
Yep, and we pass all
of the checks.
And so basically, if unrooted
device, unmodified
app looks good.
So.
This is readable.
I think that's OK, that's fine.
Um, so there's this like
this is the AP, so if you just like,
unpack this APIC quickly.
And then we just kind of modified some
code,
so this is just like some small code,
which I'm going to just like in to this
application.
That's all we need.
So.
And it can just.
Now, we just like rebuild was basically
use a tool again and like those sign
use like the sign with like the default
key to like just have
a self signed a.
Oh, I guess.
I guess I didn't set the path for that.
Where is that?
Who knows where that filer's.
Sen. Bill Tool's.
Yeah, no, I have followed the path for
Sinar.
The combined arguments for Justyna, um.
Yeah, that.
I guess I should have.
Where is that?
Um, oh, yeah, yeah,
it's I heard JDK swear that's exactly
where it is, whereas my JDK.
Definitely not here.
Where is the JDK?
There we go.
Placers.
Should be more of those, yeah.
I was pretty sure.
There you go.
OK, so let's do this again.
Yeah.
So now we redesigned the app,
um, so what what
else do we need to do?
So we have or we signed up.
Um.
So we want to compile this
app on the device
with.
Basically pushing
the then the new OPK
and getting the modified comp.
Audax,
now we want the original.
We the original base file, because
we need to extract the original secrecy
and all we can do.
And so on, this
is the this is the original one,
and this one is the one we want to
change. So what what are you going to do
here is.
I want to change this one.
To this one.
And if we run it on this.
Alzira, serious news here, see oh.
You know, it's always nice if you forget
the command line of your own
applications.
And now we modify, you
know, it's modified, so this is like
patched.
And for the attack, basically push this
modified app, the modified audio
file to the to the device and then run
that one vertical.
It's another nice point of failure in the
demo.
And it didn't work.
You can try
try again.
I have a few more minutes, you
know, life that I like, life to mostly
just like turn to.
Sometimes it's like do not work
on the first try.
So good.
So he's going to reinstall the original
APIC.
Since you already have all the modified
files, you can just skip
everything else.
So let's try it one more time.
And it worked, so let's go to the
camera.
Let's wait until the white.
And now you see the snow is probably
added and you will see
all those checks passing and.
So, yeah, and basically
unrooted device, but complete,
basically compromised
from the integrity level.
So what is the actual impact of
this attack?
Yeah, it's of course, limited to Android
device that's still vulnerable to a dirty
car. There's probably like a lot of them.
The nice part is that basically the
owner of the device has to, like, perform
this attack himself because
ABSs.
So, like, if you get a malicious app that
runs on your device, it could not
modifying other app because apps cannot
open old X files.
So that's good.
Of course, the attack goes way beyond
safetynet attestations.
So any any device that
any any check you do on like
like old X Files
or something will be vulnerable to this
attack.
The nice part is Android seven devices
will not be vulnerable because
Google changed basically the policy
for this test.
So they will actually check if your
criminal has still
has this background and you will not get
Google certification, 407 devices,
the generic Ettakatol, Google, like many
by I guess now it's like probably
two years ago.
So they know it, but it's like,
I guess, hard to fix Copperhead or assets
like hard Android clone, they
actually buy it not by accident, by
design, mitigate any kind of these
attacks, but just recompiling every app
on every start.
So that would kill like modified
or X Files.
So I made some observations over time.
So basic integrity was like
June, July 2016,
suddenly, like found this.
And I was like, hey, does anybody know?
Because this is not really documented.
And then again and I guess maybe
this year the editor's advice field
that will tell you about like you
bootloader or like please refresh your
daylight's because we determined your
device was like tampered.
So that was like kind of interesting.
Now there's also like a mailing list
where you can, like, subscribe and they
will tell you, I guess, about new
features. But the website will
not be updated like in a timely way at
all.
Also, the
little bit more interesting parts,
since attestation
is based on CTS data and
CTS is run by manufacturers before
they release
an update or a patch or a phone.
So if this data is false or not up
to date, of course, the CTS
test will fail. I will tell you, like,
hey, your device has been modified
and actually found that unlike some
Yotel phone where like, I guess they
rolled out a security patch and
did not submit to test data.
So on all of those devices, actually
all of this will just fail just because
Google didn't have the up to date data
and actually Google did it themselves
here in March this year,
Google had to like pull a security update
for the Nexus seven because it
like broke their safety net
and thereby also Android pay
Pardinas. Probably
that the last part.
I don't like how that happened, but
basically, if it's safety net at the
station has an outage and
you can't react to like this outage, you
will have an outage, too, as like an app
developer.
And you probably do not want that.
The fun part about
safety in general, Google really
improves it like all the time, if you
like, follow forums, rooting forums
and so on very closely, you
will see this cat and mouse game.
Um, and
it's mostly for Google, I guess, mostly
about protecting Android pay.
You know, and yeah,
but the other the big, the big,
I guess the big benefit of of safety net
on the other station part is that
really do you have a bunch of people at
Google who constantly, like, work on
improving basically the results for a
safety net? So if you use that to secure
your own app, you get like a lot of
security for free where you
otherwise would have to, like, employ a
bunch of people or by like a third party
product that does like app and device
integrity checks for your service.
The nice part is attestations is free,
but of course it can go down and have
outages. You basically don't get an SLA.
There's raid limits which you should
never be able to reach.
Yeah, and it's free. It's like if you
compare it to like third party service
that are not free, this
should be interesting on the
side, not about malware.
So there's a lot of Android malware that
basically is repackaged Android apps.
So basically people just like add,
they're like whatever they want to do to
like Angry Birds.
And then you have like download that
modified Angry Birds, if that
if that game or like that would actually
run safety net and they
would basically have to.
Yeah. Basically that repackaging wouldn't
work because the apple just like say,
hey, I was modified and I don't work.
So they have to like either cut out a lot
of functionality of that specific app
and they probably won't do that because
then we'll just like go after some other
app so you can basically use us to
basically prevent your product from
being targeted by app repackaging malware
in a as like a site, as
a site,
as a side effect.
So summary and conclusions, basically,
it's like one of the essential platform
security services and if you like,
see serious about like any kind of
security on Android, you should really,
really use it.
As I showed you, there's like some
like downsides or some things you have to
be aware of, but you have to be aware of
those anyway. If you use if you roll your
own or like by a third party service
and the majority of apps will just like
benefit from this and
it really will really get better over
time.
And you kind of really see Google doing
improvements to that.
And that's it.
Slides are online, tools are online on
my GitHub page. Or like if you go to a
molenaar android, you'll find
everything related to this talk
some more references to read up.
That's it.
Thank you very much.
And I guess we have two minutes for
questions.
So first of all, I would like to say
one of
other people
need in order to comply.
That's another thing. That's why we
do the Q&A.
Yes, what a safety net,
not wrong with full permissions
because it runs inside
the Google Play services
like the, um, basically the, um,
the play app, like the Android
like play service
app. And that only runs like
ass like system service.
And so it doesn't run with full services
because, um,
because of that it just like runs on like
a slightly privileged like app.
And I think that's by design.
Also think about other manufacturers
like maybe Samsung or HTC.
They maybe like other companies, probably
like do not want to have a super
high privilege Google process on
their phones. It's just by design, like
that's the only thing I can think of.
Um, yeah.
Thank you. Next question from microphone
number two, please.
Hello?
Can you hear me?
Yeah, um, thank you for
your talk. First of all, uh,
it looks like surfing the Net runs
like, uh.
Under a system user,
right? Yeah, and
it has way more privileges to check
for filesystem when an ordinary
application. Yes, I do think
it is still worth to do enough
checks for things like the technical
MicroTech devices.
So I think it really depends
on your risk model.
Like if if you if you're very concerned
about modified apps or modified
devices, of course it makes sense to add
your own checks in addition.
But I think if you like starting to
develop like a new app, you should first
implement safety net at
a station and get all of this right.
And then you can, like, start investing
money to to build your own, because
if you start rolling your own, you
basically you have to have a team that
constantly, like, keeps up to date with
Android versions, because if something
changes from your app and your own
detection has false positives, you have
like just like disable your app
for, like, a lot of people.
So, um, yeah, it's
like, uh, depending on what you want to
do and like how much you want to spend on
on on. Yeah.
On that.
Thank you very much.
Unfortunately time is up by now.
So whoever else has questions, please
find Colin after the talk.
I know you probably all know
that it's pretty nerve racking when
you're on stage and your demo or whatever
you were planning in your presentation
doesn't work as planned.
So I hope that you are going to show a
lot of empathy and give Colin another
big round of applause.
Thank you very much.