 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 can dream, can't you? Here's 1,500 of my closest friends. All right. Pour him another one. He can't. You 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. 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 type writing this will have a hard time now. I want to point out you had no accent before that shot. Sorry, guys. My English is... Spanglish. All right. I'm going to talk about AC Android, which is, as you might know, Selenux in Android operating system. It has now been renamed, so the name is Security, Defeating Security Enhancements for Android. My name is Pauli Bafora. 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 BF4N6. I do R&D in Android security. And I'm also a 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. And this is the agenda for today. First, I will talk about in which devices I have test AC Android, most of them. Then I will briefly talk about effectiveness and weaknesses of AC 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 AC 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 AC Android code. And they host it in Bitbucket. So there is the AC Manager application, which is used to set the system in enforcing mode. And also the AC Admin, which is now has replaced AC Manager. It's better because it runs as a device administrator, while AC Manager just runs as a system application. I've also tested AC Android in the Toshiba 8300 tablet. This tablet here, to my knowledge, this is the first device that was in the market with some AC Android implementation. It's a bit weird. It's not the same AC Android we have seen in other devices. It uses a C-Lime Linux kernel module. And, yeah, it's based on an early implementation of AC Linux. It runs as a Linux security module. And finally, Android 4.3 came last week. And as you might know, it comes with AC Linux by default. So I've also tested it a little bit before coming here and found little things. Yeah, you might know that AC Android is effective. It's good to enforce fine-grained mandatory access control, which is 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 AC Android, you have also three different branches to test mandatory access control in installed time of application, also in intents and in content providers. It is good to prevent privileged escalations 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 we would like to allow it to do or not. So as every application runs confined in his context, this allows to prevent privileged escalations because application cannot access file outside this context. It's also good to do permissions checks on IPC or inter-process communication operations, which is mainly binder on Android. And it's good also to do permission revocation of application, either installed time or 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 a 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 lets 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, 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 left, leave it in permissive 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 policies screw up of vendors. They say, okay, my device is running in enforcing mode. So I'm preventing the root user to set permissive mode again. So they write a rule that says root user cannot set the device in permissive. So root user cannot use the setting force command, right? But then they forget about system user. So again, as you see here, we have the ID command. We are root, if we do a setting force zero or echo zero to CSS, Selenux and force, it says permission denied. We just have to sue system. And once we are running the system privilege, we can just use setting force zero and set the system to permissive. So typical screw up, right? Also, this is another issue that I've seen sometimes. This comes because a lot of people has used the SEM 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, recovery was left in permissive mode, it's very easy to reboot into recovery and pull the system APK of the SEM manager just to have a backup then remove the system in read write mode and remove the SEM 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 boot in permissive. 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 Selenux. We run the SEM manager application. We put the system in enforcing mode. So in this shell here, first I check if the device is running in enforcing mode. So I use the command get enforce. I see it says enforcing. So now I reboot the device and I set one liner to check every second the get enforce command. So we see it says error device not found because the device is still booting. But once ADB 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 brought the SEM 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 where while 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 all applications that have registered to receive it. So it is booting in permissive mode. So we can take this window where 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, we choose the package manager just to disable the com.android.se booting in permissive, we execute the command, but it says error because the package manager is not loaded yet. But now it says, okay, new state disabled. We have disabled the C android manager application, which is a system application. And the system is fully booted and it's still in permissive 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 book that we have seen in the video. You can also over complicate 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 module 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. Yeah. So we will use the Toshiba tablet and we will disable this C line module, which is based on SC 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 says operation not permitted. We try to list the proc SC Android 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. Just give execute permissions to the exploit and then run it. And now we have overwrite a kernel pointer and run the reset security ops symbol, which now disables the Linux security module and allows us to remove the system in read write or list the proc SC Android folder, which was forbidden before. 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 screw this. There is the config strict fmem 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, these implementation issues that I got found real quick because it came last week. One thing is that the over the air update from 4.2 to 4.3 leads to unleveled file system. We see here ls of slash system and we see that all files there are unable. This is because the recovery of Android 4.2.2, the recovery image of Android 4.2.2 is not compiled with Selenux support. So this happens. We have reported this to jump up this square of IOSP and he said it will be fixed in the next release because the Android 4.3 recovery is already with Selenux 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 sce policy file which contains, it's a binary file which contains all the policies compiled on it and you run the sce info command on it, you will see that for example here, 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 unconfined. So enforcing isn't really enforcing here, right? So if you want to play with this, there is a tool by Joshua Brindel which is the sce policy inject that allows to inject your own policies into this. Or you can also compile from IOSP, right? Because now IOSP includes all the C100 stuff. And that's it. Thank you very much for attending. 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 in the URL at the bottom, in the ViaFrancis website, you can download the presentation and I will publish the exploit code and the videos later today. Thank you very much.