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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:01:14 PDT