In the event a system compromise is suspected or confirmed, the ultimate goal is to re-establish a trusted, private environment for future activities. This is essential to protect yourself and other parties that are communicated with.
This entry assumes you still have or have regained access to your digital property. In order to move forward, it is necessary to adopt a reasonable compromise recovery technique that poses an acceptable trade-off between difficulty and security. The possible methods outlined below are listed in order of increasing security:
- powered on, Internet-connected compromised machines
- powered on, LAN-connected compromised machines
- powered on machines without connectivity (shared folder for VM or USB for host)
- powered off machines and mount
- the Qubes method
The threat models below currently utilize the "powered on, LAN-connected compromised machines" method. Community contributions to outline additional techniques are most welcome.
This threat model assumes a host compromise has been confirmed or is strongly suspected. In this case, it is important to remember that hardware is expendable, but data is precious. Consider your current hardware and everything attached to it as compromised.
Workstation Compromise without Virtual Machine Escape
1. Transfer the data out of the Workstation via a shared folder.
2. Apply steps 9 and 10 from the section above.
3. Discard the infected Workstation snapshot or VM image.
More complex ideas for recovering from an AppVM compromise on Qubes can be found here [archive]. However this may not be necessary because the steps above should equally apply to any hypervisor and are easier to grasp. Qubes does not have the concept of shared folders, so it is best to draw inspiration from ideas suggested in that link.
Gateway Compromise without Virtual Machine Escape
This threat model assumes a Gateway compromise has been confirmed or is strongly suspected, but there has not been a VM escape (breakout).
Firstly, it should be noted that a compromised Gateway has no access to the host resources. Further, a compromised Gateway does not automatically lead to a compromised Whonix ™ Workstation.
In the hypothetical case that a remote code execution vulnerability was found in Tor, this would compromise Tor but would only cause the following limited Workstation breaches:
- Ability to read (non-https) clearnet traffic originating from the Workstation (unless the Workstation has the following configuration:
- Ability to read onion traffic originating from the Workstation.
- Loss of anonymity.
The Gateway does not occupy a more privileged position to exploit the Workstation compared to a Tor exit. It is true the Gateway does not need to find a specific target, but a compromise of the Workstation still requires an additional vulnerability.
A compromised Gateway should not lead to a compromised (as in unwanted code, malware running) Workstation. This means the Workstation's shared folder should be safe, along with any locally stored data that has never been transmitted unencrypted over the Internet. For example, any OpenPGP encrypted messages from the Workstation sent through a compromised Gateway should still be confidential.
The recovery process is similar to the Workstation section above, except for the steps that involve key revocation:
1. Transfer the data out of the Gateway via a shared folder.
2. Discard the infected Gateway snapshot or VM image.
The most likely reasons for a Gateway compromise are:
- Installation of third party software on the Gateway.
- Purposefully browsing clearnet sites from software purposefully installed on the Gateway.
- Installing vulnerable services on the Gateway (like DHCP) that a malicious Workstation can access and compromise.
- Using a vulnerable version of apt to perform software updates; this happens on occasion and Whonix ™ routinely notifies users of the risk beforehand.
- A remote code execution vulnerability exists in Tor itself or pluggable transports; this is considered extremely improbable according to The Tor Project's track record.
- Risk of booting a malicious VM without an Internet connection:
- If disconnected from the Internet for too long, malware might be programmed to trigger the deletion or malicious editing of files (adding fabricated evidence), or perform actions which damage the hardware.
- Malware could load more code which might include capabilities to infect more hardware or perform a VM escape.
- The possibility of exfiltration may not be a simple binary (yes or no) proposition. For example:
- Imagine a scenario whereby the attacker is using malware to remotely search images/videos/other files in succession (there are screenshots/videos available about malware features).
- Not all attackers will immediately fetch a whole image dump.
- Malware might upload more files over time; upload over Tor is slow.
- Depending on when the compromise was noticed, everything may not be in the hands of the attacker yet. This is particularly true with large files such as video recordings.
- The attacker might upload illegal files (non-torified) somewhere that result in a raid by authorities.
- The attacker might come up with a new strategy, such as uploading false evidence files to the victim’s computer followed by authority tip-offs that result in a police raid and false accusations.
- When a malicious computer is connected, it might perform illegal activities like becoming part of a spam botnet.
- The longer a compromised machine is connected to the Internet -- imagine a user following poor advice and taking days to search for all relevant data and making backups -- it is harder to explain away a decision to continue operating it. For example, stating “my computer was compromised, it wasn’t me” is hard to reconcile with evidence that it was used in an attack for days on end.