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.
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.
"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!
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.
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) ?
Readit News
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.
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.
Deleted Comment
From <https://www.amnesty.org/en/latest/research/2021/07/forensic-...>
"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."
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?
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?).
[0] https://en.wikipedia.org/wiki/Telephone_tapping#Legal_status
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!
Deleted Comment
And the Guardian has some in-depth reporting going on. https://www.theguardian.com/news/series/pegasus-project
None of this really answer how prevalent the spyware is, though.
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 ...
If only ...
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:
https://googleprojectzero.blogspot.com/2021/01/a-look-at-ime...
They can use fake cell towers, no need to escalate that far.
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) ?
Forgive me - I am not an iMessage user ...
I also installed usbmuxd via Pacman.
Dead Comment
Deleted Comment
Deleted Comment