A Deep Dive Into an NSO Group Zero-Click iMessage Exploit ⇥ googleprojectzero.blogspot.com

Ian Beer and Samuel Groß, of Google’s Project Zero team:

Earlier this year, Citizen Lab managed to capture an NSO iMessage-based zero-click exploit being used to target a Saudi activist. In this two-part blog post series we will describe for the first time how an in-the-wild zero-click iMessage exploit works.

Based on our research and findings, we assess this to be one of the most technically sophisticated exploits we’ve ever seen, further demonstrating that the capabilities NSO provides rival those previously thought to be accessible to only a handful of nation states.

This is a breathtaking accomplishment by NSO Group. I thought I knew where this explanation was going, but then I got to the penultimate section and it left me amazed.

One thing I have long wondered is what avenue was chosen for delivering the first part of the payload. iMessage has allowed the delivery of many file types since it launched. Most — like video or some arbitrary file — require user interaction, so those are ruled out. That leaves webpage previews and images, and we know that webpage previews are generated on the send-side, not by the recipient. So:

Looking at the selector name, the intention here was probably to just copy the GIF file before editing the loop count field, but the semantics of this method are different. Under the hood it uses the CoreGraphics APIs to render the source image to a new GIF file at the destination path. And just because the source filename has to end in .gif, that doesn’t mean it’s really a GIF file.

Are image formats the only instances where a file is interpreted and then a version created by iMessage on the client device? I am looking forward to the promised followup to this post.

Also, I recommend this article about how Xerox scanners screwed up documents and made files legally invalid — linked by Beer and Groß — just because it is really interesting.