Re: Lion Worm/crew.tgz

[Neil Long <neil.long () COMPUTING-SERVICES OXFORD AC UK>]

> On Fri, Mar 23, 2001 at 10:24:02AM -0700, Alfred Huger wrote:
> > There is no t0rn rootkit involved and the root shell is on  1008 so
their
> > Lionfind may be misleading.
>
> The initial exploit installs an inetd-based backdoor on 1008/tcp, as
> posted earlier.
>
> Once the rootkit is downloaded, however, additional backdoors are
installed
> on the sytem.  These are on 60008/tcp and 33567/tcp.
>
> The SSH backdoor runs on 33568/tcp.
>
> The SANS advisory just doesn't cover (yet) the initial attack sequence,
> just the analysis of the downloaded crew.tgz (aka 1i0n.tgz).
>
> Whats also interesting about the exploit is that it uses a 53/udp DNS
> query packet to seed a /bin/sh, then push through the attack payload
> (Bash shell commands as previously posted) on an open 53/tcp session.
> Pretty interesting.
>
> I've been tracking the worm since late February when it attacked a client
> (unsuccessfully).  So far, no variations have been noted the 12+ unique
> sources that have launched it against my client.  Activity has definitely
> increased over the past week.
>
> I'll see if I can get permission to post the sanitized TCPdump log, but
> that will take a few business days.

My comments yesterday were in reference to the crew.tgz as found at that
time (the file datestamps indicated a fresh brew on the 23rd). There are
clearly others around as well.

Would admins looking for worm sign please take note that any host which
could have been exploited via this worm has been vulnerable to any number of
variations on the theme since at least the Jan 26th release of BIND
8.2.3/9.1.0 - and obviously before that date but the probability obviously
increased after the vulnerability was announced.

There is nothing quite like a flurry of hype to get people looking at their
systems but the installation of t0rn, etc could have been done quite
independently of the crew/l10n activity but the indications are that there
were fatter versions of crew.tgz before yesterday.

There could be several variants running round the net (of course there are!)
and the 'fix' has been available since Jan 26th and vendor type packages
soon thereafter. Modifying the crew.tgz is trivial as is modifying the
rootkits.

Use of TCT and comparison with netflow data should enable people to figure
out who, what, where but reliance on a 'detector' package is not as
effective as updating the version of named in use.

Best advice I can offer is - block tcp-53 incoming unless it is to a well
secured and necessary DNS for the local domains which should not disrupt
normal usage.

Some might block outgoing but that would really impact on normal sysadmin
activity.

regards
Neil