Re: Bind compromise

[Jason Lewis <jlewis () jasonlewis net>]

Is there an exploit for 8.2.3-REL?

What else was running on this box?  ftpd?

What version of SSH?

I am rolling out two new name servers and I would rather not roll out
something with holes.

What kind of options are you using in the named.conf?  Is it secure?

jas
http://www.rivalpath.com


-----Original Message-----
From: Incidents Mailing List [mailto:INCIDENTS () SECURITYFOCUS COM]On
Behalf Of Jim Olsen
Sent: Tuesday, February 20, 2001 1:22 PM
To: INCIDENTS () SECURITYFOCUS COM
Subject: FYI: Bind compromise


I know this may be somewhat old news to some, but the confirmation of live
BIND 8.2.3 exploit's may not be. One of my customer's boxes was penetrated
last thursday. I lost network connectivity to the box around 7:00 AM , and
got it back online around 8:30 AM with help from my colo provider. Upon
ssh'ing into the box I was investigating the logs to see what had caused the
outage, and I saw some weird log entries, most notably stating that named
and
syslogd had been restarted at 3:00 AM the same day, which is abnormal for
that particular system.

So, onto the next steps. I did a 'ps auxw' and everything looked fine. Of
course, we all know we can't trust that in and of itself. Time to do an
'lsof
-i -n -P'.

[root@ns4 /root]# lsof -i -n -P
COMMAND   PID USER   FD   TYPE  DEVICE SIZE NODE NAME
sshd      443 root    3u  IPv4     723       TCP *:22 (LISTEN)
named   26675 root    4u  IPv4 2695432       UDP *:1917
named   26675 root   20u  IPv4 2693627       UDP 127.0.0.1:53
named   26675 root   21u  IPv4 2693628       TCP 127.0.0.1:53 (LISTEN)
named   26675 root   22u  IPv4 2693629       UDP 209.190.211.2:53
named   26675 root   23u  IPv4 2693630       TCP 209.190.211.2:53 (LISTEN)
named   26675 root   24u  IPv4 2693631       UDP 209.190.211.3:53
named   26675 root   25u  IPv4 2693632       TCP 209.190.211.3:53 (LISTEN)
named   26675 root   26u  IPv4 2693633       UDP 209.190.211.4:53
named   26675 root   27u  IPv4 2693634       TCP 209.190.211.4:53 (LISTEN)
named   26675 root   28u  IPv4 2693635       UDP 209.190.211.10:53
named   26675 root   29u  IPv4 2693636       TCP 209.190.211.10:53 (LISTEN)
sshd    27364 root    5u  IPv4 2695890       TCP
209.190.211.10:22->209.190.230.3:813 (ESTABLISHED)
sshd    27364 root   11u  IPv4 2695901       TCP *:6010 (LISTEN)
in.amdq 27400 root    3u  IPv4 2695932       TCP *:12300 (LISTEN)

Hrm.. in.amdq? on port 12300? Not normal... Looked at /proc/27400/ and found
out it had been running since 3:00 AM.  I tried 'kill 27400'; no go... so
'kill -9 27400' did the trick for me. If they had made their rootkit good
enough to hide it from /proc and lsof, then I wouldn'tve found it so easily.
Network connectivity stopped working around 7:00 AM, according to the logs;
I
can only assume that the attacker had logged into the box between 3:00 am
and
7:00 AM and screwed up the networking (either purposefully or by accident).

also found some other files touched:

In order to get the daemon to start on bootup, /etc/rc.d/rc.local and
/etc/rc.d/rc.sysinit had this line:
/usr/sbin/in.amdq -q

also, in /var/log a program was sitting there called 'wzap' which is used to
erase login entries from the 'lastlog'.

What is in.amdq? A customized ssh daemon of sorts that allows anyone to
connect as root, or so it appears. They also must have used a rootkit of
some
sort, as the process does not show up in ps auxw.  There is probably more to
the compromise, but this is all I found. This server was running named
8.2.3-REL, which i assume was the source of the system compromise.
According
to my colo provider, everyone who had a collocated linux box with this
version of BIND had been penetrated, so it's possible this attack is
self-replicating, although I could not find any traces of this on the
compromised system. Thankfully this box isn't that important, and thank
goodness I got bind 9.1 up and running on my important boxes before this had
happened.
--
Jim Olsen
Systems Administrator
Browser Media