James's Blog

Sharing random thoughts, stories and ideas.

No One Is Safe

Posted: Sep 7, 2019
◷ 4 minute read

This past week the Google Project Zero team published their deep dive into several iOS exploit chains found in the wild. It generated a lot of buzz in mainstream media, with a much more sensationalist spin on the content. But to the people more involved in the field of information security, it simply re-affirmed a fact that everyone already knew: no one is safe from bad actors (e.g. nation states) when they have enough resources.

The vulnerabilities used in these exploit chains were fixed prompted by Apple back in February (shortly after the Project Zero team notified them of the issues). But they were nonetheless extremely severe. Simply visiting a website (which could’ve been forced via a redirect) running these exploits would result in a nasty program being implanted on the victim’s phone, with full root access (the highest level of privilege for running programs in an operating system). There is no way to detect whether you have been infected, since iOS does not expose the list of running processes to the user in any way, and the only way to remove it is to do a full device reset. Presumably updating iOS to the latest version on an infected phone would’ve removed the implant as well, but I’m not sure.

Once this malicious program is implanted, you are pretty much done. Almost all applications secure their data only during transit, including ones that are end-to-end encrypted. On the actual device itself, once unlocked, the data for all the apps are unencrypted (after all, the user needs to be able to see the data), sitting in plaintext ready to be grabbed by the implant1. This includes Gmail, WhatsApp, Telegram, iMessage, Photos, and many others, which the implanted payload periodically sends to remote servers as revealed in PZ’s teardown.

Something that is a bit different, and one that I’m more concerned about, is access to data in password managers. Due to their more sensitive nature, the data for password manager applications is usually encrypted by the app itself, in addition to any OS-level encryptions. Only when the user needs to use it and types in the master password to unlock the password manager is the password data decrypted. This unencrypted password data usually resides in memory only (i.e. it is never written to persistent storage, not even as temporary files, for security reasons), and so if the malicious implant only scanned for disk content, it would not be able to get password data.

Of course, this completely depended on the behavior of the implant, and not its privileges. It definitely had the ability to dump the entire password manager data (assuming it was unlocked by the user at least once on an infected device), we just don’t know whether it did. I messaged the security team at 1Password, which is my password manager of choice, and confirmed some of this information. They have posted some details on their discussion board as well. The implant could have gotten the entire password data by dumping the memory while in use (technically possible but unlikely), or it could have intercepted clipboard data as passwords are used (more likely, but less impactful). For automatically filled passwords, it would depend on whether the iOS Password AutoFill API can be compromised, which is an unknown even to the 1Password team, as only Apple has visibility into OS-level APIs.

An important thing to realize from all this, is not what was exploited and fixed, but rather that this is likely just the tip of the iceberg. These 5 exploit chains relying on this set of 0-day vulnerabilities are only the ones that we found and know about. Bad actors with big resource pools, typically large nation states, probably have many more working, unpatched exploits running at any given time, including now. To be fully immune to these actors would be way too cost-prohibitive for most people, and arguably impossible even for the more inclined. The best and most effective thing we can do is to help increase the cost of this type of exploits for the attackers, making it more and more cost-prohibitive for them to mount these attacks. This includes keeping our devices up-to-date, using a password manager, being mindful of our online hygiene (i.e. try to stay away from shady websites), and being vigilant of good security practices.


  1. In this case, I am speaking of access in the software layer. The physical storage of the data (i.e. on the actual flash drive) is still encrypted, using a key derived (by the Secure Enclave) from the device unlock code. However, when a user unlocks the device, and opens an app (e.g. Gmail), that data becomes unencrypted for access by the app and user. Of course the data is still restricted to be accessible only by that app, but since the implant has root level access, it can grab data from any app that it wants. ↩︎