I ran this tool and found a trace that I was infected (malware detected in CrashReporter.plist). Any clue what I should be doing, if anything, to address this?
Reach out to Amnesty Tech and/or Citizen Lab for help establishing whether this is a real infection or a false positive.
If it's real: Adjust your behavior to account for the fact that once you know you're a target, there is no device on the market and no practical measures you can use to maintain safety. Assume everything you do on or near a computer used by you or a close contact is being monitored. The level of effort needed to maintain strong security in the context of being a target is astronomically higher than any individual can deal with.
How about use your phone as only a data modem and do everything on a chrome os device, which have no known malware. Just don't install chrome extensions and you are safe. Also avoid installing apps on your phone
This is basically what I wish I had, except back in reality there's no Chrome device that's the size of my cell phone. There are some with cellular modems.
Chrome OS is probably the most secure system to use from an exploit perspective.
Just never install an Android app on it (that feature doesn't have the same guarantees as the rest of the system), and preferably use a guest account on it (that's how they run it in security competitions)
You basically have to break four layers to exploit that. You have to break the web renderer, then out of the browser sandbox, then you need to exploit the kernel to be able to write outside the (non persistent) guest account storage, then you need to exploit the firmware/secure boot chain so secure boot doesn't detect your modifications to the filesystem when the system next boots.
Chrome OS is probably the OS that leaks the most personal info and behavior of all OS combined. It is inexcusable to subject children to it in my opinion. Advertisers know how to groom.
Store your files in local files, running on their Linux "crostini". Apple and android have hundreds, probably thousands of documented attacks, plus known companies attacking them with rats and various spyware. There's an article a day. Apple took apps off their app store to satisfy the Chinese govt and hurt Hong Kong democratic resistance. Google has paid hackers for various attempts to break into chrome os, most of them were really chrome attacks but the signed os images have generally brought safety. Linux even has many known su root attacks plus malware and supply chain attacks.
I'm no expert, but if you ask me, I would completely erase the phone, upgrade it via DFU, and start fresh. After setting it up again, run another backup and rerun the tool to doublecheck. That or ditch the phone
What’s the best procedure for getting data off a compromised iPhone before wiping? Plugging it into other devices via usb or backing up to iCloud seems sketchy to me but maybe I’m overly paranoid.
You've never plugged your phone into your computer before? If so, I doubt it could cause more harm to do it again unless you haven't done it since your device was infected. You're just mentally aware of it now, but how long has it been there and how many devices have you plugged your phone into since then, even just to charge? If you never plug your phone into another device, it's moot, but I suspect most people do at sometime or another. "Hey, can I plug my phone in real quick to charge a bit" type stuff. Airdrop is good for quick, small files, but I'm not going to be transferring multiple gigabytes of 4k video via wifi speeds that way.
Thanks. Wasn’t sure how airdrop worked so wasn’t sure if connecting a compromised device that way was a concern. Unfortunately there is no info out there because the official line is “all apple devices are secure don’t worry!”
"At around the same time the file com.apple.CrashReporter.plist file was written in /private/var/root/Library/Preferences/, likely to disable reporting of crash logs back to Apple."
This is a very good question and one to check - merely having crash logs disabled (at least for an HN audience) isn't a high information signal.
I've got crash logs and as much analytics and telemetry disabled in a custom provisioning profile just to save having to navigate through menus to turn everything off...
Would need to test this on one of those devices to see if there's a false positive as a result though. But it's possible this is a false alarm if it's just checking for existence of this file. Has anyone checked through the logic the tester uses?
You'd likely need to do several things, but one mitigation is to set up a network-wide firewall to block everything except IPs and domains you explicitly add to allowlist, and only connect your devices through the firewall.
For iOS, I don't believe a capable on-device firewall exists; but even if it did, NSO likely may have compromised it too.
Also: If it amounts to unlawful tapping where you live [0], you may want to consider a legal recourse (like signing up for a class-action?).
I don't believe there are proper application level firewalls. You can however (at least if the entire OS isn't compromised at the time of the network requests) get something which is better than nothing through the private DNS API.
If you configure your own private DNS server over DNS-over-HTTPS, and have your own logging on it, you can review your DNS logs across any devices configured to use it, rapidly.
While keeping a log of your own DNS queries might be a risk for some threat models, if you aren't doing this, chances are you were sending your DNS traffic in the clear to your ISP or mobile operator (or into a VPN provider of questionable trust). You probably aren't a huge amount more exposed by logging it for yourself.
This let me check for any of the IOC domains given in the write-up. While no doubt there will be attacks which could override the provisioning profile that forces this DNS to be used, it would still need to get into the system without making a query that's part of the IOCs. That limits attack vectors a fair bit - the payloads here seemed to do a fair bit of network-based fetching of subsequent payloads. The hostnames of these requests should be logged on your DNS and enable you to rapidly confirm if exposed.
As a bonus you can do host level ad blocking via this DNS server, which should definitely be the minimum you do if you're concerned about skilled attacker threat models - code execution in the browser via a delivered ad isn't something you want to make easy!
> If you configure your own private DNS server over DNS-over-HTTPS, and have your own logging on it, you can review your DNS logs across any devices configured to use it, rapidly.
Pegasus can always DoH its DNS queries to a server of its choosing bypassing any and all network-wide / os-wide DNS settings. Granted IoCs can be set to flag such behaviour. Besides, DNS and ICMP can be additionally be used to siphon off data too.
When used carefully, IP firewalls make for a good defence.
> ...if you're concerned about skilled attacker threat models - code execution in the browser via a delivered ad isn't something you want to make easy!
True. If NSO group is in your threat-model, it definitely warrants extreme paranoia and caution.
Good point - perhaps didn't make the limitations clear enough though - this would only help if the early payload gets delivered through a request made to a remote server (which inherently goes through default system DNS).
That's a fairly common compromise model though in my view - a message might contain a URL, and your phone might locally do a fetch of it to prepare a pretty preview, and that might try to exploit some weakness in the browser engine or whatever.
Given this was delivered via iMessage you're right - once they have code execution, the attacker can evade your DNS. If they can't get enough code in through their initial method to get their own DNS going, they might send a dropper which then pulls more code in from elsewhere, and that may give you an IOC to detect from that first query. If they can front their content on a popular domain though, this won't help.
Definitely favour network level protections before doing this, but if you just want the ability to get a view of your own DNS traffic from your device when it moves across WiFi and mobile data, this will give you a starting point.
Something like this should be available from Apple. But I guess they only offer privacy and security if it doesn’t require transparency. Well as long as it makes for good marketing.
It's actually a pretty big security win that I don't have to worry about what my grandma downloaded from the internet for her iPhone for instance, the way I have to worry about her laptop. Apple profits from this, and I really don't mind.
> I don't have to worry about what my grandma downloaded from the internet for her iPhone
Yet you're ironically responding about an article telling how to find if your iPhone has been infected with Pegasus, one of the worst most obtrusive security vulnerabilities you can have, period.
Since the law doesn't protect citizens from illegal surveillance, no matter if that is your grandma or not, this kind of security is extremely important.
Of course this is a big deal. But I think people are sort of missing the point. Nation States will always find a way in. There’s really no kind of security that stops a persistent well resourced threat.
If you think android/<insert OS> is immune to an advanced persistent threat, you're wrong.
Apple will fix these vulnerabilities, and then these professional hackers will get back to work on finding a new way in. The goal isn't 100% impenetrable security--that's impossible. The goal is really imposing a high enough cost so that as few as possible are capable of getting in.
There is not a rampant security problem on iOS. But there are still vulnerabilities for those with the resources to find them. That's only surprising to people that don't follow the security world.
States probably have dragnet surveillance and devices like iPhones make this far easier than it should be.
> If you think android/<insert OS> is immune to an advanced persistent threat, you're wrong.
Some of these devices are probably even more vulnerable. But the heterogeneity of systems is what provides practical security and systems like iOS are the opposite of that. Through this uniform software environment you create the juicy target in the first place.
Also anything in the Apple cloud is highly vulnerable to state actors anyway. Not only in the Apple cloud of course.
> But the heterogeneity of systems is what provides practical security and systems like iOS are the opposite of that.
This may be the first time someone tried to argue the fragmented nature of Android makes it more secure.
It is true that iOS, being as uniform as it is, can present a plum target. The difference is that this also means that with one fell swoop Apple can mitigate vulnerabilities for a billion devices--and they do.
One of the primary reasons to buy an iPhone is Apple's commitment to update support for many, many years. All phones will have vulnerabilities. That is inevitable. The most important part is manufacturer commitment to promptly fixing them when they're found.
> States probably have dragnet surveillance and devices like iPhones make this far easier than it should be.
The cost of these exploits makes it unlikely that it's truly dragnet. You don't want to risk burning your expensive exploit by going after literally everything. The wider you cast the net, the more likely you are to be found, your exploit patched, your infrastructure compromised. Again, platform security is not about being impenetrable--it's about imposing costs high enough to limit the number of players and the corresponding damage.
Android isn't the alternative draft to iOS, it is similar in significant properties. Alternatives would be relatively open PC systems for example. That diversity grows with more uncommon operating systems, which are currently endangered by MS secure boot btw, which would put PC in the same boat as mobile systems.
This isn't about favorites, I own Apple devices myself, although only MacOS and I don't expose by ID to Apple. Doing so is a major risk for the case your OS gets compromised.
As with Windows PCs in the past, you become a target with popularity.
With dragnet surveillance I mean that state actors scoop up every source they can get their hand on. It doesn't need justification because they already moved the goalpost to wanting to access encrypted information. Als the other sources aren't even questioned anymore.
For me, on macOS, I had encrypted backups already turned on, using the Finder. So, when I did the "mvt-ios decrypt-backup" I omitted the "-p ..." and gave my login password. I had assumed that the Finder-initiated backups would use it, and it appears to be the case (the decryption data looks good to me).
It doesn't run live on your phone—rather, you back it up using Apple software and then run the tool on the backup. So it never touches your phone directly.
Isn't "Pegasus" transmitted via a well-crafted iMessage ?
If only there was a central choke-point, globally, for all iMessage messages that could weed out particularly ill-formed messages such that they never reach your phone ...
Apple doesn't have access to the message content thanks to end-to-end encryption (technically they can have access if you backup your messages to iCloud, but by that point it's already too late).
However they are working on better sandboxing to help prevent this class of attacks, and Google Project Zero posted an overview of how that "blastdoor" process works:
In the Amnesty report there were multiple attack vectors, one of which is via network hijacking which involves data mangling by network operators. Now it begs the question whether the network operators were in cahoots or this Pegasus is also capable of infecting network infrastructure.
Wouldn't a simple block/allow list for sending IDs / phone numbers be trivial to implement on the iCloud (or whatever) side of things such that the end user could allow their known contacts and block (everyone else) ?
Apple product marketing would never sign off on that because it would a) confuse their messaging by signaling that iMessage is less safe than email, b) hurt the user experience for the vast majority of customers.
Trail of Bits hasn't shared what detections they're looking for with iVerify, but the app has extremely limited access to your device data - the device backup or full filesystem dump approaches will give you better detection.
Trail of Bits here -- while this is mostly correct, there are also parts of the runtime that dead file forensics won't be able to identify. There's no harm in doing both and, in fact, we'd recommend it if you're concerned.
We're using most of the exact same file-based indicators as MVT. It's really refreshing that Amnesty shared so much of what they found -- it made our own process of testing our checks against their discoveries much easier.
