Michael, Andrew, Fred, and Mark,
first of all,
thank you for your rapid response to my append to this list. All your
comments were constructive, and helpful.Do I have any reason to think that this is an OpenSSL bug? No - I have my doubts. If this was an OpenSSL bug in the wild, I am sure that this list would be full of appends about it. What makes me think it might be, is
1. The quoted(might be false trail) modus operandi of the hackers -
use an openssl scanner, get in and then do a root exploit . . .
2. The first attack followed this MO impeccably, but I only have
myself to blame for not being up to date. The first attack
downloaded files - like telnet, and some backdoors to /tmp. All
files were nobody nogroup. A root exploit was downloaded, and my
machine was theirs.
3. The system was rebuilt, except for the Apache sub-system, and was
not attacked . No data files from the original incarnation of the
system were installed on the machine. All code restored was from
the development site, and could not possibly have been corrupted.
The system was online for 3 days without Apache/OpenSSL. Apache
without OpenSSL was up and down several times. Nothing was
attacked. Within two hours of the Apache/OpenSSL service being
restored, the system was attacked in the manner described in the
original append.
4. In the second attack, the kernel was protected from the root
exploit to which it was vulnerable in the first attack. In this
attack, files were also downloaded to /tmp, but the crackers were
unable to gain root access(I think!!), at least I have no evidence
of this. All the files down loaded were once again user/group
nobody/nogroup. there were some traces of the attacker trying to
damage files, but getting rejected due to not having the
appropriate permissions.
5. The attackers in their publicity on their own site do not (apart
from their claims of omnipotency) claim to be capable of attacking
0.9.7c it may be that their particular scanner was capable of
attacking 9.7c, be they themselves were not aware of it (if (it
was && if they were) { I'm sure there would have been a lot of noise})
6. Information in the main server log is written by Apache, or one of
it's children(assumption). Yes it looks like a wget, but I think
the wget was issued by the exploited Apache system to download
the root backdoor.When we cleaned up the system, we bought a new disk. All the new stuff went on the new disk from external sources. To be honest the old disk was still in the machine, but not mounted. Of course I may have problems elsewhere, but I haven't found evidence, and I'm still looking pretty hard. No unnecessary services are running, and those that are running show no sign of attack. My business partners are pushing pretty hard to put the system back online, and at some point, we have to put a toe in the water.
We had CGI scripts in the system, but only one or two for specialised parts of the system.. The were in situ for the first attack, but hadn't been rebuilt when the second attack took place. The CGI directory is still empty, except for the demo/test stuff originally put there by Apache.
What do I think might have happened??
* I might have fubar'd the rebuild of the supposedly "immune"
system, and left an unprotected system.
* 0.9.7c may have a vulnerability not yet recognised by the
attackers(as proclaimed by their silence).
* Something completely different happened.There is no evidence at all in the logs. The main server error log is precise on the time of the attack, but there is nothing in the access, or engine logs that are near to the date and time of the failure.
For the moment, I'm just checking, and rechecking, but unless I can think of something else, I guess I have to bring it up some time this afternoon, for a short while, and watch it like a hawk.
Once again, thanks for your help. . . Fred
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
