Apple has patched a potent chain of iOS zero-days that were used to infect the iPhone of an Egyptian presidential candidate with sophisticated spyware developed by a commercial exploit seller, Google and researchers from Citizen Lab said Friday.

The previously unknown vulnerabilities, which Apple patched on Thursday, were exploited in clickless attacks, meaning they didn’t require a target to take any steps other than to visit a website that used the HTTP protocol rather than the safer HTTPS alternative. A packet inspection device sitting on a cellular network in Egypt kept an eye out for connections from the phone of the targeted candidate and, when spotted, redirected it to a site that delivered the exploit chain, according to Citizen Lab, a research group at the University of Toronto’s Munk School.

A cast of villains, 3 0-days, and a compromised cell network

Citizen Lab said the attack was made possible by participation from the Egyptian government, spyware known as Predator sold by a company known as Cytrox, and hardware sold by Egypt-based Sandvine. The campaign targeted Ahmed Eltantawy, a former member of the Egyptian Parliament who announced he was running for president in March. Citizen Lab said the recent attacks were at least the third time Eltantawy’s iPhone has been attacked. One of them, in 2021, was successful and also installed Predator.

“The use of mercenary spyware to target a senior member of a country’s democratic opposition after they had announced their intention to run for president is a clear interference in free and fair elections and violates the rights to freedom of expression, assembly, and privacy,” Citizen Lab researchers Bill Marczak, John Scott-Railton, Daniel Roethlisberger, Bahr Abdul Razzak, Siena Anstis, and Ron Deibert wrote in a 4,200-word report. “It also directly contradicts how mercenary spyware firms publicly justify their sales.”

The vulnerabilities, which are patched in iOS versions 16.7 and iOS 17.0.1, are tracked as:

• CVE-2023-41993: Initial remote code execution in Safari
• CVE-2023-41991: PAC bypass
• CVE-2023-41992: Local privilege escalation in the XNU Kernel

According to research published Friday by members of Google’s Threat Analysis Group, the attackers who exploited the iOS vulnerabilities also had a separate exploit for installing the same Predator spyware on Android devices. Google patched the flaws on September 5 after receiving a report by a research group calling itself DarkNavy.

“TAG observed these exploits delivered in two different ways: the MITM injection and via one-time links sent directly to the target,” Maddie Stone, a researcher with the Google Threat Analysis Group wrote. “We were only able to obtain the initial renderer remote code execution vulnerability for Chrome, which was exploiting CVE-2023-4762.”

The attack was complex. Besides leveraging three separate iOS vulnerabilities, it also relied on hardware made by a manufacturer known as Sandvine. Sold under the brand umbrella PacketLogic, the hardware sat on the cellular network the targeted iPhone accessed and monitored traffic passing over it for his phone. Despite the precision, Citizen Lab said that the attack is blocked when users turn on a feature known as Lockdown, which Apple added to iOS last year. More about that later.

There’s little information about the iOS exploit chain other than it automatically triggered when a target visited a site hosting the malicious code. Once there, the exploits installed Predator with no further user action required.

To surreptitiously direct the iPhone to the attack site, it only needed to visit any HTTP site. Over the past five years or so, HTTPS has become the dominant means of connecting to websites because the encryption it uses prevents adversary-in-the-middle attackers from monitoring or manipulating data sent between the site and the visitor. HTTP sites still exist, and sometimes HTTPS connections can be downgraded to unencrypted HTTP ones.

Once Eltantawy visited an HTTP site, the PacketLogic device injected data into the traffic that surreptitiously connected the Apple device to a site that triggered the exploit chain.

Predator, the payload installed in the attack, is sold to a wide array of governments, including those of Armenia, Egypt, Greece, Indonesia, Madagascar, Oman, Saudi Arabia, and Serbia. Citizen Lab has said that Predator was used to target Ayman Nour, a member of the Egyptian political opposition living in exile in Turkey, and an Egyptian exiled journalist who hosts a popular news program and wishes to remain anonymous. Last year researchers from Cisco’s Talo security team exposed the inner workings of the malware after obtaining a binary of it.

Incomplete information included in recent disclosures by Apple and Google reporting critical zero-day vulnerabilities under active exploitation in their products has created a “huge blindspot” that’s causing a large number of offerings from other developers to go unpatched, researchers said Thursday.

Two weeks ago, Apple reported that threat actors were actively exploiting a critical vulnerability in iOS so they could install espionage spyware known as Pegasus. The attacks used a zero-click method, meaning they required no interaction on the part of targets. Simply receiving a call or text on an iPhone was enough to become infected by the Pegasus, which is among the world’s most advanced pieces of known malware.

“Huge blindspot”

Apple said the vulnerability, tracked as CVE-2023-41064, stemmed from a buffer overflow bug in ImageIO, a proprietary framework that allows applications to read and write most image file formats, which include one known as WebP. Apple credited the discovery of the zero-day to Citizen Lab, a research group at the University of Toronto’s Munk School that follows attacks by nation-states targeting dissidents and other at-risk groups.

Four days later, Google reported a critical vulnerability in its Chrome browser. The company said the vulnerability was what’s known as a heap buffer overflow that was present in WebP. Google went on to warn that an exploit for the vulnerability existed in the wild. Google said that the vulnerability, designated as CVE-2023-4863, was reported by the Apple Security Engineering and Architecture team and Citizen Lab.

Speculation, including from me, quickly arose that a large number of similarities strongly suggested that the underlying bug for both vulnerabilities was the same. On Thursday, researchers from security firm Rezillion published evidence that they said made it “highly likely” both indeed stemmed from the same bug, specifically in libwebp, the code library that apps, operating systems, and other code libraries incorporate to process WebP images.

Rather than Apple, Google, and Citizen Lab coordinating and accurately reporting the common origin of the vulnerability, they chose to use a separate CVE designation, the researchers said. The researchers concluded that “millions of different applications” would remain vulnerable until they, too, incorporated the libwebp fix. That, in turn, they said, was preventing automated systems developers use to track known vulnerabilities in their offerings from detecting a critical vulnerability that’s under active exploitation.

“Since the vulnerability is scoped under the overarching product containing the vulnerable dependency, the vulnerability will only be flagged by vulnerability scanners for these specific products,” Rezillion researchers Ofri Ouzan and Yotam Perkal wrote. “This creates a HUGE blindspot for organizations blindly relying on the output of their vulnerability scanner.”

Google has further come under criticism for limiting the scope of CVE-2023-4863 to Chrome rather than in libwebp. Further, the official description describes the vulnerability as a heap buffer overflow in WebP in Google Chrome.

In an email, a Google representative wrote: “Many platforms implement WebP differently. We do not have any details about how the bug impacts other products. Our focus was getting a fix out to the Chromium community and affected Chromium users as soon as possible. It is best practice for software products to track upstream libraries they depend on in order to pick up security fixes and improvements.”

The representative noted that the WebP image format is mentioned in its disclosure and the official CVE page. The representative didn’t explain why the official CVE and Google’s disclosure did not mention the widely used libwebp library or the likelihood that other software was also likely to be vulnerable.

The Google representative didn’t answer a question asking if CVE-2023-4863 and CVE-2023-41064 stemmed from the same vulnerability. Citizen Lab and Apple didn’t respond to emailed questions before this story went live.

The Signal Foundation, maker of the Signal Protocol that encrypts messages sent by more than a billion people, has rolled out an update designed to prepare for a very real prospect that’s never far from the thoughts of just about every security engineer on the planet: the catastrophic fall of cryptographic protocols that secure some of the most sensitive secrets today.

The Signal Protocol is a key ingredient in the Signal, Google RCS, and WhatsApp messengers, which collectively have more than 1 billion users. It’s the engine that provides end-to-end encryption, meaning messages encrypted with the apps can be decrypted only by the recipients and no one else, including the platforms enabling the service. Until now, the Signal Protocol encrypted messages and voice calls with X3DH, a specification based on a form of cryptography known as Elliptic Curve Diffie-Hellman.

A brief detour: WTF is ECDH?

Often abbreviated as ECDH, Elliptic Curve Diffie-Hellman is a protocol unto its own. It combines two main building blocks. The first part involves the use of elliptic curves to form asymmetric key pairs, each of which is unique to each user. One key in the pair is public and available to anyone to use for encrypting messages sent to the person who owns it. The corresponding private key is closely guarded by the user. It allows the user to decrypt the messages. Cryptography relying on a public-private key pair is often known as asymmetric encryption.

The security of asymmetric encryption is based on mathematical one-way functions. Also known as trapdoor functions, these problems are easy to compute in one direction and substantially harder to compute in reverse. In elliptic curve cryptography, this one-way function is based on the Discrete Logarithm problem in mathematics. The key parameters are based on specific points in an elliptic curve, which is defined as the field of integers modulo prime P.

When someone knows the starting point (A) in the above image showing an elliptic curve and the number of hops required to get to the endpoint (E), it’s easy to know where (E) is. But when all someone knows is the starting and end points, it’s next to impossible to deduce how many hops are required.

As explained in an Ars article from 2013:

Let’s imagine this curve as the setting for a bizarre game of billiards. Take any two points on the curve and draw a line through them; the line will intersect the curve at exactly one more place. In this game of billiards, you take a ball at point A and shoot it toward point B. When it hits the curve, the ball bounces either straight up (if it’s below the x-axis) or straight down (if it’s above the x-axis) to the other side of the curve.

We can call this billiards move on two points “dot.” Any two points on a curve can be dotted together to get a new point.

A dot B = C

We can also string moves together to “dot” a point with itself over and over.

A dot A = B

A dot B = C

A dot C = D

…

It turns out that if you have two points, an initial point “dotted” with itself n times to arrive at a final point, finding out n when you only know the final point and the first point is hard. To continue our bizarro billiards metaphor, imagine that one person plays our game alone in a room for a random period of time. It is easy for him to hit the ball over and over following the rules described above. If someone walks into the room later and sees where the ball has ended up, even if they know all the rules of the game and where the ball started, they cannot determine the number of times the ball was struck to get there without running through the whole game again until the ball gets to the same point. Easy to do, hard to undo. This is the basis for a very good trapdoor function.