Re: Sounds like ftp-anon needs work?

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

On Wed, 19 May 2010 13:28:58 -0600, David Fifield <david () bamsoftware com>
wrote:
> Looks good, and good job on the research. The patch requires a 331
> response and only a 331 response after USER; the Metasploit code accepts
> 331 or any 2?? code. I recommend this procedure:
>
> 1. Send USER.
> 2. Read a single line and ignore it. (Check for a socket error.)
> 3. Send PASS.
> 4. Read lines, checking for any 2?? reply.

I'm way ahead of you (okay, maybe a just a few minutes...)!

It seems that a small minority of servers will simply accept "anonymous"
without prompting for a password, so we need to check the first line for a
230 response rather than discarding it. How does the following sound
instead?

1. Send USER.
2. Read a single line and check for 230 or 331 (break if 230; check for
socket error)
3. If 331 send PASS.
4. Read a single line and check for 230.

I've been running tests against over 2200 servers (based on an old list
from http://www.ftp-sites.org). Just over half have open FTP servers and
about 2/3rds of those allowed anonymous access using my updated script with
a 5 second timeout. I'm currently testing it with a 30 second timeout to
see how much of an improvement I get (but it's taking ages to run), as the
majority of servers that weren't flagged that I've manually tested seemed
to take 10-15 seconds to respond to the initial connection. Would 30
seconds be too long?

I'm a bit concerned about checking for a 2?? reply. The expected response
would be 230, anything else beginning with a 2 would be quite unusual [1]
and I'd imagine would always be a false positive. It'd be nice to work out
why Ron has x.x.x.251 appearing in the Metasploit results and not the Nmap
results - I'm personally hoping it's a false positive ;-)

If we want to be really nice, we could try sending a QUIT at the end?

Rob

[1] http://en.wikipedia.org/wiki/List_of_FTP_server_return_codes

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