Security Incidents mailing list archives
Re: Slapper questions
From: Cian Whalley <cian () somewhere ca>
Date: 28 Oct 2002 21:13:47 -0000
In-Reply-To: <3DB85052.7A4F4286 () unix si edu> I've seen a similar incident, very recently (last week infact). It appears that someone has modified slapper to be used in conjunction with a root kit (I'm not sure which one, haven't been able to research that yet) to gain access to their server. They then proceeded to use several tools to clear the log files (/var/log/messages anyways) and start up some ethernet sniffers. I've included a list of files that I found on the system that you may want to look at (though I would personally run checks agains all my system binaries as well, I found some that didn't match the MD5): /var/www/.bash_history (this was very interesting to look at) /etc/security/console.apps (found some new entries here) /etc/sysconfig/console (same here) /usr/bin -rwxr-xr-x 1 root apache 1250 Oct 16 14:43 clean* -rwxr-xr-x 1 root apache 18827 Oct 16 14:43 slice* -rwxr-xr-x 1 root apache 21850 Oct 16 14:43 stealth* Those ones were the log cleaner/sniffer... /usr/local/games -rwxr-xr-x 1 root apache 18799 Oct 16 14:44 parse* -rw-r--r-- 1 root apache 37 Oct 17 10:49 pid I can't remember what those two did, I think they wre part of the sniffer. Now there was other stuff in there, but they didn't give me enough time to do a full analysis, as soon as they found out why their machine was running so slow they went to work on repairing it. I kept as much data as I could, and it's available upon request.
It seems unlikely that an automated process was scanning on port 23/tcp for anything that would use the SSL libraries which had these problems. As far as I know, no self-spawning trojan was ever created that would even check port 22 - only port 443 would be affected at least by the slapper worms I know of, since they relied 100% on an SSL-enabled web server. I don't believe they infected via SSH on any port automatically, though it could be theoretically possible (the first advisory bulletins I saw regarding the SSL problem were for SSH actually, the slapper worm was an afterthought that went after web servers, not SSH servers). It seems like you've done a lot right, and very little if anything wrong, but there may be some more checking left to do. A good place to start is a full audit of anything affecting init (ie /etc/rc?.d, /etc/init.d, your init configurations like inittab, etc), a ps listing audit, and running some MD5 checksums against your system binaries against a clean and 100% secure machine if possible. An audit on /tmp sounds like it wouldn't hurt, either. :-) Stephen Smoogen wrote:Its a bit late in the game, but you may have a backdoor (or various backdoors) running on the system. My advice is to do the following
(with
the assumption you only have 1 machine available to run the website). [Sorry if it is a bit general, but its from a list I hand out to completely new sysadmins working on compromised machines.] A) Take the system off the network (letting management know why) B) Backup the system to completely to tape in case you need to present
a
report to law enforcement or management (why I need to be paid more or sent to that SANS training. :)) C) Go over what you need on this machine still (IE what code etc is running on it for webservices that may need to be audited to see if
a
back door was planted there.) D) Reinstall the machine from source cdroms and then put all updates
for
that operating system on the machine. E) If your Linux vendor has an automated system of alerts or updates
see
if you can sign up for it or get your employeer to pay for it. F) Reinstall the software that you need for the website to be operational and test it for working. G) Put the machine back on the network and test functionality again H) Go over all that was discovered and write up a short report for your CYA file and to hand over to management over what happened, why, and what needs to be done in the future. If you have multiple hardware and more than 1 staff you can parallelize portions of C, D, E, and F. H sounds like a nuisance, but it can save your job or worse. On Wed, 2002-10-23 at 13:42, Griff Palmer wrote:Hello: I'm trying to learn more about how the Apache/mod_ssl worm variants
operate.
Last month chkrootkit discovered evidence of the Slapper worm on my
RedHat
7.2 server. I found .bugtraq.c in my /tmp directory and eliminated
it. I
updated my openssl to 0.9.6g-1. I blocked port 443 on my firewall. I keep my ftp daemon stopped except for occasional short periods
when I need
to use it. I've been leaving port 23 open and making my ssh host
listen on
port 23. (My employer's firewall blocks traffic on port 22, forcing
me to go
to the port 23 setup.) Regular scans with chkrootkit since then have shown no signs of the
slapper
worm's presence. This morning I received an e-mail bounce from cinik_worm () yahoo com (apparently Yahoo has disabled that address). A search on cinik led
me to the
latest CERT bulletin, which showed information about the slapper B
and C
variants. After reading the bulletin I discovered the presence of cinik.c and
cinik.go
in my /tmp directory, which I eliminated. I also discovered an active .bugtraq process on my machine and
killed it.
I've blocked UDP packets on ports 1812 and 1813. (Looking at the CERT bulletin it looks as if I should also block 1978, 2002 and 4156.)
I've
commented out the listen 443 line in my httpd.conf file. At this point I'm confused about the mechanics of the infection
process and
about what further steps I may need to take to fully eliminate
infection and
harden my server. Is Port 23 an avenue of infection? Does upgrading to openssl-0.9.6g-
1 not
eliminate vulnerability to compromise? Is it possible that I missed
the
C-variant code when I discovered the .bugtraq code, and that the C
variant
code has lingered on my machine since then? I'm using chkrootkit-
0.37. Is it
able to detect the B and C variants as well as A variants? I've run ps on my machine many times since chkrootkit discovered the
Slapper
A variant. Those checks showed no presence of the .bugtraq process.
(I even
downloaded and installed new system binaries in case any of those
had been
subverted.) The .bugtraq process showed up after I upgraded my kernel this
morning. Is it
possible that my earlier kernel had been compromised and that
the .bugtraq
process was being hidden? Any advice appreciated. Griff Palmer ---------------------------------------------------------------------
-------
This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com-- Stephen John Smoogen smoogen () lanl gov Los Alamos National Labrador CCN-2 B-Schedule PH: Ta-03 SM-261 MailStop P208 DP 17U Los Alamos, NM 87545 -----------------------------------------------------------------------
-----
This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com-- /* * * Matt Harris - Senior UNIX Systems Engineer * Smithsonian Institution, OCIO * */ -------------------------------------------------------------------------
---
This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
Current thread:
- Slapper questions Griff Palmer (Oct 23)
- Re: Slapper questions Stephen Smoogen (Oct 24)
- Re: Slapper questions Matt Harris (Oct 24)
- Re: Slapper questions Hugo van der Kooij (Oct 25)
- Re: Slapper questions Matt Harris (Oct 24)
- Re: Slapper questions Hugo van der Kooij (Oct 24)
- <Possible follow-ups>
- Re: Slapper questions Cian Whalley (Oct 28)
- Re: Slapper questions Stephen Smoogen (Oct 24)