Re: [NSE] NSE script to detect web apps vulnerable to HTTPoxy

[Daniel Miller <bonsaiviking () gmail com>]

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 two
> scenarios 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.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
> > ]]
> >
> > -- @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
>
> _______________________________________________
> 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/