Google’s Threat Analysis Group (TAG) says it has discovered “five separate, complete and unique” iPhone exploit chains, used by a group making a “sustained effort to hack the users of iPhones in certain communities” over at least two years.
The attacker had set up several websites that delivered sophisticated malware indiscriminately to visiting iPhone users, using 14 vulnerabilities and at least one so-called zero day to track location, read encrypted messages and steal files.
They could use the exploit to read encrypted iMessage, Whatsapp or Gmail messages, and even track location as regularly as every minute, if the iPhone was connected, essentially owning fully patched iPhones, although the attacks lacked persistence, or the malware was wiped when a user rebooted their phone.
This is the scariest thing I've seen in infosec in the last 5 years at least. "This suggests that this group had a capability against a fully patched iPhone for at least two years." Scarier than Hearthbleed. It's beyond PRISM level, if you ask me.https://t.co/gWZOb47Yy6
iPhones are tough to exploit, with companies like Zerodium paying $2 million for a “zero click” iOS remote jail break with persistence, with full exploit chains fetching even more on the grey market for zero days and other exploit tools. The attacks sophisticated suggests a nation state actor, although Google did not point to a particular APT.
Ian Beer, from Google’s Project Zero threat hunting team, said in a blog post published late Thursday: “Simply visiting the hacked site was enough for the exploit server to attack your device, and if it was successful, install a monitoring implant. We estimate that these sites receive thousands of visitors per week.”
He added: “We discovered exploits for a total of fourteen vulnerabilities across the five exploit chains: seven for the iPhone’s web browser, five for the kernel and two separate sandbox escapes.
Initial analysis indicated that at least one of the privilege escalation chains was still 0-day and unpatched at the time of discovery (CVE-2019-7287 & CVE-2019-7286). We reported these issues to Apple with a 7-day deadline on 1 Feb 2019, which resulted in the out-of-band release of iOS 12.1.4 on 7 Feb 2019. We also shared the complete details with Apple, which were disclosed publicly on 7 Feb 2019.”
Project Zero noted: “[The attackers gained] unsandboxed code execution as root on iPhones.
“At the end of each chain we saw the attackers calling posix_spawn, passing the path to their implant binary which they dropped in /tmp. This starts the implant running in the background as root. There is no visual indicator on the device that the implant is running. There’s no way for a user on iOS to view a process listing, so the implant binary makes no attempt to hide its execution from the system.”
Current educated guess: Threat actor is a Middle Eastern oppressive government and specifically targets a group (dissidents/opp party/journos) via the unknown low traffic sites (indirectly discriminate). Money blown on exploit kits from talented folks with slapped on homegrown C2
Despite the detailed breakdown of the exploit chains themselves, many questions remained unanswered in the post, including the website urls themselves, what kind of visitors they would have attracted (the number of visitors is comparatively small, speculation who the threat actor was, and more). .
As Aaron Grattafiori, Red Team lead at Facebook, noted on Twitter: “Why do they indiscriminately target victims, yet gather a ton of personal data + photos + GPS? Were the hacked sites distributing other malware or just these iOS payloads?
“How many C2 servers were there? What are their IPs? Where were they hosted? (Also hacked sites?) Did the hacked sites/watering holes have something in common? (All WordPress? Rails?) If we’re talking about a nation state with all these payloads… Why the plaintext exfil?”
He speculated that it may have been a Middle Eastern threat actor. Others disagreed, speculating that it was instead China. Google’s focus in the post was more on Apple’s software development lifecycles. As Beers notes: “The root causes I highlight here are not novel and are often overlooked: we’ll see cases of code which seems to have never worked, code that likely skipped QA or likely had little testing or review.”