Hackers exploited more than a dozen iOS vulnerabilities—most of them unpatched zerodays—in a two-year campaign that stole photos, emails, log-in credentials, and more from iPhones and iPads, researchers from Google’s Project Zero said.
The attacks were waged from a small collection of hacked websites that used the exploits to indiscriminately attack every iOS device that visited. Attacks against 14 separate vulnerabilities were packaged into five separate exploit chains that gave the attackers the ability to compromise up-to-date devices over a period of more than two years. An analysis of the well-written exploit chains shows they were likely developed contemporaneously with the exploited iOS versions, which spanned from iOS iOS 10.0.1 released in September 2016 to 12.1.2 issued last December.
Real-time monitoring of entire populations
“I shan’t get into a discussion of whether these exploits cost $1 million, $2 million, or $20 million,” Project Zero researcher Ian Beer wrote in a deep-dive post analyzing the exploits and the malware they installed. “I will instead suggest that all of those price tags seem low for the capability to target and monitor the private activities of entire populations in real time.”
The post didn’t name or describe any of the hacked websites, other than to say they were estimated to “receive thousands of visitors per week.” Neither Project Zero nor Apple has offered any guidance to iOS users who want to know if they may have been infected. The installed malware, which is nearly impossible for most users to detect, can’t persist after a device reboot, so compromised phones are disinfected as soon as they’re restarted. Still, because the implant sent such a wide range of data to attacker-controlled servers, it may be possible for users of compromised devices to be monitored even after the malware is gone.
Researchers outside of Project Zero told Ars the quality and reliability of the exploits indicated they were written by developers with talent and experience. iOS is one of the hardest operating systems to compromise. The ability to combine non-public exploits in a way that “groomed” the highly fortified data structure known as the heap and bypassed other advanced protections was impressive, particularly when considering the span of two years the exploits were were collectively effective.
Significant effort
The 14 vulnerabilities comprised seven flaws in the Webkit package used by Safari, five bugs in the iOS kernel, and two flaws that escaped a browser sandbox that attempts to keep untrusted code from interacting with sensitive parts of the OS. At least one of the five chains was still a zeroday when Project Zero discovered it early this year. The Google researchers reported those flaws to Apple on February 1 with a seven-day deadline for Apple to fix before Google publicly disclosed them. Apple responded with an unscheduled update six days later.
“It feels like the amount of effort that went into the exploits is very significant,” said Charles Holmes, a managing principal research consultant who focuses on mobile security at Atredis partners. “Maintaining capabilities off of the last three years of iOS and a combination of hardware devices and firmware—a lot of time and effort went into that. My gut feels like some nation was behind maintaining that capability.”
By comparison, the outside researchers were quick to point out a detailed analysis of the implant the exploits installed was crude. The malware made no attempt to conceal its processes. More surprising still, it used unencrypted HTTP channels to send login tokens, stored images, and transcripts of messages sent over Gmail, iMessage, WhatsApp, and other programs. The plain-text communications would have made it easy to detect the mass exfiltration of sensitive data by people who monitored the Wi-Fi or enterprise networks infected phones connected to.
Another thing that made the attack unusual was that it targeted every iOS device that visited the hacked websites. Advanced espionage hackers typically try to protect their campaigns and the valuable zerodays they exploit by infecting only individuals of interest. By indiscriminately attacking every iOS visitor, the hackers in this case made it much easier for the campaign to come to light.
“It seems likely that these attackers were probably well funded but didn’t necessarily have a ton of experience doing cyber espionage operations, or didn’t really care if they got caught,” Patrick Wardle, principal security researcher at Jamf, an Apple enterprise software company, told Ars. “If I could guess, a nation state with a ton of money went out and bought a bunch of iOS exploit chains, cobbled them together and indiscriminately began targeting victims to spy on groups of interest.”
While unsophisticated, the implant offered a full feature of capabilities for stealing data from infected devices. The implant was particularly concerned with live location data and with databases for the end-to-end encryption apps WhatsApp, Telegram, and iMessage. Container directories—which store data used by most iOS apps, including unencrypted copies of sent and received messages—were uploaded for all of the following:
- com.yahoo.Aerogram
- com.microsoft.Office.Outlook
- com.netease.mailmaster
- com.rebelvox.voxer-lite
- com.viber
- com.google.Gmail
- ph.telegra.Telegraph
- com.tencent.qqmail
- com.atebits.Tweetie2
- net.whatsapp.WhatsApp
- com.skype.skype
- com.facebook.Facebook
- com.tencent.xin
The attackers could get a listing of all installed apps on an infected device and make an ad-hoc request to download container directories for any specific apps that weren’t on the list. The attackers could also issue an “allapp” command that would download the container directories for all apps on the device. The malware checked an attacker-controlled server every 60 seconds for commands.
The implant also sent attackers a complete copy of the iOS keychain. The keychain contains a large amount of highly sensitive data, including credentials and certificates used to log into services such as Gmail, Facebook, and countless other services and SSIDs and passwords for all saved Wi-Fi access points. The keychain also contains long-lived tokens used by services such as Google’s iOS Single-Sign-On to enable Google apps to access the user’s account. By uploading this data, the attackers could maintain access to the user’s Google account even once the implant is no longer running.
As noted earlier, the installed implant binary doesn’t survive a reboot, meaning a device will be disinfected as soon as its restarted. It’s not clear if the lack of persistence was intentional or the result of developer limitations. In either case, iPhones can go weeks or longer without being rebooted. By that point, the data obtained likely gave attackers other means to continue surveilling targets of interest.
The attack underscores the damage that can result when a device is compromised by even a “one shot” attack that lasts only a short period of time, said Will Strafach, founder of Sudo Security Group and an expert in iOS security.
“Persistence requires additional exploit(s) and allows active surveillance, but increases the possibility of detection,” he said. “A non persistent attack can nab large amounts of historical data which is likely no less damaging, as many folks (even with Signal and WhatsApp) do not routinely delete data, as they assume data-at-rest on their device to be safe.”
Anyone in Cupertino got a fuzzer?
Many of the exploits that installed the implant were the result of flaws the Project Zero researchers said would have been easy to catch with standard quality assurance and code-hardening processes. An exploit chain that targeted iOS versions 11 through 11.4.1 over a 10-month span, for instance, included a sandbox escape that was the result of a “severe security regression” refactoring that mistakenly broke an important security check for validating messages from interprocess communications, or IPC, in iOS.
“It’s difficult to understand how this error could be introduced into a core IPC library that shipped to end users,” Beer wrote. “While errors are common in software development, a serious one like this should have quickly been found by a unit test, code review or even fuzzing. It’s especially unfortunate as this location would naturally be one of the first ones an attacker would look.”
A different exploit chain exploiting iOS 12 and 12.1 similarly exploited vulnerabilities the Project Zero researchers said should have been caught before shipping. Beer wrote:
It’s the kernel bug used here which is, unfortunately, easy to find and exploit (if you don’t believe me, feel free to seek a second opinion!). An IOKit device driver with an external method which in the very first statement performs an unbounded memmove with a length argument directly controlled by the attacker:
IOReturn
ProvInfoIOKitUserClient::ucEncryptSUInfo(char* struct_in,
char* struct_out){
memmove(&struct_out[4],
&struct_in[4],
*(uint32_t*)&struct_in[0x7d4]);
...The contents of the
struct_inbuffer are completely attacker-controlled.Similar to iOS Exploit Chain 3 [mentioned above], it seems that testing and verification processes should have identified this exploit chain.
Challenging the perceived scarcity of iOS exploits
The campaign is concerning, because it challenges the conventional thinking that iOS vulnerabilities are exploited only in limited instances and then only against highly targeted individuals. The price for a single exploit chain is typically valued in the millions of dollars, in part because of the perceived scarcity of the flaws. The attackers’ ability to continuously exploit vulnerabilities over two years—and to do so in a way that was easy for others to see—demonstrates a new wrinkle to iOS exploitation.
“To see an attacker do this with iOS exploits is interesting,” said Wardle, an Apple security expert who previously worked as a hacker for the National Security Agency. “It shows that this group has no problem acquiring these capabilities and likely can acquire more if needed.”