RE: Sounds like ftp-anon needs work?

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

Hi David,

I did some digging and it looks like Nessus/OpenVAS simply checks for a 2 or
3 as the first character, so other tools do appear to be pretty generous
when comparing FTP codes. I'll stick with your suggestion of allowing other
2xx codes, but to help people determine false positives I'd like to add the
FTP code to the output if it's not a 230, similar to how http-methods works.
Does that sound reasonable?

As part of my larger test, I have spotted some servers (mostly NcFTPd)
returning a couple lines beginning with "230-" before the final "230 Logged
in anonymously." so checking for multi-line responses at each stage is
definitely required if we're going to check for 3 digit numbers followed by
a space.

I also detected about 100 extra servers that supported anonymous access -
935 vs 829 - with the longer (30 second) timeout, although I'll try and
repeat the test from a slightly better net connection.

I might leave out the ACCT stuff for now due to its rarity (something to add
to the todo list), especially as I don't know of any servers I can test such
a script against. I have a feeling that Nessus might correctly match it by
accident due to its (lazy?) testing for a 2 or 3 digit, and Metasploit would
miss it entirely.

Rob
 
-----Original Message-----
From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org]
On Behalf Of David Fifield
Sent: 19 May 2010 21:22
To: nmap-dev () insecure org
Subject: Re: Sounds like ftp-anon needs work?

On Wed, May 19, 2010 at 09:09:44PM +0100, Rob Nicholls wrote:
> 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?

Okay, that looks good. Except that we should really handle multi-line
responses. Since we're only interested in the status code, I think this
can be done by reading lines until one begins with a number followed by
a space.

> 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 ;-)

I don't know--all 2?? are "positive completion." In this case I'd rather
have false positives (that can be removed later) than false negatives
(that will never be discovered).

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


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