On August 29th 2019, the British security researcher Ian Beer (@i41nbeer) from Project Zero at Google published multiple blog posts about a series of iOS exploits. According to their findings, those exploits have been used to completely take over iOS devices. This article provides focused answers to eleven questions about this series of events.
What is the overall impact of this attack?
- you used an iOS device (iPhone, iPad, …) in the last two years and
- visited a certain hacked site (more on that later)
your device could have potentially been overtaken by the attacker.
Complete access to all your data, including
- All messages (even encrypted ones, even from WhatsApp and iMessage – of course also unencrypted texts)
- Passwords (iOS Keychain)
- Third-Party Application Data (Facebook, Telegram, Skype, …)
- Locations (via GPS)
What was the attackers’ goal?
This is still open to speculation. The researchers suggest that the attackers may have wanted to target members of a certain community over a long period of time.
iOS exploits are very costly (e.g., Zerodium would pay anyone up to $ 2,000,000 for a zero click remote jailbreak for iOS ). Since it seems that the attacker had no financial motives, one might be tempted to suggest a political agenda behind the attacks.
Which iOS versions were affected?
iOS 10 through to iOS 12.1.4 (which was released in February 2019) .
|10.2.x||unclear (according to , no exploit chain existed for this version)|
|12.1.1 – 12.1.3||yes|
When did the attack start?
Probably in September 2016  with the launch of iOS 10.
Are iOS devices still endangered?
With today’s knowledge, iOS devices running at least iOS 12.1.4 are no longer affected by this exploit.
It is unclear whether infected devices remain affected after an update, but the researchers suggest that the infection does not survive a reboot .
Why are different exploit chains used?
After the initial attack’s launch, some vulnerabilities were patched by Apple. The attackers then reacted to those patches by finding new exploits.
A total of five chains were identified, using a total of fourteen vulnerabilities .
Why are encrypted messages also affected?
Many apps offer end-to-end encryption (e.g. Whatsapp and Telegram).
While this encryption is completely secure and not the target of this exploit, it does not help in this case. Once an attacker has root access on a device, they can simply grab the decrypted version of the messages from the application’s local SQLite database.
Could the attacker track my location?
Yes. The installed software was configured to automatically report your current GPS location up to once per minute .
No evidence currently indicates that past GPS locations could be fetched unless they had been stored by a third party application.
How could the attackers control infected devices?
The researchers published  a list of supported commands which were executed by the infected devices.
|systemmail||upload email from the default Mail.app|
|device||upload device identifiers (IMEI, phone number, serial number etc)|
|locate||upload location from CoreLocation|
|contact||upload contacts database|
|callhistory||upload phone call history|
|notes||upload notes made in Notes.app|
|applist||upload a list of installed non-Apple apps|
|keychain||upload passwords and certificates stored in the keychain|
|recordings||upload voice memos made using the built-in voice memos app|
|msgattach||upload SMS and iMessage attachments|
|priorapps||upload app-container directories from hardcoded list of third-party apps if installed (appPriorLists)|
|photo||upload photos from the camera roll|
|allapp||upload container directories of all apps|
|app||upload container directories of particular apps by bundle ID|
They also reconstructed a list of third-party apps. The data of each app on this list is always uploaded to the attacker:
|com.netease.mailmaster||NetEase Mail Master|
It should be noticed that this list includes applications that are very popular in the Asian market (Tencent QQ, QQMail).
Is there any way to check if I was affected?
It turns out, there is. The attackers made a mistake and did not use HTTPS to encrypt their network traffic. Therefore, if you happen to have access to your network traffic logs, you can scan for the string
/list/suc?name= in your past GET requests. Positive matches may hint that a communication to the attackers’ servers occurred.