Unmasking Operation Triangulation & Zero-Click Exploits

Last month three engineers from Kaspersky delivered a bombshell talk at the 37^th edition of the Chaos Communication Congress, an annual gathering of hackers in Europe. They had reverse engineered the most sophisticated attack chain on smart phones in recent history: a cyber-attack known as Operation Triangulation, which had targeted Kaspersky employees' iPhones and iPads in 2023. The attackers used a combination of multiple zero-day and zero-click CVEs to gain access to the devices and steal sensitive information. Myntex’s development team did a deep dive into this attack to help you make informed decisions about your mobile endpoint security. Our research reinforced our beliefs about the absolute need for phone security and the value that a hardened operating system like Renati OS brings to the table.

The discovery of this attack occurred when suspicious network activity was discovered within the Kaspersky offices. They noticed high outbound traffic to multiple suspicious domains. The investigating engineers took possession of the suspicious devices, backed them up and initiated standard digital forensics and incident response (DFIR) protocol. They ran Mobile Verification Toolkit against the culprit devices; MVT is a useful utility developed by Amnesty International to discover traces left by hackers on compromised devices. We also ran the MVT on a device in our offices, resulting in the below output:

The Kaspersky team obviously had a very different output. Using the timeline file generated by MVT they were able to trace back the sequence of the compromise.

They discovered lines for "BackupAgent", a binary that has been deprecated on iOS since 2004. BackupAgent was preceded by the process “IMTransferAgent”, that downloaded the attachment with the exploit. The downloads lead to timestamp modifications in multiple directories in the Library/SMS/Attachments/ folder. However, the exploit attachment was subsequently deleted. The attackers left this trace by mistake because they forgot to delete the modified directories.

They also removed evidence from:

• SMS.db
• ids-pub-id.db
• knowledge.db
• ids-gossip.db

But they forgot about datausage.sqlite which is used to track network usage by apps and is very useful for iOS forensics.

Along with the BackupAgent, their team also discovered other indicators of compromise in the timeline file, but they were less reliable and not as important to dissect here.

Looking at the network logs, they also discovered:

• Legitimate connections with the iMessage service
• Download of the iMessage from domain names like icloud-content.com and content.icloud.com
• Connections to Command and Control (C&C) servers with significant outbound traffic:

The iMessage attachment was encrypted and downloaded over HTTPS and the only indicator they could initially decipher was the size of the payload: 242 Kb:

A high-level overview of the attack chain:

1. The targeted device received an iMessage with an attachment containing an exploit
2. Without any user interaction, the message triggered a vulnerability that leads to code execution
3. The second stage of the exploit downloaded several subsequent stages from the command-and-control server
4. The third stage of the exploit included a privilege execution and invokes the next stage
5. The final stage involves a downloaded payload from the C&C server that is a fully featured APT platform, i.e. a package with full privileges to track, control, and exfiltrate any data from the device
6. The initial message and the exploit in the attachment are then deleted to hide its traces

The attackers thought of almost everything. Knowing that the exploit might be patched in a future iOS update they even modified one of the system settings files named com.apple.softwareupdateservicesd.plist. This modification prevented all iOS updates, thereby preventing any patches that would obviate the exploit.

To understand the nature of the exploit, the researchers had to uncover the initial payload received by the iMessage attachment. Since the attackers were deleting the attachment once the exploit had run, the researchers decided instead to set up a trap and wait for a subsequent exploit. They used a Frida script coded by Google Project Zero and designed to be used on a Mac. They installed the script on a spare Mac mini, asked one of their colleagues who was targeted by the exploit to log into their Apple iMessage account on the Mac mini. Then they waited for the exploit message to come in while also monitoring the network for suspicious activity against the Mac mini. Unfortunately for them they noticed the suspicious activity on the network logs but when inspecting the baited Mac mini, they failed to find any traces of an infected message.

They had to try something else next:

1. They setup mitmproxy on a Linux server
2. Installed a self signed root SSL certificate on several iOS devices that were compromised
3. Installed a Wireguard VPN on the devices and configured them to use the mitmproxy server as the VPN
4. They even developed a telegram bot to notify them when one of the monitored devices became infected

While they were able to intercept the messages they were unable to decrypt them because Apple has implemented SSL pinning, preventing the use of custom self-signed SSL certificates. Although the initial iMessage could not be decrypted they were able to successfully decrypt the subsequent communications with the C&C servers. The payload was a JavaScript validator which collected information about the victim's browser and sent it to the C&C server:

The JS Validator performed various checks and did canvas fingerprinting. It also rendered a yellow triangle and calculated its hash value. Hence the name "Triangulation".

The validator then was reaching out to the C&C server with the newly identified information. However, the response from the C&C server was encrypted because the JS Validator had implemented its own layer of encryption for the communications with the C&C server using the NaCl library. The JS Validator was performing the following steps:

• Generated a random public/private key pair
• Derived a shared key from the generated private key and the C&C server’s public key
• Used this shared key to encrypt messages sent to the C&C server and decrypt the ones received from it

Since the private key is kept in memory the researchers had to do some additional work to decrypt the message. They coded a mitmproxy add-on that was triggered whenever nacl.box.keyPair() method was invoked and it replace the code with another method, nacl.box.keyPair.fromSecretKey(). That is, the research team injected their own private key into memory.

With these steps the team had successfully decrypted all communications between the infected device and the C&C servers.

In summary, the first stage of the attack involves receiving an iMessage which triggers a code execution for the second stage of the attack. The second stage involves a JS Validator whose purpose is to identify the victim, fingerprint them, and request the C&C server for the third stage of the attack. The payload returned by the C&C server during this second stage contained two exploits. The first was a webkit exploit and the second was a kernel exploit. Both were used to trigger the third stage of the attack – a binary validator. With the ability to now decrypt the payloads the researchers discovered what the validator function did. It deleted crash logs from specific processes that would have crashed due to one of the previous stages of the exploit. This was clearly done to make the work of forensic researchers harder.

Apart from deleting the crash logs they also attempted to clean up traces of the initial iMessage that triggered the whole exploit chain in the first place. To do that however they had to reference the Apple IDs used in the sending of the initial exploit. These IDs were hashed via MD5:

How did they crack the MD5 hashes? MD5 is a one-way hashing algorithm. Presumably they brute forced the hashes against some gigantic rainbow table. For example, you can go online and run an MD5 hash against any of the above emails and it will return the same hash. Thus, if these emails were used in some previous exploits, they could be floating around on some dark web database.

The binary validator was also detecting if the device was jail-broken. This was done for stealth. If the device is being run on a jail-broken or simulated device then the exploit does not run, knowing that it can be more easily detected in such systems.

The validator can even customize the form of the exploit based on if it is on an iPhone or a Mac device. We can confirm this by the unused action called "PSPDetect", which detects if there is an antivirus on the device. iOS devices do not have antivirus, Macs do.

Most importantly, the binary validator collects important information to confirm that the victim is the intended target and reports this information to the C&C server:

If the server believes that the correct victim has been identified by the validator it responds with the final stage of the exploit.

The malware that is finally installed on the device is a fully fledged APT platform (Advanced Package Tool - a Linux package). The virus/malware/spyware was developed in Objective-C, receives and executes additional plugins, and communicates via Protobuf and HTTPS. Interestingly, the researchers noted that the code had signs of having existed for at least 10 years.

What does it collect? Almost everything:

• Geolocation (location, speed, direction)
• Full access to all files and databases
• Extraction of keys from iOS keychain
• Signal and similar apps that store their private keys on the iOS keychain can thus be decrypted
• Application data (all messengers too)
• Access to camera and microphone
• Access to address book
• Information about nearby Apple devices
• Real time audio recording for eavesdropping
• No recording is done while screen is on to hide the traces
• Stored and transmitted in a custom format that includes metadata (information about device that occurred during the recording process)
• Sets a trap for forensic researchers where it sends a notice to the attackers if the logs are ever checked
• All photos and videos taken by the device

To assist the attackers in parsing hundreds of photos, the exploit also transmits metadata about images that is derived by iOS devices with machine learning:

Preceding the discussion on mitigation, a noteworthy aspect left unexplored pertains to the initial phase of the attack. The intricacies of this stage came to light subsequent to the researchers' meticulous examination, spurred by discerning clues unearthed during the third phase of the assault. The binary validator contained a function that cleaned up traces of the malicious iMessage:

SELECT guid FROM attachment WHERE uti == "com.apple.watchface" AND LENGTH(transfer_name) > 32 AND INSTR(transfer_name, CHAR(0x2013)) == 9;

This code indicated that the initial malicious message was a .watchface file. With this knowledge they planned and executed another trap to obtain the first attachment.

The sender of an Apple iMessage generates a random AES key and encrypts the attachment with it. Then the encrypted attachment is uploaded to iCloud. The iCloud URI of the attachment along with the AES key are encrypted with the public key of the recipient device and sent over to the recipient. The recipient then can decrypt the message which includes the AES key and the URI to download the attachment from iCloud and decrypt it.

Thus, to obtain the malicious attachment the researchers had to retrieve the iCloud URI of the attachment and the AES key used to encrypt it. While iOS prevents decryption of HTTPS traffic of Apple services with SSL pinning, it turns out the URI of iCloud attachments is not protected in the same way. The researchers were able to obtain the ciphertext of the attachment. The difficult part was decrypting the AES key for the attachment sent in the iMessage. SSL Pinning prevented the decrypted interception of iMessages. However, the researchers intercepted modified the bytes in the ciphertext of the attachment with a custom add-on created for mitmproxy. This prevented the file from being executed once downloaded and thus prevented from being deleted. The AES decryption key was stored in the SMS.db database. They backed up the infected device via iTunes and then extracted the key from the databases inside this backup. As a result, they now had access to the malicious .watchface attachment.

Inside the attachment was a TrueType font exploit.

TrueType had two undocumented assembly level instructions that had a buffer overflow zero-day bug:

This buffer overflow error has been in True Type since the early 1990s. It was silently removed in iOS 16.3 and macOS 13.2 in January 2023, but not removed until July 2023 in iOS 15 and MacOS 12 after Kaspersky's report. And as noted earlier, even though it has been patched by Apple, a portion of the exploit prevents system updates, suggesting that the exploit may still be in extensive use.

On newer devices (arm64e) the attackers used a Pointer Authentication Code bypass. Either of the attacks were used to execute a ROP chain and several expressions (NSExpressions), which subsequently execute a binary property list which is used as a container for more expressions. All these ultimately used to execute the next stage, a kernel exploit written in JavaScript (JS). On iOS apps can run JS without just-in-time (JIT) compilation. Attackers modify the memory of JavaScriptCore Library, enabling it to have very large memory, disable garbage collection, and enable $vm. With $vm, an attacker can then use special functions from within a JS script which gives an attacker the addresses of objects and gets read write primitive. The JS exploit was obfuscated and minimized and still had 11K lines of code.

The JS exploit, now having elevated privileges due to $vm was able to create and execute a kernel vulnerability, the third vulnerability in the whole chain.

Even with this kernel vulnerability, the attackers had to go further because iOS has protections in place against kernel level attacks, i.e. hardware based memory protections. These are PPL, KTRR, and Kernel PAC. These hardware protections are bypassed using a new feature in Apple System on a Chip (SoCs). This bypass requires knowing the following information some of which is provided by the previously described vulnerability:

1. Destination address
2. Write privilege
3. Hash of the data to write

Apple SoCs is not just the CPU but different peripheral devices with memory mapped I/O (MMIO) registers.

The exploit uses the bypass by writing to MMIOs that would be unknown to anyone who did not have access to Apple's core architecture code. Either that or somebody painstakingly attempted every possible memory address (would take millions of years). That is a bit of hyperbole, it is also possible to have "guessed" to search for addresses nearby to other known addresses:

These MMIOs were used to patch data in Page Table entries, the _PPLDATA segment, the __TEXT_EXEC segment. In this way, they bypassed hardware based kernel memory protections. Further, it turns out that it would have been impossible to know how to use this hardware feature unless one knew how to calculate a secret hash:

The researchers were able to reverse engineer the hash function as well.

To summarize, the researchers had discovered four main CVEs in the attack chain. Three of them were utilized in the first stage itself:

• CVE-2023-41990 - TrueType buffer overflow and PAC bypass
• CVE-2023-32434 - Kernel exploit using JS Core vm entry
• CVE-2023-38606 - Used in combination with previous CVE to bypass hardware level kernel protections
• CVE-2023-32435 - Safari exploit that triggered the binary validator

In the first stage of the attack alone, three out of the four CVEs were utilized. And we can look at this magnificent research done by the Kaspersky team and re-assert that the pattern of these attack chains remains the same:

• Identify zero days or violations of memory safety
• Combine zero days to get to root privileges
• Hide your steps along the way
• Exfiltrate at leisure

Kaspersky has a policy not to speculate on attribution without strong evidence. We will follow the same policy but note that it would be near impossible for an individual malicious actor to singlehandedly discover the vulnerabilities that were exploited in the Triangulation chain. CVE-2023-38606 alone would have been impossible to uncover unless one had an infinite amount of time or knew exactly where Apple stored the MMIOs.

As you may have noticed, the largest portion of the effort in the attack was directed towards getting into the victims' devices. The subsequent steps were relatively simple once the entry had been gained. This is also why the simplest protection is sometimes the best protection. Threema Messenger and a privacy focused OS would not have protected anybody from these forms of attacks because they leave a lot of doors open. There is nothing preventing an attachment received on a phone from triggering remote code execution. This is why Renati OS is special. It is purpose built to withstand attacks that would cripple other systems.

Sometimes you need a fortress with no doors to open in the first place. This is ChatMail on Renati OS.

The triangulation attack would have been blocked at the first stage because the only attachments permitted in ChatMail are from within its closed ecosystem. There is no possibility of an external PDF to attach. The subsequent vulnerabilities in Webkit and Safari would have also been moot because we have removed browsers. It may sound overly simplistic until you witness an attack like Triangulation in the wild, that seems to have been in play for over a decade.

We take security very seriously. This is why our customers choose us over the "free" options.

Next Steps & Resources

Delve deeper into the advantages of ChatMail on Renati for secure mobile endpoint communications:

1. myntex.com
2. renatimobile.com
3. chatmailsecure.com

Acknowledgements:

We extend gratitude to our dedicated DevOps team, whose unwavering commitment ensured the seamless integration of our solutions. Special appreciation goes to our Chief Operating Officer for providing invaluable insights that shaped the trajectory of our research. We also express sincere thanks to the engineers from Kaspersky for their collaborative technical expertise, significantly enhancing the depth of our review.

Source: securelist.com/operation-triangulation