in all cases: if starting something compromised: disconnect internet first
shared folder
Doesn’t apply to Qubes and could use links to existing documentation for virtualizer specific instructions.
Turn on your compromised machine
This shouldn’t be done or at least this should be considered a less secure option. With forensics and malware infections:
don’t continue to power on the hardware again
make an image and copy of that image before working with the image
Connect new external storage
I know what you mean but many users probably won’t. Needs to be clarified a bit what is considered new, i.e. not the ones connected to the infected host and why, to prevent BadUSB.
untrusted external USB or HDDs
Same as above. Untrusted probably meaning: no data stored on it that you care about or wiped beforehand, and knowing that this device can never be connected again to any non-compromised computer. Perhaps trusted/untrusted doesn’t describe it well? Perhaps better compromised/non-compromised or infected/uninfected? The previously uninfected HDD should be considered infected after being connected to a malicious machine?
Threat model: You know or highly suspect that the Workstation is compromised, but there was no VM breakout.
Transfer your data out of the Workstation via shred folder.
If so: remove internet connection first.
But then still applies: It is easier but not the most secure option.
Threat model: You know or highly suspect that the Gateway is compromised, but there was no VM breakout.
A compromised Gateway has no access to the host resources. Only the Workstation should be considered compromised along with any data that it contains or is in shared folders it can access.
Why should the workstation be considered compromised? By mistake wrote workstation but meant gateway?
Why not? Considering exfiltration has already happened what are we protecting the infected machine from? If not the network then the HDD Needs to be taken out and put in a USB enclosure to be connected offline from the clean machine. This brings up another set of problems that can also lead to infection. At least with the network we can have higher chances of keeping the new machine trustworthy. Also the forensic method is not accessible to most people.
OK
Yes I understand these are reasons for not powering on compromised devices but if something was to auto destruct then the damage could have been done before you’ve even received back the devices or even accessed them again. If that was the intention of the attacker.
OK I will make clearer
In this context, the data was exposed but the machine not infected because of whonix-firewall. Data exposed because the GW can see all traffic.
Risk of booting a malicious VM without internet connected:
if internet is considered off for too long: malware might react on this trigger such as by deleting files or maliciously editing files (adding fabricated evidence)
or do some action to damage the hardware
Risks of keeping internet connected when being compromised:
malware can load more code and the newer code might include stuff for infecting more hardware or VM breakout
exfiltration may not be a binary yes/no. Could be something in between. Imagine a malware where the attacker remotely is searching one by one (there are screenshots/videos available about malware features). Not all attackers straight fetch a whole image dump. Malware might upload more files: upload over Tor is slow. Depending when one noticed the compromise, specifically with lots of data (lets say video recordings) not everything may be in the hands of the attacker yet.
the attacker might upload illegal files (non-torified) somewhere that result in a police raid
the attacker might come up with a new strategy such as uploading false evidence files to the victim’s computer and then tip the authorities resulting in a police raid and false accusation
when a malicious computer is connected, it might do nefarious work such as for a spam botnet
the longer it’s connected to the internet (image a user following that advice and taking days for searching all the data and making backups) it’s harder to explain (think in front of a judge) that “my computer was compromised, it wasn’t me” vs “your computer was used in an attack for days”.
I think it comes down to USB vs network. What is the best way to do this in your opinion (with details because simply telling users connect the unpowered thingymajig to WS then move stuff leaves a lot to the imagination and not practical).
None of this is very realistic. I don’t expect a high share of users being even aware of this or capable to apply these steps or even have the motivation/resources to apply these steps.
It’s in the spirit of Advanced Security Guide to also mentioning things which are difficult, even if we can’t document them fully.
Starting with the least secure up to the most secure way:
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
(machines shall be somehow a term that can mean both real hardware or VM, unless there is a better term.)
We should probably distinguish between considering hardware compromise and host compromise.
the malicious USB device, 2) malformed partitions or other volume meta-data, and 3) malformed filesystem metadata.
If one is worried malicious USB, the best option can only be Qubes since it supports USBVM.
If one is worried about malformed partitions or other volume meta-data, and 3) malformed filesystem metadata, then best option can only be Qubes since it allows to restore AppVMs on a fresh Qubes installation in a safe way, and the virtual disks of these VMs can then be mounted and then By using Qubes secure file copy operation. Specifically the user might copy the whole home directory to a new AppVM, and then analyze, verify and start using (the verified) data in a new, non-compromised AppVM:
So for one section, hardware compromise could be mentioned but out of scope. And for another section issues with mount could be mentioned but out of scope.
Threat model: You know or highly suspect that the Gateway is compromised, but there was no VM breakout.
A compromised Gateway has no access to the host resources. Only the Workstation should be considered compromised along with any data that it contains or is in shared folders it can access.
This is still confusing me. highly suspect that the **Gateway** is compromised but then be told **Only** the **Workstation** should be considered compromised.
A compromised Gateway has no access to the host resources. Both the Gateway and the Workstation should be considered compromised along with any data that it contains or is in shared folders it can access.
Implies so, but a compromised gateway doesn’t automatically lead to a compromised workstation.
Let’s say a remote code execution vulnerability was found in Tor. That would compromise Tor but a compromised Tor only leads to the following breaches for the workstation:
reading (non-https) clearnet traffic originating from the workstation (unless the workstation is using a user → Tor → VPN → destination tunnel configuration)
reading onion traffic originating from the workstation
loss of anonymity
The gateway is no more privileged position to exploit the workstation than a Tor exit. Well, it doesn’t have to find a specific target, but it still requires to compromise the workstation through another vulnerability.
A compromised gateway shouldn’t lead to a compromised (as in unwanted code, malware running) workstation. So the workstation shared folder should be safe along with any data locally stored and never transmitted unencrypted over the internet. So any OpenPGP encrypted messages from the workstation sent through a compromised gateway should still be confidential.
