Situation: * You have a Debian machine, which might be compromised by a backdoor due to a targeted attack. You don't know and want to make sure it's not. For example, a server or a client internet machine.
* You have a Debian Live CD or USB install, which you believe to be clean. * You want to boot from the trusted system (CD or USB) and check the internal hdd, which might be compromised. Non-solutions: * debsums: is a fine tool, yes. But its own man page acknowledges, that it has limited use as a security tool. It also only supports checking the system in which itself it is running. There is no feature to check a Debian, which is in another folder. * I have looked into intrusion detection systems (debsums,) Afick, AIDE, FCheck, Integrit, Osiris, OSSEC, Samhain, Tripwire, but they all have in common, that they want to create a known-good database before auditing. This doesn't scale very well, because updates are pretty frequent, which render that known-good database less useful. Re-creating the known-good database after updating isn't very safe either - let's say apt-get had a bug and installed a malicious package, then the checksum of that malicious package would end up in the known-good database. Goals: * No code within the untrusted system must be required to be executed in order for the check, since no code inside the vm image is trusted while testing. Work in progress: I wrote a bash script, which uses dpkg from the trusted system, to parse the /var/lib/dpkg/status file from the untrusted system. It then uses the trusted system, to download all packages, which are claimed to be installed in /var/lib/dpkg/status and extracts them. The sha512 (could be easily replaced with sha256) checksum of all files which come with the package is created on the trusted system and checked against the files from other untrusted system. Known good files will be stored in an array, mismatches will be reported and stored in array as well. Symlinks are checked as well. At the end, the script goes through all files within the untrusted system and compares which one are already known as good or bad and reports which extra files, which have not been verified against anything, are there. Ideally, there are very few extra files. Only changed configuration files and files manually created by the user. In reality, it seems like many files are auto-generated and not owned by any packages. Some of them even hold binary code, which gets executed during boot. Some examples: - /boot/grub/video_fb.mod - (dpkg -S /boot/grub/video_fb.mod reports not owned by any packages) - /lib/modules/3.10-2-686-pae/modules.symbols - /etc/ssl/certs/GeoTrust_Global_CA.pem - /etc/ld.so.cache - /etc/rc*.d/* - /usr/lib/python2.7/dist-packages/pygtk.pyc - and many more... It could be quite difficult to get a signed version of some of them or to deterministically freshly generate them? And I have open questions, such as: - Which package is responsible for creating device files (/dev/...)? How to check if they are legit? - Is there a signed dump of the grub boot sector somewhere? - What other places exist to hide rootkits? Where would be a good place to ask such questions? All in all, I am wondering, is writing such a verification script a promising or futile approach? At the moment, the script is still Whonix specific and verifies a .img image file. It wouldn't be hard to make the folder it audits configurable and to check any other hdds or root folders. If you like to have a look at the work in progress script, see: https://github.com/Whonix/Whonix/blob/master/release/verify_build Comments, criticism, enhancements, etc. welcome. It would be great if anyone is interested to co-author the script (we can pick any Free license) to make it usable for the general use-case. Cheers, adrelanos -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5238a34e.6040...@riseup.net
