RE: Sounds like ftp-anon needs work?

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

I've tried to take on board everyone's suggestions with this version of the
script (and it should be a little bit faster compared to my previous version
for servers that respond properly). If everyone's happy with it, let me know
and I'll commit this one. Suggestions are also welcome.

It doesn't currently deal with the ACCT code at this point - what would we
send at that point? IEUser@ again?

Some quick stats against some servers on the internet:

My scan of ~2200 servers detected 1294 open 21/tcp ports this time.
The script detected 962 supported anonymous logins this time.
The only FTP code detected was 230.

In comparison, the previous version I sent out picked up 829 and with a
longer timeout it would pick up 935 that supported anonymous logins (which
suggests around 3% of FTP servers don't require a password for the anonymous
account), so this is definitely an improvement. I've done some checks of
open ports that weren't flagged by the script and it doesn't appear to have
missed anything.

This script should flag other FTP codes, and was briefly flagging 220 until
I added some checks to try and parse the banner to avoid false positives
when servers return dodgy "220-" banners that contained line breaks (this
seemed to affect a few dozen servers).

Also, something I hadn't appreciated last time was that
socket:receive_lines(1) doesn't return a single line. I assume the name is
simply a little ambiguous, rather than this being a bug.

Rob

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

On Wed, 19 May 2010 21:09:44 +0100 Rob Nicholls <robert () robnicholls co uk>
wrote:
> 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?
I told you this off list, but I thought I'd let everybody know. This
definitely happens. PureFTPd, one of the servers we were testing on, seems
to do that occasionally (but not always). 

A second issue we noticed is that during a -sS scan, it worked, but with a
-sT or -sV scan, it didn't. I assume this is because the FTPd did some rate
limiting when it saw an actual connection (instead of a half-open). If we
upped the timeout to 30 seconds, everything worked fine. 

--
Ron Bowes
http://www.skullsecurity.org
http://www.twitter.com/iagox86

Attachment: ftp-anon.nse
Description:

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