Server Subject to Attack
Reported November 16, 1999 by Erik Iverson
- NetFtpd distributed with NetTerm 4.2.a/4.2.2/4.2.1, and possibly
According to the bulletin at Dragonmount,
Many insecure options are enabled by default. A number of buffer overflows also exist.
Users of the program NetFtpd (which 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
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
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
InterSoft has been notified about this problem. Their
response to Dragonmount was brief, sharp, and highly unprofessional. Kenneth R. Robinette
of InterSoft replied, "You guys are a bunch of fools..."
You"d be well-advised to steer clear of companies that
display such complacency.
Discovered by Erik Iverson
Posted here at NTSecurity.net on November 16, 1999