Re: Ncrack on exotic Windows-land

[ithilgore <ithilgore.ryu.l () gmail com>]

Rob Nicholls wrote:
> > I have no idea why Windows sends the RST, it shouldn't.  The only
> > explanation I can come up with is that Windows doesn't support one-way
> > TCP connections.  When I saw this I muttered some anti-Windows,
> > anti-Microsoft slurs and threw my hands up in disgust.
>
> I've only tried this using ftp on the command line and quitting the FTP
> server, but I only see this behaviour (the unusual RST immediately being
> sent) if the Windows Firewall is enabled. If I disable it I can see the
> final handshaking done properly. I'm not sure if the Windows Firewall is
> behind the RST sent to the OSX clients or if this is a separate - but
> similar - issue. Can either of you reproduce your issues if the Windows
> Firewall is disabled?

You are right about the firewall. I reproduced the issue with Windows Firewall
disabled and it worked as it should.

> I would imagine (for the ncrack issue) that the Windows Firewall knows that
> the process has exited (and released it's connection) so it sends a reset
> because even if it got a response back there wouldn't be an application
> that's listening so it would just get filtered, causing the FTP server to
> send more traffic trying to gracefully close the connection.

The problem is that ncrack does *not* exit - it doesn't use a separate process
for each connection like for example hydra does - as it is always one thread
utilizing nsock to handle parallel sockets. But even if that was the case, the
process wouldn't exit until it read the final server's reply (which is what the
main problem is - losing that final reply because of the Windows kernel
prematurely sending the RST back to the server and thus killing the socket and
any associated receive-buffers).

In addition, what baffles me is that the Windows firewall is supposed to filter
only incoming connections. Any connection beginning from the inside, is
supposedly not influenced by using stateful firewall techniques (keeping a table
of every connection alive and allowing any packet that belongs to any of them to
pass unhindered).

As for what you said about the FTP server sending more traffic trying to
gracefully close the connection: the only thing that it would need to send would
be the ACK of the client's FIN. I don't see how this 'innovative' approach would
lead to any significant performance gain (which anyway should *not* be the
firewall's work).


> I can see why it's potentially bad for a firewall - other firewalls may do
> the same? - to do this (it should only issue resets in response to a
> connection request for a nonexistent connection, and shouldn't be
> proactive), but I can understand what they're trying to do. I suspect we'll
> have to live/deal with it, especially as the Windows Firewall is on by
> default.

Honestly, this is the first time I come across this bizarre behavior. I know of
no other firewall which does anything similar. It goes against the RFC rules,
against the rules of logic and potentially against the rules of the universe.

Given that the windows firewall is, as you said, enabled by default and that
ncrack is limited by the underlying network stack as it doesn't use raw sockets
or other low-level stuff, I don't see any other solution at the moment, other
than specifically instructing the users to disable the firewall for the time
they are running ncrack (or else they will suffer a serious performance
degradation). I really don't like this approach but anything else would require
sending ha^H^H mails to Microsoft about changing the firewall's behaviour (and I
have a feeling they might go unanswered).

-- ithilgore

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