Known-Good MD5 Database 309
bgp4 writes "Have you ever examined a system you thought was broken into but you weren't sure? If only you had run an integrity verification program like osiris or Tripwire first you could have figured out what programs had been changed. In an effort to help out in the instances when you can't answer the question "what was this like before?" we've constructed a searchable database of MD5 and SHA-1 hashes for files in many standard operating systems. You can search using the filename or the checksum and see if you have a trojaned binary or an overactive imagination. Currently at knowngoods.org we have many FreeBSD, OS X, Linux, and Solaris installations checksummed and cataloged. If you have other programs or distributions you would like to see in the database, please let us know."
Cool? (Score:2, Interesting)
Re:So what about the obvious scenario... (Score:2, Interesting)
What if someone hacked into the MD5 database and changed the entries?
This is definately a legitimate concern. I would be wary about this.
There is one possibility however. Even if the entries are changed maliciously, the MD5 sums might possibly be different from the rootkit that is installed. IIRC rootkits are compiled on the host machine, and this might change the MD5 sums for the rootkit. Also, there are different sources of rootkits, so that would also affect the MD5 sums and the feasibility of changing the entries.
neurostarFiltered as a "Hacking" site (Score:4, Interesting)
Problems with patched OSes / custom builds (Score:2, Interesting)
Are you running BIND, Apache, wu-ftpd, or (shudder) Sendmail? If you are, your system won't be entirely in their shiny dbase for more than a month (probably more like a week) after you install. And if _you_ don't update it, someone will be kind enough to "update" some file for you soon enough...
As a test, I checked
From the dbase:
RH 7.1 - MD5: ac0b58050deb21db1ed701277521320b
RH 7.3 - MD5: 6d3abf4efc9235e4eb5dc540d61d42fa
My systems:
#1 - MD5: ac0b58050deb21db1ed701277521320b
#2 - MD5: ac0b58050deb21db1ed701277521320b
#3 - MD5: 9724525265900e5f9020de3b431425b1
#4 - MD5: 881c7af31f6f447e29820fb73dc1dd9a
#5 - MD5: 6d3abf4efc9235e4eb5dc540d61d42fa
Binary compatibility is seen for systems 1, 2, and 5, but the RH7.2 system (#4) doesn't match. System #3 is a Gentoo system, which is probably the most secure, but also the least likely to ever match with their list. I guess that's the peril of compiling your own code.
Combination solution. (Score:3, Interesting)
Compare the MD5sums of critical files to a recent known "snapshot" of the system on RO media, which only indexes files that were changed and reconciled. Perhaps there is a list of files of which only certain byte ranges (perhaps just executable ELF sections) are checked, are some are omitted. (Other slashdotters mention caches/timestamps in certain relevant files that screw up checksums). You would have a whitelist (files which must match), then a graylist (files which meet byte-range criteria), and perhaps even a blacklist that prevents files that would normally be flagged to be ignored.
In checking full file checksums, those not explicitly listed above would fallback to a check using a HTTP get request conforming to this helpful document [knowngoods.org] these guys have offered.
And to those who were asking about other distributions: they are looking for people willing to work with them to add new distros/architectures to their database.
Re:Something's wrong here (Score:3, Interesting)
Chicken-and-egg...
Re:Useless for RPM-Based Distribuitons (Score:4, Interesting)
I'd also mention that it appears to be useless for BSD or Gentoo-like systems as well. BSD because it's built form source and the fingerprints won't always match, and Gentoo because there's already something like this built directly into the system, at least for verifying source tarballs.
Gentoo checks the md5sum of each tarball against another file containg the known value every time it installs something. The md5sums and the sources are obtained from different servers, so a lot of the risk of trojans is removed. Granted, this doesn't do continuous monitoring like this does, but it helps ensure you don't install something bad. The biggest worry now with this system could be vulnerable if several mirrors are hacked. They're working to replace it with a private-key signed system, which is much better than and md5 based system. The reason being that, that you can verify _who_ created the checksum in addition to that the checksum matches the file.
So, I'm not sure what the real benefit of this system is. It seems to be duplicating a lot of features that really should be built into the package manager ideally. Maybe someday we'll have package managers that actually watch their packages in realtime w/ strong crypto to make sure things are still good. That would be very cool.
Excellent! (Score:4, Interesting)
Now I can add a compromised md5sum to my rootkit which uses values from this site.
Go team!
Prebinding on OS X breaks checksums (Score:2, Interesting)
I'm not familiar with the Mach-O file format, but I'd guess that the changes are confined to a small part of the file. But if you could just checksum the code sections, that might work.
On the other hand, talking about libraries makes me think. Don't forget to check the libraries. If I trojan libc, I'll be getting all kinds of control while leaving the program binaries unmodified.
rlwimi
Re:What about source builds? (Score:3, Interesting)
Re:What about source builds? (Score:1, Interesting)
Re:What about source builds? (Score:2, Interesting)
307: if (f_sortacross)
308: base = 0;
309: for (row = 0; row < numrows; ++row) {
310: endcol = colwidth;
311: if (!f_sortacross)
312: base = row;
It is obvious how a compiler may think base could be used uninitialised, but clearly it never is.
sh
Re:Something's wrong here (Score:3, Interesting)
Basically to be really careful, you have to do the checks offline, on a separate computer, i.e. not relying on executables running on a system that's been exposed to attackers.
This is the kind of thing that the Palladium hardware should be able to help with. What Microsoft wants to do with it is evil, but it's capable of being used for good purposes too.
Personally.. (Score:3, Interesting)
What about AIDE? (Score:4, Interesting)
In additon to being a proper Open Source project, it allows for features that (last I heard at any rate) tripwire doesn't support, like a centralized checksum DB. That feature alone makes the tool superior (IMHO). For example it makes the verification process a lot nicer (intruder can't courrpt the local md5sum's because there aren't any).
Re:You know... this brings up a question.... (Score:5, Interesting)
Both lists have a fairly good signal-to-noise ratio, and there is a lot of good info to be had.
If nothing else, it's certainly a good place to ask that exact question.
You can sign up here [securityfocus.com].
Straightforward solution (Score:4, Interesting)
On top of this I stuck in one small bit of shell script that allowed me to modify a file myself without setting off alarms - it simply recalculated the md5 value and updated the record files.
I suppose this is theoretically vulnerable to an attacker reading through
The nice thing about this code is that it also implicitly tests for corruption of critical files after fsck-triggering events like kernel panics or total power failures. (That's actually what prompted its initial writing) And it's remarkably trivial to implement, even more so if one simply copies an off-the-shelf md5 binary rather than compiling one's own wrapper.
Re:Yes, in fact, I have! (Score:5, Interesting)
[ This is a story about why getting "good" checksums to start with is very important. ]
On a related topic: Ever examined a system you didn't think was broken into, and were sure?
The sysadmins at my old school did. And they were wrong.
You see, they connected a new box, the replacement main server, to the LAN, and used an easily-guessable password convention for staff accounts, PRIOR TO RUNNING TRIPWIRE on it. Seems "someone" got in and changed a few key binaries, THEN the admins ran Tripwire. Periodically, when the system got munged and a restore was required, they'd restore the original tapes, Tripwire would yell about a few binaries (including some innocuous distractors), and the admins would dutifully go to backups, find the modified binaries and restore them, figuring they had to be right, because of course, they matched the Tripwire signatures.
Ya gotta love self-repairing back doors when you're a student at the mercy of admins who work 9-5 M-F, NFS and lpd subsystems that croak only after 10pm or on weekends, and newbies who fill up file systems.
The local 3-person student root cabal used these back doors for several years, until the machine was replaced. AFAIK, the admins never knew. They had spent much of my undergrad time trying to find SOMETHING I'd done, to punish me for, so if they'd known about this...
Re:What about source builds? (Score:2, Interesting)
You've only proven my point, by thinking exactly what the compiler has. However, if you follow the code up (it's a bit spaghetti-like, computing the number of columns and stuff) you will see that numrows cannot be zero.
sh
Re:What?! No Windows? (Score:3, Interesting)
Don't worry, you'll have that soon. It's called Palladium.
As my grandmother used to say: "Be careful about what you wish for, because your wishes might come true". Wise woman.