You all know the drill by now. So we've 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. No, no, no. Get them up on stage. I mean, come on. You
there's 1,500 of my closest friends. All right. Pour him another one. He can't ‑‑ don't ‑‑
dude, slow down. Holy shit, he's taking a ‑‑ all right. You know what? Hold it ‑‑ don't
give it to him until we're ready. Because he's scaring me. All right. Our tradition
is first‑time speakers ‑‑ where's mine? All right. First‑time
speakers. All right. First‑time speakers. All right. First‑time speakers. All right. First‑time
speakers. How about a round of applause for our first‑time speaker and for our first‑time
attendee? Good luck with your talk. Yeah, the person typewriting this will have a hard
time now. I want to point out he had no accent before that shot. Yeah, sorry,
guys. My English is Spanglish. All right. I'm going to talk about SE Android,
which is, as you might know, Selenox in Android operating system. It has now been renamed. So the
name is Security, Defeating Security Enhancements for Android. My name is Paul Ibafora. I'm at
POF in Twitter. Some of you follow me. If you don't, you should. And, yeah, I'm a mobile
security engineer with VIA Forensics. I do R&D in Android security. And I'm also co‑author
of the Android Hackers Handbook, which hopefully will come out later this year. I've brought
these postcards. So you are welcome to come after the presentation and grab one. I have
a bunch of them here. All right. This is the agenda for today. First, I will talk about
in which devices I have test SE Android, most of them. Then I will briefly talk about effectiveness
and weaknesses of SE Android. And then to the dirty details of the implementation issues
that I've found on most of these devices. So first thing that you might want to try
if you care about SE Android, you can compile it from public sources, that is, AOSP, Android
Open Source Project, and also the BitBucket repository that the NSA controls, your beloved
NSA. They are the contributors of the SE Android code. And they host it in BitBucket.
So that is the S damager application which is used to set the system in enforcing mode.
And also the SE admin which is now ‑‑ has replaced SE Manager. It's better because
it runs as device administrator, while SE Manager just runs as a system application.
I've also tested SE Android in the Toshiba AT300 tablet. It runs both on the Android
This tablet here, to my knowledge, this is the first device that was in the market with
some C Android implementation.
It's a bit weird.
It's not the same as the Android we have seen in other devices.
It uses a Linux kernel module and, yeah, 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've also tested it a little bit before coming here and found little things.
Yeah.
You might know that C Android is effective.
It's good to enforce fine-grained mandatory access control.
Which it's different.
It's different from the discretionary access control that we are used in Linux and Unix
system and also in Android with file permissions and user IDs.
So in C Android you have also three different branches to test mandatory access control
in install time of application.
Also in intents and in content providers.
It is good to prevent privilege escalation.
By isolating context.
So a context is a process runs inside a context.
So for example, we can say an untrusted application, we can define a rule to set if we allow this
untrusted application to access files on the SD card or access the radio interface
layer, whatever, if we would like to allow it to do or not.
Okay.
So as every application runs confined in this context, this allows to prevent privilege
escalation because application cannot access file outside this context.
It's also good to do permissions checks on IPC, interprocess communication operations,
which is mainly binder on Android.
And it's good also to do permission recovery.
It's also good to do the authentication of application either at install time or on
already installed applications.
And yeah, but not everything is so good as it might sound.
The most known thing, it runs kernel level.
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 completely.
The security of C Android.
So for this, it needs to be enhanced with, for example, the typical setup is to have
a secure bot mechanism that makes sure that the code that we are running, the kernel is
not tampered or modified in any way.
And also some runtime integrity check, which can be hypervisor or, for example, trust zone
also allows to make sure that the kernel is not mute or modified at runtime.
Yeah, also vendors or companies deploying policies for employees 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's what vendors are more ‑‑ are having a hard time, right?
And that's where they screw up as well.
So this leads us to see the implementation issues.
First thing, okay, when you have all your C Android setup working properly, you set
the system to boot in enforcing mode.
And some vendors ‑‑
VENDORS, SOME PEOPLE SETTING THIS UP, FORGET ABOUT THE RECOVERY IMAGE.
IF YOU BOOT IN ENFORCING MODE ALSO, DON'T FORGET YOUR RECOVERY TO BE IN ENFORCING MODE.
NEVER LEAVE IT IN PERMISIVE MODE.
SO I WAS GOING TO DO A DEMO HERE, BUT THIS IS SO OBVIOUS THAT IT DOESN'T NEED A DEMO.
ANOTHER THING IS POLICY SCREW UP OF VENDORS.
THEY SAY, OKAY.
MY DEVICE IS RECOVERY.
IT'S RUNNING IN ENFORCING MODE.
SO I'M PREVENTING THE ROOT USER TO SET PERMISIVE MODE AGAIN.
SO THEY WRITE A RULE THAT SAYS ROOT USER CANNOT SET THE DEVICE IN PERMISIVE.
SO ROOT USER CANNOT USE THE SET ENFORCE COMMAND, RIGHT?
BUT THEN THEY FORGET ABOUT SYSTEM USER.
SO AGAIN, AS YOU SEE HERE, WE HAVE THE ID COMMAND.
IF WE DO A SET ENFORCE ZERO OR ECHO ZERO TO C, S, F, S, SELENUX, IT SAYS PERMISSION DENIED.
WE JUST HAVE TO SUE SYSTEM.
ONCE WE ARE RUNNING WITH SYSTEM PRIVILEGE, WE CAN JUST USE SET ENFORCE ZERO AND SET
THE SYSTEM TO PERMISIVE.
SO TYPICAL SCREW UP, RIGHT?
ALSO THIS IS ANOTHER ISSUE THAT I'VE SEEN SOMETIMES.
THIS COMES.
BECAUSE A LOT OF PEOPLE HAVE USED THE SC 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.
IF WE COMBINE THIS WITH FAIL NUMBER ONE, WHICH IF YOU REMEMBER WAS RECOVERY WAS LEFT IN
PERMISIVE MODE, IT'S VERY EASY TO REVOTE INTO RECOVERY AND PULL THE SYSTEM APK OF
THE SC ANDROID MANAGER, JUST TO HAVE A BACKUP, THEN REMOUNT THE SYSTEM IN READ WRITE MODE
AND REMOVE THE SC ANDROID MANAGER APK FROM THE SLASH SYSTEM, SLASH APP FOLDER.
SO WE HAVE JUST REMOVED THE SYSTEM APPLICATION THAT SETS THE SYSTEM IN ENFORCING MODE,
RIGHT?
SO IT WILL VOTE IN PERMISIVE.
BUT WHAT IF WE DON'T HAVE ACCESS TO RECOVERY OR WHAT IF RECOVERY IS RUNNING IN ENFORCING
MODE?
WELL, NO PROBLEM.
THIS ‑‑ SORRY.
HERE, THIS IS A GALAXY NEXUS RUNNING SELINUX.
WE RUN THE SC MANAGER APPLICATION.
WE PUT THE SYSTEM IN ENFORCING MODE.
SO IN THIS SHELL HERE, FIRST I CHECK IF THE DEVICE IS RUNNING.
THE DEVICE IS RUNNING IN ENFORCING MODE.
SO I USE THE COMMAND GET ENFORCED.
I SEE IT SAYS ENFORCING.
SO NOW I REBOOT THE DEVICE AND I SET ONE LINER TO CHECK EVERY SECOND THE GET ENFORCED COMMAND.
SO WE SEE IT SAYS ERROR DEVICE NOT FOUND BECAUSE THE DEVICE IS STILL BOOTING.
BUT WHEN ADB DIAMOND IS RUNNING, WE WILL SEE THAT THE SYSTEM IS BOOTING IN PERMISIVE
MODE, RIGHT?
AND NOW THE ANDROID SYSTEM WHEN IT FINISHED THE BOOT, IT BROADCASTS A BOOT COMPLETE EVENT
TO ALL APPLICATIONS THAT HAVE REGISTERED TO RECEIVE IT.
SO IT IS NOW IN ENFORCING MODE BECAUSE THE SC MANAGER APPLICATION HAS RECEIVED THE BOOT
COMPLETE EVENT AND HAS SET THE SYSTEM IN ENFORCING.
BUT YOU CAN SEE WE HAVE A WINDOW THERE.
SO WE CAN TAKE THIS WINDOW WHILE THE SYSTEM IS BOOTING WHICH IS STILL IN PERMISIVE 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 PACKAGE MANAGER JUST TO DISABLE THE COM.ANDROID.SE
ANDROID MANAGER APPLICATION.
SO IN THE UPPER TERMINAL WE SEE IT'S BOOTING IN PERMISIVE.
WE EXECUTE THE COMMAND BUT IT SAYS ERROR BECAUSE THE PACKAGE MANAGER IS NOT LOADED YET.
BUT NOW IT SAYS OKAY.
NEW RELEASE.
WE HAVE DISABLED THE C ANDROID MANAGER APPLICATION WHICH IS A SYSTEM APPLICATION AND THE SYSTEM
IS FULLY BOOT AND IS STILL IN PERMISIVE MODE, RIGHT?
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 MODE IN INIT RIGHT BEFORE THE ADB DIAMOND STARTS.
SO THIS SINGLE ONE LINER HERE WILL DO THIS, THE SAME POCK THAT WE HAVE SEEN IN THE VIDEO.
YOU CAN ALSO OVERCOMPLICATE THAT AND WRITE AN ANDROID APPLICATION WITH A HIGHER PRIORITY
BOOT RECEIVER AND DO THE SAME FROM AN ANDROID APP.
BUT YEAH, SYSTEM FROM THE SHELL IT'S EASIER AND FASTER.
NOW THE TOSHIBA TABLET.
IF YOU REMEMBER, THIS WAS THE C LINE MODE.
THAT DOESN'T ALLOW US TO DO SOME THINGS LIKE, FOR EXAMPLE, MOUNTING THE SYSTEM PARTITION
IN READ WRITE MODE EVEN IF WE ARE ROOT.
SO THIS IS POSSIBLE TO DO ON ANY ANDROID SYSTEM.
BUT IN THIS TOSHIBA TABLET, IT DOESN'T ALLOW US TO DO THIS.
SO I HAVE A DEMO HERE.
SO WE WILL.
.
USE THE TOSHIBA TABLET AND WE WILL DISABLE THIS C LINE MODULE, WHICH IS BASED ON AN ANDROID.
WE RUN AN ADB SHELL ON THE DEVICE.
WE SEE THE C LINE 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 IN READ WRITE.
IT SAYS OPERATION NOT PERMITTED.
WE TRY TO LEASE THE PROC SEANDROID FOLDER AND IT SAYS OPERATION NOT PERMITTED.
OKAY.
NOW I'M GOING TO COMPILE THE EXPLOIT.
THE CODE WILL BE AVAILABLE AFTER THE TALK.
DON'T WORRY.
SO I JUST ADB PUSH THIS EXPLOIT INTO THE DATA LOCAL TMP FOLDER.
AND ACCESS THE ADB SHELL AGAIN.
OKAY.
SO NOW I'M GOING TO PUSH THIS EXPLOIT INTO THE DATA LOCAL TMP FOLDER.
JUST GIVE EXECUTE PERMISSIONS TO THE EXPLOIT AND THEN RUN IT.
AND NOW WE HAVE OVERWRITED A KERNEL POINTER AND RUN THE RESET SECURITY OPS SYMBOL, WHICH
NOW DISABLES THE LINUX SECURITY MODEL AND ALLOWS US TO REMOUNT THE SYSTEM IN READ WRITE
OR LEASE THE PROC SEANDROID FOLDER, WHICH WAS FORBIDDEN BEFORE.
SO WE HAVE EFFECTIVELY DISABLED.
THIS WORKS BECAUSE IN A LOT OF ANDROID DEVICES, NOT ONLY THIS TOSHIBA TABLET, BUT A LOT OF
VENDORS SCREW THIS.
THERE IS THE CONFIG, STRICT DEF MEM, KERNEL CONFIGURATION OPTION, WHICH SAYS IF IN DOUBT,
SAY YES, BUT THEY HAVE SAID NO.
SO THIS ALLOWS FOR FULL ACCESS TO KERNEL 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.2.2 TO 4.3 LEADS TO UNLABELED FILE
SYSTEM.
WE SEE HERE.
L.S.
OF SLASH SYSTEM.
THIS IS BECAUSE THE RECOVERY OF ANDROID 4.2.2, THE RECOVERY IMAGE OF ANDROID 4.2.2, IS NOT
COMPILED WITH CELINUX SUPPORT.
SO THIS HAPPENS.
WE HAVE REPORTED THIS TO IOSP, AND HE SAID IT WILL BE FIXED IN THE NEXT RELEASE BECAUSE
THE ANDROID 4.3 RECOVERY IS ALREADY WITH CELINUX SUPPORT.
.
.
And finally, if you want to play with it, you have to know that the ENFORCING MODE IN
NEXUS DEVICES ISN'T REALLY ENFORCING.
IF YOU PULL THE SC POLICY FILE, WHICH CONTAINS THE BINARY FILE, WHICH CONTAINS ALL THE POLICIES
COMPILED ON IT, AND YOU RUN THE SC INFO COMMAND ON IT, YOU WILL SEE THAT, FOR EXAMPLE, HERE,
THIS IS FOR NEXUS 4.
WE SEE THAT THERE ARE 44 PERMISSIVE DOMAINS.
SO EVERY SINGLE DOMAIN IS SET TO PERMISSIVE.
AND EVERYTHING IS UNCONFINED.
SO ENFORCING ISN'T REALLY ENFORCING HERE.
IF YOU WANT TO PLAY WITH THIS, THERE IS A TOOL WHICH IS THE SC POLICY INJECT THAT ALLOWS
TO INJECT YOUR OWN POLICIES INTO THIS.
OR YOU CAN ALSO COMPILE FROM IOSP BECAUSE NOW IOSP INCLUDES ALL THE C ANDROID STUFF.
AND THAT'S IT.
THANK YOU VERY MUCH FOR ATTENDING.
.
IF YOU CARE ABOUT ANDROID SECURITY, YOU SHOULD FOLLOW THESE GUYS HERE.
THEY HAVE HELPED ME IN THE RESEARCH AND IN THE MAKING OF THIS PRESENTATION.
AND ALSO IN THE URL AT THE BOTTOM, YOU CAN DOWNLOAD THE PRESENTATION AND I WILL PUBLISH
THE EXPLOIT CODE AND THE VIDEOS LATER TODAY.
THANK YOU VERY MUCH.
Thank you.