Nmap Development mailing list archives

Re: [NSE Script] HTTP probe for /etc/passwd


From: Brandon Enright <bmenrigh () ucsd edu>
Date: Sat, 21 Jul 2007 18:15:03 +0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 20 Jul 2007 23:12:49 -0500 plus or minus some time Kris Katterjohn
<katterjohn () gmail com> wrote:

Thanks for the advice!  And please test the new one out (attached) and 
let me know if you have problems (or if you see anything else wrong with 
this new one)

I added a few of your ideas, and separated it into functions.  It's 
really easy to add any other ideas now.

I like the way you've gone about adding multiple probes, the design stays
pretty clean.

Thanks again,
Kris Katterjohn

I ran the new copy of the script against about 20k hosts on 80, 8000, and
8080.  The scan turned up two results, one a false positive and the other
worked on the simple '/etc/passwd' request.  Here is the output from the
false positive:

80/tcp   open   http
|_ HTTP /etc/passwd probe: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitio nal//EN"><html><head><title>IT Temperature Monitor: [blocked] Temp
Monitor</title> <meta http-equiv="REFRESH"
content="60;url=index.html"></head><body bgcolor="#C0 C0C0" text="#000000"
vlink="#800080" link="#0000FF"><table border=2 cellpadding=
2><tbody><tr><td align=center><table cellpadding=2 cellspacing=0
2>border=1><TR><T
D>Model:</TD>...[snip]...

This output matched because it is all one line and has a few ':'s in it.
To fix this, I had to strengthen the regex to hopefully match /etc/passwd
output better:

if string.match(line, "^[^:]+:[^:]*:[0-9]+:[0-9]+:") then

Notice now that I force a user and group to be set in fields 3 and 4.  I
*think* pretty much every Unix/Linux uses the same /etc/password format
regardless of shadowing and that this should still match.  Someone with
more Unix wisdom should chime in on this though.

The real /etc/password output looked like this:

80/tcp   open   http
|  HTTP /etc/passwd probe: root::0:0:root:/root:/bin/bash
|  bin:*:1:1:bin:/bin:/sbin/nologin
|  daemon:*:2:2:daemon:/sbin:/sbin/nologin
|  adm:*:3:4:adm:/var/adm:/sbin/nologin
|  lp:*:4:7:lp:/var/spool/lpd:/sbin/nologin
|  sync:*:5:0:sync:/sbin:/bin/sync
|  shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown
|  halt:*:7:0:halt:/sbin:/sbin/halt
|  mail:*:8:12:mail:/var/spool/mail:/sbin/nologin
|  news:*:9:13:news:/etc/news:
|  uucp:*:10:14:uucp:/var/spool/uucp:/sbin/nologin
|  operator:*:11:0:operator:/root:/sbin/nologin
|  games:*:12:100:games:/usr/games:/sbin/nologin
|  gopher:*:13:30:gopher:/var/gopher:/sbin/nologin
|  ftp:*:14:50:FTP User:/var/ftp:/sbin/nologin
|_ nobody:*:99:99:Nobody:/:/sbin/nologin


My only gripe here is that the contents of the file start on the same line
as the name of the script.  You should probably throw a newline in there
somewhere so that /etc/password output doesn't get mixed up with the name.

Also, with the name "HTTP /etc/passwd probe", one might assume that the
only request it made was for '/etc/passwd'.  You might consider changing
the name to "HTTP Directory Transversal '/etc/passwd' check".  This is a
matter of taste though.

Finally, one of the most common services *not* to match any service
fingerprint are all the odd HTTP servers we have running around here.  Your
portrule looks for 80, 8000, or "http".  If we have some strange HTTP
server running on 1234 this script wont run.  I think the most likely
candidates for these types of directory transversal problems are all those
non-standard, poorly implemented HTTP servers that don't match a
fingerprint.  One idea is to add "unknown" services to the portrule and then
in the first probe ('/etc/passwd') if you don't get a HTTP response back
short-circuit and return immediately.  This is no worse than if Nmap had
sent an additional service probe during the -sV scan.

Thanks again for this script!

Brandon


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGok0nqaGPzAsl94IRAt6TAJ9zniZbPrCHoh4pJRFT/QIZxnbNjQCgwUzj
zUjA1BGqrzzbT/HG9mx//Os=
=kGN3
-----END PGP SIGNATURE-----

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


Current thread: