An iMessage vulnerability that was revealed in depth in a Project Zero report late last week was given to Apple months ago and has already been patched. However, hackers and coders who are interested in learning more about this vulnerability could now dig deeper into how it was pulled off by the experts over at Google's Project Zero.

Project Zero is a team of security analysts employed by Google tasked with finding zero-day vulnerabilities, the secret hackable bugs that are exploited by criminals, state-sponsored hackers, and intelligence agencies.

Google's Project Zero blog posted a report last Thursday titled "Remote iPhone Exploitation Part 1: Poking Memory via iMessage and CVE-2019-8641." It was the first part in a three-part series that details how a vulnerability in iMessage could be exploited remotely without any user interaction on iOS 12.4 (fixed in iOS 12.4.1 in August 2019). It is essentially a more detailed version of the authors 36C3 talk from December 2019.

The first part of the series provides an in-depth discussion of the vulnerability, the second part presents a technique to remotely break ASLR, and the third part explains how to gain remote code execution afterwards.

The attack presented in this series allowed an attacker, who was only in possession of a user’s Apple ID (mobile phone number or email address), to remotely gain control over the user’s iOS device within a few minutes.

Afterwards, an attacker could exfiltrate files, passwords, 2FA codes, SMS and other messages, emails and other user and app data. They could also remotely activate the microphone and camera. All of this is possible without any user interaction (e.g. opening a URL sent by an attacker) or visual indicator (e.g. notifications) being displayed to the user. The attack exploits a single vulnerability, CVE-2019-8641 to first bypass ASLR, then execute code on the target device outside of the sandbox.

This research was mainly motivated by the following question: given only a remote memory corruption vulnerability, is it possible to achieve remote code execution on an iPhone without further vulnerabilities and without any form of user interaction? This blog post series shows that this is in fact possible.

The vulnerability was found as part of a joint vulnerability research project with Natalie Silvanovich and reported to Apple on July 29 2019, followed by the proof-of-concept exploit on August 9, 2019. The vulnerability was first mitigated in iOS 12.4.1, released on August 26, by making the vulnerable code unreachable over iMessage, then fully fixed in iOS 13.2, released on October 28 2019.

Further hardening measures were suggested based on insights gained during exploit development, which, if implemented, should make similar exploits significantly harder in the future. As some of these hardening measures are also relevant to other messenger services and (mobile) operating systems, they will be mentioned throughout this series and summarized at the end of it.

For security researchers, a proof-of-concept exploit targeting iOS 12.4 on the iPhone XS is available here. In order to hinder abuse, it deliberately alerts the victim of an ongoing attack by displaying multiple notifications throughout the exploitation process.

Furthermore, it does not achieve native code execution (i.e. shellcode execution), thus making it more difficult to combine it with an existing privilege escalation exploit. However, none of these restrictions require further vulnerabilities to remedy and only require re-engineering of the exploit by a capable attacker.

The in-built restrictions and notifications are merely designed to stop abuse by unskilled attackers simply running the code. It should be noted that skilled attackers likely already have the capability offered by the released exploit code, either from finding vulnerabilities themselves, from reverse engineering patches as has been observed before, or, as 1-day exploit, by for example combining CVE-2019-8646, a remote infoleak bug, with any of the other memory corruption bugs that were found.

For hackers and coders who are interested in learning more about Project Zero's Remote iPhone Exploitation, read Part 1 in full here.

Part 2 titled " Remote iPhone Exploitation Part 2: Bringing Light into the Darkness -- a Remote ASLR Bypass," and could be found here.

Part 3 titled "From Memory Corruption to JavaScript and Back -- Gaining Code Execution" could be found here.