Re: [Request for Testers] CVE-2011-3368 "Reverse Proxy Bypass"

[Patrik Karlsson <patrik () cqure net>]

On Wed, Oct 12, 2011 at 7:01 PM, Gutek <ange.gutek () gmail com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Le 12/10/2011 09:34, Michael Meyer a écrit :
> > *** Gutek <ange.gutek () gmail com> wrote:
> >
> > > Yes, that's the key point : getting an error status code, whatever it
> > > could be. Maybe a 30s timeout is, here, too short ? On the other hand, a
> > > timeout of >1m could make this script very slow. I have to figure out
> > > the best balance between speed and efficiency.
> >
> > I'm doing something like the following for OpenVAS at the moment:
> >
> > ,---|
> > | mime@kira[4]: ~ 0)$ telnet 192.168.2.7 80
> > | Trying 192.168.2.7...
> > | Connected to 192.168.2.7.
> > | Escape character is '^]'.
> > | GET @6666.6666.6666.6666 HTTP/1.0
> > |
> > | HTTP/1.1 200 OK
> > | Date: Wed, 12 Oct 2011 06:46:28 GMT
> > | Server: Apache/2.2.10 (Linux/SUSE)
> > | Vary: accept-language,accept-charset
> > | Accept-Ranges: bytes
> > | Content-Type: text/html; charset=iso-8859-1
> > | Content-Language: en
> > | Connection: close
> > |
> > | [...]
> > |
> > |<title>Bad Gateway!</title>
> > `---|
> >
> > With such a wrong "ip", a vulnerable server immediately returns a 200 and
> > "Bad Gateway". Could you confirm that?
> >
> > Micha
> I'd rather say no. On the first hand, Contextis' analysis concludes that
> (in the case of the LAN ip test, that's different for the other ones) a
> vulnerable reverse proxy should return an *error* within a *delay*
> (...when querying a non-existing host).
> According to this statement, *immediately* should be the evidence for a
> *non* -vulnerable target, and a 200 as well, whatever the title would be.
> In this particular case, a 200 which is in fact a customized error
> answer (the normal behavior would be a code 502 in this case), I'd
> conclude maybe "filtered" or "patched". Plus, we have no delay, which
> sounds to me like a filtering system is immediately spotting something
> wrong.
>
> On the other hand, my own tests seem to show that everytime I get a 200,
> that was in fact a false-positive. It seems to confirm the Contextis
> conclusion on that matter.
>
> The only case when you could get an immediate 200 is the one when you've
> hit an existing LAN webservice. Lucky you :)
>
> Cheers !
>
> A.G.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.16 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6Vx8wACgkQ3aDTTO0ha7hqvwCfY8ODKFGBKtFG49TTfvmtymo9
> qbIAnRxqf9Fj9aqaknXAQP5tZFUAWz+f
> =IiJz
> -----END PGP SIGNATURE-----
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/

Hi Ange,

I was looking into the details of this vulnerability today and set up a
number of servers to do some testing.
I followed the discussion in the mail thread and checked out Contextis
write-up and tried some of the info in there manually.
Based on all the tests I did, with a number of different configurations,
the most reliable detection was still timing.
For some reason your script failed to work (I'm not sure why?), but I
started to do some changes to it.

Here are the changes I did and hopefully you will find them useful:
* First of all, I removed the page comparison based on MD5 as any change by
dynamic components would result in
  a comparison failing, even though it's "the same page"
* I made necessary changes to support both 404 and 200 error messages for
missing pages
* I've added support for a prefix, eg. /owa for servers that don't reverse
proxy from the root
* I've changed the script and output reporting so that it makes use of
Djalal's vulns library
* I noticed the following when trying to connect to internal servers
x if there's a devices with the requested IP on the network there will be
no delay in response
x if the IP is reachable on the network but is not in use there will be a
small delay (+-3 seconds)
x if the requested IP is not reachable on the network there will be a
longer delay (several minutes)
  In my case the 10.0.0.61 test was therefore not optimal so I made a few
changes there.
  The script now tries to call 1 IP in a number of different private
networks. Not 100% reliable either, but maybe better?
  Also, instead of having to measure the time delta for time passed I've
simply set the http.get timeout to the time
  it takes to retrieve the 404 + 5 seconds. This way, we can determine
whether it was successful or not by checking
  the response.status field. I'm aiming to detect the long delay as the
short one could be risky.

I've tested the attached script against a few of my own servers where it
seems to work good. However when working with these
changes and while testing different proxy configurations I've understood
some of the complexity involved.
That said, I might have made some wrong assumptions or changes that do not
make sense. If that's the case, please let me know!

Cheers,
Patrik
-- 
Patrik Karlsson
http://www.cqure.net
http://twitter.com/nevdull77

Attachment: http-reverseproxy-bypass.nse
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/