 They're talking about Vulnerable Out-of-the-Box and evaluation of Android carrier devices. I'm sure that's going to be exciting right now, but here they are. Enjoy the con. All right. First I'd like to thank everyone for coming. My name is Ryan Johnson. I'm from Cryptowire and I collaborated with Angel Ostavro for this research. So why are we doing what we're doing? The short answer is to be proactive, look for vulnerabilities, responsibly disclose them to minimize any impact to the end user. So there are some recent examples for Android and on the right is from the New York Times when we found that the number one selling on lock smartphone on Amazon was sending the user's text messages and call log to a server in China every three days and it also had a command and control channel where it could execute commands is the system user. So you can see the Android software stack and mostly where we're going to focus is up at the top at the pre-installed apps also the Android framework and some system libraries. So anytime you have an Android device there's going to be some pre-installed apps on there and they can run as soon as you turn the device on. Some of these apps like platform apps and other pre-installed apps cannot be disabled so if there's a vulnerability in them you're kind of left to try and potentially root your device assuming there's a root strategy available and remove it or wait for a firmware update that fixes it and some of the platform apps they run as a system user which is very privileged so if there's a vulnerability in there an attacker can get some pretty nice capabilities. So some of these applications you know can be malicious or insecure and Android vendors when they take Android AOSP code sometimes they customize it a little bit just to differentiate themselves and in doing this they can introduce vulnerabilities. So here's a little primer on Android. When you're building an Android app there are certain functional blocks from which you can build your application. They're provided there and each of these can provide as a potential entry point into the application. When you create an Android application you declare them in the androidmanifest.xml file and you communicate with app components using intents so that's just a framework provided API class which serves as a message to send to an app component and you can also embed data in them. So what makes an application component accessible or not to other processes on the device it's regulated by two attributes that would be present in the application component declaration in the manifest file. So and there are some instances where Android will by default export an application component so if it doesn't use the Android exported attribute and it contains at least one intent filter Android will export this by default even though you didn't say set Android exported equals to true. So at the bottom there's a service that's being declared and this service is exported by default and using it you can actually download and install an application. So here's the threat model a low privilege third party app needs to be present on the device and this can reach the device either by repackaging so taking an application inserting code into it putting it onto a third party market phishing sending it directly to the target or remote exploit we saw with the eight ups command and control channel that that was over HTTP and using that you could just man in the middle it and say download this application install it and run it or it could be part of a second stage exploit. Generally the attack the permission requirements are potentially no permissions or read external storage because read external storage we've noticed that pre-installed applications some of them will just dump data to the SD card and so the the application is a malicious app without malicious permissions that is leveraging a pre-installed app an open interface in the pre-installed app to get some resources or capabilities that it cannot access directly. So here's a list of some of the vulnerabilities we found we process more than 500 firmwares and it shows the device the vulnerability as well as the carrier and we have a framework scanning for vulnerabilities and a pipeline with additional vulnerabilities that haven't yet been disclosed and in this presentation we're going to try and cover all of them. So starting off with ZTE we looked at a bunch of ZTE devices on carriers and each ZTE device we looked at contain this vulnerability so you can see the devices at the bottom and essentially any application on the device can interact with a custom service that they have and have this service start writing the modem log and the logcat log to the SD card and the logcat log the system wide one is not directly accessible to third party applications no matter what permissions they request and when this logging is occurring there's no visual or audible queue to the user that this is occurring and it writes it to a base directory of just SD card SD underscore logs. So here's some instances of things that we've seen in the logcat log so any process on the device can write any arbitrary message to the log it's a shared resource so if you leak data there it's going to show up in the log the example up at the top right that is from Fortune 500 Android Fortune 500 banks Android app and the device or the application writes the user credentials to the log some devices we've seen have the messaging app in debug mode so at that point you'll see the destination of the text message as well as the body of the text message and we've also seen things like unique device identifiers, user's email address and GPS coordinates. So due to the log being a shared resource and that any application can write arbitrary data there it was moved from an application of permission that a third party app could get to a system or platform permission in Android 4.1. Here's a list of some devices as well as the carrier and some unlocked devices where a third party application can have a pre-installed app on that device start writing the log to a location the system-wide log to a location that it can access. And I've got a question for the audience does anybody know how to interact with a bound service without the accompanying AIDL file? Okay, so this is how it works on the ZTE device. There's a pre-installed platform app. This app right after boot registers itself as a custom service called modem service. The third party app says give me a handle to this service it gets the handle from the Android OS service manager and this service that it obtains is like a mini service manager that offers five services. So you get the SD log service and at this point then you just call three functions and it will start writing the modem logs and for this it's specifically the modem log although the logcat log is done in a very similar way except just with a different service and we have a video for that. So here just going terminal application going to the SD card, going to the directory where it writes them just showing that it's not there. So for a third party application to actually access the modem log which you know contains the user's text messages and call data they would need the read external storage permission to access it. So just installing some app it's gonna be done by an activity in the foreground this could be done in the background by a service going back to the terminal that directory should be there now. And the modem logs are actually in a QMDL file which is a binary file. There is a program to access it to parse it out. I don't have that program but I can still identify where the text messages are and show you in a slide soon. So here's the logcat log which is the they should have a file for four different log buffers and it's just going to continue writing to them any time the device is on. So just lsing to show that the size is increasing and then just catting it to show the contents of it. And then we'll go back to the base directory to look at the QMDL file. We're unsure if this actually contains voice data from the telephony but it does contain the text messages and incoming and outgoing calls. So this is just parsing the QMDL file. You can see the text messages incoming and outgoing one. The phone number is in reverse byte order and the actual body of the text message is in 7-bit packed format. And so it's just incoming and outgoing text message and then just the calls that you may also show up in this QMDL file. And moving on switching to LG we have some vulnerabilities here. You can also obtain the system-wide logcat log except this you can get it written to the attacking application's private directory so you don't need any permissions and you can see the device is affected. It's generally written to the SD card but that you can use path traversal and you can also inject a parameter argument to the command that's being executed to get all of the logs. You can also lock the user out of their device so a zero permission app can just send a single broadcast intent and the screen lock will not let the user in. I'll show a video of that soon. There's another pre-installed app where you send it a broadcast intent and it's going to write a database that contains snippets of the logcat log and the kernel log to external storage. So to get the system-wide logcat log there's a pre-installed app. It will execute the command that's shown in the first bullet. This when you activate it by sending an intent you can actually provide the path. There's the default path in the second bullet so if you just do double dot slash four times it takes you back down to the root directory and then you just add on slash data slash data package name and then a file in your private directory and at that point that does require some file permission changes which any app can do. You need to have the app's private directory globally executable and you need to create that file or create the file that you're going to write to and then make it globally writable. So this system process can append to it but you'll still own the file. And in the intent you can provide an array list of strings and in these strings it's essentially just a log tag to add to the command but and it appends a colon V to it just to give any log message at any log level for that log tag but in red if you just do the wild card colon V this will give you every single log message in the log and then space and then any arbitrary word and then that gets added to the command and then it's going to start writing the system wide log hat log to the attacking applications private directory. So you can also lock the user out of their device so this makes the screen lock essentially unresponsive except for making emergency phone calls and this is done the system UI app has an exported interface where you send it a broadcast intent and at this point it's going to lock the screen and this screen lock is active in safe mode so in safe mode third party apps are running but pre-installed applications are running but it reads from system UI app will read from system settings and keep the lock in place. This sort of thing could be used for a crypto less ransomware where you could provide messages at the bottom they're called toast messages informing the user you know where to pay to unlock it and the user if they have enabled adb prior to the screen lock attack they can unlock it if they are crafty and look around change manually change the settings and or send a different broadcast intent to unlock it so have a video so this just showing we have a screen lock on and also LG patch all these vulnerabilities so just a zero permission app installing it it should run for a second and then the screen lock you can't really do much with it so unless you know you can figure you have adb enabled prior to that and you can figure out how to do it you're going to have to put in a recovery mode and factory reset the device potentially lose data to actually recover it so they're speaking of factory resets we also found that a number of devices some of them carrier some of them unlocked expose the capability to perform a factory reset if you have an android phone you've potentially gone into the settings app and seen a race data this it will perform a factory reset this is generally done just by an exposed interface in a platform app where a zero permission app sends it a specific intent message and then it will programmatically go and wipe the device and any user data that is not backed up somewhere will be lost so if you've been playing a video game for a long time made a lot of progress that's potentially gone as well as text messages and pictures so we have a video for that so this is a t-mobile revel device and we're going to just install an application it shows it it doesn't have any permissions there and then it it boots into recovery mode and then wipes the data in cache partitions so this is kind of the workflow to do it on the essential phone so just any application on the device it can have no permissions it starts an activity RT RT and reset activity that's in a pre-installed platform app which is very privileged that activity then starts another activity which is going to send the master clear broadcast intent and this will be received by the system server process the system server process provides applications with all sorts of services so the master clear receiver receives this it calls an internal API class recovery system in a method called reboot wipe user data and at this point it writes minus minus wipe underscore data as well as a few things to the column the cache partition cache recovery command then reboots into recovery mode and then just wipes the data in cache partitions so also we did find arbitrary command execution as a system user through a vulnerable platform app on the ASUS Zenfone 5 live device so we talked about the Android manifest XML file earlier here's the entire manifest file for the application so in red just showing that it's a platform app running a system blue is a package name red is exported meaning any application can interact with it and orange is the name of it and the service declaration is provided in bold so this is a bound service we don't have the ideal file but this can be found out by looking at the stub class and the stub proxy class for the service so you know usually if you had the ideal file you could use some RPC which would make it easy but since you don't you have to go one level down actually get the eye binder reference call the correct function number for it and populate any parameters in the parcel so here is just writing a string to the parcel also using one flag one way so it's asynchronous and doesn't block and here's some of the capabilities once you have arbitrary command execution a system user what you can do and we have a video for that so here just going to the applications that are installed it's called that con 26 you'll see that it doesn't have any permissions click around on it for a little bit so there's a nice little menu if you want to obtain the user's text messages you can the way it's being done takes a little bit and I'll explain why so just getting the user's contacts looking at the call log also this application has the code to be a notification listener embedded in it so it can obtain the user's notive active notifications receive them when they come in it can go take a screenshot so that shows up in the applications directory you can also this application has the code from the spelling checking framework it implements a spell checking service so at this point when the user's typing something and it doesn't work in all applications only when the spell checker kicks in but you can kind of see what they type and also record a video of kind of what the user's doing so here just playing some game and trying not to die also this application if you want to implement a keyboard on android it's called the input method editor so the previous keyboard was actually the standard looking keyboard it has the code to be an input method editor so it's going to change the settings to set itself as the keyboard so the keyboard is going to look different I mean if you wanted to be malicious you would want to try and have it match the default keyboard but the keyboard you'll see soon will be blue so it's going to swap the keyboard it's this it just writes some changes settings to have the keyboard be the one that it's implemented in its code and then any key codes that are pressed are going to be transferred to the malicious app via a dynamically registered broadcast receiver and this will get something you know everything that you type so going to type something delete it and then type something else and then just keeping a log of what the user typed and then calling 911 which if you can do I talk to a nice gentleman who was kind of understanding about it once I explained why I was doing it so we also once we saw that on aces devices we they provide actually the firmware on their website and also historical firmwares so we downloaded a bunch just to see what was vulnerable and also we also found that tablets had this vulnerable platform app then we also wanted to find out when it was introduced so we focused on one device which was the aces and phone 3 and saw that it was introduced around March 2017 and then it further got introduced into all other markets except for China which was just stated Android 6.01 which is a non-vulnerable version and this is a non-us carrier device but it's a device that's popular in Asia it's called the op-oh f5 and this vulnerability has been patched and they also went and after this became a cna which we thought was a very good thing so there's an application up on here which is a very simple application we took the odex file and then provided the source code for it so essentially it just has a thread and it will take a string and then execute it as the system user and on the lower right is actually just the code to execute it so another question for the audience so does anybody have a good way if you just have access to runtime exec to make the vulnerable app write a script and then execute it okay so what we did one of the devices we looked at actually the platform app the sce linux rules prevented the platform app from reading and writing from an untrusted third party app's private directory although all the other devices allowed that but this device prevented that so just using runtime exec is kind of limiting we would you know want to have some logic in there as well as some output redirection so the approach that we came up with to do that is just to select a string with high entropy and then in the attacking app create a dynamically registered broadcast receiver that has an action string of that high entropy string and then from there start writing to the log using a log tag of that high entropy string and then each log message contains one line of the shell script to execute you can see it number two from there since you have command execution you make it execute the command in bold so this makes it there's a bunch of parameters to it so it's just a log command minus be raw just gets you the actual log messages as opposed to the log tags and any timestamp stuff minus s silences every other tag except the one that you want which is that high entropy string at any log level minus f writes the log messages to a shell script in the vulnerable apps private directory and then minus d makes it dump the log as opposed to keep reading from it so just dumps a log buffer so that's gonna write your script to the vulnerable apps private directory and then you just change the file permissions on it and then execute it and the example here is just to get the text messages write it to a file in its private directory and then send that file using a broadcast intent and embedding it in there to the attacking apps to the attacking app and then if you relax some of the conditions if it can write to the vote the vulnerable platform app if it can write to the third party apps private directory then you can just have it write directly in there with the text messages shown here and that it requires the file permission changes that I mentioned earlier making the attacking apps private directory globally executable and creating an empty file making it globally writable. So OPPO does provide the firmwares on its website at least the most recent one so we downloaded some of those just to see what's vulnerable it's segmented by country market and we downloaded more except they use an ozip format which is encrypted we were able to get some of them but not all of them and this table is ordered chronologically with most recent first and if you do have command execution as a system user if the attacking app implements an IME or a spell checker those are just the commands to actually change it in settings the platform app has the privileges to change system settings. So we have an analysis framework we have something called force path execution which will you know take a firmware unpack it and then process all of the apps in parallel and the force path execution it can actually force into certain branch constraints just in case there's any triggered functionality to try and make the application show all of its behavior under you know any circumstances we also do some static analysis some tan analysis to see if there's any vulnerable flows to see if there's you know say that obtaining the user's text messages to see if that flows to a network socket and then also using a custom Android build where we control the framework key we can perform some hooking at the framework level and also hook some of the library calls see how the application is interacting with the system and man in the middle of the traffic and we have a video so we there's three vulnerable platform apps that have command execution as a system user so just performing some tan analysis building the control flow graphs also the data flow graphs and then looking to see if there's any paths and data that actually flow from the application entry point to runtime exec or process builder to see if there's you know any vulnerable or any pass as well as the path condition so what it would actually take to reach that path we also found that certain devices have the capability where a third party app can initiate the taking of a screenshot so this is generally from system server being modified there will be a broadcast receiver where if you send it a specific intent message it will take a screenshot and if an application has read external storage it can read from the SD card also expand the status bar to see what the user's current notifications are and this sort of thing isn't transparent to the user so they can see it but an application if it knows the user hasn't been using the device for a while it can even though there's a screen lock come into the foreground bring down the notification bar take a screenshot and then use a generic attack to soft reboot the device to get rid of the notification so we have a video showing that so there's a active screen lock on the device the application runs takes a screenshot shows up in the application's image view and then it's going to cause a system crash because that screenshot does leave a notification so it wants to remove that not to alert the user we also found an application on certain devices which allows any third party application without any permissions to send text messages read text messages modify them and also obtain the phone numbers of the user's contacts the package names are provided there one of the package package names is actually just a refactored version of the others of the namespace is a little different but the functionalities the same and this is a platform app that can't be disabled so looking at the manifest file for the application the receiver up at top and read it's exported and if you send an intent message with the correct fields that it's looking for such as the message to send and the phone number to send to it will go on and send a text message for you and there's also seven content providers which are exported and that's usually kind of strange behavior a little bit because they tend to contain their repository for data so that opens it up to any process on the device and they actually act as a wrapper so you can't query this content provider it's going to query the text message content provider get the results pass that back to you so moving on to the ZTE ZMAX champ device so there's a pre-installed platform app here which will just allow any application on the device to cause a factory reset resulting in potential data loss for the user there's also a way to get the log cat logs and modem logs that were described previously and you can also if you have just a standard zero permission third party app just with a standard template with all the call backs you can make this device non-functional with essentially one line of code by sending a broadcast intent to a specific app and we have a video showing that so this is the ZTE ZMAX champ device we're going to install an application on it I got to allow third party sources so it doesn't have any permissions that's what that screen shows going to cancel that so this application is just going to send a single broadcast intent message with a particular action string it's going all explain the workflow in the next slide but essentially what's going to happen is it writes a certain value to a file that's going to be processed in recovery mode and as far as we can tell it's going to encounter a fault boot back into recovery mode encounter the same fault while trying to erase it and it appears this is due to them using a non-AOSP command in recovery which I'm not sure is just not handled but essentially that device will just keep doing that until it runs out of battery and we weren't able to find a way to boot into an alternate mode at that point so here's the workflow for it it's just a zero permission third party app on the device it sends a broadcast intent message there's an application that has hidden menu in the package name and usually those are apps you want to look at so it sends that broadcast intent it receives it and then it's going to go on and send a different broadcast intent and it's called master clear data carrier this again is going to be received by the master clear receiver that's in system server at this point it calls a non-AOSP API method call in recovery system called reboot wipe user data in carrier it writes that file shown in step five there's minus minus wipe carrier which is not part of AOSP and then it's going to write it to that file reboot into recovery and then it's going to go into recovery and just perpetually crash in recovery mode so here's moving to Alcatel this is an unlocked device this was sold a while ago as an Amazon Prime exclusive so it would have some of the Amazon apps on there and be at a discounted price and this device allows read only properties to be modified at runtime which is not the standard behavior so if you have ADB enabled you can execute those commands below just setting RO debuggable to one and then RO security zero and then ADB root that's going to restart ADB demon running his route as opposed to ADB shell and then disabling SC Linux and then at that point you have a root shell one thing we noticed on this device we looked at the init RC file which contains commands for the init process to execute and there's a directive so if RO debuggable gets sent to one to start a process this process is the BTW land demon and it will go on and start a binary called factory test that's running as root so once that property gets changed that process starts executing as root and it essentially its function is to listen to create a socket you can send to the socket commands and it will execute them as root we weren't able to do that from a third party application but we did notice that platform apps actually can modify that permission or that property at runtime to make that socket show up we're unsure if system platform user can actually write to it but the vendor controls the SC Linux rule so if they wanted to they would be pretty close to getting command execution as root and just kind of to conclude many of these vulnerabilities were just done by insecure access control so there were a lot of exported components which you know don't necessarily need to be open to every third party application on the device also if you're an app developer you don't want to assume that you know just because an application doesn't have the AIDL file for the bound service that they can interact with it somebody will be able to figure that out and you know access it if you are executing commands as a system user and somehow that gets exported you would at least want to filter commands just so it's not any arbitrary commands only actually what's needed and just from the responsible disclosure process all of these vulnerabilities were responsibly disclosed although sometimes it's difficult to find you know who exactly to talk to who's going to escalate it quickly so if there was a common email address to send to that would facilitate things and also we have a report if you're interested send us an email and does anybody have any questions I didn't look at any one plus devices I was sorry so the question was if we looked at any one plus phones because they actually have the parent company is I think BBK electronics which owns Appo Vivo and one plus but and like we haven't looked at one plus devices one of the things that I want to point out is that the devices that we show today are a small sample of the devices that we have identified as being vulnerable clearly the length of the talk does not allow us to talk about all the devices that we have found but there were more than 26 devices that we have currently identified that disclosed as part of the report and we have an ongoing pipeline of devices that we have identified that are vulnerable and we're in the process of disclosing it to the vendors the key here is that a lot of the devices come with a lot of the OEMs have vulnerabilities that the devices come from the factory directly to the user and this these vulnerabilities cannot be disabled but they use it even if they identify that their phone is vulnerable and I think that's the important part here. The question is if the essential phone is specific to Sprint no it's not specific. The reason that we have some of the phones are tied to carriers is because we wanted to show that basically that's not a specific carrier problem or specific OEM problem but it's a pervasive problem across multiple carriers and the industry needs to be looking at that as a whole rather than you know specific carriers. So this is the answer to that is no and the reason is because this type of we looked at over 500 firmware we didn't have this is the first initial preliminary I would say presentation for the study we do believe that there are other vulnerabilities so if you don't see a phone here it doesn't mean that we looked at it and it's not vulnerable. We had limited amount of time and you remember that all of these devices were disclosed 60 days so between the 60 days prior and now we have more devices identified which we cannot disclose here but they're still vulnerable. I didn't hear the question. Yeah we weren't aware of that at the time but thanks for letting us know. So I want to point out that the disclosure happened not only to the OEMs guys the disclosure happened to Google and to the carriers themselves so it's not that we tried very hard to reach out to the responsible parties and have these these firmware spots ahead of our presentation so basically we don't put people in hands way and most of the vulnerabilities somehow being either addressed or there's a fix prepare some of them are not but this completely up to the OEMs and the carriers to that process to proceed. Kind of a history with Samsung I mean they've given me you know bug bounty a free phone I presented at Black Hat Asia 2015 for them. So the short answer is that we are in the process of looking into more devices. Some of them might be vulnerable some others are not. We cannot disclose anything today more than but we disclose because we are in the 60 to 90 days disclosure process that we have established with the OEMs. I don't know if we can we can't speak for Google. Yeah I think I think you can you can directly address the question directly to Google. I think I think they're trying hard to help with the ecosystem security but I mean we cannot answer questions. Thank you very much.