WU FTPD Version Information On Connection

WU FTPD Version Information On Connection

Post by Brian McEntir » Fri, 09 Oct 1998 04:00:00



Hello,
  In order to offer anonymous ftp services we are using WU FTPD. The box
happens to be a LINUX box, but I can see using it on an HP-UX host
too... I've heard it should be more secure than most vendor supplied
daemons.

  Anyway, I was wondering if its a good idea that the default behavior
of 'wuftpd' tells EXACTLY what version the ftpd server is (down to the
beta) when anyone connects to the server. This seems to me like  giving
someone more information than they need (unless its required by an
RFC or something.) Suppose you've neglected the server for a while and
it turns out there is a well known bug in your particular version....
the information is offered to everyone right upon connection.
  So I discovered a simple fix to remove ALL the version information by
replacing it with an empty string -- now when I compile the program, the
file vers.c contains only the line:
  char version[] = "";

Are there any drawbacks to doing this, does it open up other
problems?? Maybe its trivial because there is some other way for an
outsider to get the server version??

Thanks for any thoughts,
  Brian

 
 
 

WU FTPD Version Information On Connection

Post by Alun Jon » Sat, 10 Oct 1998 04:00:00



> Are there any drawbacks to doing this, does it open up other
> problems?? Maybe its trivial because there is some other way for an
> outsider to get the server version??

The chief drawback to disabling version notification entirely is that it
denies information that may be used by the connecting client.  Many clients
use the 220 greeting to determine what FTP server they are connecting to,
and thereby what commands they can expect to work and what format responses
are likely to be in (for example, whether to expect an 'ls' format or DOS
'dir' format for directory listings).

Similarly, knowing which version you are running may enable a client to use
more advanced features - for instance, the REST command in stream mode,
which was implemented long before there was a portable method to indicate
that it would be supported.

In the absence of such information, a client may have to guess (and
sometimes get it wrong, or miss useful features), or the user will have to
tell it specifically what server is being connected to.  This means that you
have to supply your users with exactly the same information that you are
intending to deny them, thus making it no harder on the hacker, and more
annoying on your own users.  This seems not to be such a good idea.

However, reporting the minor version numbers (often indicating what security
flaws have, or have not, been fixed) does seem less defensible.

Does anyone have any further views on whether to leave the server
software's name and version number in the 220 greeting message?

Alun.
~~~~

---
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email

Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*******-- Alpha processors now supported under Windows NT --*******

 
 
 

WU FTPD Version Information On Connection

Post by Michael Fu » Sat, 10 Oct 1998 04:00:00



> However, reporting the minor version numbers (often indicating what security
> flaws have, or have not, been fixed) does seem less defensible.

> Does anyone have any further views on whether to leave the server
> software's name and version number in the 220 greeting message?

I can think of a couple of views on giving out version information:

Hiding this information doesn't fix any bugs in the code.  If it was
vulnerable before, it's still vulnerable.  Security by obscurity isn't
much security at all.

On the other hand, if crackers don't have version information then
they'll have to try different things in an attempt to crack the
software because they don't know what vulnerabilities you have.
Hopefully your monitoring will pick up some of the failed attempts
before they have any success.

Just a few thoughts, both of which I'm sure could be disputed.

--
Michael Fuhr
http://www.fuhr.net/~mfuhr/

 
 
 

WU FTPD Version Information On Connection

Post by Alan J Rosenth » Sat, 10 Oct 1998 04:00:00


There is a general issue of banner identification.  Telnet banners usually
offer unix version info; several unix service banners traditionally offer
version info including (usually) smtp, pop3/imap, and ssh, as well as ftp as
you note.

My inclination is towards suppressing banner identification on basic
non-disclosure grounds, but I don't see that it necessarily helps.
If there is a known breakin program for wu-ftpd version minus-infinity-
plus-one, rather than connecting to your ftp daemon to see if it's the
compromisable version, someone can just run the breakin code.

There may be all sorts of ways to identify aspects of a machine or its
services.  The recent flurry of checking for the existence of the tcpmux
service to guess that it's an irix machine comes to mind.  Some of these
methods have similar success rates to banner checking, which is pretty high
but definitely less than 100% (some people use fake banners).

Better than killing the banner for something like wu-ftpd is to keep up with
security fixes.  Since the maintainers are pretty responsive to security
issues and since there isn't a large bureaucracy in the way in that particular
case, you can probably stay ahead of the "bad guys" by being on the alert
mailing list and installing new versions.  The more you change in each
version, the more work it is to install the new version; certainly, if you put
off the upgrade because you have to get around to making your change to
version.c, you're making a mistake in strategy.

 
 
 

WU FTPD Version Information On Connection

Post by Alun Jon » Tue, 13 Oct 1998 04:00:00



> I can think of a couple of views on giving out version information:

> Hiding this information doesn't fix any bugs in the code.  If it was
> vulnerable before, it's still vulnerable.  Security by obscurity isn't
> much security at all.

Specifically, if you're aware of a problem that _doesn't_ appear to be
fixed, it is in your best interests to inform the authors and expect a fix.  
Going to another product just lays you open to a _different_ set of flaws,
not necessarily a smaller set.

Quote:> On the other hand, if crackers don't have version information then
> they'll have to try different things in an attempt to crack the
> software because they don't know what vulnerabilities you have.
> Hopefully your monitoring will pick up some of the failed attempts
> before they have any success.

My call on this is (as has been pointed out before) if you've got a program
with flaw X, and it doesn't identify itself, then hackers will try flaws A-Z
on all 'unidentified' system, and eventually reach and find flaw X, thus
deducing the flavour of your system.  You think they don't have a script?

Especially if the banner serves some usability purpose (and for FTP servers,
I know it does, since I know of many FTP client authors that use it to parse
listing formats, etc), there is generally no security purpose to removing
it, save perhaps to slow the hacker down by a few seconds.

Alun.
~~~~

---
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find it
1602 Harvest Moon Place | at web site http://www.wftpd.com or email

Fax +1 (512) 378 3246   | NT based ISPs, be sure to read details of
Phone +1 (512) 378 3246 | WFTPD Pro, NT service version - $100.
*******-- Alpha processors now supported under Windows NT --*******

 
 
 

WU FTPD Version Information On Connection

Post by Michael Fu » Wed, 14 Oct 1998 04:00:00




> > On the other hand, if crackers don't have version information then
> > they'll have to try different things in an attempt to crack the
> > software because they don't know what vulnerabilities you have.
> > Hopefully your monitoring will pick up some of the failed attempts
> > before they have any success.

> My call on this is (as has been pointed out before) if you've got a program
> with flaw X, and it doesn't identify itself, then hackers will try flaws A-Z
> on all 'unidentified' system, and eventually reach and find flaw X, thus
> deducing the flavour of your system.  You think they don't have a script?

> Especially if the banner serves some usability purpose (and for FTP servers,
> I know it does, since I know of many FTP client authors that use it to parse
> listing formats, etc), there is generally no security purpose to removing
> it, save perhaps to slow the hacker down by a few seconds.

...which goes back to the first point in my previous post, that hiding
version information doesn't fix any bugs.  If you were vulnerable
before, you're still vulnerable.

Let's consider the situation, however, in which your software has
vulnerability X, which has only recently been discovered by crackers
and is not generally known about.  If you announce your software
version, and your particular version is known by the cracker to contain
vulnerability X, then the cracker need only try exploit X.  Since X
isn't commonly known about, you haven't plugged its hole and aren't
watching for it.  If the cracker is successful and then careful, you
may not immediately discover that you've been compromised.

On the other hand, if you don't announce your version then the cracker
has to try exploits A-Z to see if you're vulnerable.  Okay, you're
still hacked, if only a few seconds later than if you had announced
your version.  But hopefully the failed attempts in exploits A-Z have
tripped some alarms so at least you know you're under attack and should
check for damage.  Your system might even be able to automatically
start dropping packets from the attacking site and possibly prevent the
hack from happening.  This probably wouldn't work for a coordinated
attack coming from multiple sites, but it might prevent the lone kiddie
from getting in.

I'm not suggesting that hiding version information makes you any more
secure, but hiding it can force the would-be-cracker to work harder at
breaking your site, and this extra effort might be noticed and possibly
even thwarted by a vigilant monitoring system.  You can use scripts
too, you know.

--
Michael Fuhr
http://www.fuhr.net/~mfuhr/

 
 
 

1. wu-ftpd with RH v7 sending auth packet/wu-ftp connection delays SOLUTION

You can disable rfc931 in wu-ftp all you want, but it will not help unless
you also disable it in xinetd.  

Check /etc/xinetd.d/wu-ftpd  for:
        log_on_success          += DURATION USERID
        log_on_failure          += USERID

USERID forces xinetd to do a identd lookup on the remote user.  
Most times the userid is useless anyway, so you can just
change USERID to HOST to log the IP address instead.

        log_on_success          += DURATION HOST
        log_on_failure          += HOST

killall -USR2 xinetd  to restart/reread the config changes
and you should be in business.

BTW - Telnet access experiences no such delay, because xinetd is
not configured with log_on_success          += DURATION USERID
USERID is only called for on the login failure, which you would not
notice the delay on.

Cheers
George

2. Emergency boot disks for 4.2

3. Looking for wu-ftpd information

4. Programming BSD and Posix 4, differences?

5. Information for wu-ftpd

6. remotly check for trojans?

7. Solaris PKG version of WU-FTPD somewhere?

8. TCP/IP on standalone workstation

9. wu-ftpd shadow version pid file

10. how to set wu.ftpd refuse connection if no reverse DNS lookup??

11. wu.ftpd connection refused problem

12. wu.ftpd refuses connection?

13. wu-ftpd closes connection