Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: ncat - proxy behavior / dns lookup / bug?
From: Florian Roth <venom14 () gmail com>
Date: Fri, 15 Jun 2012 21:15:48 +0200

Hi David,

Thank you for your reply.
I tried to dive into the ncat code and already spent 2h finding a way
to skip some hostname checks. Actually I am no C++ Developer so
figuring out the structure is hard for me. (I am used to C#, Perl,
Python, Java)

I checked that the proxy is parsed by the "parse_proxy" method in ncat_main.c.
Although the proxy is defined, ncat tries to resolve the hostname of
the requested target later in line 624.
First I tried to avoid any DNS lookups changing line 624 ff in ncat_main.c.
I added the "else if" statement and some code. I set "o.target" to the
requestet address "www.somesite.com" but later on an error is caused
beacuse &targetsslen is empty.
I am sorry, but I tried my best following the debugger steps deeper
and deeper into the code to figure out what has to be done.

        /* Resolve hostname if we're given one */
        if (strspn(argv[optind], "0123456789") != strlen(argv[optind])
&& ! proxyaddr ) {
            o.target = argv[optind];
            /* resolve hostname */
            if (!resolve(o.target, 0, &targetss.storage, &targetsslen, o.af) )
                bye("Could not resolve hostname %s.", o.target);
            optind++;
        /* If a proxy is give - don't resolve the target hostname */
                } else if (proxyaddr) {
                        o.target = argv[optind];
                        optind++;
        } else {
            if (!o.listen)
                bye("You must specify a host to connect to.");
        }

My last step brought me into "nsock_connect_tcp" in "nsock_connect.c"
where I noticed that the following debugging output showed only "TCP
connection requested to (null):8080", which should be "TCP connection
requested to 127.0.0.1:8080".

    nsock_trace(ms, "TCP connection requested to %s:%hu (IOD #%li) EID %li",
                inet_ntop_ez(ss, sslen), port, nsi->id, nse->id);

I suppose, I am no great help.
Thank you for your time and feedback.

Florian

On Fri, Jun 15, 2012 at 3:24 PM, David Fifield <david () bamsoftware com> wrote:
On Thu, Jun 14, 2012 at 06:25:24PM +0200, Florian Roth wrote:
Recently I carried out of an audit at a client's network in which I
tried to connect trough the clients proxy server (HTTP, HTTPS) to
another ncat instance running on a remote server.
Workstations in the clients internal network cannot resolve host names
located in the Internet. The internal DNS only resolves internal host
names. I though - wow, cool, ok, it's safer that way. But than I
noticed that ncat tries to resolve the DNS addresses given as
parameters and fails.

ncat --proxy proxy.company.net:8080 www.web.de 80
.. cannot resolve www.web.de ...

Therefore I tried this

ncat --nodns --proxy 10.1.1.250:8080 www.web.de 80
.. cannot resolve www.web.de ...

I tried to connect to the IP but the proxy was configured to deny all
requests made to IP addresses.

My final impression is that this is a bug, because ncat should not try
to resolve the host name to an IP address before sending the request
to the proxy server.
It should be the task of the proxy server to resolve the IP.

I agree that Ncat shoud use the proxy to resolve the name when possible.
According to my understanding, this is possible with SOCKS4a, SOCKS5,
and HTTP proxies, but not SOCKS4.

This would require some changes to the structure of the code, because if
I remember correctly, Ncat resolves the destination address shortly
after option parsing.

David Fifield


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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault