COMMAND
metainfo
SYSTEMS AFFECTED
WinNT (MetaIP 3.1, Sendmail 2.0 & 2.5)
PROBLEM
Jeff Forristal found following. MetaInfo (www.metainfo.com) puts
out many NT service products, including MetaIP (DHCP/DNS manager)
and Sendmail (Unix port). Both products allow remote
administration via Web UIs, and MetaIP uses Java to communicate
back to the server.
MetaInfo bundles their own in-house web server, MetaWeb server,
for use with the web UIs and to serve the Java applets. The
server can be configured to run on multiple ports (default is
5000), and you specify a root directory per port. For instance,
you can run the server on port 5000, and use c:\webpages as the
root index, and run another instance on port 5001, and use
d:\inetroot as the root index. This configuration is stored in
the registry under:
http://mail.server.com:5000/../../
it is possible to retrieve files from the root (c:\) file
directory. Consequently, since this is an NT system, you can
request files from the winnt directory by specifying
http://mail.server.com:5000/../../winnt/
MetaIP's default directory is c:\metaip\java\webui, which would
require 3 levels of transversal to the root directory
(/../../../), compared to Sendmail's 2 (/../../). This allows
anyone to request, via a normal web browser (NOTE: only Netscape
browsers are able to retrieve unathorized files, from testing
made) any file known on the file system (directory browsing is not
allowed, so the filename must be known).
In a Sendmail situation, the most obvious file is the password
file used by the Sendmail program for POP3 access. This file is
located in c:\sendmail\smusers.txt and can be retrieved via the
web by
http://mail.server.com:5000/../smusers.txt
This file is in standard UNIX /etc/passwd format, and can have 3
types of entries:
1. a normal entry, where the password field contains a
standard crypt hash.
2. a blocked entry, where the password field contains a '*',
which doesn't allow logging in for that user
3. a NT authenticate entry, where the password contains a
!DOMAIN, causing sendmail to authenticate the user's
password to a NT DOMAIN. So, an entry of !NEOHAPSIS would
authenticate to the 'NeoHapsis' NT domain.
Since this file is in standard Unix format, that allows sysadmins
to copy /etc/passwd files onto the NT server (assuming a
heterogenous network). This means it is possible to find 'root'
password hashes in smusers.txt. Simpliest use for this file is to
strip out all blocked (*) and NT domain (!DOMAIN) entries, and run
Crack to find the passwords.
Of course, retrieval of a copy of the SAM would lead to password
compromise for the NT authentication. A typical copy can be
found in the /repair/ directory, and retrieved as:
http://mail.server.com:5000/../../winnt/repair/sam._
Directly requesting the SAM or other system-wide locked files
results in an in a Error 404 and an Application error is written
to the Event Log. The MetaWeb server allows the running of NT
batch/CMD files (this is how some of the Sendmail remote
configuring works); if an attacker was to upload or produce a
standard NT batch file, he could run any program he wishes. It
has also been proven that the MetaWeb server will allow execution
of any application on the server. Execution of command line
applications will have their results sent back to the browser.
GUI applications will NOT be displayed on the server, but will
result in the MetaWebs.exe process to spike to and maintain a 100%
utilization.
To execute a command, you must append a '?' to it; otherwise, you
will merely download the application. For instance:
http://mail.server.com:5000/../../winnt/system32/net.exe
would download net.exe; however,
http://mail.server.com:5000/../../winnt/system32/net.exe?
will run the net program. Command line parameters are possible,
using '%20' for spaces. So
http://mail.server.com:5000/../../winnt/system32/net.exe?user%20joe%20/delete
would delete user 'joe' (however, certain commands will not work,
including subsets of the 'net' command. This was just an
example). Even worse, by enabling remote administration of MetaIP
causes the software to make an NT share with full permissions to
the Everyone group. The share is hidden as MetaIPAdminData$.
This is presumably so a remote client generates the proper
named.conf files locally, and then the Java applets open a local
conection to the server via the share to actually write the
configurations.
All the DHCP information is kept in an Access Database located in
c:\metaip\data\MetaIPAdminData.mdb
It is password protected; however, it is no surprise to find out
the password is 'metaip rules'.
As far as the Java applets go, they require a name and password
to log into the server, which is then sent over the wire. A
network packet capture of this transaction shows a data packet
that contains a plaintext user name, and what appears to be a 8-10
character password hash.
MetaIP and Sendmail both include security mechanisms via passwords
and even restricting remote access to certain IP ranges/addresses.
Problem is that this information is NOT used by MetaWeb server.
Each product uses an application CGI to process and handle remote
requests (ie. handling a POST from FORM data on a web page), and
it's these CGIs that take into account password and IP
restriction. Since we are not running the CGI applications (we
are not using HTML FORM elements POSTed to the CGI applications,
such as config.exe for Sendmail, to access the information), the
security is effectively bypassed.
According to Perry Harrington, following would be possible
(upload):
GET ../../winnt/system32/cmd.exe?/c+copy+/b+con+c:\temp\trojan.exe HTTP/1.0
Or if you want to create a text file:
GET ../../winnt/system32/cmd.exe?/c+copy+con+c:\temp\trojan.txt HTTP/1.0
and terminate with a ^Z. Theoretically the commands above should
work for the sendmail case explained before.
Identifying a victim:
---------------------
For sendmail, telneting to port 25 will yield a banner stating
'Sendmail 2.0/ 2.5 (Build xxxx)', which lets you know they're
running MetaInfo Sendmail (v2.5 includes MetaInfo's name in the
banner). For MetaIP, if remote administration is enabled,
telneting to port 2040 (default) will give you a prompt to the
effect of 'V3.1'. Of course, the default Java config port of
2040, and the web UI ports of 5000 and 5001 are user-definable;
so it is possible to have these services running and not on these
particular ports. A thorough port scan would resolve that issue.
SOLUTION
There's a patch online, available, with instructions, at:
http://www.metainfo.com/download
While this patch corrected the problem of transversal into higher
levels of the filesystem, it is still open to another kind of
DoS attack (see metainfo #2).