Re: Nmap DNS leak and proxychains redesign?

[Daniel Miller <bonsaiviking () gmail com>]

On Sat, Jul 4, 2015 at 3:43 AM, Jacek Wielemborek <d33tah () gmail com> wrote:

> 1. nmap_dns.cc - already uses Nsock routines for UDP. My idea is that
> perhaps proxy support could be integrated here for SOCKS5 only with code
> similar to one from nsock_connect_internal. This seems rather easy, am I
> missing something?

If we had name-aware proxy capability (e.g. SOCKS5), we would not have to
use any routines from nmap_dns.cc. The leak happens when an application
assumes it has to resolve a name before it can connect, and the DNS lookup
happens outside the proxy chain.

> From a user's perspective, I think that --proxies socks5://1.2.3.4:9050
should imply "no non-proxied traffic" even to the point of ignoring -O or
--traceroute, or bailing out before a scan if -sS, -sA, etc. were chosen
(since raw packet scans will not work over a proxy like this). An option
like --unproxied-ok (terrible name, but that's beside the point) could then
be used to restore the current behavior of using the proxy for some things
but not others.


> 2. Hostname resolution in NSE connect() scripts. Since those can be
> arbitrary strings, the point above doesn't handle that.

Not sure what you mean here: most scripts pass the host table to a connect
call, so we'd just make sure that there's enough info in that to perform
the proxied connection. No matter how the script chooses to connect, it's
fine as long as the connection is TCP. We would probably have to draw a
conceptual boundary (some sort of wrapper function?) around calls that are
strictly un-proxiable: nmap.ethernet_*, nmap.new_dnet, nmap.pcap_*, etc.

3. Establishing connections to proxies defined by hostname in --proxy.
>

This is fine, since the connection will use the same Nsock pool that has
the proxychain established. Obviously, the first hop would have to be
resolved normally, but that doesn't "leak" since you're not hiding the fact
that you're using a proxy. The issue is not "we have a hostname instead of
an IP" but rather "our code expects an IP address even though it's not
needed to connect through the proxy"


> I guess there are other spots, can you think of any? Is there any
> previous discussion of this topic in nmap-dev archives?

No other discussion that I'm aware of.


> BTW, is there any specific reason why nmap_dns.cc doesn't seem to handle
> DNS resolution over TCP as well? Perhaps such a resolver could work with
> proxies out of the box, at least for bullet #1.

Again, I don't think this is relevant to the proxy issue, but we do have an
issue in for it: #103


Dan

[#103] http://issues.nmap.org/103

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