Re: Bind compromise

[John <johns () TAMPABAY RR COM>]

I am rather curious as to know what
services this machine was running also.
How do you know the machine was penetrated
through the named version running on
the client's machine? Is there any visual
evidence of this? If in fact
they were penetrated through Bind
8.2.3-REL than I suggest you display all
the details about this and maybe we
can come up with something as to there
being a new (another) Bind exploit.
I highly doubt this cause if there is a
exploit for Bind 8.2.3-REL than we
would see MORE wide spread compromises.


----- Original Message -----
From: Jason Lewis <jlewis () jasonlewis net>
To: <INCIDENTS () SECURITYFOCUS COM>
Sent: Tuesday, February 20, 2001 6:56 PM
Subject: Re: Bind compromise


: 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