Nmap Development mailing list archives
Re: sslstrip -sV false positives
From: jah <jah () zadkiel plus com>
Date: Sun, 10 May 2015 13:43:04 +0100
Hi List, On 24/03/14 20:35, Ron wrote:
I've been seeing a lot of 'sslstrip' false positives as well. I think we should find a better way to do the signature, or disable it. Ron On 2014-03-24 16:18, Jacek Wielemborek wrote:Hi, Today _ynk on IRC reported that the Nmap 6.40 recognized his home router's HTTP port as sslstrip. Bonsaiviking pointed out that the patterns for sslstrip is quite likely to produce false positives. Here's what the patterns look like: match http-proxy m|^HTTP/1\.1 400 Bad Request\r\n\r\n$| p/sslstrip/ match http-proxy m|^HTTP/1\.0 200 OK\r\n\r\n$| p/sslstrip/ Perhaps we should change the product name to 'sslstrip?' to suggest that it's not exactly reliable? I couldn't get a fingerprint, but here's debug log of the probing: Starting probes against new service: 192.168.1.10:80 (tcp) Service scan sending probe NULL to 192.168.1.10:80 (tcp) Service scan sending probe GetRequest to 192.168.1.10:80 (tcp) Stats: 0:00:06 elapsed; 0 hosts completed (1 up), 1 undergoing Service Scan Service scan Timing: About 0.00% done Service scan sending probe HTTPOptions to 192.168.1.10:80 (tcp) Service scan sending probe RTSPRequest to 192.168.1.10:80 (tcp) Service scan sending probe X11Probe to 192.168.1.10:80 (tcp) Service scan sending probe FourOhFourRequest to 192.168.1.10:80 (tcp) Service scan sending probe GenericLines to 192.168.1.10:80 (tcp) Service scan match (Probe GenericLines matched with GenericLines line 4615): 192.168.1.10:80 is http-proxy. Version: |sslstrip||| Completed Service scan at 17:01, 24.26s elapsed (1 service on 1 host) NSE: Script scanning 192.168.1.10. NSE: Starting runlevel 1 (of 1) scan. NSE: Starting 'skypev2-version' (thread: 0x1bffac0) against 192.168.1.10:80. Initiating NSE at 17:01 NSE: TCP 192.168.1.15:40556 > 192.168.1.10:80 | CONNECT NSE: TCP 192.168.1.15:40556 > 192.168.1.10:80 | 00000000: 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 30 0d 0a GET / HTTP/1.0 00000010: 0d 0a NSE: TCP 192.168.1.15:40556 > 192.168.1.10:80 | SEND NSE: TCP 192.168.1.15:40556 < 192.168.1.10:80 | 00000000: 48 54 54 50 2f 31 2e 31 20 34 30 30 20 42 61 64 HTTP/1.1 400 Bad 00000010: 20 52 65 71 75 65 73 74 0d 0a 0d 0a Request NSE: TCP 192.168.1.15:40556 > 192.168.1.10:80 | CLOSE NSE: Finished 'skypev2-version' (thread: 0x1bffac0) against 192.168.1.10:80. Completed NSE at 17:01, 0.01s elapsed Yours, Jacek Wielemborek
The attached patch makes the following match line in the GenericLines probe ( |\r\n\r\n| ) section a softmatch:- match http-proxy m|^HTTP/1\.1 400 Bad Request\r\n\r\n$| p/sslstrip/ This pattern is too broad: it prevents, for example, matching TwistedWeb httpd with the GetRequest probe and it may be preventing a number of other matches. There might be a case for removing this line entirely, especially if, as a softmatch, it still matches lots of otherwise unknown services, i.e. acts like a catch-all. I think it sensible to give the line a chance as a softmatch before deciding to remove it. I haven't personally had any problem with the other line Jacek mentioned so the patch doesn't alter it: match http-proxy m|^HTTP/1\.0 200 OK\r\n\r\n$| p/sslstrip/ This also seems broad and may be one to watch. jah
Attachment:
sslstrip-softmatch.patch
Description:
_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: sslstrip -sV false positives jah (May 10)