Courant octobre 2014, j’ai pu reporter deux vulnérabilités de type « Reflected XSS » et « DOM-XSS » aux équipes en charge du domaine principal « java.com ».
La vulnérabilité RXSS affectait l’ensemble du module d’aide de www.java.com, quelque soit le template de la langue utilisée. La DOM-XSS quant à elle impactait uniquement le module d’impression des pages. Revenons plus précisement sur ces vecteurs d’attaque.
Une RXSS ou une DOM-XSS permettent toutes deux d’injecter du code arbitraire au sein du rendu des pages web d’un domaine. Visant à falsifier/détourner le comportement légitime d’une page dans le navigateur des utilisateurs cibles, ce type de vulnérabilité peuvent générer d’importants dégâts.
Dans le cas présent, le bien connu site officiel de téléchargement de « Java », régulièrement falsifié par des assaillants pour infecter des victimes de faux plugins, présentait ces vulnérabilités.
Le paramètre GET de gestion de la pagination « n » dans la FAQ n’était pas suffisant nettoyé et validé avant d’être réutilisé au sein du code de la page. Il était possible de le faire suivre d’un code JavaScript valide pour l’exécuter dans le contexte du navigateur des victimes.
https://www.java.com/fr/download/faq/index_general.xml?n=20'>2</a><script>alert(/Yann CAM @ASafety - www.synetis.com/);</script>
Démonstration de l’injection (Firefox 32) :
RXSS canonique java.com
Le contexte utilisateur d’exécution du code JavaScript permet la manipulation des cookies :
RXSS et récupération de cookies
L’autre page vulnérable était en réalité la fonctionnalité d’impression « printFriendly » de la documentation/FAQ de Java. Pour ne pas polluer les impressions des pages, Java.com propose un petit icône d’imprimante qui mène au même contenu que la page courante, sans les fioritures, logos, et diverses images. Ceci se traduit par l’ajout du paramètre « ?printFriendly=true » dans l’URL :
Affichage en mode impression de la documentation Java
Vous remarquerez très certainement que l’URL courante, sans les paramètres GET ni les ancres (si indiquées) est intégrée dans le contenu de la page en haut à gauche. L’objectif est que l’utilisateur ayant imprimé la documentation, puisse garder une trace de l’URL de la version en-ligne.
Le code réalisant cette incrustation automatique de l’URL courante est le JavaScript suivant :
<script type='text/javascript'>document.write(document.location.href.split('?')[0]);</script>
Visible à même le code source :
Récupération de l’URL courante en JavaScript, sans les paramètres ni ancres
Cette instruction engendre la présence d’une vulnérabilité de type DOM-XSS, à savoir des XSS calculées, interprétées et exécutées qu’au niveau du DOM du navigateur (et non pas du code source de la page retournée par le serveur).
L’instruction découpe l’URL courante en fonction du caractère « ? », utilisé pour séparer le script appelé des paramètres GET transmis à la page.
L’idée de la DOM-XSS est d’ajouter un code arbitraire avant ce caractère « ? ». Seulement il ne faut pas modifier le nom de la page atteinte qui exécute le code.
L’utilisation de la séquence « %0a%0d » (LF / CR) url-encodée dans la barre d’adresse permet de forcer un retour à la ligne lorsque le serveur va interpréter le fichier requêté. L’injection suivante permet cela :
http://java.com/fr/download/help/uninstall_needolder.xml%0a%0d<script>alert(/Yann_CAM_@ASafety_www.synetis.com/);</script>?printFriendly=true
La page « uninstall_needolder.xml » est correctement appelée, et le paramètre « ?printFriendly=true » lui est transmis. Ainsi le « document.write() » JavaScript est réalisé. Celui ci récupère tout ce qui se trouve avant le « ? » dans l’URL, à savoir
http://java.com/fr/download/help/uninstall_needolder.xml%0a%0d<script>alert(/Yann_CAM_@ASafety_www.synetis.com/);</script>
Il traduit ensuite le « %0a%0d » comme un retour à la ligne / fin de chaîne (\r\n), et injecte donc dans le DOM notre XSS.
Remarque :
Les navigateurs actuels auto-url-encodent les balises xHTML / JavaScript au moment de leur insertion dans le DOM. C’est pourquoi, dans le cadre du présent PoC, les tests ont été effectués sur une ancienne version de IE :
DOM-XSS java.com
Ces diverses vulnérabilités ont été reportées aux équipes en charge du domaine Java.com/Oracle. Celles-ci ont été corrigées très rapidement suite à plusieurs échanges.
Hello Yann,
Thanks you for reporting these issues, we have validated both issues, the RXSS issue on all browsers with the second DOM-XSS issue on an old version of IE.
We will be getting in touch with the team responsible for this site to have them resolve these issues, once they have been fixed we will ask you to validate the issue has been resolved.
Regards,
Oracle GIS
L’XSS a été corrigée sur l’ensemble des templates de langues, en nettoyant les caractères spéciaux. La DOM-XSS a été patchée en découpant l’URL non plus sur le caractère « ? » mais sur l’extension « .xml » bloquant ainsi le détournement du nom du fichier :
Patch de la vulnérabilité DOM-XSS
Les équipes de Java / Oracle ont salué cette contribution sur leur acknowledgement page du Q1 2015 recensant les vulnérabilités et correctif par trimestre.
Java/Oracle acknowledgement page 2015 Q1
Par le biais de ces injections, il aurait été très simple de falsifier le rendu d’une page, modifier le lien de télécharger de « Java » ou encore corrompre l’enchaînement habituel des pages. De telles injections publiques et exploitées par des assaillants sur le domaine légitime et officiel « java.com » aurait pu causer des désastres importants…
Je salue, pour achever cet article, les équipes qui sont intervenues sur la correction de ces vulnérabilités et les remercie.
Sources & ressources :
