Nmap Development mailing list archives
Re: Nmap DNS leak and proxychains redesign?
From: Daniel Miller <bonsaiviking () gmail com>
Date: Sat, 4 Jul 2015 07:09:49 -0500
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/
Current thread:
- Nmap DNS leak and proxychains redesign? Jacek Wielemborek (Jul 04)
- Re: Nmap DNS leak and proxychains redesign? Daniel Miller (Jul 04)
- Re: Nmap DNS leak and proxychains redesign? David Fifield (Jul 04)
- Re: Nmap DNS leak and proxychains redesign? Daniel Miller (Jul 04)