First, let me make it clear that the disk coming up blank happened first, and I found rootedoor running several days afterward.
On Sunday 27 February 2005 09:56 am, Don Erickson wrote:
"Rooted" to me means that an unauthorized person has gained root access. Since your disk was wiped, this frankly has _got_ to be the case.
Not necessarily. Hardware errors are possible, but as the hardware has run without errors since, that's unlikely. Client error is also not only possible, but likely. Finally, there are exploits that, like a buffer overflow, don't give crackers useful access to the machine, but merely destroy the system. Someone may have exploited a CGI weakness to delete all the files without having arbitrary access.
The question to me is, does the "rootedoor" "trojan" provide a root shell if running as root?
Read up. I posted the links to what information is available.
It appears to ONLY provide a doorway, and probably one that implants itself and then waits for the exploiter to come along and use it. I caught it right after it was launched, and I'm pretty sure I caught it before anybody used it.
I have already followed some of your suggestions. Log file analysis/extraction that is delivered to some other machine can be even more usfull than raw remote logging, as it reduces the data to a more useful set. It can also be used via email when remote logging isn't an option.
Since the machine's in Tucson, doing something like booting from a Knoppix CD isn't possible, but it's not actually necessary in order to have good confidence in the integrity of the system.
One of the concepts that doesn't seem to have been caught in this discussion is that you can take a hash of your system files just like a PGP signature, and the verify that hash, either against a stored hash or the hash of a known good copy. That allows you to do a fairly easy system sweep, looking for tampered files. If the hash verifies, you really can be reasonably certain that the file has not been tampered with and does not need to be replaced.
Check all binaries in cgi-bin.
How would you do that? Understand that most of the web site is writen by the client, so his selection of CGI programs is something I don't fully control. I've scrutinized some of them, but sometimes he puts test scripts on it that I know nothing about. Any good methods for screening them? Mark 1 eyeall of the code is the best I've got, and at a certain level of volume and complexity it becomes less reliable.
These rootkits are pretty damned sophisticated.
Again, (and again, and again), this doesn't seem to be a "rootkit". It's just a backdoor, not a kit. I have seen some of the moderately sophisticated ones, and this ain't.
Anybody who really knew what he was doing, you'd probably never find out that he was there in the first place.
Unless you happened to run "ps ax" at a critical moment...