Re: Slapper questions

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@xxxxxxxxx
> > (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@xxxxxxxx
> 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