[12678] in bugtraq
DNA-1999-001: NetTerm FTP Daemon vulnerabilities
daemon@ATHENA.MIT.EDU (Jeremy Iverson)
Mon Nov 22 14:54:49 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <LOBBLDPBJIBNNFAOHFKKCENDCCAA.jeremy@dragonmount.net>
Date: Mon, 22 Nov 1999 11:33:52 -0600
Reply-To: Jeremy Iverson <jeremy@DRAGONMOUNT.NET>
From: Jeremy Iverson <jeremy@DRAGONMOUNT.NET>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
DNA-1999-001: NetTerm FTP Daemon
Vendor:
InterSoft
Vendor Status:
November 15, 1999: We notified InterSoft of the security issues.
November 15, 1999: InterSoft (sort of) responded. See
http://www.dragonmount.net/security/vra/InterSoft/NetFtpd_response.htm for
details.
Program:
NetFtpd distributed with NetTerm 4.2.a/4.2.2/4.2.1, and possibly previous
versions
Platforms:
All versions of 32-bit windows
Risk:
High
Problem:
Many insecure options are enabled by default. A number of buffer overflows
also exist.
Solution:
Vendor: Don't enable insecure options by default. Perform length validation
on all input to the program.
User: Immediately cease use of NetFtpd unless you are absolutely positive
that it is configured correctly, your box isn't open to a console attack,
and the only account activated is your own. Disable anonymous access
immediately.
Details:
Users of the program NetFtpd (comes standard with the newest version of
NetTerm 4.2.a, and possibly previous versions) are vulnerable to myriad
security problems. The ones we have concentrated on deal strictly with the
FTP server itself, and not the NetTerm terminal emulation program.
*NONE OF THIS AFFECTS THE NETTERM CLIENT, ONLY THE FTP SERVER BUNDLED WITH
IT!*
By default, the FTP server allows access to the entire hard drive to anybody
presenting any user name. There is an option that says "Accept calls from
anyone." This option is misleading; I took it to mean "Accept connections
from anyone.", not "Let anyone log in." Why would there be an option to let
anyone presenting any userid full access to the hard drive? By default this
is on, and all servers I have seen configured have left this option turned
on. This should not be an option, period. If it is an option, it should not
be the default. Absolutely ridiculous.
Anonymous access is allowed by default. Sure, many FTP servers come
configured this way. Unfortunately, the default (without any configuration)
read and write drive for user anonymous is C:\. This means even if you force
people to provide a login/password, allowing anonymous access without
changing the directory privileges gives anyone full access to the hard
drive. Also, write privileges do mean write; overwrite even. Running the FTP
server "out of the box", anyone can upload a new autoexec.bat, etc. Plus,
users have delete privileges by default. There isn't an option to turn off
deleting files, or even writing files for that matter. It is all or nothing
with this program. The default read/write drive for anonymous should be a
directory lower than the root directory. Perhaps C:\Program
Files\NetTerm\FtpRoot would be more appropriate. Secondly, anonymous access
should be turned off by default.
The password scheme is weak. First and foremost, there is no "administrator"
type password. Anyone with console access can add/delete/and change any
user's password. There should be an admin password required before any of
this action can be taken. The passwords are stored in a file by default
called "password". The form of the file is
user1:encryptedpass
user2:encryptedpass
etc..
So, by having access to this file, users don't need to use the program as
front door. They can edit this file by hand, adding/deleting/changing users
passwords. In most cases, users can upload a new "password" file,
overwriting the current settings. This assumes the directory problems aren't
fixed as noted in [2]. Also, the encryption method is weak and would not
take much skill to break.
Surprise, a closed-source Windows FTP Server has a buffer overflow. Nothing
exciting here. It appears that the USER command is truncated to 16
characters; no problem there. The PASS command also seems to stand up to our
testing. However, there are problems with the following when a large string
[~1024 chars] is sent to the server: dir, ls, mkdir, pass [when used for
anonymous access], delete, and rmdir. These all crash the server with an
invalid page fault. From the looks of it, remote code execution is a
definite possibility. You'll notice that PASS has an overflow only when user
anonymous logs in [i.e. where it asks for email address]. This is why
anonymous access should be disallowed immediately if you are to continue
using this product.
Conclusion:
With everything wrong with this program, it is only our hope that no one
person or business will use this for any machine that they wish to be
secure. Hopefully, after these problems have been brought to InterSoft's
attention they will be fixed in a new release. Users should thoroughly test
that anonymous access is disallowed, and that any user name will not work.
When logging in, they should restrict themselves to certain directories, not
the entire C:\. This way if their username/password is compromised, the
entire C:\ will not be open. There may well be other exploits that work in
this manner. If you allow anyone access, even anonymous, do not let them
read the directory the program was installed in. They will be able to
retrieve the password file remotely and steal all the encrypted passwords,
which may yield elevated access.
Release: November 15, 1999
Dragonmount Networks Advisory 1999-001 [DNA-1999-001]
Erik Iverson
erik@dragonmount.net
http://www.dragonmount.net/
http://www.dragonmount.net/security/dna/
http://www.dragonmount.net/security/vra/
