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 erikat_private http://www.dragonmount.net/ http://www.dragonmount.net/security/dna/ http://www.dragonmount.net/security/vra/
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:13:37 PDT