Re: Scripts for proxy detection

[Joao Correa <joao () livewire com br>]

David,

I agree that only receiving a "Request Granted" from the server is
already enough to determine that the proxy is open. Anyway, I don't
know how is the usual behavior of world coffee shop proxies. In Brazil
the Coffee Shops use to require that you authenticate on a web page,
just like you mentioned. If this happens, doing the HTTP request will
return the same result as only doing the proxy handshake (which is
someway a false-positive). Such proxies here use to be transparent,
and I never had to setup a proxy while using the computer on it.

We could go back and look for another google's header string, what
could precisely determine if the proxy is really open (and we can
reach google), but it would not work with argument passed urls.

Except for the case of the Coffee Shops, I don't think that making a
request contributes much more than only trying to do the handshake.
For this reason I've removed the HTTP request from the script.

On Mon, Jun 1, 2009 at 5:47 PM, David Fifield <david () bamsoftware com> wrote:
> On Thu, May 28, 2009 at 05:17:43AM -0300, Joao Correa wrote:
> > I'm posting two new versions for the open proxy detection scripts.
> >
> > The new features are:
> >
> > HTTP:
> > * Changed pattern for connect (tested and supporting both polipo and
> > ncat, needs to test on squid!)
> > * Default test address is now nmap.org, and not www.google.com
>
> I see that you have already changed it back to www.google.com. I think
> that is a better default too. I did a search and that is what is used by
> the ScanSSH proxy detector too (http://monkey.org/~provos/scanssh/).
>
> > * HTTP status codes 200, 301 and 302 are recognized as valid
> > responses, meaning that the proxy is correctly working
> > * It is also possible to use a different test address, specified with
> > script-args. The args should be "url", with the url that might be
> > tested and "hurl" with the url used to set the "Host:" field of the
> > HTTP requests. If no hurl is set, than url is used as hurl. If none is
> > set, nmap.org is used.
>
> I can see why you have a separate url and hurl; it's because you may
> want to make a proxy connection to http://example.com/dir/file.html (url),
> but then the Host: header field has to be just "example.com", not
> "example.com/dir/file.html". But you should do that work in the script,
> and not make the user do it. There are functions in the url module that
> will make this easy.
> http://nmap.org/nsedoc/modules/url.html
>
> Now that I look back at it, there's no way to access a URL like
> http://example.com/dir/file.html in socks-open-proxy.nse, because the
> code will try to resolve the name "example.com/dir/file.html" as if it
> were a host name. I take back what I wrote in
> http://seclists.org/nmap-dev/2009/q2/0523.html; you should keep the
> script argument name "url", allow it to be followed by a path, and use
> the url module to parse out the host name.
Since the socks-open-proxy.nse is not going to execute the third step
anymore (doing the HTTP Request over the proxy connection, as
mentioned at: http://seclists.org/nmap-dev/2009/q2/0523.html), it
makes no sense to receive a full URL as an argument. The only needed
information for the script will be the hostname, used to determine its
IP address. As no HTTP Request is going to be made, having a url such
as url.com/path/path/path won't be any better than having only
url.com, the path won't be used for nothing.

For this reason I'm not using the URL lib you mentioned.

> > Questions:
> > Should we include new HTTP status codes?
>
> I think the ones you have are good.
>
> > Should we remove POST from the HTTP open proxy tests? (as mentioned by
> > David in his previous e-mail)
>
> I recommend this, especially now that I see it requires a separate
> script argument for a POST-able URL. I guess it would be possible for a
> proxy server to support POST but not GET or HEAD, but it wouldn't be
> very useful. Enumerating the methods supported by an HTTP server or
> proxy would best be done in a separate script.
>
> > Socks script only tests a connection to the destination's port 80.
> > Should we include more ports? If yes, how should we parse the
> > responses? (we'll have different responses from each service)
>
> See my question in http://seclists.org/nmap-dev/2009/q2/0523.html. I
> don't know much about SOCKS, but perhaps "Request granted" is enough
> without sending any application-level data.

Sending some data during the "socks handshake" is needed. Some
important data are the port and the IP address you want the proxy to
connect you to.
> David Fifield
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org

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