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
