Re: Nmap proxy auth support, masking --proxies auth command-line data?

[Daniel Miller <bonsaiviking () gmail com>]

Here are some general rules for refactoring that ought to be helpful (taken
from [1]):

1. Don't try to refactor and add functionality at the same time.
2. Have good tests before you refactor, and run them regularly.
3. Make small, deliberate changes and test after each one.

In the case of this project, you don't really have a choice of not adding
functionality, since Nsock doesn't support some existing functionality like
authentication. But if you follow step 3, you'll realize that you can
subdivide the task into logical chunks that maintain these rules. So here's
how I'd see all the tasks you've considered breaking down (with a full
test, review, commit at each step):

1. Add connect-by-name support to Nsock (the big API change we discussed
with Henri).
2. Add proxy authentication to Nsock (HTTP Basic, Digest, SOCKS5).
3. Implement Ncat-supported proxy protocols in Nsock (SOCKS4a, SOCKS5).
4. Replace Ncat's single-proxy functionality with Nsock's proxy
implementation.
5. Add proxy chaining support to Ncat via Nsock.

Steps 1 and 2 could be swapped if you think 2 would be simpler and would
allow you to get a successful commit under your belt to motivate you to
continue. Also, any of these could be stripped down to a smaller,
functioning feature that could be committed early for testing before
fleshing it out. For example you could do proxy authentication for HTTP
Basic auth, make that complete, and commit it. Then go back and add other
auth types as needed. Or only do HTTP proxies for step 2, so that you can
get the core end-to-end functionality finished quickly before going back
and adding SOCKS4a or 5 in step 3.

It's also helpful to have a clear goal and frequently review your task list
to see if your tasks align with your goal. If I remember right, you started
the project with the goal of "scanning Tor hidden services," which ended up
being redefined as "support SOCKS4a in Nsock." Then, I suggested you use
Ncat as a test driver, not realizing its proxy support was not using Nsock.
So you added tasks for converting Ncat to use Nsock for proxies, which
brought with it lots of existing requirements to avoid regression. But in
reality, only step 1 above would be needed to accomplish your stated goal.
It's true that you need a test driver, but perhaps something built on
nsock/examples/nsock_telnet.c would be a simpler way to go about it.

Just some suggestions. I hope they help.

Dan

[1] Andrew Hunt and David Thomas. *The Pragmatic Programmer: from
Journeyman to Master.* Addison-Wesley, Reading, MA, 2000.
http://amzn.to/1MiGh8w


On Sun, Jul 19, 2015 at 8:19 AM, Jacek Wielemborek <d33tah () gmail com> wrote:

> W dniu 19.07.2015 o 14:54, Andrew Jason Farabee pisze:
> > Okay, I think I understand how I would implement masking from within
> > ncat, I'll have to look into how large of a footprint the patch would
> > have to have in order to mask the username and password in nmap or if
> > the memory passed nsock_proxychain_new() from nmap is already a direct
> > reference to argv.
>
> Don't jump straight to coding though - it might just not make sense. I'd
> wait for somebody else to comment on this first.
>
> > I really like your idea btw, my first ideas for
> > this were way too complicated (I remembered a program I used that had
> > the user encrypt their password with a different program before using
> > the ciphertext in the command line).
>
> That adds very little extra security - if I can log in as you, I can
> just read the command line and decrypt the password. The only time it
> can theoretically help is when the command is not running, provided that
> the arguments are not stored in ~/.bash_history. STDIN could also be
> used, but I'm not sure it makes sense...
>
> > I do have a secwiki account already, do you recommend documenting this
> > there for now?  I started posting tests for other patches on my gist
> > for now.  Sorry I haven't really documented things yet, I was trying
> > to get as much working as possible today.  I'm currently working on
> > http proxy authentication, so hopefully once that is done I can re-run
> > ncat-test.pl and check those tests that were failing.
>
> For now you can just write a TODO list of what has to be documented.
>
> > As for your questions, right now it does not attempt anonymous
> > authentication first, do you think there would be benefit to attempt
> > to connect without authentication first? I should look into the ncat
> > trunk authentication methods to see what the existing behavior is
> > (it's probably best for now if I try to change as little as possible).
> > I've been testing it with wireshark, valgrind, and gdb for now and
> > everything looks good so far.
> >
> > Thanks for the feedback!
> >
> > Andrew
>
> Good idea, better than I had. See how Ncat handles things and consider
> replicating it.
>
> Cheers,
> d33tah
>
>
> _______________________________________________
> Sent through the dev mailing list
> https://nmap.org/mailman/listinfo/dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/