Re: Sounds like ftp-anon needs work?

[Rob Nicholls <robert () robnicholls co uk>]

On Tue, 01 Jun 2010 18:55:14 +0200, Gutek <ange.gutek () gmail com> wrote:
> I'm a bit lost between my working copy and those that were already
> proposed to the list, but i'm nearly sure that the line
> socket:send("PASS IEUser@\r\n") has never changed since the beginning

Apologies, you're right that your attachment was fine in the email that
was sent out. However, I grabbed the script earlier today from the
seclists.org website, and the version at
http://seclists.org/nmap-dev/2010/q2/att-653/ftp-anon-rw-v3.nse appears to
have the @ symbol replaced with (), presumably to prevent spammers from
grabbing email addresses off the mailing list! So neither of us are going
mad :)

> A few hours after posting my last copy of the script I've noticed,too,
> that it warns about unhandeled 530 too many times for very common
> reasons that, indeed, did not worth to mention like "530 Login
> incorrect.".

I also discovered a very quirky (anti-Windows?!) FTP server that returned
a 530 if you sent anonymous\n but would return 331 - with exactly the same
message - if you sent anonymous\r\n (and then returned an "unhandled" 503
FTP code telling us off for not sending USER after we sent it a PASS). I
think the best way of dealing with that specific case is to let the script
flag the unusual/unhandled FTP code, especially as it'd probably be
difficult to code around without breaking anything else.

> I'm afraid it will be hard (or: I don't know how) to detect this
> max-users-limit-reached, as the 530 code is a very generic failure and
> the message attached can be in any language (i.e: we can't string.match
> on it)

I wish I had a better answer, but we might have to rely on string.match to
check for "530 Login incorrect." type messages to prevent the majority of
unhandled exceptions, and then flag any other 530 result as an unhandled
exception that needs to be manually investigated. I guess the FTP codes
weren't really designed to deal with "too many users, try again later"
scenarios, plus it'd be too late to try and create a new (4xx?) one now.

Rob

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