← All talks

Breaking The Impossible: Bypassing Android's Secure Hardware Backed Attestation by Joseph Foote

BSides Basingstoke35:45402 viewsPublished 2022-07Watch on YouTube ↗
Speakers
Tags
CategoryTechnical
StyleTalk
Show transcript [en]

so the title of this talk is Android safety net Hardware um back test station now I'm going to introduce all the Core Concepts and start our low level and try and make sure that everyone can understand hopefully and follow along even if you've not got any better background or you're not in security Etc specifically we're looking at what I refer to as bypassing the impossible and I explain why I'm confronted as that as we go so a little bit of an introduction to who I am I know you're all sick of seeing who I am be atop the slide and it's a bit there it's a cool part we're here now so I'm a security researcher and consultant my day job is actually in consultancy however during my hobby time my free time Etc I'm always hacking something trying to break something new or generally just doing something that I find fun which happens to be typically around computing I have a background in faucet development as well um with around 10 plus years just of my own personal life programming a minimum with fluency far to main languages account and my current hobby project is trying to run doom on an HDMI adapter and specifically this is uh an apple little Haywire adapter that plugs into your iPhone and it has its own system it has round memory Etc a lot of weird quirky limitations I'm trying to export that so I can get Doom running on it and plug it in and make it persist as well um all the necessary areas of expertise in there so how to piece together pieces though it's gonna be good fun hopefully the next talk will be on that um responsible disclosure just for everyone here this has been as close to Google I haven't had confirmation yet if it's a unique volatility as far as I know from Google or searching the web Etc and no one else has done something like this attempted it Etc The Source code's not available yet there's two reasons for that okay I don't really want anyone exploiting you before it can be fully patched and mediated although technically you could try and do your implementation but you've answered a few herders along the way and secondly Source code's a mess I've tried my best to make it clean and readable um but I've been tweaking it and the last few days have been a real rush to try and make this as um functional as possible foreign it's essentially a module or a library that you have because you can load and attempt to do a few key things and I cover this in the next slide just so it makes a little bit more sense of reference but it's only supported on Google pixel devices and that means essentially that what our oldest for this would be for instance Google pixel 4 and later specifically because that's when they invented Hardware testation which uses part of the actual system to perform a process it's theorized to be impossible to bypass take another pinch of salt bow because the majority of these people are self-programmed experts on Twitter who believe that it can't be done and no one should ever attempt to and you're stupid for trying um or something along those lines as we know that to hackers something's impossible because when you do they get furious they start breaking things and then suddenly you've got an expert in your hands so the use of safety net I just touched upon you can use it for my daughter or a variety of functions particularly verification is installed on the device so for instance if you have malicious applications or something that's not approved by Google a safe browsing API which refers to verifying URLs that might look like they're potentially phishing on dodgy domains strange characteristics Etc but that's prior to when a user visits it and that uses Google's database essentially of what makes it a good and more bad a recapture API white standard things has proven like they're not robots and then finally and this is what we're actually interested in the attestation API so a testation on Android means checking the device's state and a variety of facts about it to determine things like is it rooted or has it been tampered where has the Constitution being changed the idea is that bank social media Games Etc can use this and essentially say yes this device is in a good State and we continue to operate on it it's quite straightforward to actually Implement for a developer pump you do require an API to you from Google which can be obtained in all of around 10 or 15 minutes have I was lazy suffered my purposes I stole someone else's key um and here's a little example of how it works at kind of high level so on Android applications typically have a naming Convention of something like com for example not my app and this is actually an APK so when you click on the settings app that's the individual APK when you click on photos that's another individual APK so your application Imports the safetynet library and the message dependencies for it that in turn facilitates speaking to Google Play services on the device itself and then Google Play services speaks to Google's actual API which is remote and on the internet and this API takes the blog data you've sent which we'll cover in more detail exactly what that is it signs it checks it Etc and returns something you can actually use to save this device is secure it's being verified by Google and you can essentially verify the signature of that on your own actual web server so they are step three is a website for the application and you can think of this in ethereum account like a bank that might have the application their test security of the device and they send the token they get back with Google's API with every single request and that's verified or server side which essentially limits and removes the facts of you being able to bypass client-side security if you can't use the internet functions that are sort of dependent to do what you want so an example of how this is actually implemented is quite simple before this in the main class of the actual program we have about three or four Imports which is just graphing safety net jerseys but let's break down this code for people who are Java developers and try and understand it a little bit better so the first lines say I want to create a safetynet client and I want to instantiate that you'll see in the brackets given is an argument called Tab and we're covered out a little bit more later but essentially the context of the application which is a way for something to achieve details of the app like its name what do what kind of activities it exposes Etc so we're giving the API some reference to our app and then after that we're asking it to perform our test function and this a test is actually a task I mean it is asynchronous takes a while to return it doesn't it doesn't immediately return so we actually have to then call or set up essentially a listener or callback for it and it says that when the task is finished the safety that test patient pass you want to call the on success callback with our testation response included and then we can grab from the attestation response object within Paul Park a jws token I'll detail a little bit more of that is in next slides and then finally we just have a simple debug message just so we as a developer know it succeeded we should have something back and now we can work with it so I alluded this before Google Play services speaks with Google's API it uses HTTP as traffic and that essentially includes a whole bunch of data about device which Google can then verify to ensure it matches what expectations so typical pinning and Foundation is enforced so they can't sniffer on a non-rooted device meaning we have no visibility into a root device and the rooted device doesn't quite behave the same as a unrooted device for reference routing here refers to braking constraints of an Android device so you can run your own code Etc and as I said the response proves that our device is rooted and I'll show you what that looks like shortly this is an example of an actual request to Google's API it reads other things you need to sort of look at be aware of so we're speaking to the attestations the test endpoint where it has alt equals Proto this refers to a protobar wrapper around that's going to come back we don't care too much about this but it just helps us make sense of the data is coming back the host again is google'sapi.com and then we also have two more information and this is between seemingly random data a load of random hex um this is the build date of the application that is trying to run the test function and also the apk's name and these are going to be very important later because of essentially we run into some hurdles with this and we need to try and modify what's happening in order to work with it the response back from Google's API so after we've asked it to a test of the device's state give the database applied it's something like this so you see those first two red bytes that is part of the Proto buff wrapper and I believe that I just say you can expect the following response to be excellent now the keynime key eyed monk you may notice the beginning of that message which is eyj quite standard for JWT tokens jws Etc so if anyone is not aware a Json web tofu jws is a base64 encoded data structure delimited by all stops so the structure you'll be looking at would be something like a header they've also got a payload or stopping in the signature each one with individual components it's basic support encoded meaning it's represented by 64 which you need characters to include the data we are only interested in the payload for this and you can also actually decode a 30 bus token just for reference purposes you can grab the payload from the middle code it Basics or a little bit of data so what do we get back well we get back to up it looks a bit like this we get an initial launch token which is typically something like 32 random buttons of data that the calling application so for instance com.example.myapp included within its request we get time stamp as well and then we get two more elements which we need to care about CTS profile match and basic editor I'm going to break down what each of these actually means and why we actually have to care about them now but we also see that this was around on a router device the advice back from Google is restore to factory wrong and lock bootloader thank you and then the evaluation type just so we know we're on the right track here is Hardware backed and what this means is when your test function was called and heard it actually used The Trusted execution environment on the phone which is part of the system odd chip the soc essentially your main processor and a variety of other pieces of very important technology within a silicon itself it's very very difficult to reverse engineer or break things at a hardware level and typically is more or less unheard of currently we always Target software vulnerabilities whenever possible So within this we're actually missing two bits of data and it's a very good reason why it's don't appear in adjacent I can go back to this so you can see there is no APK by desk or package name included in what we've got back as a good reason for that so when you perform a test the basic Equity is not true then Google doesn't even bother to attempt to verify your device it makes the request to see myself as happening but it just throws it out really it doesn't care basic Integrity refers to whether or not the device has presence of specific characteristics that success is being rooted so typically this would include mad disk used for routing devices by commonly binaries like XU X8 or bash Etc and modifications such as binaries along with modifications to the bootloader if any of that is detected then basically take it you'll fail and this one will come back to our data for reference the complete data set would look something like this where we have an APK digest in sha256 which does a hash of the APK itself and then we have a package there which tells us who actually requested this data to begin with so what's the taking that failure level like well this is a application on the Android play store called taking that test you can download this yourself and you can test it I believe safeness only supported by Google pixel devices so if you don't have one you won't be able to find it or it probably will just say doesn't work it may also quite well just do software-based testation instead a completely skip Hardware portion which is something we actually care about so a failure here says that our CTS profile was false basically just false didn't get the advice back so I didn't pass safe in there the key balance as I mentioned were that CTS profile basically take the two so CTS refers to compatibility testing suite and what this means is the data you send to Google's apis with your devices state is not match what they believe a factory restored or safety device looks like so in other words it had something that being modified hashes didn't match like a person being changed oh and basic Integrity also outlines whether or not you are using an emulator for instance so Google a very um focused on avoiding you've been able to emulate safety net so you can't easily reverse engineering I don't know as we see later I think it's a very bad job of that so as a developer what can we do with the jws token we get back from Google's apis well we can verify on the device as a really basic and quick check to say whether or not the device is in a secure state but this can be bypassed and Fireside cooking or general modifications to the APK itself otherwise we can also send the request we can send a request to our server with the jws included so for instance as I said a banking application when you make a payment might want to include as jws your bank server verifies it says yeah the application is a secured state so I let this payment proceed because it's probably not being formed by a malicious actor and you'll see taking this actually used a lot in acne app social media and games particularly things like Pokemon guy I believe use safety nets so how does cigarette really work at a more technical level well the client Imports a library we know that and then Google Play services actually download the safety net runtime binary which is a jar file on the Fly that binary is being obficated it's very difficult to read and it is difficult to actually adverse engineer as well in fact it errors out a lot of attempting to try to reverse engineer it the uterus has said utilizes these trusted execution environment within the SRC so I already were facing Hardware limitations potentially where we're not going to dig into it and quieter in one and we're not going to see anything that's going on and the device state is actually verified and the collected data you get back in devices States is then sign up a private Key by the cost of distribution environment so what that means is unless it happens private key we can't make our own data and we also don't really know what data looks like to begin with because it's all encrypted or attack audience so people would actually want to bypass taking that perhaps looks like security researchers like myself so I'm doing application testing quite often I'm going to try and test them out it's going to do a safe and access station and then suddenly I can't test it because it knows that my device is rooted or I have a very limited foothold essentially tested on non-roots advice you just wanted to run out to the routes of devices so maybe you wanted to get some more freedom you want to get away from platforms like Google are trying to get rid of the bloatware or what you might satisfy wear potentially and various Telemetry data and then finally and it wouldn't really want to support the Pirates and Jesus so mobile games where you might want to try and cheat to get yourself advantages Pirates trying to rip obstacles money off the app store no longer support the developer or potentially even implant militias um payloads into those applications to compromise uses or attempt to use them so that's three key audiences and then the attack surface we've got so if we want to look at exploiting this bypassing safety net or generally just avoiding its using applications what can we do well we can look at personal attacks which rely on having a device connected to a network which you control and you intercept the data going back and forth without advice which then in turn goes back and forth to Google this isn't really possible because there's typical pinning and validations are forced over a TLS connection so we don't really know what's going on behind the scenes at least within the years and we can't intercept and change things because if there's signatures involved anyway which validate the actual data itself you can put the client-side runtime hooking however this usually needs to be implemented on a case-by-case basis in every single application you want to bypass taking the air which is essentially what already happens but it's a sort of ineffable option because of we don't want to do a head spaces we want to achieve this globally we can replay safety net responses put your sword as a timestamp involved there and a unique value in the actual response so the next payoff byte it won't match what's expected and the timestamp will be essentially out of the limits defined by the app and then finally we could just steal the private keys from the hardware and sign our own data the issue is this has happened in the past and Google simply decided to revoke certificates do a system update and now that doesn't work anymore the ability that's actually happened is so few of our between as well that it's very unlikely enough to keep stealing private keys and compete with Google to keep signing his data for such a simple purpose so rolling out this tax is what we've just sort of achieved here we've said each partner has different drawbacks so what's the best option here now there is one that we can kind of come back to but impact in a different sense so if we look at client-side hooking ordinarily this would still fail with the hardware is responsible for actually achieving infestation and filing a device to stay but if we use two devices which is in this diagram concept here so we have a good Android phone which is unrooted and runs our safety net server let's call it and this actually performs all your testation on our behalf and then Returns the data and the equal device has your test function and the get jws result function both hooked on the framework so when we attempt to do a test station you could devise conduct on our path we take the response from that which is valuables of good devices in a know and good State and we use that in our either application to make it appear as if that's actually a good device at least that's the theory behind it so as a framework called Exposed on Android it's a runtime cooking framework for clientsides it uses Java you need a module loader for it and it's very difficult to get up and running initially which is quite outdated and documentation Max but if you do get working you can put content successfully including either test functions and jwf results there are some limitations of it namely it only really works with Java unfortunately we can't currently put kotlin applications which are quite common for developers of writing and the standard workflow like I sort of showed up before might look something like this for cessation you can't have positive test methods the task happens you get the call back and we return to jws but a standard workflow with exposed in between might look something more like this the clientification attempts to call your test function but that has been hooked by this exposed framework and we actually dumped a little trampoline sets up all of our parameters our data Etc then we jump to a Macbook chord beforehood methods and this is within our exposed module that enabl