Mailing List Archive

On Saturday 05 January 2002 04:18 pm, Michel Arboi wrote:
> A couple of ideas about proxy detection...
>
> 1. Some people wanted Nessus to detect Wingate or MS proxies.
> If some documentation is available, that would be great. The only
> source of information on this topic is, AFAIK, the Dante source
> code. This open source project tries to be compatible with M$

There are some slight differences between Dante and MS Proxy when it comes to
the SOCKS 5 support. The Dante client and libs are unable to use a MS Proxy
box because of it. The Netscape browser seems to be able to work with either,
I was comparing sniffed traffic between Dante and Netscape the other day to
see what I had to change in Dante to get it to work with MSP, I will throw
together some notes on it if you want.

> 2. Should we do more on SOCKS?
> The SOCKS proxy detection in find_service now tries to identify the
> "external" interface of the proxy (I also fixed a bug)
> I wonder if we should try to connect to some private network and raise
> an alert if we can: we may have an "open" proxy in this case.

Trying to connect to an internal network is going to be tricky, no matter
which set of address you use to test, theres a good chance youre still going
to miss about half of the networks being used. Even worse, quite a few places
use external/bogus internal IP's that arent in one of the reserved ranges.

This would also falesly trigger when the scan is being run on the internal
network. The Content-Location HTTP plugin triggers falsely on internal scans
because of this. There doesn't seem to be a 100% workaround for either issue.

> I suspect that HTTP proxies are far more common and we should rather
> spend time on them. However, the tests look all right. Currently, Nessus
> checks:
> - if anyone can use the proxy
> - if the proxy accepts CONNECT to any port
> - if the proxy accepts connections through POST

The current HTTP proxy checks look good, might want to add Apache
reverse-proxy detection too:

$ telnet reverseproxied.com 80
GET / HTTP/1.0

200 OK
Server: Microsoft-IIS/4.0
[ ... ]

$ telnet reverseproxied.com 80
GET /%00. HTTP/1.0

404 Not Found
Server: Apache-1.3.22/Unix
[...]

Essentially just sending a null followed by a period and seeing if the
Server: header changes, if you want I will write one of these up.

-HD

H D Moore <hdm@digitaloffense.net> writes:

> There are some slight differences between Dante and MS Proxy when it
> comes to the SOCKS 5 support.

You mean that Dante does not support the MS winsock proxy?

> The Netscape browser seems to be able to work with either

Once I looked at Netscape, at it was using SOCKS4. Did this change, or
can it adapt?

> Trying to connect to an internal network is going to be tricky, no matter
> which set of address you use to test, theres a good chance youre still going
> to miss about half of the networks being used.

I thought of something like trying to connect to a couple of RFC 1918
addresses. I agree that this will not cover all private networks, but
it will be better than nothing...
A "good" proxy should return "permission denied" for any RFC1918
address.

> This would also falesly trigger when the scan is being run on the internal
> network.

Yes. However, the proxy should not be used to connect an internal
machine to an internal server.
I agree that a "clean" test is tricky in NASL. It should take three IP
address into account: the nessusd machine, the target machine, and the
external interface (if we could find it)

> The current HTTP proxy checks look good, might want to add Apache
> reverse-proxy detection too

Looks nice, for information gathering.