Security vulnerabilities in MetaInfo products

[jeff () WIRETRIP NET (Jeff Forristal)]

Intro:
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.

Problem:
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:
HKEY_LOCAL_MACHINE/software/metainfo/metaweb

The problem is that the MetaWeb server doesn't restrict you to the root
directory.  By using /../ notation, you can escape to higher levels of
the file structure, and retrieve known files.

For instance, the default MetaWeb server root for Sendmail is
c:\sendmail\web.  A request to to http://mail.server.com:5000 will
retrieve
index.html from this directory.  However, by requesting
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 my testing)
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, I
was not surprised to find out the password was '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.  I have yet to
determine if the application is immune to a packet-replay attack.

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.

In a nutshell, this whole thing boils down to the fact that the security
is in the program/application CGIs, but the MetaWeb server is completely
open.  If you haven't figured it out yet, this is not a problem that leads
to an attacker directly reconfiguring your MetaInfo product; however,
should the attacker gain access to password info, it is possible that he
could use that info to go back and reconfigure the MetaInfo product via
normal means (the web UI), but security and IP restriction would then
apply.
So, just because an attacker retrieved your Sendmail password file, this
doesn't mean he can log into the web UI and reconfigure the software if
you have your IP restrictions set correctly.  But he can use the passwords
to log into the server via POP3 and retrieve email, as well as test
whether
those user/password combinations are valid for other services (ftp,
telnet,
etc).

Logging options exist in the configuration of each product, but this turns
out to only log CGI application accesses, and not standard web accesses
via
MetaWeb server.  There is a registry entry regarding logging for MetaWeb,
which defaults to 'N' (No?).  I attempted to set this to 'Y', with out
apparent results.

Who's vulnerable:
It seems anyone with remote administration of these products (MetaIP 3.1,
Sendmail 2.0 & 2.5) is vulnerable to the MetaWeb server file retrieval
hole.  How to fix it?  Simple: turn off remote administration.

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.

As far as current victims, MetaInfo has conveniently compiled extensive
lists located at:

www.metainfo.com/products/sendmail/users.htm
www.metainfo.com/products/metaip/users.htm

each with approx. 100 names, including such people as:

US Army STRICOM, US Coast Guard R&D, Federal Aviation Administration
(FAA),
IBM Global Services, IEEE Computer Society,  and NBC.

MetaInfo's Stance:
I contacted MetaInfo on June 21st about the problem and requested a reply.
To this day (June 30th) I have still not heard back from them.
Suspiciously,
after I contacted them, MetaInfo disabled their remote administration of
thier Sendmail server (they were vulnerable as well).

-Jeff Forristal
Neohapsis,  Inc.

More information about the MetaInfo bug will be posted in the future at
www.forristech.com.