Security Incidents mailing list archives

Re: FYI: Bind compromise


From: Jim Olsen <jim () CYBERJUNKEES COM>
Date: Wed, 21 Feb 2001 09:02:08 -0500

On Tuesday 20 February 2001 20:53, gabriel rosenkoetter wrote:
Woah, there. Did you really mean 8.2.3? Or 8.2.2-P<something>?

If the former, then lots of folks are in trouble, since the ISC
still thinks that version is secure. (Granted, everything I admin is
9.1.1rc1, but some servers I trust are running 8.2.3, so I'd rather
not hear it's got problems, since it means pestering those admins to
upgrade to BIND9, which they were none too eager to do the last time
around.)

named as of right now reports this:
[root@ns4 .nis01]# named -v
named 8.2.3-REL Sat Jan 27 05:32:51 EST 2001
        prospector () porky devel redhat com:/usr/src/bs/BUILD/bind-8.2.3/src/bin/named

Okay, you really did mean this. 8.2.3-REL, last I heard, was
supposed to be safe. If the rootkit installed upgraded your 8.2.2-P
or 8.2.3-beta version to 8.2.3, that's another story, but if there's
a working exploit of 8.2.3, that's bad news, and somebody needs to
get the ISC to update their web page
(http://www.isc.org/products/BIND/bind-security.html).

I had not considered the fact that the attacker would upgrade the version of
named to 8.2.3 -- this is probably the case. I kept no change-log for this
server, so I do not know what version was running before the compromise,
unfortunately. Checking rpm:

[root@ns4 .nis01]# rpm -qa | grep -i bind
bind-utils-8.2.2_P5-9
ypbind-3.3-28
bind-devel-8.2.2_P5-9
bind-8.2.3-0.6.x

So it looks like this box was running 8.2.2-P5-9 before hand. Also,
considering the fact that I have not logged into this box for at least 3 to 4
months tells me that I definitely did not upgrade the daemon on this box.
Sorry for the poor research on that part, yesterday was a very busy day for
me (isn't every day a busy day for a sysadmin?).

Without further confirmation, I'd say you should check which version
of ssh you're running and go read up on the Bugtraq traffic
regarding it over the past week. (Short story, sshd1 from SSH.com
is not safe under any version, and using any client to connect to
an unknown sshd using protocol 1.5 is a security risk.)

ssh version:
[root@ns4 .nis01]# rpm -qa | grep -i ssh
ssh-1.2.27-5i
ssh-clients-1.2.27-5i
ssh-extras-1.2.27-5i
ssh-server-1.2.27-5i
[root@ns4 .nis01]# ssh -V
SSH Version 1.2.27 [i586-unknown-linux], protocol version 1.5.
Standard version.  Does not use RSAREF.

This box only runs named and sshd - nothing more. I have't logged into this
box in a long while (4-6 months?), so i'm not sure if this vuln. in ssh can
be exploited if you don't connect. If we take ssh out of the picture because
of that, then I'm pretty sure it was named that was compromised because I
manage quite a few boxes at this colo facility, all of which are running
linux, and this is the only box to have been compromised.  Some of the boxes
I had already upgraded to bind 9.1.1rc2, others were not running bind at all
- none of these boxes were compromised.  I also received this email from tech
support staff for my colo provider:

==
Wanted to let you know that we had a ton of customer Cobalt Linux
servers and other various customer Linux servers hacked this weekend due
to a vulnerability in BIND.  Please make sure that your servers are up
to speed as far as patches go and check to make sure that no one has
tried to gain unauthorized access to your Linux boxes.
==

This is why I assumed my compromise was related to a vuln. in bind, although
I must now say that it is more-than-likely a 8.2.2-P5 exploit rather than a
8.2.3-REL

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.

I do hope you mean 9.1.1rc1. (9.1.0 is DoS-able.)

details, details, details ;-)  actually, I meant 9.1.1rc2. this email was
typed in a rather hurried fashion - sorry for the missed details.

--
Jim Olsen
Systems Administrator


Current thread: