Hello. I am using Kicksecure and Whonix on a virtual machine. Usually, I use live mode. If I delete these virtual machines, what level of danger exists in case of forensic examination? Or do these metadata not pose any danger? I understand that the best option would be to use Kicksecure-host in live mode, but I am interested in your opinion on virtual machines. Disk of course encrypted. There are many opinions on this topic. But you are the best security experts and I am very interested in your opinion. I think that the metadata in log does not pose a threat, otherwise you would not created Whonix and Kicksecure as virtual machines. But your answer is very important to me. Thank you
No, that doesn’t follow. See history:
The foundational vision for Whonix was to employ (virtual) machines in a manner that would guarantee all internet traffic was reliably and exclusively channeled through Tor, offering robust protection against IP address and DNS leaks.
Whonix was founded in 2012.
Discussions on Whonix live mode / amnesia / amnesic / non-persistent / anti-forensics - Development - Whonix Forum started in 2017.
See:
Thank you Patrick. Using Kicksecure-host seems to be the best solution for protecting amnesic VM from forensic analysis. Kicksecure has kernel dump disabled by default, swap is not enabled by default, and in future you will add user-session mode (read-only). And host log deletion.
I meant that if live function in VM didn’t make sense, you wouldn’t have added this to Whonix and Kicksecure. Yes, this is not full protection from forensic, but it significantly complicates it. Otherwise, you would simply recommend using VM snapshots or USB-live.
Patrick, can you explain this question - in wiki is written that Qubes has problems with amnesia for Whonix and Kicksecure due to problems with launching live mode. But it is also written in wiki that VM snapshots work better than live mode, and in Qubes snapshots are simple and convenient. Does this mean snapshots can solve problem with amnesia? or did I misunderstand something?
and how much can this script replace live mode for Kicksecure in Qubes? GitHub - kennethrrosen/qubes-shadow-dvm: Simple dom0 bash script inspired by Unman's 'Really Disposable Qubes' scripts
- Kicksecure for Qubes: For Qubes OS, the process may not work as expected. For further details, refer to the related Qubes feature request Implement live boot by porting grub-live to Qubes - amnesia / non-persistent boot / anti-forensics
- Non-persistence, yes. You can easily delete App Qubes.
- Anti-forensics, no. Disposable VMs, App Qubes, snapshots are not an anti-forensics features. Qubes - to my knowledge - does not make any claims about anti-forensics.
It’s just a simple shell script running commands. If something goes wrong, cleanup will not be done. Quote from the script source code:
qvm-run -a "${QUBE_NAME}" "${BROWSER}"
wait
If something happens and the script does not continue (such as power loss), data will persist and not be automatically cleaned up. Commands such as:
qvm-remove -f "${QUBE_NAME}"
qvm-pool rm shadowy
sudo umount shadowy
sudo rm -rf "${TMP_DIR}" \
/var/log/libvirt/1ibx1/new.log \
Will not be executed.
Writing data to the disk and cleaning up later is an insecure approach to non-persistence and anti-forensics.
I don’t know if there are any reviews of that script and it also seems it’s not part of Qubes and hasn’t been attempted to upstream to Qubes. Therefore I would be cautious.
There are no shortcuts. The only serious solution would be for Qubes to properly implement functionality to not write data that should not persist to the disk.
Can practice of deleting VMs and clearing host log with overwriting (shredding) be called antiforensic? I understand that deleting log has two sides - logs are important for finding possible errors, but it is also metadata for forensic experts
As stated in Forensics.
Unfortunately, these methods are not a sufficient substitute. It is manifestly unsafe to try and deal with data by wiping it after it has already been stored, so this is a poor design principle to implement.
Wear leveling - Wikipedia is one reason for that.
The most secure way to avoid data persistence is to avoid data ever being written, ideally combined with Read-Only: Setting Hard Drives to Read-Only.
1 Like
Shredding is effective against forensics - military uses it. but yes, frequent shredding damages ssd
I saw comparison of Tails and grub-live. Does this table apply only to Kicksecure on host and vm? Or does it also apply to Kicksecure-usb in grub-live mode?
I failed to provide enough context for wear leveling. Disk damage is not the main issue. The main issue is, that disk shredding can be ineffective.
The problem is that the hard drive is not just a hard drive. It’s a its own “computer” with a complex firmware (operating system).
The issue with Wear leveling - Wikipedia is that the disk controller tells the kernel “file deleted” while in reality the sector has been marked unusable but still contains data, which can be recovered by data recovery professionals with low level disk controller commands. This is documented here in more detail:
Advice for Solid-state Drives and USB Storage
(And that’s the link I should have used.)
1 Like
So in summary:
- We don’t have a list of things to shred;
- the list keeps changing over time;
- for example, this had been identified Disable PStore by raja-grewal · Pull Request #304 · Kicksecure/security-misc · GitHub;
- unknown unknowns;
- Computer storage hardware is not designed with non-persistence and anti-forensics as a primary goal in mind.
Conclusion:
The most secure way to avoid data persistence is to avoid data ever being written, ideally combined with Read-Only: Setting Hard Drives to Read-Only.
Added to grub-live - boot an existing Host OS or VM into Live Mode documented just now:
This wiki page documents grub-live mostly as a standalone software package outside the context of Kicksecure. Any elements related to Kicksecure are clearly marked as such (“Kicksecure feature”).
1 Like