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."
You know, this is sort of cool... until it gets hacked (cracked... whatever) and then your entire OS looks bad. Wait. That is COOL!
3cx.org - A truly bad website.
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.
neurostarMu corporate www proxy filters this site as category "Hacking".
This sounds nice, but I see problems as installs move from the "100% installed code" to the "patch of the week" versions. Especially when you have to do custom builds of the software.
/bin/ps on a few local systems. (If you don't know why I started with this one, you will. Probably sooner than you'd wish to.)
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.
Turambar
------------------------------
Common sense is not so common.
--Voltaire
Ideally, a simple tool should be developed that does the following:
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 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.
Fuck Beta. Fuck Dice
And what's to prevent an intruder from adding a trojan to the signature-checking program/library?
Chicken-and-egg...
Solution to blink tags: wrap them in another blink tag, with a javascript delay loop, so they cancel each other out
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 problem with this is that it assumes that binaries never legitimately change. That is false in Mac OS X. The Mach-O file format allows for "pre-binding", where the linker tries to resolve imported functions and data before the app is loaded, and, if successful, writes the offsets to the file.
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
Actually, I know Windows 2000 Professional has a similar system. I've recently been installing/reinstalling a few things and suddenly a box popped up saying something like "Windows File Integrity Checker. Windows has detected that vital system files have been modified and to ensure stability needs to restore these files from the Windows 2000 Professional CD". I'm not sure which files it checks or how, but I do know it has got a least "a" level of checking inbuilt.
Ahh, Free Software at its best -- the stable verions compile complete WITH warnings!
Follow the logic:
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
"[A] high IQ is like a Jeep; you will still get stuck, just farther from help!" --Just d' FAQs, c.g.a
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.
I like this utility. It's pretty handy, although probably not as effective as this database, unless you're running slackware, or another popular, but undatabased distro. :-)
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
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...
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
"[A] high IQ is like a Jeep; you will still get stuck, just farther from help!" --Just d' FAQs, c.g.a
We need file verification, too! Probably more so with some of the Windows/IE vulnerabilities.
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.
"There are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare." - Blair Houghton