Gunnar Alendal discusses his research at DFRWS EU 2018.
Gunnar: Now to something completely different, as they say. My name is Gunnar Alendal, I’m a PhD student in Norway at the Norwegian University of Science & Technology. I’m mainly doing work in digital forensics, and mainly concerning the digital acquisition – that means getting access to data, in the first hand, not so much the analysis of it. And I will try to look into using more offensive techniques to get data in digital forensics. That’s sort of the goal.
So, you can see this paper, and this is sort of a contribution in that sense, sort of a case study. And this is also a long and complicated title, which promises probably more than it actually is giving you, as it implies something about common criteria. But if any of you are experts in common criteria, you’ll soon know that we are moving away from this; it’s just the name that it bears. So, you’ll soon see.
First some motivation: Digital forensics, yes, we need data, and we are sort of splitting these days, in some sense we are getting too much data, in some areas, and we need some big data, handling of that; and in some other areas, we are getting less data. For mobile devices, they are … and one example of devices that are getting more secure. What would we need from a mobile device, typically of RAM, if we can get that. But more importantly, storage.
With the increase in mandatory security of these devices, they are working against digital acquisition of them. So, where does this lead? Well, we don’t know. We don’t know, we can sort of predict the future, if that means no data from digital or mobile phones, we don’t know. But in the meantime, we can try and use more offensive techniques to try and reach the same goal as before, to acquire data from them.
In that sense, the common criteria … we’ll also include something called mobile device management, I’ll come back to that. These two are just examples of security mechanisms that might be needed to be bypassed to be able to acquire data from these devices. This is just a case study of a Samsung mobile phone. There’s no particular reason for choosing that phone. It’s just to see examples, how we can try and get past some of the security mechanisms that prevent acquisition of it.
The mandatory security of some phones includes, among other things, the encryption, mandatory encryption of user data. So, the good old chip-off will not work, because it might also be tied to the trust zone, which means you have to have this exact phone up and running to be able to decrypt the data on it. And they also have signed firmware, and they have something called a secure boot to ensure that the phone never runs unauthorized software or firmware. And then, you have these optional enterprise security features, which MDM and CC mode represents. They are doing more than this thing that we will focus on here. They typically apply a policy, and all kinds of password policy and all kinds of Android policy, security policy statements on the phone.
But for our concern and the digital acquisition, it also enforces something called non-OTA or non-over-the-air firmware updates. We will come back to why this is so important, but that’s the one and only feature we will look at for this CC mode and MDM mode.
First, let’s go back a step. Why is update mode for firmware important in digital acquisition, digital forensics? Well, if you look at it from offensive perspective, the bigger attack surface you have on a device, it’s a bigger or higher probability that there will be a vulnerability somewhere that you can use to bypass security mechanisms. So, the bigger the attack surface, the better for us, probably.
Well, we have example interfaces. An interface will basically be any input we can give to this device that it will react upon [as] sort of a user input. So, any device or any input channel we can use is to our benefit. And examples, of course – Wi-Fi, the modem, and the physical interfaces, like the USB plug, the SD card interface, the SIM card interface, etc. In this sense, this firmware update protocol, which is then [non] over the air, which means we can actually plug something in and do firmware updates, it’s important, because it’s an increased attack surface of the device.
So, what is this firmware update mode or ODIN as they refer to? It’s [non] over the air, it means I need physical access to the device. Many of you have or have not used this. It means I can update the firmware as the user will and not as the Samsung way of doing it over the air. It’s a Samsung proprietary protocol. It’s not documented anywhere, it’s just something they invented and put in. And this is giving us a possibility to maybe install [an maybe unsigned] firmware or signed firmware on the device. And of course, this increased the attack surface. We have seen other people have used this protocol, this ODIN protocol, to read [randoms] from the device. You can use it to attack the protocol directly, sort of find a vulnerability and exploit it. So, there are all kinds of stuff you can do. You can also downgrade the device. You can find an earlier vulnerable firmware that you can install on the device this way.
I hope we can all agree that having ODIN is better than not having it. This is just how it looks on my test device. You have not seen this downloading screen before. If you’re used to ODIN mode, you have seen this. And this is just how it looks when you block this. So, basically, the [common criteria] mode, the effect of implementing this on the mobile device will be exactly this – you cannot reach the ODIN mode anymore, it will be blocked.
How did you test this? We have … as this CC mode and MDM mode is part of enterprise solutions, we don’t have access to enterprise solutions, so we have tested this using a CC mode test application developed by Samsung, and they have posted this, it’s available online. So, you can do evaluation of the common criteria. So, you can just install this app and emulate that this device is part of an enterprise environment. This of course sets the Android password policy and all kinds of Android-specific security policies, but also enables this blocking of ODIN mode. And again, we will only look at this.
The questions are then: How does the phone know when to block ODIN mode? We have to figure out how does he know this, and can we do something to bypass it, to regain access to ODIN mode? I’m spending half my time to reach till the questions. That’s good.
To be able to talk about this, we need to talk about the secure boot model of Samsung devices. This is probably similar to other devices, the fact that they need to trust the code running on the device. So, they have a BootROM, which is up here, which is read-only, it can never be firmware updated. So, if there is a vulnerability up there, then you have to get a new device. But everything below here is part of the firmware you install on the phone. And the important factor is that every stage here is signature-checked – so, they have a signature chain, making sure that the BootROM loads the bootloader 1 and 2 and a trust zone. And checks its signature – if it’s okay, it will execute it. And then, later, this one, the bootloaders will check the Android kernel for a signature and then further boots the phone, if it’s okay.
Because … why is this important for ODIN mode? Well, we need to know where ODIN mode is implemented to be able to figure out where it is enforced and maybe bypass it. So, long story short, it’s implemented in what we call bootloader2, which is the main bootloader of the device. It has all kinds of functionality. It’s a Samsung proprietary code. So, there is no Android framework here – this is before any Android firmware is up and running. No Android kernel. So, this is a proprietary code, it has … of course a very important functionality is to check the signature of the Android kernel, and it will load Android kernel, and it has all kinds of other responsibilities. But here we can see that it is code for implementing the ODIN protocol. So, the code is actually in the bootloader, so the bootloader handles this. That also means that the bootloader must be able to read this configuration to be able to react and block ODIN mode.
Where is this configuration stored? It’s stored in a logical partition called PARAM. As this is an Android phone, it has all kinds of different logical partitions on the storage. And one of them is PARAM. CC and MDM mode is just stored here, so the SBOOT or bootloader2 can read it out and see if it should enforce CC mode or MDM mode, and blocking ODIN. Now, it turns out that MDM mode, that’s just … it’s written in plain text, so it’s just written directly to the PARAM partition. But CC mode is encrypted with a [whitebox AS] function, which means that the SBOOT can read this block and it has the decryption function for the [whitebox AS], so it can decrypt the configuration data and see if CC mode is on or off.
Now, we know where he is storing this configuration. We need to see how he enforces it. At the bottom, we can see that this is the goal – we want to enter ODIN mode with no blocking. So, this is the goal – that’s the green arrow. You can see that if we come here and this is just a [pseudo] code, simplified [pseudo] code or [how] SBOOT is handling this enforcing of CC mode. You can see he enters ODIN mode all the way at the bottom. But the … we can see here that there’s a function code that is checking if CC mode is set. So, if this returns true, it means we must block ODIN mode. And you can see the same string here as we saw on the screenshot.
Here we can see that if this function is returning true – and this is also important for … we will see this later, in a later slide – then we will not enter ODIN mode. But a sharp eye would see that there’s a second call to this ODIN mode function, which is called above this blocking and checking of CC mode. This means that there’s a different path to getting to ODIN mode than we first thought. You can see here, he will enter ODIN mode and not check if CC mode is enabled. But there’s [some weird reason 6] for this to happen. What is reason 6? Now we’re over, talking about how to disable the CC mode.
You can see that if we can call this function with reason 6, we will go to ODIN mode, even if CC mode is on. It turns out that the … again, this is a long story short. The details are in the paper. But there is an environment variable set for SBOOT that says if there’s a DN error, if this variable is set to something different from zero, you will consider this as an emergency and go to emergency ODIN mode, which will bypass CC mode as well. So, we only need to set this environment variable. And it turns out we can actually set this with a special cable and some technical details. But we can actually set this DN error and bypass the blocking. This is the first one.
The second way of bypassing this CC mode is if we can write to flash – if we have a chip-off, chip-on situation, we can of course just replace the MDM setting, because that’s in plain text. But the CC mode was protected with [whitebox AS]. But it turns out that the encrypt function, not only the decrypt function, is also included in the SBOOT, even if it doesn’t seem to use it. They have included the encrypt function. So, we don’t actually need to know any AS keys or anything. We can just use this function as an encryption oracle, to replace the CC mode setting.
And the last way we try to bypass this was try to change the execution flow of the SBOOT. This can be done by, for example – and this is a very, very offensive technique – trying to exploit a vulnerability in the SBOOT itself, not to pay attention to a CC mode setting. There is an example, public vulnerability, published for SBOOT, and we just implemented that to see if we can actually just change the MDM and CC mode setting, which is rather simple once you get this to work.
With an exploit in the bootloader, well, of course that breaks all trust in the bootloader, so of course we can change all kinds of things. But of course we can just set these two functions, that is true or false, if CC mode or MDM mode is on. We can just set them to always false. We don’t care about any setting.
The conclusions. We have only tested this with a lab device. We have not tested this in real enterprise environments. But there is no reason why this shouldn’t work unless they are doing something, other magics, on the phone. But at least the SBOOT part of it, the enforcing and blocking of CC mode and MDM mode during boot, was fully recovered. And we can re-enable ODIN mode. And we use … we just demonstrated three different approaches to be able to bypass the enforcing of CC mode, where one is just … I don’t know if this is by design or if it’s actually a vulnerability, because they … if there’s a download emergency on the device, it will bypass the CC mode setting and just go directly to an emergency ODIN mode, which is opening up for flashing firmware. That might be by design.
And we saw that we can do low-level modification of PARAM, since we have access to the [AS, whitebox AS] [18:33]. And the last one was just modifying the execution of the bootloader.
I think that was it.
End of transcript