Re: Ncrack ftp testing - proftpd peculiarities

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

ithilgore wrote:
> 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

[SOLVED]:

I discussed the problem with Fyodor and he suggested that the source of all
troubles might be the fact that some services (like proftpd for example) like to
first try connecting to the peer's identd/auth port 113 before presenting you
with the login banner. That was exactly the case. The difference with Windows
was that because by default the firewall just discarded every packet destined to
113, proftpd tried sending many SYN probes until the identd connection
eventually timed out (after 10 seconds) and then it let you proceed with the
login procedure. On the other hand, the Linux hosts that tried connecting to
proftpd were not firewalled and thus immediately sent an RST back to the identd
connection attempt, allowing to proceed to the next step without delay.

-- ithilgore






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