Art of bug bounty: a way from JS file analysis to XSS

Jakub Żoczek | | Research, Uncategorized

Summary:

During my research on other bug bounty program I’ve found Cross-Site Scripting vulnerability in cmp3p.js file, which allows attacker to execute arbitrary javascript code in context of domain that include mentioned script.

Below you can find the way of finding bug bounty vulnerabilities from the beginning to the end, which includes:

  • In depth analysis of vulnerability,
  • Proof of Concept for consent.cmp.oath.com domain,
  • Proof of Concept for tumblr.com.

To describe the impact of this research, it is worth to mention that described research should also works for any other host that includes cmp3p.js file.

Browser’s Cross-Origin Communication:

To better understand this vulnerability it’s worth mentioning some mechanism that browsers implement to communicate between origins. One of them is postMessage. If site A have an <iframe> pointing to site B in its source, we can get access to DOM tree of site B from the site A. Because of Same-Origin Policy, to have full access both site A and B must be in same origin. Otherwise, to communicate one of sites need to add onmessage even listener, and second site can send events with data, which will be processed by function defined in listener. For example:

Site A:

Site B:

Above mechanism works not only over frames and pop-ups, but also between two tabs. For example if site A have hyperlink to site B, which gonna be clicked – page containing hyperlink can be accessed from new opened tab by window.opener.

Analysis:

During my research I’ve decided to take a look on main tumblr.com page, the plan was to discover if it handles any postMessages. I’ve find out that there’s interesting function in cmpStub.min.js file, that doesn’t check the origin of postMessage. In obfuscated form, it looks as following:

Basing on the above part of code, it is worth to notice that:

  1. It takes event data parameter (as JSON string),
  2. than parses it using JSON.parse() function,
  3. than create javascript object n containing attribute cmpCall (which is object).

Mentioned cmpCall object contains fields called command and parameter which are both based to window.__cmp() function:

Although this code is obfuscated, it’s analysis could be problematic, so I will focus on two most important lines:

After checking isSafeUrl definition, we can notice that it checks if URL provided in parameters object (this could be controlled by attacker) is safe:

If URL provided as function parameter contain javascript: string at beginning it should be treated as unsafe and return -1 (and stop futher execution).

Second interesting line is:

Let’s take a look on b() function definition:

As before – obfuscated, hard to read – but really interesting part here which gonna bring us to the point of this vulnerability is renderConsents() function. Definition:

As you can see – renderConsents() is finally interesting element from security perspective, because it creates iframe element with src attribute controlled by attacker, that can be controlled by attacker. We can easy execute Javascript code using <iframe> element by providing code as URI (in src attribute) – by using special URI schema / protocol – javascript. By using <iframe src=”javascript:alert(1)”></iframe> browser simply gonna execute alert(1) Javascript code. That was the reason why isSafeUrl() function was previously executed. So how we can still pass URL containing javascript schema at beginning?

It’s good to know that we can still use whitespace characters in schema part of URL, which gonna be ignored by browser. That brings us really simple bypass for isSafeUrl(), consists on provinding URL parameter with newline inside:

After this step, by constructing postMessage with this JSON, it would be possible to execute javascript code:

To pass this message into vulnerable page we also need to have a link to its window object, which can be easily achieved by putting vulnerable page into iframe. When we sum up all described steps, final Proof of Concept would look following:

As far as page doesn’t contain X-Frame-Options header, it doesn’t require any additional user interaction, visiting malicious website is sufficient. In case when application implement X-Frame-Options header this exploit won’t allow attacker to frame target page. Whole attack will require to create connection between two browser tabs to pass postMessages through window.opener, which is also pretty simple:

  1. Create a page containing hyperlink to itself.
  2. Execute window.opener.postMessage() function with payload in loop.
  3. After clicking a link – new tab opens (we have window.opener connection between tabs)
  4. Redirect first page to target straight after clicking a link (onclick event)
  5. Profit.

That was situation with tumblr.com page, which also contained vulnerable cmp.js code, but page itself wasn’t framable because of X-Frame-Options header. So the Tumblr exploit code looks like this:

Impact:

Attacker that can execute arbitrary javascript code in context of vulnerable target is able to abuse it in multiple ways such as:

  • Steal sensitive user’s data (personal data, messages, etc),
  • steal CSRF tokens and perform malicious actions on behalf of user,
  • steal account credentials and takeover user’s account,
  • …and many others.

Timeline:

07/10/2019 – Found vulnerability and reported it parallelly to Verizon Media and Tumblr
07/10/2019 – Triaged and fixed by Tumblr
08/10/2019 – Fixed by Verizon Media
09/10/2019 – Tumblr rewarded me with $500 bounty
26/10/2019 – Verizon Media rewarded me with $500 bounty

Author: Jakub Żoczek

Tagged: ,