Re: Bind compromise

[Ryan Sweat <h3xm3 () SWBELL NET>]

     Looks like you have a modified version of tornkit installed.  Tornkit
calls its precompiled sshd with -q and loads it from /etc/rc.d/rc.sysinit.
Also check /usr/src/.puta/.1* for the strings to hide from ls,ps and
netstat. I seriously doubt you have bind 8.2.3 running, but I do believe its
likely that the person who cracked your box upgraded it to 8.2.3 to protect
his investment.

 /rs

----- Original Message -----
From: "Jim Olsen" <jim () BROWSERMEDIA COM>
To: <INCIDENTS () SECURITYFOCUS COM>
Sent: Tuesday, February 20, 2001 12:22 PM
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