Nmap Development mailing list archives
Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy
From: Daniel Miller <bonsaiviking () gmail com>
Date: Mon, 22 Aug 2016 13:01:23 -0500
Paulino, Any thoughts on these comments? I'm not sure how much the extra tests would improve the confidence if we did interleave requests as suggested; I'd want to know just how many tests we're talking about. I do think we could improve the tests themselves; here are some possibilities: * As nnposter suggested, use a URL that validates in order to avoid false negatives due to something short-circuiting. * Determine where the delay comes from: is it in DNS resolution of the proxy, in connecting to the proxy, or in sending responses through the proxy? This will determine whether we get better results by using a resolvable address or a random one, and whether the target's port should be open. We would like to not cause backscatter, though. * Use other cache-avoidance mechanisms like Cache-control: max-age=0 headers and possibly random URL parameters ("?blahblah=qwerty") I would like this script to be added pretty soon if we can address these questions. Dan On Tue, Jul 26, 2016 at 4:23 PM, nnposter <nnposter () users sourceforge net> wrote:
I might be missing something but the script logic seems to exhibit inherent 12.5% false-positive rate (in the default configuration). Specifically, this rate is 2^(-"tests"). An alternate approach might be to run a single sequence, interleaving requests with and without the Proxy header, while keeping track of elapsed time differences between each pair of adjacent requests. (Since the two types of requests would be interleaved then there is a lesser chance of skewed timing due to any transient resource congestion.) The resulting series might be treated as a normal distribution, which would allow the script to replace the "iterations" and "tests" parameters with a desired result confidence, which could be in turn easier for users to interpret. The test whether a target is deemed vulnerable would be implemented as a statistical test of the sample mean of the collected data series against a hypothesis that the true mean is zero. On a completely separate note, would it make sense to format the proxy header to be a URL, such as "http://"..stdnse.generate_random_string(12)..".net/" to reduce the chance that the value will be rejected outright by the target? Also, the code has a minor bug: --- http-httpoxy.nse.orig 2016-07-25 16:45:08.840774600 -0600 +++ http-httpoxy.nse 2016-07-26 15:17:18.672813900 -0600 @@ -97,7 +97,7 @@ action = function(host, port) local path = stdnse.get_script_args(SCRIPT_NAME..".path") or "/" local req_count = stdnse.get_script_args(SCRIPT_NAME..".iterations") or 10 - local test_count = stdnse.get_script_args(SCRIPT_NAME.."tests") or 3 + local test_count = stdnse.get_script_args(SCRIPT_NAME..".tests") or 3 local output = stdnse.output_table() local vuln_report = vulns.Report:new(SCRIPT_NAME, host, port) local vuln = { Cheers, nnposter On 7/22/16 2:43 PM, Paulino Calderon wrote:Hey list, Can you help me test this script? It seems to detect correctly the twoscenarios I’ve tried (One of them is https://github.com/httpoxy/ php-fpm-httpoxy-poc) but more testing will be great before committing.Cheers. http-httpoxy.nse: https://github.com/cldrn/nmap-nse-scripts/blob/master/scripts/http-httpoxy.nsedescription=[[ Attempts to detect web applications vulnerable to "httpoxy"(CVE-2016-5385, CVE-2016-5386,CVE-2016-5387, CVE-2016-5388, CVE-2016-1000109, CVE-2016-1000110). The script attempts to detect this vulnerability by measuring theresponse time whenassigning a non-existing proxy to the headers. In theory, vulnerableapplications will tryto connect to the bad proxy increasing the response time. To reducefalse positives we runthe test several times and we expect the response time from the requestwith the badproxy to always be greater than normal responses. References: * https://httpoxy.org ]] -- @usage -- nmap -p80 --script http-httpoxy --script-args iterations=5 <target> -- nmap -sV --script http-httpoxy <target> -- -- @args http-httpoxy.path Path. Default: / -- @args http-httpoxy.iterations Number of requests to measure responsetime. Default: 10-- @args http-httpoxy.tests Number of comparison test to run. Default: 3 -- -- @output -- PORT STATE SERVICE REASON -- 80/tcp open http syn-ack ttl 64 -- | http-httpoxy: -- | VULNERABLE: -- | HTTPoxy -- | State: VULNERABLE -- | This web application might be affected by the vulnerabilityknown as HTTPoxy. It seems the-- | application is reading an arbitrary proxy value from therequest headers.-- | -- | Disclosure date: 2016-07-18 -- | Extra information: -- | Avg response:0.003057 Avg response with bad proxy:0.008315 -- | References: -- |_ https://httpoxy.org_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev Archived at http://seclists.org/nmap-dev/
Current thread:
- [NSE] NSE script to detect web apps vulnerable to HTTPoxy Paulino Calderon (Jul 22)
- Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy nnposter (Jul 26)
- Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy Daniel Miller (Aug 22)
- Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy Paulino Calderon (Aug 22)
- Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy Paulino Calderon (Sep 11)
- Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy Daniel Miller (Sep 12)
- Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy Paulino Calderon (Sep 12)
- Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy Daniel Miller (Aug 22)
- Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy nnposter (Jul 26)