[217] in Best-of-Security
BoS: Re: getting passwd file via WWW
daemon@ATHENA.MIT.EDU (Douglas C. Merrill)
Thu Jun 5 15:10:49 1997
Date: Thu, 05 Jun 1997 08:37:25 -0700
From: "Douglas C. Merrill" <drdcm@ix.netcom.com>
In-Reply-To: <199706041913.PAA02113@SPARKY.CF.CS.YALE.EDU>
Errors-To: best-of-security-request@suburbia.net
To: best-of-security@suburbia.net
Resent-From: best-of-security@suburbia.net
At 03:13 PM 6/4/97 -0400, long-morrow@CS.YALE.EDU wrote (in response to
Stan Wnuck <swnuck@unixpros.com>)
>>Or how dangerous this is?
>
>Very. If you have a standard Unix /etc/passwd file with readable
>password hashes (ie. you don't have a 'shadow' password file) then
>Crack can be run on the text of the password file.
For completeness, if the system has a shadow password file, then the
password entries are only readable by root. But with what privileges is
the WWW server running?
Unfortunately, often WWW servers are run with root privileges because of
the need to bind to port 80 (a privileged port). However, this means that
a simple exploit like the one reported here using the phf bug gains even
more power.
In this particular case, if the WWW server is running as root, the phf bug
allows an attacker to read the shadow password file and attempt an off-line
crack on it. Shadow password files do not offer protection against
attackers who have managed to get illicit privileges already (such as by
convincing a SUID program to run something for them).
Of course, if the WWW server is running with privileges, the attacker could
(just as easily) have *added* an account to your system. This account
would probably have root privileges and a known password. If you don't
check your accounts adequately, you may not notice this. (Also be aware of
traditional back-door tricks like moving the colons in the password
entries, etc.).
>>.............................................., since I am not sure what
>>my next move would be.
The first thing to do is to get a copy of the CIAC post-intrusion clean up
list. It contains really good guidelines for figuring out what to do after
a break-in.
Another really good idea might be to take one of the vendor's classes in
computer security (there are a lot out there).
And, if your WWW server (or your SMTP server, etc) are running with root
privileges -- CHANGE THIS NOW! (They only need privileges to *bind* to the
relevant ports, not to operate).
>8. Run COPS (an internal Unix audit tool) on the server machine.
COPS is really out of date (no offense, Dan, if you're reading this). ISS
is much better, but costs $. TIGER (from Texas A&M) is free, and pretty good.
>Send a copy of your security incident
> report to CERT, Postmaster@some.remote.location.edu, and any other
> relevant body (ie. if your site is military-related there will be
> a different agency than CERT to which you should report incidents).
Please be aware that there may be legal issues involved here. Before
sending off information to postmaster@some.remote.location.edu, you should
check with your corporate counsel, etc. Most of the time, postmaster is a
"good guy" - however, that account may have been compromised. Also, there
are sites that have not dealt well with "Hey, you attacked me" messages,
and have gotten the lawyers involved in a not-very-pleasant manner.
Probably not an issue here, but IMHO it's not worth the risk. Talk to your
lawyer first, and have a clear policy about what you are going to do and why.
The process of figuring out what to do after an attack should, in the
Best-Of-All-Possible-Worlds, be done well before an attack. Your
organization might want to secure the system at all costs, immediately
(which is the approach in long-morrow's response), or might want to
consider criminal prosecution (which would require different actions).
In any case, a clear paper trail of YOUR actions is really critical here.
Spaf's book talks a great deal about cleaning-up -- well worth a read.
>Consider installing a firewall
> or at least a screening router in between your Web server and the
> Internet.
Of course, the best firewall in the world would not have prevented this
attack. Also, the particular topology of the network depends on the
organization's needs (e.g., it is easy to imagine having the WWW server in
a DMZ *outside* of the firewall, etc). Firewalls are only *part* of a
network protection system.
Cheers, and good luck with the clean-up,
Douglas Merrill
----
Dr. Douglas C. Merrill
drdcm@ix.netcom.com
According to sendmail, I am no Wizard...
