Ncrack on exotic Windows-land

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

I've been running some tests on Windows and came across some unexplainable (or
just plain idiotic) behaviour on part of Windows (which can be in general
reproduced without ncrack).

The problem arises when ncrack on Windows tries to crack an ftp host (running on
a different platform but that doesn't really matter). A common ftp login
procedure goes like this:

1) client connects to ftpd
2) ftpd sends login banner
3) client sends USER <username>
4) client waits for reply
5) ftpd sends that a password is needed
6) client sends PASS <password>
7) client waits for reply
8) ftpd sends results (success or fail)

9) if authentication attempts for this connection surpass a certain limit then
ftpd closes the connection, else the client can continue from step 3


Now consider the case, when we have already done 2 authentication attempts, the
server supports in total 3 attempts per connection and we are at step 6. So we
send the password and then prepare to read the reply. But before we do that
(going to step 7 that is), the peer sends us the "Login incorrect" tcp segment
and also sends a second FIN packet immediately after. What happens with Windows
is that it will acknowledge the FIN packet with a pure ACK (as it should), but
immediately after it will send to our peer an RST packet (which it shouldn't)!!
This has as a result, that the read call that was scheduled for step 7 (and
which due to any reasons might be delayed) will return with a ECONNRESET (and
this is really funny since ECONNRESET usually refers to an RST from the peer -
not us!) and we will never be able to read the last reply of ftpd! The thing is
that every time that I tested it on Windows it happened. You can reproduce the
case with a plain ftp client (though the client usually calls read (step 7)
immediately after step 6 so you don't notice anything strange apart from the
unexplainable RST. Ncrack uses an event-driven API due to nsock and thus the
read call of step 7 might be a little bit delayed after step 6 and that delay is
enough for the connection to be RESET and consequently for us to lose the last
reply.

The question is: does anyone have any idea for the bogus RST that the Windows
kernel sends? I cannot find a logical reason why this is happening.


Starting Ncrack 0.00001ALPHA ( http://ncrack.org ) at 2009-06-17 16:08 GTB
Daylight Time

ftp://10.0.0.100:21 Initiating new Connection
ftp://10.0.0.100:21 reply: 220 ProFTPD 1.3.2 Server (ProFTPD Default
Installation) [10.0.0.100]
ftp://10.0.0.100:21 reply: 331 Password required for guest
ftp://10.0.0.100:21 Login failed: guest test
ftp://10.0.0.100:21 reply: 331 Password required for root
ftp://10.0.0.100:21 Login failed: root test
ftp://10.0.0.100:21 reply: 331 Password required for guest
NSOCK read WERROR: An existing connection was forcibly closed by the remote host.
read: nse_status_error

You can find some wireshark dumps here:

[1]. http://sock-raw.org/tmp/windowsftp.jpg
[2]. http://sock-raw.org/tmp/dumps.txt

Regards,
ithilgore

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