With the release of iOS 10, it is time to examine what has changed in matters of security.
Apple has made huge progress to become much more security-aware recently, starting with the bug bounty program Apple announced to encourage white hats to report on vulnerabilities. Moreover, Apple notably acted quickly in response to the Pangu jailbreak vulnerability, patched in iOS 9.3.4, and the vulnerabilities exploited by the Pegasus spyware, patched in the iOS 9.3.5 update (attend our Pegasus webinar). Considering the high upgrade rate of iOS, Apple has taken a big step in thwarting hackers (68% of Skycure iOS devices are 9.3.5, 11% are 9.3.4 to date, 35 days after 9.3.4 was released).
Now, with the release of iOS 10, a notable action Apple has taken is that the kernel caches and the bootloader are no longer encrypted. Although Apple has stated the change is meant to improve system efficiency, we cannot ignore the security influence of such a move, where the core of the system will be much more accessible to researchers. As we said, Apple may be very cooperative with rapid patching of high risk vulnerabilities.
The new iOS 10
As for iOS 10 itself, it includes more security features. We can name for instance the App Transport Security, which now obligates all 3rd party applications’ transportation (except in a few special cases) to be encrypted with TLS protocol version 1.2 by the end of 2016. Apple also introduced the support of Certificate Transparency, with which the identity of the server the client is communicating with is much more reliable, as the certificate is being verified by another entity.
Besides those great network security features in iOS 10 (and few more we won’t elaborate on here), we cannot see any prominent feature to remark as a game changer in the main attacking vectors. Apple cannot entirely prevent kernel exploits, but has introduced in the past security mechanisms to harden it such as KASLR (Kernel Address Space Layout Randomization) and KPP (Kernel Patch Protection).
We believe that Apple ought to take further steps to improve the current security mechanisms in order to weaken the possibility of attacks. To demonstrate, let’s take the code signing policy, one of the strongest iOS security features, as an example.
The code signing policy allows only 3 types of binaries to be executed:
- Signed by the App Store certificate
- Pre-defined system binaries (through the code signing trust-cache)
- Enterprise apps (with explicit consent from the user)
Hardening the code signing even more will improve the ability to avoid threats from recurring.
If we will take the recently exposed Pegasus espionage tool as a case study – no remarkable change has been made in order to avoid threats of this kind. Although the Trident vulnerabilities (those exploited by Pegasus) have been patched, we cannot say how many zero-days of the same type, exploiting the same attack vector, are still out in the wild and being used.
Pegasus replaced a system daemon named rtbuddyd (executed on reboot) to gain persistency, with the jsc (Java Script Core) tool. Pegasus executed with a custom script using the jsc with which the kernel was exploited. Since jsc is a system binary, registered in the trust-cache, the code signing policy was irrelevant. The Pegasus persistency could have been mitigated by verifying not only the code signature of the binary, but also by verifying its name, path and other attributes too.
Jsc’s code signature segment extracted from the Mach-O using jtool. Notice the adhoc flag is turned on.
As a system binary, its CDHASH is registered within the trust-cache what makes this binary approved by the Code Signing security policy.
Another example for the insufficiency of the code signing policy is the jailbreak exploit for iOS 9.3.3, introduced by Pangu team. The exploit is carried by an unsigned dylib. In order to load the dylib, a binary with debug entitlement was needed (since it enables to load unsigned dylibs). Apple made a tremendous effort to have no binary with this entitlement on iOS 9, yet allowed the execution of system binaries with the former entitlement from old iOS versions through mounting of a Developer Disk Images (DDI). Ideally, the code signature policy should restrict old system binaries from being executed.
To conclude, iOS 10 includes some enhancements that make the operating system more secure, but there are not any new exciting announcements that address the attack vectors used in the recent system breakdowns. Patching the vulnerabilities exploited by the Pangu jailbreak tool and by the Pegasus spyware prevents those specific tools from violating the operating system, but does little to mitigate other zero-day exploits yet to be exposed. Learn more about zero-day exploits and spyware in our Pagasus webinar.
We admire Apple on their continued work to improve iOS security and look forward to see exciting new features in next releases. As always, Skycure will continue to protect iOS devices from novel and zero-day threats, and work closely with Apple to address any newly discovered vulnerabilities.