Nmap Development mailing list archives
Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy
From: Paulino Calderon <paulino () calderonpale com>
Date: Mon, 22 Aug 2016 13:45:15 -0500
Hello Daniel, I wasn’t sure why it had 12.5% false-positive rate but nnposter kindly explained it to me. We agreed that a better approach is to interleave the requests but I haven’t done any testing that proves we can get a mean value that will accurately determine if a host is vulnerable or not. * The reasoning behind using a random host instead of a valid one is that against non-vulnerable applications the requests with the additional header should not have any effect, only applications reading that value will try to connect to the proxy. If the connection completes successfully and fast we might get a similar response time as the non-vulnerable requests. By using a non-existing host we force an increase of the delay time when connecting and that’s what we are measuring. Even if its non existing hostname, it will attempt to resolve it externally or locally. *I did have issues with cache first but got rid of them by bypassing the cache. I’d also like to include it soon. Going to run more tests with interleaved requests and adjust the number of tests to find the optimal accuracy. I only have access to two different vulnerable setups myself, but someone on twitter reported it worked successfully in his environment too (The original script). Cheers.
On Aug 22, 2016, at 1:01 PM, Daniel Miller <bonsaiviking () gmail com> wrote: 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 <mailto: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 two scenarios I’ve tried (One of them is https://github.com/httpoxy/php-fpm-httpoxy-poc <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.nse <https://github.com/cldrn/nmap-nse-scripts/blob/master/scripts/http-httpoxy.nse> description=[[ 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 the response time when assigning a non-existing proxy to the headers. In theory, vulnerable applications will try to connect to the bad proxy increasing the response time. To reduce false positives we run the test several times and we expect the response time from the request with the bad proxy to always be greater than normal responses. References: * https://httpoxy.org <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 response time. 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 vulnerability known as HTTPoxy. It seems the -- | application is reading an arbitrary proxy value from the request headers. -- | -- | Disclosure date: 2016-07-18 -- | Extra information: -- | Avg response:0.003057 Avg response with bad proxy:0.008315 -- | References: -- |_ https://httpoxy.org <https://httpoxy.org/>_______________________________________________ Sent through the dev mailing list https://nmap.org/mailman/listinfo/dev <https://nmap.org/mailman/listinfo/dev> Archived at http://seclists.org/nmap-dev/ <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)