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
|
