The Role of JavaScript in the Biggest Apple Security Breach

A few months ago, Google Project Zero discovered a bunch of security exploits in iOS versions from 10.0 up to 12.1.3 that cover a total of 1.4 billion devices.

Last week, they published their findings in more detail. What part did JavaScript play in the incident?

Based on the Google Project Zero research, a malicious website would be able to install a monitoring implant on the phone, and the implant would have access to pretty much everything on the phone–photos, contacts, messages, the real-time location, and keychain (passwords, certificates, etc.)

Based on Google’s investigation, this was used by the Chinese government to target some of their citizens. They estimate a few thousands of people a day were targeted for up to 2 years, but it’s hard to know if they were the only ones.

We’re talking more than 2 million instances of privacy breaches, and that’s just the part that’s been accounted for.

Perhaps not directly, but any developer using iOS, or any “smart” device for that matter (yes, even a blender), should make sure they are up-to-date with the latest security updates. To me, the most interesting part of this privacy breach was how the attackers found the security issues.

The issues are mostly using array or object bugs to gain read/write access to the system memory and then use some lower level OS issues to install the tracker.

The most likely scenario is that the attackers used the open source nature of WebKit and to find the vulnerabilities affecting the Safari browser on iOS. Once a vulnerability was detected by someone and reported to Apple, it would usually be fixed, test cases (both JavaScript and C++) were added and a nice descriptive commit message was written.

The problem here is that with WebKit being open source, and the fact it is updated together with the OS, the fix would be waiting for the next OS release–usually for months. All the while, the vulnerability was exposed to the public.

The same issue could happen, but a bit more unlikely because the release cycle is faster, and they generally don’t include JavaScript test cases. Therefore, the attackers would need to reverse-engineer the commit instead of just copy/pasting the problematic code.

Mozilla and Microsoft keep the security commits private until the release is public, so the chances of this are very slim.

The majority of other projects, like Linux and Android have a similar approach to Mozilla, in which they discuss and prepare security fixes in private, and publish them publicly only after they’re ready to be installed on the affected systems.

In the case described above, it seems like malicious websites added the problematic code themselves, but it could have also been added by some third party.

Although it’s not realistic to review all the source code of all the dependencies we’re using, it’s important to use reliable libraries from well-known authors (which is also not a 100% guarantee) whenever possible.

Also, keep an eye on the npm install command, which is doing an automated security audit of all installed packages, and run npm audit / yarn audit manually from time to time–or use the GitHub’s security monitoring feature.

Better safe than sorry!