HCSW Technical Blog

HCSW Technical Blog


Doug Hoyte

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

19. The Quarterly Marathon
Tue, Jul 25 2006

Well, I just finished another version detection fingerprint integration marathon! Big up to Google's Summer Of Code for providing funding for me to work on this and other Nmap related projects.

I hope you enjoy the following notes.


Ouch. We still don't have a proper solution for this service and it shows in the quantity of skype 2.0 fingerprints. I'd like to thank Brandon Enright for his hard work and good ideas on the subject.

After putting a little bit of thought into it, I recognise that there are various hacks we could put in place that would probably work reasonably well. What's bothersome is that there doesn't seem to be some sort of better solution like, for instance, a new Skype probe. One of Brandon's suggestions is to measure the entropy of the results to attempt to figure out if they are randomly generated like the skype results seem to be (More likely, they are the output of some cryptographic algorithm). This could work but we might get the occasional false positive. And what happens when another application that uses similar protocol obfuscation becomes popular? I think the key to fingerprinting skype is recognising that its response to the GetRequest is the following (extremely general) fingerprint:

"HTTP/1\.0 404 Not Found\r\n\r\n"

but that the results to any other query are the above-mentioned constantly changing binary sequences. If we could bend version detection to have match lines depending on the results of 2 or more different probes then we could probably nail skype down quite easily. This is a design possibilty we are currently considering.

Apparently in certain systems' line printer daemons there is an option to restrict connections based on the source port of a connection. This is the first instance I've seen (but, sadly, I suspect not the last) of Nmap's source port affecting the result of version detection. Here is the (sanitised for privacy) fingerprint:

Port 515-TCP
---------- NULL ----------
"lpd \[@some.hostname\]: connected from invalid port \(51116\)\n"

---------- GetRequest ----------
"lpd \[@some.hostname\]: connected from invalid port \(51118\)\n"

---------- Help ----------
"lpd \[@some.hostname\]: connected from invalid port \(51119\)\n"

---------- LPDString ----------
"lpd \[@some.hostname\]: connected from invalid port \(51125\)\n"

And its new match line:

match printer m|^lpd \[@([\w-_.]+)\]: connected from invalid port \(\d+\)\n| p|BSD/Linux lpd| h|$1| i|source port denied|

Remember, protocol designers, that while depending on source port values as an authentication technique may keep out the lamest of script kiddies, it is completely vulnerable to anyone who knows how to read the bind(2) manpage.

Also see this blog entry of mine.

As Fyodor and I discussed in this thread, these types of "ISP blocked outbound port 25" situations are becoming more common:

match smtp m|^554 Please check that your outgoing mail server settings are correct\. Contact your service provider's technical support for assistance\.\n| i/Wanadoo blocks smtp - NOT A REAL smtpd!/

In a similar vein, I am comforted by the fact that at least one other person out there finds discoveries like these fasincating:

Notes: This fascinating signature is a result of performing nmap through a Cisco router (yes, with permission and at my own company) that supports Cisco's Application and Content Networking Software (http://www.cisco.com/en/US/products/sw/conntsw/ps491/index.html). This software is a sort of web cache proxy that resides on the routers. If the remote end does _not_ have the http port (80) open, then the router responds with this HTTP response.

The fingerprint, which I agree is very interesting, resulted in the following match line:

match http-proxy m|^HTTP/1\.0 200 OK\r\nCache-Control: no-store\r\nPragma: no-cache\r\nCache-Control: no-cache\r\nX-Bypass-Cache: Application and Content Networking System Software ([\d.]+)\r\n| p/Cisco ACNS outbound proxying/ v/$1/ i/**PROXIED**/

In theory, having lots of service submissions for various services helps us match services more specifically. Sometimes we are able to, after seeing many examples, make match lines more specific by discovering small differences between fingerprints. A good example of this is the APC PowerChute power device. The old Nmap match line was:

match powerchute m|^RTSP/1\.0 400 Bad request\r\nContent-type: text/html\r\n\r\n| p/APC PowerChute Agent/ d/power-device/

But, thanks to some submissions this quarter, we've branched it into these:

match powerchute m|^RTSP/1\.0 400 Bad request\r\nContent-type: text/html\r\n\r\n| p/APC PowerChute Agent/ v/6.X/ d/power-device/
match powerchute m|^RTSP/1\.0 400 Bad request\nContent-type: text/html\n\n| p/APC PowerChute Agent/ v/7.X/ d/power-device/

Another similar situation arises when specific versions of an application have identifiable bugs in them. For instance, take DJ Bernstein's qmail. I found the following in the archives of a qmail mailing list:

qmail-smtpd-auth-0.31 has a minor bug if you use morercpthosts. After a failed authentication attempt, if the client attempts to send mail to a domain which is not listed in rcpthosts, qmail-smtpd is unable to read morercpthosts.cdb. Instead, it sends "421 unable to read controls (#4.3.0)"

This is nice because we now can make a qmail match line like so:

match smtp m|^421 unable to read controls \(#4\.3\.0\)\r\n| p/Qmail smtpd/ i/qmail-smtpd-auth 0.31/ o/Unix/

I really appreciate getting submissions like the following that assure me people out there are getting valuable use out of service detection:

Notes: This is a banner from a backdoor trojan. I use Nmap for compromised host detection as I think a lot of others do. It would be nice if this could be included with some sort of note about malware.

Apparently this trojan spits out something like this upon connect:

"A-311 Death welcome\x001\.87"

so we now have the following (which I hope isn't too specific):

match backdoor m|^A-311 Death welcome\x001\.87| i/**BACKDOOR**/ o/Windows/

And now for the traditional gallery of funny or otherwise noteworthy submissions:

  • Postfix's response to GetRequest:
    "220 smtpd\r\n221 2\.7\.0 Error: I can break rules, too\. Goodbye\.\r\n"
  • Canon Pixma IP4000R Printer http config
    "Last-Modified: Sun, -24797 Jan 1970 -16:-1:-48 GMT\r\n"
  • Browser Sux Err0rzzz!!1!11
    "HTTP/1\.1 601 Browser Sux Error\r\nDate: Thu, 15 Jun 2006 11:43:34 GMT\r\nServer: \.V04 Apache/1\.3\.26 \(Unix\) mod_fs 6\.005\r\nFilter-Revision: 1\.206\r\n"
  • Freenet's response to the Help probe:
    "HTTP/1\.1 400 Parse error: Could not parse request line \(split\.length=1\): HELP\r\n"

I got a submission for a SpamAssassin spamd service. From the comments:

Notes: I'm not sure why you don't recognize this. There is nothing special about this service. It was auto-installed by CPAN.

Try upgrading from 3.75 :)

All material is (C) Doug Hoyte and/or hcsw.org unless otherwise noted or implied. All rights reserved.