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.), 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"

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).

This module is also a bit slow (several seconds to retrieve each target 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.

This may be 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. 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

Finally, certain files may be truncated or corrupted in other ways by ePO, 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.


