Slashdot Mirror
Known-Good MD5 Database
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."
Mu corporate www proxy filters this site as category "Hacking".
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.
Now I can add a compromised md5sum to my rootkit which uses values from this site.
Go team!
the poster mentions Tripwaire, but what about AIDE?
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).
You could start by subscribing to the forensics mailing list over at securityfocus.com. The honeypots list is also of interest.
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.
Never trust an atom. They make up everything.
I found a fairly straightforward solution to this problem. I wrote a small wrapper around a known-good md5 function, compiled it and placed it in a nonstandard location. (Thus it doesn't have a widely recognizeable filesize or md5 to be detected and stomped) Then I wrote a simple shell script which checksums various critical files on a regular basis and tests the MD5 values against a record it keeps, again in a private location. Whenver a change happens, it sets off alarm bells all over the place, both in syslogs and on the console.
/etc/crontab, then checking each local shell script for a sensor and carefully overwriting my own nonstandard code - but if any attacker has that much free time on his hands, there's a limit to how much of a sensor I can implement.
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.
Have to AC this one....
[ 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...