NetFTPD Server Subject to Attack
Reported November 16, 1999 by
Erik Iverson
VERSIONS AFFECTED
  • NetFtpd distributed with NetTerm 4.2.a/4.2.2/4.2.1, and possibly previous versions

DESCRIPTION

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!*

  1. 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.

  2. 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.

  3. 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.

  4. 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.

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.

VENDOR RESPONSE

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.

CREDITS
Discovered by Erik Iverson

Posted here at NTSecurity.net on November 16, 1999