Five privilege escalation exploit chains actively used to compromise iOS devices by unknown attackers have been discovered in the wild by Google’s Threat Analysis Group (TAG) and Project Zero teams earlier this year.
The threat actors used compromised websites to run watering hole attacks targeting users of iPhone devices running almost all versions between iOS 10 and iOS 12, sites that were visited thousands of times each week.
“This indicated a group making a sustained effort to hack the users of iPhones in certain communities over a period of at least two years,” says Project Zero’s Ian Beer.
iOS zero-days and ‘en masse’ attacks
In total, the Google security researchers found 14 iOS vulnerabilities being exploited as part of the five unique exploit chains, five impacting the kernel, seven the iPhone web browser, and two sandbox escapes.
One of the five exploit chains abused CVE-2019-7287 and CVE-2019-7286 which, at the time, were zero-day vulnerabilities. These got patched by Apple on February 7 as part of the out-of-band iOS 12.1.4 release after the researchers reported their discovery on February 1.
Extensive analysis for all five exploit chains are available in these separate posts:
The victims would get infected immediately and “en masse” after visiting the hacked websites used by this campaign, with malicious implants being dropped, installed, and launched on the visitors’ vulnerable iPhones.
“There was no target discrimination; simply visiting the hacked site was enough for the exploit server to attack your device, and if it was successful, install a monitoring implant,” Beer added.
Stolen data sent home in plain text
To stage the privilege escalation exploits that would give them “unsandboxed code execution as root on iPhones,” the campaign’s operators used several JSC WebKit exploits to gain an initial foothold on their victims’ iPhones.
While these exploits were designed to circumvent JIT code injection mitigation measures, they were not able to bypass the newer PAC-based JIT hardenings available on A12-powered iPhones.
This implies that iPhone XS, iPhone XS Max, and iPhone XR users were protected from these attacks since the JSC exploits would have “bailed out if they ran on an A12 device.”
Even though the malicious implant used by the attackers is capable of stealing “private data like iMessages, photos and GPS location in real-time,” it also shows signs that its creators are not as experienced in developing malware since it uses a hardcoded command and control (C2) server IP address and all the data sent to its C2 server is sent in plain text.
Seeing that no encryption is used to exfiltrate the stolen data, “If you’re connected to an unencrypted WiFi network this information is being broadcast to everyone around you, to your network operator and any intermediate network hops to the command and control server.”
Malware capable of real-time data exfiltration
While the malware will always upload the container directories—containing unencrypted data like messages—for a list of hardcoded third-party apps including but not limited to WhatsApp, Telegram, Gmail, Skype, and Facebook, it can also be instructed to upload the data for specific apps or for all the apps installed on the iPhone at once.
Unfortunately, infected users wouldn’t be able to detect if the implant was running on their iPhones since there is no way of accessing a list of all running processes on the device—this made it possible for the implant’s creators to skip adding any concealment features designed to hide the malware’s presence.
Even though the malicious implant does not have a way to gain persistence on compromised iPhones and it gets removed after the device is restarted, the attackers can steal the victims’ account credentials for various services and control those even after their malware is wiped.
“Let’s also keep in mind that this was a failure case for the attacker: for this one campaign that we’ve seen, there are almost certainly others that are yet to be seen,” concluded Beer.
BleepingComputer has reached out to Google and Apple to request more info on the malicious campaign but had not heard back at the time of this publication. This article will be updated when a response is received.