This module requires access to an account which has permission to export and import dashboards in ePO. You will need to log into the ePO web interface (proxied through OWASP ZAP, Burp Suite, etc.), navigate to an existing dashboard, and capture two values for use in OTORI - the session ID cookies, and the ePO security token value.

The session ID cookie string looks something like this:

JSESSIONID=62007442EA6B53C7AFE46E0BBE5B8E9D; orion.login.language="language:en&country:"; JSESSIONIDSSO=8613AD47217BB13D403BD81BE0160114; orion.content.size="width:1470&height:606"

*IMPORTANT*: you *must* navigate to an existing dashboard (or possibly some other subset of content) in order for all of the cookie content to be populated correctly. If your use of this module is failing, make sure that you are correctly capturing both the JSESSIONID and JSESSIONIDSSO values.

The security token value for the logged-on user is found in a hidden form input on most/all pages within the ePO web interface. The hidden form input looks something like this:

<input type="hidden" name="orion.user.security.token" id="orion.user.security.token" value="H6iHJPdR9fR1mjTs"/>

You should only copy/paste the actual value, without quote marks (in this case, H6iHJPdR9fR1mjTs).

Certain files may be truncated or corrupted in other ways by ePO - there is a roughly 1024-character limit on retrieved content - and some characters are escaped by the ePO parser before being returned*. This module attempts to unescape them, so if the actual file contained faux-escape-sequences, the results will be inaccurate.

This module is also a bit slow (5-10 seconds to retrieve each target file**). Are you excited about using it yet? But really, there is at least one good reason to, if you keep reading into the section about the ePO database configuration file.

There is some unavoidable (to my knowledge) evidence left behind when using this module - even though it deletes the temporary dashboards it creates, ePO increments the dashboard ID number, so an attentive administrator may notice that this value has suddenly jumped by hundreds or thousands. In extreme conditions, perhaps the number can grow too large for the database to represent, although I have not encountered this myself.

---

Oddly, on my test system the first line of any result obtained through ePO would be corrupted - and this was while testing manually, before the OTORI module was even written. This occurred even when using fields other than the Description field to contain the XXE content.

For example, when retrieving the contents of C:\boot.ini (file:///c:/boot.ini), the actual file would begin with these two lines:

	[boot loader]
	timeout=30

...but the content returned by ePO was:

	t lot loader]
	timeout=30

Similarly, when retrieving a directory listing of the C: drive, the first two entries should have been:

	ADFS
	AUTOEXEC.BAT
	
...but the following lines were returned by ePO


	AUT
	AUTOEXEC.BAT
	
(There was actually a leading newline before the "AUT")

In these specific cases, you can see the the first four characters of the content are replaced by copies of the fifth through eighth characters of the content. I am unsure if this is always the case or not.

I initially suspected that this was an artifact of obsolete libraries on the test system - it was an unpatched Windows Server 2003 R2 instance, and this odditiy is not mentioned in the original disclosure of the vulnerability by RedTeam Pentesting GmbH. However, even with all possible OS-level patches and updates applied, the issue persists on my test system.

Maybe there is some sort of memory-overwriting vulnerability here as well that can be used to e.g. write a Metasploit remote code-execution module?

---

RedTeam Pentesting GmbH specifically suggest obtaining the ePO database configuration file via the vulnerability in their writeup (https://www.redteam-pentesting.de/advisories/rt-sa-2014-001.txt or http://www.securityfocus.com/archive/1/archive/1/531255/100/0/threaded):

By default on 64-bit English versions of Windows, this would be:

file:///c:/Program Files (x86)/McAfee/ePolicy Orchestrator/Server/conf/orion/db.properties

On 32-bit English versions of Windows:

file:///c:/Program Files/McAfee/ePolicy Orchestrator/Server/conf/orion/db.properties

Nathan Einwechter's Metasploit module "post/windows/gather/credentials/epo_sql" contains the encryption key for ePO 4.6 in a signed 8-bit format. Converted to ASCII hex, it becomes:

0x5E9C3EDFE625843666219380315A2933

Because of McAfee's unfortunate decision to use a fixed encryption key for every installation of ePO 4.6, anyone can decrypt the password obtained from this file via the following steps:

Obtain the base64-encoded password from the recovered file. For example:

	db.user.passwd.encrypted.ex=YagHmc2w9cDzid1EKHz6VtYWE2o8GFmz2BbIDPneQ+KX6dwLjkjsC1lhKqciAp3aZvKW/zl9bJ3CcBG1Acw3YXWAcvvt3Ct8v/JcM0ZOaB0\\=
	
If the base64-encoded value ends in equals signs, remove the double-backslashes, e.g.:

	YagHmc2w9cDzid1EKHz6VtYWE2o8GFmz2BbIDPneQ+KX6dwLjkjsC1lhKqciAp3aZvKW/zl9bJ3CcBG1Acw3YXWAcvvt3Ct8v/JcM0ZOaB0=
	
Decode the data to binary, e.g.:

	echo "YagHmc2w9cDzid1EKHz6VtYWE2o8GFmz2BbIDPneQ+KX6dwLjkjsC1lhKqciAp3aZvKW/zl9bJ3CcBG1Acw3YXWAcvvt3Ct8v/JcM0ZOaB0=" | base64 -d > /var/tmp/fixed_encryption_keys_are_awesome.bin
	
Decrypt the binary data:

	openssl enc -d -aes-128-ecb -in /var/tmp/fixed_encryption_keys_are_awesome.bin -out /var/tmp/decrypted_epo_password.txt -K 5E9C3EDFE625843666219380315A2933
	cat /var/tmp/decrypted_epo_password.txt
	
Or, if you would rather not write it to a file:

	openssl enc -d -aes-128-ecb -in /var/tmp/fixed_encryption_keys_are_awesome.bin -K 5E9C3EDFE625843666219380315A2933

---

This module does not appear to be capable of successfully triggering a denial-of-service condition using --dos-lulz. It can temporarily peg the CPU of the target system using --dos-quad, and cause the tomcat5.exe process to dramatically increase its memory use, but it does not appear to be possible to actually crash the Tomcat process or otherwise create a persistent DoS other than by re-running the --dos-lulz attack continuously.

---

* the following ASCII characters are escaped: 0x09 (tab), 0x21 (!), 0x22 ("), 0x23 (#), 0x24 ($), 0x25 (%), 0x27 ('), 0x28 ((), and 0x29 ()).

** during testing against an ePO instance on another system attached to the same switch, it took 101 minutes to attempt to download 550 files or directories starting from the URI file:///c:/Program Files (x86)/McAfee/ePolicy Orchestrator/ - an average of about 11 seconds per request.