Nmap Development mailing list archives
Re: bizarre false positive (?) in service detection
From: "DePriest, Jason R." <jrdepriest () gmail com>
Date: Thu, 12 Apr 2007 23:58:20 -0500
I'll double check the stuff from the port tomorrow. I was able to telnet to the port and run some rudimentary mail commands. EHLO gives me a list of features (2 whole features) I can set a MAIL TO: but I don't know a valid RCPT FROM: for the printer. So, the port really is SMTP and not Skype -Jason On 4/12/07, Brandon Enright wrote:
On Thu, 12 Apr 2007 18:06:50 -0500 "DePriest, Jason R." wrote:I'm attaching the debug output as explained on http://insecure.org/nmap/vscan/vscan-community.html#vscan-submit-corrections I don't see in the information where it determines what is running on the port, but then again, I don't know how to read the nitty gritty details of the capture information either. IP addresses have been sanitized and replaced with <BIGWORDSINBRACES> -JasonFrom the service probes file: # Skype - Protocol seems to spew out 14 random characters upon # connection. Luckily, this shouldn't conflict any other X11 services. match skype m|^.{14}$|s p/Skype VoIP data channel/ Either the service you are scanning really is Skype (not Skype v2) or you have a service that returns exactly 14 bytes. I haven't looked very closely at Skype v1 but if the data being returned really is random enough that a regular language can't match it without overmatching there is little that can be done to improve the check. One idea would be to use a NSE script like what we did with Skype v2. The logic would be something like "if we receive exactly 14 bytes and it looks fairly random" say it is Skype. The "if it looks fairly random" was done in the v2 script with this line: if string.match(result, "[^%s!-~].*[^%s!-~].*[^%s!-~].*[^%s!-~]") then Basically this regex requires at least 4 non-typeable bytes. This would improve the Skype v1 match some but certainly wouldn't eliminate false-positives (and would add rare false negatives). Real knowledge of the Skype v1 protocol would be needed to improve the check much further. If you comment out the out the match skype line in your nmap-service-probes file you should start getting a fingerprint. Run Nmap against the service several times. If you can discern a pattern in the output (or if it is the same every time) or if you can illicit different (interesting) response for different probes we can write a pattern match for your service that will take precedence over the Skype match. Brandon -- Brandon Enright Network Security Analyst UCSD ACS/Network Operations bmenrigh () ucsd edu
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- bizarre false positive (?) in service detection DePriest, Jason R. (Apr 12)
- Re: bizarre false positive (?) in service detection DePriest, Jason R. (Apr 12)
- Re: bizarre false positive (?) in service detection Brandon Enright (Apr 12)
- Re: bizarre false positive (?) in service detection DePriest, Jason R. (Apr 12)
- Re: bizarre false positive (?) in service detection DePriest, Jason R. (Apr 13)
- Re: bizarre false positive (?) in service detection Brandon Enright (Apr 13)
- Re: bizarre false positive (?) in service detection DePriest, Jason R. (Apr 13)
- Re: bizarre false positive (?) in service detection Brandon Enright (Apr 13)
- Re: bizarre false positive (?) in service detection doug (Apr 13)
- Re: bizarre false positive (?) in service detection Brandon Enright (Apr 12)
- Re: bizarre false positive (?) in service detection DePriest, Jason R. (Apr 12)