Bug: useproxy is forcing https

[digininja]

Expected behavior

Requests be made over http when specified

Actual behavior

Requests are made over https to port 80

Steps to reproduce

With this command line the requests are being made through Burp to the target https://cewl.test:80 rather than http://...

./program/nikto.pl -host cewl.test -useproxy localhost:8080

Even if I specify the host as http://cewl.test it still goes to https.

Running direct, no proxy, it does as it is supposed to and hits http

The only change I've made to the config file is to add this line:

LW_SSL_ENGINE=SSLeay

Without it, Nikto can't talk to Burp

Nikto version

Pull from 2.5 branch

Further technical info

In case this helps:

./nikto.pl -host http://cewl.test -useproxy localhost:8080 -D D
D:Thu Aug 19 09:13:35 2021 - Loading DB: /home/robin/tools/web/nikto/program/databases/db_parked_strings
D:Thu Aug 19 09:13:35 2021 - Loading DB: /home/robin/tools/web/nikto/program/databases/db_404_strings
D:Thu Aug 19 09:13:35 2021 - Loading DB: /home/robin/tools/web/nikto/program/databases/db_outdated
D:Thu Aug 19 09:13:35 2021 - Loading DB: /home/robin/tools/web/nikto/program/databases/db_variables
D:Thu Aug 19 09:13:35 2021 - Loading DB: /home/robin/tools/web/nikto/program/databases/db_tests
- Nikto v2.5.0
---------------------------------------------------------------------------
D:Thu Aug 19 09:13:35 2021 WARNING: No init found for nikto_core
D:Thu Aug 19 09:13:35 2021 'Request Hash' = {
	'Connection' => 'Keep-Alive',
	'Host' => 'cewl.test',
	'User-Agent' => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36',
	'whisker' => {
		'MAGIC' => 31339,
		'force_bodysnatch' => 0,
		'force_close' => 0,
		'force_open' => 0,
		'host' => 'cewl.test',
		'http_eol' => "\r\n",
		'http_space1' => ' ',
		'http_space2' => ' ',
		'ignore_duplicate_headers' => 0,
		'include_host_in_uri' => 1,
		'invalid_protocol_return_value' => 1,
		'keep-alive' => 1,
		'lowercase_incoming_headers' => 1,
		'max_size' => 750000,
		'method' => 'GET',
		'normalize_incoming_headers' => 1,
		'port' => 80,
		'protocol' => 'HTTP',
		'proxy_host' => 'localhost',
		'proxy_port' => 8080,
		'require_newline_after_headers' => 0,
		'retry' => 0,
		'ssl' => 1,
		'ssl_certfile' => undef,
		'ssl_rsacertfile' => undef,
		'ssl_save_info' => 1,
		'timeout' => 10,
		'trailing_slurp' => 0,
		'uri' => '/',
		'uri_param_sep' => '?',
		'uri_postfix' => '',
		'uri_prefix' => '',
		'version' => '1.1'
	}
};

[tautology0]

Just a couple of things

• try specifying http://target.com
• try specifying -nossl

IIRC the is the site up thingy tests ssl first unless it's specified explicitly using one of the above two mechanisms.

[digininja]

I tried with http and that didn't help, I'll try the nossl later. The fact it is going over port 80 means it is getting the https response from Burp and not from the end site.

…

On Thu, 19 Aug 2021, 15:49 D L, ***@***.***> wrote: Just a couple of things - try specifying http://target.com - try specifying -nossl IIRC the is the site up thingy tests ssl first unless it's specified explicitly using one of the above two mechanisms. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#738 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4SWMFYOPN6EUXDXTQXP3T5UKWBANCNFSM5CNV3NPA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> .

[digininja]

-nossl fixes it.

Defaulting to https is OK, but if it does, it should also default to port 443, not https on port 80.

[sullo]

@tautology0

IIRC the is the site up thingy tests ssl first unless it's specified explicitly using one of the above two mechanisms.

That was true until the last commit; now it checks HTTP first which, I think, shouldn't have any negative repercussions and as a byproduct fixes this issue due to how the fallback logic works.

However, right now it's sending the full URL in the "file" portion of the request when it shouldn't (when using a proxy with an HTTPS site).

[digininja]

I've just checked and I would agree with all that. HTTP works fine, HTTPS is making requests in the style:

GET https://digi.ninja:443/KESDM0w5.Htm HTTP/1.1

[sullo]

Yep--that's the unfixed bug I have to track down.

…

On Mon, Jan 17, 2022 at 4:14 AM Robin Wood ***@***.***> wrote: I've just checked and I would agree with all that. HTTP works fine, HTTPS is making requests in the style: GET https://digi.ninja:443/KESDM0w5.Htm HTTP/1.1 — Reply to this email directly, view it on GitHub <#738 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALICRASEG7JL6KCFP6IOGTUWPMW3ANCNFSM5CNV3NPA> . You are receiving this because you commented.Message ID: ***@***.***>

-- https://cirt.net | https://rvasec.com/