HCSW Technical Blog

HCSW Technical Blog


Doug Hoyte

Viewing entries 20 through 20.
Most Recent Blog Entries
RSS Feed

20. Q3 2006 Version Detection Notes
Wed, Dec 13 2006

I've finally been able to set aside a few days to go over the fingerprints the Nmap community submitted in the 3rd quarter of 2006.

As always, there was an amazing diversity in the network protocols and applications. I suspect anyone interested in the unexpected ways pieces of code behave when probed strangely will find some cool tidbits in the following observations.

Of course, all of the credit goes to the (mostly unrecognised) Nmap community members who contribute the fingerprints. Thanks, everybody. Keep em coming!

Possibly the largest improvement to the probes file this quarter is my addition of a couple new probes that test the state of connectivity/security of SOCKS 5 and SOCKS 4 servers. Although the SOCKS protocol doesn't provide any way to map the versions of the servers, we can still find some useful information.

These probes are intended to complement Marek Majkowski's excellent "General Scanning Engine" for Nmap which, among other things, allows one to port-scan and version scan through SOCKS proxies.

Probably the easiest way to explain the probes is to just show them and their match lines:

############ SOCKS PROBES ############

# These are some simple probes that query a SOCKS server as specified in the
# following RFCs/documents:
# SOCKS4.Protocol - SOCKS Protocol Version 4
# RFC 1928 - SOCKS Protocol Version 5
# RFC 1929 - Username/Password Authentication for SOCKS V5
# RFC 1961 - GSS-API Authentication Method for SOCKS Version 5

# The following probe is designed to check the status of a SOCKS5 implementation.
# It attempts to create a TCP connection to google.com:80 assuming the SOCKS server
# allows unauthenticated connections. The probe also tells the SOCKS server
# that we support all major types of authentication so we can determine which
# authentication method the server requires.
# We don't try to establish TCP port bindings on the SOCKS server and we don't
# try UDP connections though these could easily be added to new probes.

Probe TCP Socks5 q|\x05\x04\x00\x01\x02\x80\x05\x01\x00\x03\x0agoogle.com\x00\x50GET / HTTP/1.0\r\n\r\n|
rarity 8
ports 199,1080,1090,1095,1100,1105,1109,3128,6588,6660-6669,8000,8008,8080,8088

match socks5 m|^\x05\0\x05\0\0\x01.{6}HTTP|s i/No authentication; connection ok/
match socks5 m|^\x05\0\x05\x01| i/No authentication; general failure/
match socks5 m|^\x05\0\x05\x02| i/No authentication; connection not allowed by ruleset/
match socks5 m|^\x05\0\x05\x03| i/No authentication; network unreachable/
match socks5 m|^\x05\0\x05\x04| i/No authentication; host unreachable/
match socks5 m|^\x05\0\x05\x05| i/No authentication; connection refused by destination host/
match socks5 m|^\x05\0\x05\x06| i/No authentication; TTL expired/
match socks5 m|^\x05\0\x05\x07| i|No authentication; command not supported/protocol error|
match socks5 m|^\x05\0\x05\x08| i/No authentication; address type not supported/

match socks5 m|^\x05\x01| i/GSSAPI authentication required/
match socks5 m|^\x05\x02| i|Username/password authentication required|
# would like to see this in a fingerprint
#match socks5 m|^\x05\x80| i/Unknown authentication required/

# The following probe is designed to check the status of a SOCKS4 implementation.
# It attempts to create a TCP connection to We supply a username root
# in the user id string field. We don't try to establish TCP port bindings on
# the SOCKS server though this could easily be added to a new probe.

Probe TCP Socks4 q|\x04\x01\x00\x16\x7f\x00\x00\x01root\x00|
rarity 8
ports 199,1080,1090,1095,1100,1105,1109,3128,6588,6660-6669,8000,8008,8080,8088

match socks4 m|^\0\x5a| p/Connection ok/
match socks4 m|^\0\x5b| p/Connection rejected or failed; connections possibly ok/
match socks4 m|^\0\x5c| p/Connection failed; ident required/
match socks4 m|^\0\x5d| p/Connection failed; username required/

As a native english speaker, it's easy for me to take for granted the fact that the vast majority of software development and documentation is done in the english language. Sometimes, however, I run across some programs that purely target a non-english speaking language. Here are some cool examples this quarter:

A russian win32 web cache: HandyCache. The interface is completely in cyrillic and if it wasn't for google translation tools I wouldn't know anything about it at all! Sure enough, this fingerprint was submitted by a russian:

match http-proxy m|^HTTP/1\.0 407 Proxy Authentication Required\r\nServer: HandyCache\r\n| p/HandyCache http caching proxy/ i/Russian/ o/Windows/

Another example is the polish Gadu-Gadu instant messenger protocol and some of the interesting (and completely polish) opensource projects like Ruchomy Terminal Gadu-Gadu http interface related to it.

match http m|^HTTP/1\.0 \d\d\d .*\r\nDate: .*\r\nServer: GG/([\d.]+) \(Unix\) Debian GNU/Linux\r\nWWW-Authenticate: Basic realm=\"gg zone\"\r\n| p/Ruchomy Terminal Gadu-Gadu http interface/ v/$1/ i/Debian/ o/Linux/

Sometimes when looking at the fingerprints it's obvious why we didn't find a match but unfortunatley, there's not much we can do. Take this example:

Port 37-TCP
---------- NULL ----------

This is obviously a time service running on a machine with its clock set terribly wrong. See this blog post for info on how Nmap handles the time service.

Another rarely deployed, mariginally effective authentication technique:

match hylafax m|^130 Warning, no inverse address mapping for client host name \"[\w-_.]+\"\.\r\n220 ([\w-_.]+) server \(HylaFAX \(tm\) Version ([\d.]+)\) ready\.\r\n| p/HylaFAX/ i/Reverse DNS unauthorized/ h/$1/ v/$2/

Also see the 2nd note about source ports in this blog entry.

I'm a huge proponent and frequent user of EFF's Tor. I added a tor match line thanks to a number of useful submissions. This should, for better or for worse, make it quick and easy to identify a tor node. We even pick out the Tor node name.

match tor m|^\x16\x03\0\0\*\x02\0\0&\x03\0D.*TOR1.*[\x00-\x20]([\w-_.]+) |s p/Tor node/ i/Node name: $1/

Usually it's not quite this easy to find a default password:

match http m|^HTTP/1\.1 401 \r\nServer: PrintSir WEBPORT ([\d.]+)\r\nDate: .*\r\nWWW-Authenticate: Basic realm=\"Default password:1234\"\r\n\r\n401 Unauthorized - User authentication is required\.| p/Hawking HP1SU Printserver http config/ i/PrintSir WEBPORT $1; Default password 1234/ d/print server/

Dovecot is a very well written IMAP/POP3 server. Here is its response to SMBProgNeg:

--------- SMBProgNeg ----------
"\* OK dovecot MUA ready\r\n BAD Invalid characters in atom\r\n"

And the corresponding code from dovecot:

static int is_valid_atom_char(struct imap_parser *parser, char chr)
        if (IS_ATOM_SPECIAL((unsigned char)chr)) {
                parser->error = "Invalid characters in atom";
                return FALSE;
        } else if ((chr & 0x80) != 0) {
                parser->error = "8bit data in atom";
                return FALSE;

        return TRUE;

A couple FTP misconfigurations:

match ftp m|^Error loading /etc/ssl/certs/ftpd\.pem:| p/Linux NetKit ftpd/ i/misconfigured/ o/Linux/

match ftp m|^500 OOPS: cannot locate user entry:([\w-_]+)\r\n500 OOPS: child died\r\n| p/vsftpd/ i/misconfigured; ftp user $1/

And a more sensible configuration (although it seems to imply that non-SSL connections could be used on the data channels):

match ftp m|^220[ -].*\r\n550 SSL/TLS required on the control channel\r\n|s p/ProFTPd/ i/requires SSL/

The FourOhFourRequest probe we recently added is turning out to be very useful much in the way I hoped it would! The more angles you look at an application and the more funny ways you probe it the more likely you are to find strange application peculiarities that help with service scanning. This is the newly added probe:

Probe TCP FourOhFourRequest q|GET /nice%20ports%2C/Tri%6Eity.txt%2ebak HTTP/1.0\r\n\r\n|

Here is a great example of the FourOhFourRequest giving information when none of the other HTTP probes turn out very useful. This Allnet switch has very generic, hard to distinguish reponses to the usual GetRequest/HTTPOptions probes but gives up lots of great information in a 404 response - including its hostname and MAC address!

match http m|^<html>\n<link rel=stylesheet href=form\.css>\n<body onload='document\.login\.passwd\.focus\(\)'>\n<form name=login method=POST>\n.*System Name   : ([^\r\n]+)\n.*Location Name : ([^\r\n]+)\n.*MAC Address    : ([\w-]+)\n\n|s p/Allnet 16-Port 1000Base-T switch http config/ d/switch/ i|$1@$2; MAC $3|

And some httpds, like LANDesk/Intel Management Agent, don't handle the strange request well at all:

---------- GetRequest ----------
"HTTP/1\.1 200 OK\r\nServer: LANDesk Management Agent/1\.0\r\n..."

---------- FourOhFourRequest ----------
"HTTP/1\.1 500 Internal Server Error\r\nServer: LANDesk Management Agent/1\.0\r\n..."

And, of course, the gallery of funny or otherwise noteworthy fingerprints:

  • Mathopd speaks HTTP/0.0!
    ---------- HTTPOptions ----------
    "HTTP/0\.0 501 Not Implemented\r\nServer: Mathopd/1\.1\r\n"
  • Serpento dictd isn't as proof-read as one might hope of a dictionary program:
    ---------- GenericLines ----------
    "220 hello <> msg\r\n500 I'd be be damned if I knew what you want\r\n500 I'd be be damned if I knew what you want\r\n"
  • RICOH Aficio AP4510 printer's rshd:
    match login m|^\[Thread \d+\(INITIAL\)\] at 0x\w+: Segmentation fault \(Stack bottom 0x0\)\n| p|Aficio/NRG/Ricoh printer logind| d/printer/
  • I wonder if this SESSIONID causes any problems:
    match http m|^HTTP/1\.0 \d\d\d .*\r\nSet-Cookie: SESSIONID=-1 \r\nServer: Easy File Sharing Web Server v([\w.]+)\r\n| p/Easy File Sharing Web Server httpd/ v/$1/ o/Windows/
  • HP uses CVS.
    match http m|^HTTP/1\.0 \d\d\d .*\r\nServer: \$ProjectRevision: ([\d-.]+) \$\r\n.*<title>HP Color LaserJet 2600n</title>|s p/HP Color LaserJet 2600n http config/ v/$1/ d/printer/
  • Panasonic BL-C10 webcam's response to GenericLines:
    match http m|^HTTP/1\.0 -1 Internal Server Error\r\n\r\n| p/Panasonic BL-C10 webcam http config/ d/webcam/
All material is (C) Doug Hoyte and/or hcsw.org unless otherwise noted or implied. All rights reserved.