Thread by @billmarczak

THREAD with a couple of interesting bits from @AmnestyTech's new report on what they learned from looking for NSO Group's spyware on phones amnesty.org/en/latest/rese…

@AmnestyTech (1) @AmnestyTech saw an iOS 14.6 device hacked with a zero-click iMessage exploit to install Pegasus. We at @citizenlab also saw 14.6 device hacked with a zero-click iMessage exploit to install Pegasus. All this indicates that NSO Group can break into the latest iPhones.

It also indicates that Apple has a MAJOR blinking red five-alarm-fire problem with iMessage security that their BlastDoor Framework (introduced in iOS 14 to make zero-click exploitation more difficult) ain't solving.

Phone logs show that (at least some of) the iOS 13.x and 14.x zero-click exploits deployed by NSO Group involved ImageIO, specifically the parsing JPEG and GIF images. ImageIO has had more than a dozen high-severity bugs reported against it in 2021.

BlastDoor is a great step, to be sure, but it's pretty lame to just slap sandboxing on iMessage and hope for the best. How about: "don't automatically run extremely complex and buggy parsing on data that strangers push to your phone?!"

(2): @AmnestyTech also found that after @citizenlab's Dec 2020 report mentioning the zero-click hacking of Al Jazeera, NSO Group switched to Amazon's CloudFront to deliver exploits (lololol). @AmnestyTech reported this to Amazon, who took action to try and block the activity.

Also, (3) as @AmnestyTech observed and we @citizenlab can confirm, NSO Group's Pegasus spyware delivered via 0-click exploits is no longer "persistent" in the strict sense of the word (i.e., doesn't come back when you reboot). Persistence is achieved via firing the 0-click again

Because the 0-clicks they're using appear to be quite reliable, the lack of traditional "persistence" is a feature, not a drawback of the spyware. It makes the spyware more nimble, and prevents recovery of the "good stuff" (i.e., the spyware and exploits) from forensic analysis

(4) One of the other interesting bits here is just how much of pain it is to do phone forensics. @AmnestyTech couldn't do much w/ Android (as a lot of logs that are easy-to-access are wiped on device reboot), and the highest-signal iPhone analysis was limited to DataUsage.sqlite

DataUsage.sqlite is a file in an iTunes backup that records process names accessing the mobile data, as well as bytes uploaded and downloaded. Information can persist in here for *years* unless cleaned up. So, in around 2019, NSO Group decided to try their hand at cleaning it up.

Most of the information is in two tables, ZLIVEUSAGE and ZPROCESS. Entries in ZLIVEUSAGE reference an implicit foreign key in ZPROCESS, but there is no formal DB constraint, nor is there an ON DELETE CASCADE. Sooo... NSO deleted entries from ZPROCESS but not ZLIVEUSAGE.

This leaves an implicit inconsistency in the database which can be observed. Oh, and also you can just run "strings" on the DataUsage.sqlite file and find the deleted entries...

Another bit (5), is the fact that @AmnestyTech (and also @citizenlab) were able to trace NSO's "version 4" domain names, which NSO was using for command-and-control thru mid-2020, and for exploit/payload delivery thru early-2021. So how did this mapping work?

I'm not going to burn @citizenlab's exact process here, but I *do* want to relate a really fascinating story. Previously, we used to detect most of these through IP-based Internet scanning. But NSO threw three new major wrenches into our process here in 2018.

Wrench #1: NSO instituted "port-knocking" on their C&C servers. Originally, it looked like this (really freeking bizarre, right?), but then they switched to a much smarter scheme that only uses 80 and 443. This means C&Cs had no open ports to scan.

Wrench #2: NSO appeared to institute "DNS-knocking" on their infection servers. An arbitrary high (or low) numbered port is opened on the infection server when a victim sends a DNS query for a random 4th-level subdomain of an infection domain, like this:

Since NSO (or clients) control the DNS servers for the 3rd-level domain (e.g., *.f15fwd322[.]regularhours[.]net), they respond to the lookup, and have the chance to open the appropriate port on the infection server.

Wrench #3: The infection servers' domain names no longer appeared in SMSes. Instead, NSO created "URL shortener servers" hosted on shared-IP hosting that redirected to these bizarre 4th-level subdomains. Shared-IP hosting means scanning by IP will *not hit* the infection servers.

These three wrenches were a direct challenge to the IP-based Internet scanning methodology we used in 2018. However... what NSO taketh away, NSO also giveth :).

Because NSO infection servers used TLS, and because they were using 4th-level subdomains for infection, NSO needed to register *wildcard 3rd-level* TLS certs. Just look at these.. they look really weird, right? I'm sure you can imagine how to find a bunch more in public data 🤔