M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
A number of people have been asking me my thoughts on the viability of a software exploit against Secure Enclave enabled devices, so here’s my opinion:
First, is interesting to note that the way the FBI categorizes this tool’s capabilities is “5c” and “9.0”; namely, hardware model and firmware version. They won’t confirm that it’s the only combination that the tool runs on, but have noted that these are the two factors they’re categorizing it by. This is consistent with how exploit-based forensics tools have functioned in the past. My own forensics tools (for older iPhones) came in different modules that were tailored for a specific hardware platform and firmware version. This is because most exploits require taking Apple’s own firmware and patching it; those patches require slightly different offsets in the kernel (and possibly boot loader). The software to patch is also going to be slightly different for each hardware and firmware combination. So without saying really anything, FBI has kind of hinted that this might be a software exploit. Had this been a hardware attack, such as a NAND mirroring technique, firmware version likely wouldn’t be a point of discussion, as the technique’s feasibility is dependent on hardware revision. This is all conjecture, of course, but is worth noting that the hints are already there.
If the FBI did in fact use a software exploit, the question then becomes one of how viable it is on other platforms. Typically, a software exploit of this magnitude could very well take advantage of vulnerabilities that have long existed in the firmware, making it more than likely that the exploit may also be effective (possibly with a little tailoring) to older versions of iOS. Even if the exploit today was tailored specifically for this device, adjusting offsets and patching slightly different copies of Apple’s firmware is a relatively painless process. A number of open source tools even exist to find and patch the correct bytes in decrypted Apple kernels.
Getting into older devices isn’t really relevant, though, because we know that we can already get into most iOS 8 devices with a number of techniques, and iOS 7 and below can be imaged by Apple. More interesting is the question of whether it could be used on newer devices with Secure Enclaves.
Given the very small timeframe that this exploit would have had to be developed and integrated into an existing forensics toolset, it’s likely that this extra work has not been done yet, and there are two reasons it’s a lot of extra work. First, the chip architecture changed with newer iPhones. Apple moved from a 32-bit architecture to 64-bit. Exploits would need to be rewritten (and in some cases, are no longer viable) for a 64-bit architecture. Secondly, in order to break a numeric pin, a second exploit would need to be deployed against the Secure Enclave that you wouldn’t need on older devices. This second exploit would need to either attack the SEP itself, or bypass it by attacking a different part of the operating system by possibly clearing the lockout (the routines appear to be in the OS for that). Both of these additional pieces take considerable time and work to exploit. Remember, Apple only says the SEP enforces the lockouts by the operating system, this suggests that the operating system may have more control over the SEP that we think – and from what I’ve seen in my disassembler, it looks like that may be the case.
It is possible that the firm that sold the solution to FBI could have purchased the exploit off the “black market” (a.k.a from a teenager), and that it could have already been developed with 64-bit capabilities. It’s unlikely, however, that they would’ve had the foresight to know that the FBI would come knocking and looking for a Secure Enclave exploit as well. My best guess, with what little information we have, is that a software exploit just developed the past 30 days would not likely be developed enough to also be used to brute force newer devices. That doesn’t mean that future development won’t see to that, however, and possibly within a few months.
It’s important to note also that the exploit in its present form is dangerous to all of us – even if it can’t break the SEP. If newer, 64-bit devices are vulnerable, it would mean that an attacker could disable code signing and plant malware (spyware, surveillanceware, ransomware, or anything else) on the operating system partition (which is not encrypted). This could then be used to steal all of the user’s content the next time they booted up their device, or to persistently spy on them. You don’t have to brute force the PIN if your subject is still living, and still uses their phone. Even if the exploit hasn’t been crafted for 64-bits, it possibly could be adapted.
The exploit itself is supposedly in the hands of the FBI, or this private firm, but containment of zero-days can be an issue – especially if the firm purchased the exploit. Everyone involved in the development of such an exploit is aware of its existence, the weak points it exploits, and may even have proof-of-concept code. The likelihood is there that one of them could be bribed to sell it to a nation state, a different forensics company, or just use it themselves. What’s more, unless FBI reports the vulnerabilities to Apple, they remain open on all devices – whether the exploit is in the wild or not – leaving all of us at risk of someone else finding the same vulnerability. Thanks to the high profile nature of this case, the hackers all know there’s a hole somewhere.
To make a long story short, such an exploit in its present form, given the time constraints of this case, probably isn’t yet ready to attack a 64-bit device running a Secure Enclave… but it could be adapted to in the future. Much of the heavy lifting has already been done.
M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |