Nmap Development mailing list archives

Previous By Date Next
Previous By Thread Next

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

From: "Kris Katterjohn" <katterjohn () gmail com>
Date: Sat, 21 Jul 2007 23:11:40 -0500
On 7/21/07, Brandon Enright <bmenrigh () ucsd edu> wrote:


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.




Okay, I like that.  I've tried multiple Unices (or however it's said), and
that's the only format I've seen for it.  I'm not at my Linux box right now,
but I will be tomorrow and unless anybody objects, I'll add that match line.


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.



Yeah, it happened when I was grabbing the first line of the passwd file to
check it for validity. I was stripping the HTTP header and the "\r\n\r", and
printed the last "\n" with the passwd file, but when I started adding the
checks, I was lazy and didn't add an extra "\n" in the output.

Actually, my thought process was kinda complicated because of the different
ways I could go about doing that (and grabbing the first line), but laziness
won, as usual :)

I'll fix that tomorrow

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.



Yeah, or just "HTTP directory traversal passwd check" since it could be
"\etc\passwd" :P


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.




That's a good point.  I didn't think it through, I just left it as-is from
the HTTPAuth.nse because at first I thought it was good enough.


Thanks again for this script!


Brandon




Sorry about the whole SMTP problem, I wish I got this sooner ;)

Thanks a lot,
Kris Katterjohn

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

Current thread: