How Pegasus gets into your phone without you clicking anything: three doors on Android, WhatsApp and iOS

Prompted by a conversation about how Pegasus gets into mobile phones, and by the news that Spain's CNI intelligence service has been spying on former Catalan MPs, as it has admitted itself, it is worth explaining in detail how spyware like Pegasus ends up inside a phone without the victim clicking anything or installing anything. Here are three real entry points: one on Android, one through WhatsApp and one on iOS.

Let's start with Android. Android has, logically, an inter-process communication (IPC) system inside the kernel. It acts there as a driver and is referred to as the binder. Every process that exists as a result of what the user does on the phone has a boundary separating its memory (userland) from kernel memory. The victim visits an infected web page. Infected how? We don't know for sure. It was obviously some kind of executable code, probably JavaScript, but the people who investigated this don't have the exact detail of what was happening in the part of the web page that kicked it off. What we do know is what happened from that point on, once the malicious code ran on the phone.

Once the malicious code runs in the browser, it finds itself trapped in a container (not Docker-style, I mean a sandbox) that isolates processes like the browser's inside a very restrictive box. This is done precisely so the code cannot escape the user space (userland) into the rest of the phone. But even inside a container, the browser needs to communicate with the operating system. Because that communication is necessary for everything to work, the malicious code takes advantage of this permitted communication channel to attack the kernel directly.

When the browser asks to communicate with the system, the binder assigns it an execution thread (binder_thread) in kernel memory and puts it in a waiting queue. To know when there is activity in that queue that needs processing, the system uses a monitoring mechanism: epoll. The malicious code from the browser sends a command (BINDER_THREAD_EXIT) to force the abrupt destruction of that thread. The kernel, doing what it "thinks" it should do, frees that portion of memory so it can be used for other things.

Because of a programming bug in the binder driver, when that thread's memory was freed this way, epoll was not told to stop watching, so it kept looking to see whether there was anything there to process. This produced a dangling pointer: epoll would go and look at a memory address the system considers empty and free to be overwritten, and this let the attacker fill the memory the system believed was free with their own manipulated data. It is what is known as a use-after-free vulnerability.

The attacker uses this dangling pointer to find and modify a variable inside the structure of their own process in the Android kernel: addr_limit, the boundary that tells Android which memory addresses the browser can reach. By way of the binder bug, the attacker can overwrite this value and set it to the maximum possible, so that now the browser can reach a whole range of places it should not have been able to reach before. Now it has a path to walk in order to disable SELinux's confinement system and grant itself the highest administrator privileges over the system it can get.

And now that there are practically no defences of any kind left, it can install the RAT, that is, the remote-control tool that is part of the Pegasus ecosystem, from which the spying can be carried out. Because it acts with elevated privileges thanks to all the actions taken in the previous steps, it can directly obtain the WhatsApp database from the /data partition, intercept calls, turn on the microphone or the camera, or whatever else. We know this happened and that it was linked to Pegasus because Google Project Zero published it. Today this is no longer a zero-day: it is CVE-2019-2215, it has been known since 3 October 2019 and it is already fixed. But it explains, I think, one case of how, without clicking anything or installing anything, Pegasus ends up inside the phone.

Now let's look at an example where WhatsApp was used as the basis for the attack. First there was a WhatsApp voice call to the target's number. This call was not made from a "normal" WhatsApp, but from one manipulated on the client side. A plausible scenario would be: Pegasus operators used software that connected to WhatsApp's servers imitating the behaviour of a real phone to make the call to the victim's number, controlling themselves the "WhatsApp" (application) that made it.

Once WhatsApp's server opened the VoIP communication channel (voice over IP, calls over the internet), the attacker's software injected manipulated SRTCP packets (Secure Real-time Transport Control Protocol). Because the WhatsApp server acts as an intermediary and SRTCP packets originally serve to control parameters such as call quality or delay, the server did not inspect the manipulated packets and forwarded them directly to the victim's application. When the victim's WhatsApp, this one a normal WhatsApp downloaded from the Google Play Store or the Apple App Store, tried to process these anomalous packets, that was what opened the doors of their phone to the infection.

Technically, the door opened because of a programming bug in the "normal" WhatsApp (the sender's was manipulated, but the receiver's was not): a heap buffer overflow. All of this happened automatically during the background processing of incoming traffic. The overflow was triggered while the call was ringing, with no need to answer it actively or touch any button on the screen. From this point the process is analogous to the one already explained for Android: the door opens to install software, and they installed spyware and elevated its privileges. The Financial Times reported it. The privilege escalation was done with other, different vulnerabilities, not this WhatsApp one specifically, because that is what Pegasus does: it combines various vulnerabilities to reach its goal.

For iOS they also have ways to get into phones. One of those ways was named FORCEDENTRY. It went like this: first, the attacker sent an iMessage to the victim's phone. And the victim did not need to open it. Without the user opening it, the app automatically tried to generate a preview of the message in the background to show it on screen. This message contained a GIF with a harmless appearance. In reality, it was not a GIF, but a PDF document (or PSD) in disguise that used a very old and obsolete image-compression format, from the 90s: JBIG2.

When the image processor Apple uses in this context, CoreGraphics, tried to read this file to show the GIF preview, it ran into the fact that it was really a JBIG2. JBIG2 works by looking for shapes that repeat and storing them in a list so it doesn't have to draw them each time. Apple's image processor had to know how much memory to reserve for the list. To estimate this, it tried to read a number in the file that said "there are X shapes". The attacker manipulated the file in this respect to put in a very high, disproportionately high number.

When the iPhone multiplied this huge number to calculate the total memory, the result exceeded the maximum limit the computer system could count and caused an integer overflow. This made it think the estimate was "virtually zero" and it reserved a very small amount of memory. Then the attacker sent in a lot of data (a buffer overflow) and the attacker's data overflowed and overwrote the adjacent memory.

The JBIG2 format includes logical operations (AND, OR, XOR) that serve to draw and superimpose images; it is always a problem for a format that is theoretically for images to contain the option to run logic. Because the memory overflowed, the attacker could make these operations apply directly to the iPhone's memory. With the logic options JBIG2 allowed them, they built a small simulated computer, a "virtual machine", that did calculations, searched for data in memory and disabled the iPhone's defences from within.

We know this, and we have the link to Pegasus, also thanks to Google Project Zero, a team of Google security analysts who spend their days trying to find and fix zero-day vulnerabilities across the internet to protect users. Zero-day vulnerabilities are the ones that get exploited while no one yet knew they existed. None of these three cases requires the victim to click a link, open a file or install anything: it is the very definition of a zero-click attack, and it is exactly the kind of tool people have been spied on with here.

#pegasus#spyware#zero-click#cni#mobile-security