Open drwetter opened 5 years ago
$hostname ones are from the 'hostfiles' plugin, which does scan by IP intentionally. This plugin came about because I found a site which had a tgz of the site available via the IP but not via the name. My SOP is to run against both if I have time (which I don't always).
You should be able to disable this (to verify) by doing:
-Plugins "@@DEFAULT;-sitefiles"
@drwetter I'm not sure about the other situation--it is possibly due to SNI if you are using that, as I am unable to confirm but I do not have an SNI site handy.
I've dug into the code of LW and the SSL modules and didn't come back with a clear understanding of where/how SNI support may be lacking. So, if this is a public site that I can test against please email me and maybe we can do some testing.
$hostname ones are from the 'hostfiles' plugin, which does scan by IP intentionally.
Thanks. That part sounds reasonable to me. I was more thinking on the cgi paths (15/Nov/2018:09:48:34
--> 15/Nov/2018:09:48:36
). Especially if those end up on the default host and not on the hostname provided. That could lead to false negatives.
@drwetter I'm not sure about the other situation--it is possibly due to SNI if you are using that, as I am unable to confirm but I do not have an SNI site handy.
I've dug into the code of LW and the SSL modules and didn't come back with a clear understanding of where/how SNI support may be lacking. So, if this is a public site that I can test against please email me and maybe we can do some testing.
Currently I have a spare machine so I set up a host for you: zzabcde.testssl.sh
(SSL Info shows the certificate on the IP address, not the one on the virtual host)
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 81.169.199.25
+ Target Hostname: zzabcde.testssl.sh
+ Target Port: 443
---------------------------------------------------------------------------
+ SSL Info: Subject: /C=SH/ST= /O=Schlingel\xC3\x83\xC2\xB6l/CN=default.name
Ciphers: ECDHE-ECDSA-AES256-GCM-SHA384
Issuer: /C=OO/ST=Somewhere/L=Over/O=><script>alert(Hi)/CN=The Rainbow
+ Start Time: 2019-01-08 11:31:13 (GMT1)
---------------------------------------------------------------------------
Let me know when you're done. By Saturday I need to shut it down.
So I see the proper response for zzabcde.testssl.sh in the debug output when requesting /, and the proper 404 response that matches. The base w/o the hostname does not appear, however the base w/o hostname's 404 message is the same as with so that could be a challenge.
I am letting a rather large debug output file be created now. More analysis to come but so far it seems working ok--need to dive into that CGI business specifically.
Thanks for setting this up!
If I switch off the default IP the SSL Info is like this:
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 81.169.199.25
+ Target Hostname: zzabcde.testssl.sh
+ Target Port: 443
---------------------------------------------------------------------------
+ SSL Info: Subject: /CN=zzabcde.testssl.sh
Altnames: zzabcde.testssl.sh
Ciphers: ECDHE-RSA-AES256-GCM-SHA384
Issuer: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
+ Start Time: 2019-01-09 09:33:53 (GMT1)
---------------------------------------------------------------------------
Params: ./nikto.pl -host https://zzabcde.testssl.sh:443
Don't know whether you're done? Just wanted to remind you that tomorrow I would need to decommission the machine.
I’m not but I’m traveling and have had zero time the last few days. I’ll see if I can get some more time before you terminate it.
On Fri, Jan 11, 2019 at 4:57 AM Dirk Wetter notifications@github.com wrote:
Don't know whether you're done? Just wanted to remind you that tomorrow I would need to decommission the machine.
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/sullo/nikto/issues/573#issuecomment-453459623, or mute the thread https://github.com/notifications/unsubscribe-auth/ABaBRJ0wRiVGU13-ckXgOzULkH9jlLxlks5vCF_4gaJpZM4YfiHV .
--
Hello there,
when I scan an own host where I set up a default IP, the banner and ports of the scan are ending up not at the virtual host I was aiming at, examples:
This is the default certificate on the IP address I configured. The certificate of the hostname is different. This must have been introduced somewhat recently.
During the scan I see also in the logfile for the default IP scans for variations of
$hostname\.(sql|tar.gz|jks|war|lzma|tar|pem|cer)
etc. which could be on purpose ending up here?What about those:
(the FF user-agent is the one I supplied here)
Is that deliberately scanned on the IP and not on the FQDN?