TUCoPS :: Unix :: General :: warftpd.txt

War-ftpd v1.70b has bugs in its macro interpreter that allow a remote attacker to gain all sorts of unauthorized access.


[ http://www.rootshell.com/ ]

From sd@SINISTER.COM Thu Jan  6 09:54:10 2000
Date: Thu, 6 Jan 2000 05:48:40 -0000
From: Sir Dystic <sd@SINISTER.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Re: SECURITY ALERT - WAR FTP DAEMON ALL VERSIONS

Thanks for the props Jarle.


The current release (beta) of War-ftpd v1.70b seems to have some serious
problems with the parsing of macros.  The current version doesn't even seem
to document the macros available, but in the response files (sysmsg?.txt)
you are supposed to be able to put macros in the form [$macroname].  The
server also uses these macros internally, but most of the macros I've seen
seem to be non-functional (return ???).  The available macros seem to be:
systemname programname programversion prgcopyright dirmsg email greeting
diskfree endmacro maxanons anonsonline restrictions osname uniquefileoption
idletime ulcounttrash udrestrictions ulctype credit ulratio dlratio
dlkbcount dlfcount dlcount ulkbcount ulfcount ulcount origin user
usersonline and most interestingly the sql macro, which is the only one
that's even documented:

The macros in the server response messages supports SQL queries.  The syntax
is: [$sql, #MaxRowsReturned, SQLStatement] If #MaxRowsReturned is 0 (zero),
all matching rows will be displayed.

These macros are interpreted before text is returned to the user and
replaced with the appropriate text.  The problem is, there's nothing to
prevent the remote client from passing these macros to the server and having
them repeated and interpreted and returned to the user.  In fact, it's not
even necessary to log in since if you send it an invalid literal command (as
any of the intrepreted macros would be) it returns: 500 'whatever': command
not understood.  So as soon as you're connected to the server, even before
you log in, you can execute "literal [$osinfo]" or any of the other macros. 
It seems to disconnect if you attempt to get some of the macros before
logging in.  I haven't found a war-ftp server running on a machine with the
sql interface enabled to test on, but I suspect any sql query could be fed
in this manner, although the help does say: 'The execute statement is forced
to read-only to prevent data updates from this macro.  SQL statements like
UPDATE, DROP, or CREATE will give an error.'

More frightening is the interpretation of macros not beginning with a $. 
These are replaced with the contents of the file contained in the square
brackets.  So if you execute "literal [warsvr.conf]" you will be returned
the error:

500 '[Options]
core_RESNAME=WARSVR
core_RPCPORT=0
core_PRIORITY=2
core_TRAYICON=1
core_WM_CLOSE=1
log_LOGFILE=Log/%Y-%m-%d.log  
... etc
': command not understood.

This particular file contains the fields odbc_USER and odbc_PASSWD which may
contain a plaintext login to the sql server.  In fact, you can put
[x:\anydir\anyfile] if you know the path to an existing file.  If the server
is running on NT, UNC and network paths may even work (I couldn't get them
to on my machine, but it sure paused like it was doing something network
related).  Although this method works perfectly for text files, it only
displays some of the data in binary files, and not always the top of the
file.  As was mentioned in an bugtraq post from a while back, this beta
stores it's passwords in plaintext, and viewing a waruser.dat with several
accounts in it may well reveal these passwords.

There also seems to be a bug in the parser of the macros itself relating to
unmatched square brackets.  Executing literal open bracket commands often
dumps random chunks of memory, or simply closes the session (kills the
thread?).  With the server running under 95 I've seen it dump session text
from other active sessions, usernames, ip addresses, passwords, and plenty
of random chunks of memory.  There seems to be little consistency to what
memory is displayed or when it decides to simply disconnect.

It also fails to properly check for the existance of directories when you
change into them, so "cd nonexistingdirectory" will change your cwd to
nonexistingdirectory which will just apear to be empty if you do a ls. 
However, because of this bug you can cause more interesting things to happen
by changing to a directory with an unmatched open bracket in its name and
then repeatedly doing pwd.

All it takes is for the sysadmin password to show up and the server can be
remotely administered using the daemon manager that comes with the software. 
Then access could be granted to any local or network drives available to the
machine and account war-ftpd.exe is running as.

Oh, and if you do "literal help somethingnotrecognised" it seems to hang
that connection.

I suspect this is just the tip of the iceburg, and it is beta software, but
it also seems to be in extremly wide use and those users are putting
themselves at serious risk.  I'm also fairly certain that all this info is
'in the wild' already.

        Sir Dystic
   Cult of the Dead Cow
    sd@sinister.com

[ http://www.rootshell.com/ ]


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH