Ncrack ftp testing - proftpd peculiarities

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

Upon porting ncrack to Windows I noticed some strange TCP behavior occurring
when testing against a proftpd server. The main issue is that proftpd server
sends the first reply (banner) nearly 10 seconds after the initial 3way
handshake is completed. This happened with the proftpd server running on Linux
and the ftp client (or ncrack) running from Windows (XP SP3). Note that this is
not a ncrack/nsock issue since it also happens with the default Windows ftp
client. I conducted some test cases observing responses for various combinations:

SLOW = almost 10 seconds for first response
NORMAL = normally less than 1 second for first response

Windows client ---> Linux proftpd server  (SLOW)
Windows client ---> FreeBSD proftpd server (SLOW)

Linux client   ---> Linux proftpd server (NORMAL)
FreeBSD client ---> Linux proftpd server (NORMAL)
Windows client ---> Windows Filezilla server (NORMAL)
Windows client ---> Linux vsftpd server (NORMAL)
Linux client   ---> Windows Filezilla server (NORMAL)
Linux client   ---> FreeBSD proftpd server (NORMAL)


As you can see, the only cases that were actually marked as slow were those when
the client was running from Windows and the server was proftpd running either on
Linux or FreeBSD. As I run the windows client against a linux vsftpd server, as
well as against another windows Filezilla server and both cases were normal it
is obvious that it is not an issue of Windows specifically. Additionally,
judging from the fact that vsftpd and filezilla worked successfully, means that
the problem lies with proftpd.

I sniffed the traffic for all cases and the only thing that was noteworthy was
that as a client, Windows usually didn't include a TCP Timestamp option (which
is almost irrelevant) and also didn't include a window scale option (something
which may be of some importance in a way). However, in the windows-windows case
with filezilla, neither of the above options were enabled and it worked just
fine and afaik the windows-scale option shouldn't have that kind of impact
anyway, as it is mainly utilized for LFN (long fat networks).
Linux on the other hand always used window scale option as a client.

I am starting to think that this is just a proftpd peculiarity though. Can you
reproduce this case? If so, do you have any thoughts on the issue?

It is important for Ncrack to know about these extreme corner-cases, because it
needs to be able to adapt to slow responses like the above.


Regards,
ithilgore




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