Home Software Tradewars Security Tutorials Contact Privacy Projects WinSource.org [LINK] [USEMAP] [INLINE] IFRAME: http://ads.datais.com/ads/ad.cgi?Falcon-ad1&lmth=iframe&chnc=true Click here to visit our sponsor The Datacom Ad Network Security Home Advisories Vendor Response [INLINE] DNA 1999-002: Fictional Telnet/FTP Daemon 'Tis the season for DOS attacks and the like against closed source Windows servers, especially ones of the telnet, ftp and e-mail variety. Here's one more. Vendor: Fictional.net Vendor Status: December 10, 1999: We notified the vendor of the issues. Program: Fictional Daemon (Telnet/FTP Daemon) Version 3.1 (Possibly/Probably previous versions) Platforms: All versions of 32-bit Windows Risk: High Problem: Several problems including possible DOS attacks, probably remote execution of code, and poor logging practices. In addition, any user with write permission can retrieve or delete any file on the system, even above the root directory. Solution: Users: Cease use of this program until a fix is available from the vendor. Vendor: Do bounds checking on the CMD command. Do better permission checking on the FTP server, including directory transversal checking. Do not log invalid password attempts; invalid username and the IP should suffice. Details: 1) Denial of Service: Users who are allowed Execution privileges on the telnet server can perform a denial of service attack against the server and machine. By using the "CMD" command, which allows the remote execution of programs, users can send a long string and crash the server and or machine. Send the CMD command followed by roughly 10000 characters (multiple times in a row helps). Each one of these "CMD" commands will spawn a DOS box on the server machine with an invalid instruction fault. The effects of this are rather sporadic, ranging from the Blue Screen of Death to sending the server into "not responding" mode, thus denying connections. 2) Logging practices are poor. Upon receiving a bad username/password the combination is logged to a file in plain text. Users with console access to the machine may retrieve this file (in the default installation directory), but an even bigger problem with this is described next. The reason it is bad to log these things at all, especially in plain text, is that people who view the file will see passwords that may have been off by one or two characters and will easily be able to guess the user's passwords. This combined with the next vulnerability make for a bad combination. 3) It appears that even if the root is set at a certain directory, no checking is done on either a RETR (get) or a DELE (delete) command. Using a non-administrator account, I was able to retrieve and delete files in the C:\ root of my file system, when I had specified the program's installation directory as my FTP root. This is obviously not a good thing, as users who know the name of files (e.g., common system files) can retrieve or delete them. This includes the log file along with any sensitive information stored on the system. Release: December 10, 1999 Dragonmount Networks Advisory 1999-002 [DNA-1999-002] Erik Iverson erik@dragonmount.net http://www.dragonmount.net Top of page This page was last modified Friday, December 10, 1999 Copyright 1999 Dragonmount Networks. All rights reserved. Privacy and Usage Policy. Questions or comments? Contact us.