>> You all know the drill by now.
So we have decided to change it up a little bit today.
So, raise your hand if this is your first DEF CON as an attendee.
You liars!
All right.
You on the end.
Yes, you.
Get up here.
(Laughter) >> No, no, get him up on stage.
I mean, come on.
You can dream, can't you?
Here are 1500 of my closest friends.
What are you doing?
All right, pour him another one.
You don't ‑‑ dude, slow down.
Holy shit, he's taking a ‑‑ you know what, hold it.
Don't give it to him until we are ready, because he's scaring me.
All right.
Our tradition is, first time speakers ‑‑ >> Where is mine?
First time speakers, how about a round applause for our first‑time speaker and for our first‑time
attendee.
(Applause) Good luck with your talk!
(Laughter) >> PAU OLIVA FORA: The person type writing
this will have a hard time now.
(Chuckles).
>> I want to point out, he had no accent before that shot.
(Laughter) >> PAU OLIVA FORA: Yeah, sorry, guys, my English
is Spanglish.
(Laughter).
All right.
I'm going to talk about SEAndroid, which is as you might know security enhancements in
the Android.
It's now been renamed so the name is security enhancement for Android.
My name is Pau Oliva Fora I'm at POF at Twitter.
Some of you follow me.
If you don't, you should.
I'm mobile security engineer with via forensics.
I do R&D in Android security.
And I'm also a co‑Arthur of the Android hacker's handbook, which will helpfully come
out later this year.
I brought these postcards.
So you are welcome to come after the presentation to grab one.
I have a bunch of them here.
This is the agenda for today.
First, I will talk about in which devices I have tested the Android, most of them.
Then I will briefly talk about effectiveness and weaknesses of SEAndroid, and then to the
details of the implementation issues I found on most of these devices.
So, first thing that you will might want to care about the SEAndroid, you can compile
it from public services which is AOSP, Android open source project and the bitbucket, that
the NSA controls.
You love the NSA.
They are the contributors of the SEAndroid and they host it in bitbucket.
So there is the SEmanager application, which sets it in enforcing mode and SEadmin, which
has replaced the SEmanager.
It's better because it runs the device administrator, while SEmanager runs as a system application.
I have also tested SEAndroid in the Toshiba AT300 tablet.
This tablet here.
This was first device in the market with some SEAndroid.
It's a bit weird.
It's not the same as the SEAndroid we have seen in other devices.
It uses Sealime, Linux security module.
It's based on an early implementation of SELinux.
It runs as a Linux security module.
And finally, Android 4.3 came last week and as you might know, it comes with SELinux by
default.
So I have also tested it a little bit before coming here, and found little things.
Yeah, you might know that SEAndroid is effective.
It's good to enforce fine‑grained mandatory access control which is different from the
discretionary access control that we use in Linux and UNIX system and also in Android
with file permissions and user IDs.
So in SEAndroid, you have also three different branches to test mandatory access control,
install time of application and intent and content providers.
It is good to prevent privilege escalations by isolating context.
So a context is a process runs inside a context.
So, for example, we can say, a trusted application, we can define a rule to set if we allow this
entrusted application to access files open the SD card or access the radio interface,
whatever, if we would allow it do or not.
So as every application runs confined in this context, this allows to prevent privilege
escalations since it can not access the file outside of this context.
It's also good to do permissions checks on IPC, on the process communications operations
which mainly binder on Android and it's also good to do permission revocation, or installed
applications but, yeah, not everything is so good, as it might sound.
The most known thing, it runs kernel levels.
So it doesn't protect against kernel vulnerabilities.
If an attacker is able to get arbitrary code execution in kernel LAN, it's very easy for
him to disable the security of the Android.
So for this, it needs to be enhanced with, for instance, the typical is to have a secure
boot mechanism that makes sure the code we are running, the kernel is not tampered or
modified in any way and also some runtime integrity check, which can be hypervisor,
to make sure that the kernel is not moot or modified at runtime.
Yeah, also vendors or companies deploying policies for employers using this bring your
own device thing, they don't know how to write policies, right?
Because in a commercial device, there can be, like, thousands of policies, and it's
hard to write them, and hard to not make any mistake when there is a high number of policies.
So that is what vendors are more ‑‑ having a hard time, right?
And that's where they screw up as well.
So this lets us to see in the implementation issues.
First thing, okay, when you have all of your SEAndroid app working properly, you set the
system to boot in enforcing mode, and some vendors, some people are setting these apps
forget about the recovery image.
If you boot in enforcing mode also, don't get your recovery to be in enforcing mode.
Leave it in permissive mode.
I was going to do a demo here, but this is what I will use.
It doesn't need a demo.
Another thing is policies screw up of vendors.
They say, okay, my device is running in enforcing mode.
So I'm preventing, the root user.
They set a mode saying the root user cannot set the device in permissive.
So the user cannot use the set enforce mode, but then they get about system user.
So again...
(Laughter).
Again, as you see here, we have the ID command.
Our root, if ‑‑ if we do our set enforce 0, it says permission denied.
We just have to do the system, once we do system, we can do setenforce.
So a typical screwup, right?
Also, this is another issue that I have seen sometimes.
This comes because a lot of people has used the SE manager application, and they rely
on this application to set the system in enforcing mode.
So you should never set enforcing mode from a system application, right?
We will see now why.
So if we combine these with fail number one which if you remember was the recovery was
left in permissive mode.
It's very easy to reboot into recovery, and pull the system APK of the SEAndroid manager,
just to, and then remount the system mode and then and they just have to remove the
system that sets it in enforcing mode, so we have it permissive.
What if we don't have recovery?
Or what if recovery running in enforcing mode?
Well, no problem.
This ‑‑ sorry.
(Laughter).
Here these is a Galaxy Nexus.
We put the system?
Enforcing mode.
So in this shell here, first I check if the device is running in enforcing mode.
So I use the come and get enforce.
I see it says "enforcing."
So now I reboot the device and I set 19er to check every second that get enforce command.
So we see it says "device not found" because the device is still booting, but when the
AP Diamond is running, we will see that the system is booting in permissive mode, right?
And now the Android system, when it finished the boot, it broadcasts a boot complete event
to our application that has resisted to receive it.
So it is now in enforcing mode, because the C manager application has received the boot
complete event and has set the system in enforcing, but you can see that we have a window there.
So we can take this window, while the system is booting, which is still in permissive mode,
and we reboot the device again and we will use this window.
We have a little race condition here but we have plenty of time.
So we prepare this command, which uses the manager.
So in the upper terminal, we see it's booting in permissive, he execute the command but
it says error because the package manager is not loaded yet.
Now it says, okay, new state disabled.
We have disabled.
The SEAndroid application manager which is a system application, the system is still
fully boot and still in permissive mode.
So it's as easy as this to disable a system application, which sets the system in enforcing
mode.
So this should be always set in init.
You have to set enforcing mote in init, right before the AP Diamond starts.
So this single one liner here will do this same work we have done in the video.
You can over complicated this and write an Android application with a higher priority
and boot procedure and do the same thing from the Android app.
But system, from the shell it's easier and faster.
Now, the Toshiba tablet, if you remember, this was the Sealime model, that does not
allow us to do some things, like, for example, mounting the system par missioning, even if
we have root.
Have so this is possible to do on any Android system but on the Toshiba tablet, it does
not allow us to do this.
So I have ‑‑ wait.
I have a demo here.
Yeah.
So we will use the Toshiba tablet and we will disable
these Sealime module which is based on SEAndroid.
Okay we run an ATP shell, we see the Sealime module is loaded.
We try to remove it.
And it says it failed, right?
It doesn't allow us to remove it.
So we try to mount system partition, it says the operation not permitted.
To try to list the proc as SEAndroid and it says operation is not permitted.
Okay, now I will compile this exploit.
It will be available after the talk.
So don't worry.
So I just ATV push this exploit into the local folder and access the ATV shell again.
Just give execute permissions to the exploit and then run it.
And now we have overwrite counterpointer and run the security ops symbol, which now disables
the Linux security module and allows us to reboot the system, in the SEproc.
So we have effectively disabled this.
This works because in a lot of Android devices, not only this Toshiba tablet but a lot of
vendors, there is the config strict def mem kernel memory operation which says if in doubt
say yes, but they have said no.
So this allow for full access to memory on a root process.
So you can poke the kernel memory as you wish.
And finally, the Android 4.3.
This implementation issues that I have found real quick because it came last week.
One thing is that the ‑‑ over the air update from 4.22 to 4.3 leads to unabled file
system.
We see here LS/system and we see that all files there are unlabeled.
This is because the recovery of Android 4.2.2, the recorded image of 4.2.2 is not compiled
with Sealime Linux support.
And so this happens.
We have reported this so ISOP, and we says it will be fixed in the next release, because
the Android 4.3 is already with Linux support.
And finally, if you want to play with it, you have to know that the enforcing mode in
the Nexus devices isn't really enforcing.
If you pull the SC policy file, which sometimes is a big binary file, which all the policies
compile in it and you run the SE info command on it, you will see that, for example, this
is for a Nexus 4.
We see that there are 44 permissive domains.
So every single domain is set to permissive, and everything is in confine.
So enforcing isn't really enforcing here.
Right?
So if you want to play with this, there is a tool, by Joshua Brindle, which is the SC
policy inject that allows to you inject your own policies into this or you can also compile
from ISOP, because ISOP includes all the Android stuff.
And that's it.
Thank you very much for attending.
(Applause) And if you care about Android security, you
should follow these guys here.
They have helped me in their research and in the making of this presentation and also
at the URL at the bottom, at the via forensics, I will publish the exploit code and video
later today.
Thank you very much.
(Applause).
If you have any questions, feel free to ask them.
Oh, and don't get to come and take the book.