tcpdump should be able to record the information you'll need. Use -s65535 to be sure you capture all the payload data and -w to write out to a file in a format that can later be parsed by tcpdump, ethereal or some other tool.
If it happens again you can dig through the logs and find out what was sent, then you can probably take that to the apache list, and they'll either tell you what's likely wrong, or they'll go into a frenzy because there's a previously undiscovered exploit in use on the current version :)
In the mean time, triple check the directory permissions in the apache configuration. Make sure they're not able to just plain execute wget and/or a shell without crashing anything at all :)
Andrew
Fred Merritt wrote:
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]
______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
