Re: SOCKS4A Implementation Issues - Request for Comments

[Jacek Wielemborek <d33tah () gmail com>]

(Adding Henri to the CC list.)

W dniu 09.06.2015 o 12:59, Andrew Jason Farabee pisze:
> Hello again,
>
> Now that the socks4a proof of concept is working (
> http://seclists.org/nmap-dev/2015/q2/231), there are several design issues
> that could use community feedback and discussion before this project moves
> forward.
>
> 1.  Currently the PoC doesn’t disrupt DNS resolution.  It uses existing
> hostname variables from l_connect or handle_state_init_socks4a in order to
> create packets for establishing a tunnel.  So far we have discussed
> implementing a method for synchronous DNS resolution that would either pass
> the sockaddr_storage or provide the target name for nsock_proxy_socks4a,
> but we need some ideas about where this should be done.
>
> 2.  This is sort of in the same vein, but we need to prevent DNS resolution
> of the targetname if a socks4a proxy is being used.

I'll rephrase the problem just in case: right now, Nmap is built on the
assumption that we can always just pre-resolve a specific target name
and rely on the IP address in the future. This means that the
pre-scanning phase involves both forward DNS lookups on the target names
(and then reverse DNS lookups on the resulting IPs in case we find
something interesting) and the rest of the code just uses the resolved
IP. This makes things difficult.

First of all, when using SOCKS4a, we don't touch the IP address of the
target at all. It might not even resolve on our computer if behind the
proxy it does work properly. This means that there's little point making
DNS requests. Consider a Tor hidden service - a resolution attempt of an
.onion address on the clear internet will fail while it will work behind
the Tor's SOCKS4a. Right now, Andrew's POC will be confused and without
the /etc/hosts kludge, it will just fail saying that it failed to
resolve the name. This is not acceptable.

In the perfect scenario, Nmap would detect that we're using SOCKS4a,
assume -n, disable forward DNS lookups (and also -sn, which I explain in
#3). I am getting the feeling though that it may make sense to add a way
to manually turn off forward DNS altogether in some cases - on the other
hand, it sounds a bit crazy so I'd like to hear why it might not work.

Another problem with the current Nmap assumption is that with the advent
of SOCKS4a, Nsock currently expects an already resolved IP as an
argument to nsock_connect_tcp. This makes sense for example during
service scanning where we wouldn't like to perform DNS resolution
everytime a new probe is sent. On the other hand, with SOCKS4a we cannot
resolve an IP address with getaddrinfo, so we need another way.

At first I thought of adding a hostname argument to nsock_connect_tcp,
but this is crazy. Perhaps a better way could be to wrap getaddrinfo
with Nsock and return nsock_addrinfo that would be passed to
nsock_connect_tcp. In case of SOCKS4a, this would just store a special
value that would mean "this will be resolved behind a proxy". What do
you think about this?

> 3.  We need to find a way of allowing port scanning through socks4a.
> Depending on how we decide to handle this, it could require a lot of
> additional changes.  If anyone has ideas on how we can solve this, it would
> be very appreciated! Some of the options we discussed were:
>   *  Fixing congestion control issues with d33tah’s nsock scanning engine
> (nmap_nsock_scan) and implementing socks4a in that.
>   *  Using Henri’s NSE interface patch for specifying how to scan ports.
>   *  Bypassing port-scanning by allowing scripts, service-fingerprint, etc.
> to assume that the port is open.

Generally, I am not sure if Andrew will manage to fix my nmap-nsock-scan
code during this GSoC since Henri suggested to me that the reason the
proxy code was getting segfaults might not be related to nsock. At the
same time, he showed me that I am clearly throwing too many items on the
stack because of the architecture assumption I made during the last GSoC...

As for Henri's NSE scanning branch, I remember that there were issues
related to figuring out whether we need root access or not. There could
be more problems, I can't recall them right now though.

"Bypassing port-scanning", the last option you mentioned, sounds least
difficult to implement. What I would like to propose is a port scanning
mode like -Pn. Note that -sn doesn't do the same thing -Pn does: -Pn
assumes that the host is up without scanning it and if we had a way to
assume that a port is open without connecting to it, we could make
portrule scripts run via SOCKS4a.

> 4.  We need to decided how to handle cases where socks4a proxies are listed
> in a proxy chain that includes other proxy types.  For example, if a
> socks4a proxy is supposed to create a tunnel to an http proxy, we need to
> consider if/how to also prevent DNS resolution of the http proxy URI.  If
> anyone knows of any other issues that could come up with adding socks4a to
> proxy chains, please let me know.
>
> 5.  We need to decide how the socks4a will integrate with the current code
> for socks4 and the general proxy code.
>
> Please bring up any issues that aren’t in these categories as well in case
> we missed it.  Hopefully I will be able to create a good amount of work for
> myself by the time my classes end Wednesday!
>
> Thanks,
> Andrew Farabee

Attachment: signature.asc
Description: OpenPGP digital signature

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