Nmap Development mailing list archives

Previous By Date Next
Previous By Thread Next

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

From: Paulino Calderon <paulino () calderonpale com>
Date: Mon, 12 Sep 2016 23:08:30 -0500
Hey,

There was a problem with mixed content in my previous mail that prevented the content to be shown so I’m reposting the 
changes now that I’ve cleaned up the script a bit more:

* Requests are interleaved now. We first measure the response time of a request without the Proxy header then the “bad” 
request.
* 30 requests are sent to calculate the average response time. We could do less but this number works even in my 
terrible connection. Or you can always just adjust the value with a script argument.
* Proxy header use a random but valid hostname. Additional response time gets introduced when resolving name + 
connecting.
* A host is considered vulnerable if the ‘bad’ response time is at least twice as big as the normal one. In my 
vulnerable instances this worked fine, we could probably go with 1.5 but I rather stayed on the safe side. This also 
fixed the issue with false positives when calculating if the host was vulnerable with mean deviation calculations.  

Cheers.

http-httpoxy: https://github.com/cldrn/nmap-nse-scripts/blob/master/scripts/http-httpoxy.nse 


On Sep 11, 2016, at 9:02 PM, Paulino Calderon <paulino () calderonpale com> wrote:

Hey list,

I finally got around to update the script. After considering your feedback I applied the following changes:
* Requests are interleaved now.
* 30 requests are sent to calculate the average response time. (We could probably do less but this works even in my 
terrible connection)
* Proxy header uses a random but valid hostname. The additional time gets introduced when resolving the name + 
connection time.
* To mark a host vulnerable, the bad response time need be at least twice as big as the normal one. In my vulnerable 
instances this worked fine, we could probably go with 1.5 but I rather stayed on the safe side. This also fixed the 
issue with false positives when calculating if the host was vulnerable with mean deviation calculations.  

I will wait a few days to give everyone a chance to test it before committing. 

Cheers.

http-httpoxy.nse: https://github.com/cldrn/nmap-nse-scripts/blob/master/scripts/http-httpoxy.nse 

<http-httpoxy.nse>


On Aug 22, 2016, at 1:45 PM, Paulino Calderon <paulino () calderonpale com> wrote:

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> 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/
Previous By Date Next
Previous By Thread Next

Current thread: