Responsible disclosure #1: Numericable


Je tiens tout d’abord à remercier les gens de la cyberdéfense de SFR qui ont fait preuve d’un professionnalisme exemplaire, qui étaient très sympa, m’ont fourni un compte de test et m’ont permis d’écrire cet article :)
Grace au signalement des différentes vulnérabilités, la sécurité de Numericable a pu être améliorée.


En quête de savoir et de l’envie d’améliorer la sécurité de mon pays, j’ai commencé à m’intéresser aux FAI et à leurs sécurités.
Etant à l’école 42 et client chez Free, mon attention s’est naturellement portée sur eux.
Malheureusement, ils n’ont aucun personnel s’attelant à la sécurité de leurs services (du moins, XN ne semble pas être au courant et encourage à aller voir zataz).
J’ai ainsi voulu chercher ailleurs et, c’est là que je suis tombé sur Numericable.
Pour ceux ne sachant pas, ils ont fusionné avec SFR en 2014.
Plusieurs amis étant clients la bas, l’un d’eux m’a informé qu’ils ont un centre de cyberdefense et m’a proposé de jeter un œil.

Quand on entend que nos mots de passes sont compromis, on pense tout d’abord à notre boite mail.
En effet, celle-ci contient toutes nos informations personnelles, incluant les autres sites ou nous sommes inscrits.
C’est pourquoi mon attention s’est immédiatement portée sur webmail.numericable.com
Pour vous mettre dans le contexte, celle-ci est assez classique :
On peut faire des notes, ajouter des contacts, enregistrer des évènements, etc.
Mais, il est aussi possible d’enregistrer des fichiers sur un « disque virtuel »

Après avoir dressé un schéma rapide du Webmail, j’ai voulu commencer par là.



Playing with the file storage

En allant dessus, on remarque qu’il est possible de créer des dossiers qu’on peut ranger dans d’autres dossiers créés au préalable.
La plupart des requêtes que l’on peut faire sont gérées par des pages qui sont dans le dossier « /ncn/docs/ »
Au moment de créer un dossier, le formulaire envoie aussi notre dossier courant.
J’essaye tout d’abord de créer un dossier « ../ » mais, le serveur me retourne une erreur.
Quand on va dans un dossier, on envoie les paramètres «dft_view=tree&dir=MonDossier »
Je modifie la requête et envoie un ../ dans la variable dir….
Bingo !
Il est possible de se déplacer dans les répertoires et de lister tous les fichiers contenus dans ceux-ci.
Par contre, impossible de les lire…
Maintenant que je sais où se situe divers fichiers, je peux peut être les déplacer afin de les récupérer pour les lire ?

Un rapide coup d’œil sur la requête normale m’informe que les variables qui m’intéressent sont dir, move et uid !
On modifie un peu cette requête…
/ncn/docs/docs_valid.php Post-content : dir=../&sort=1&act=&move=MonDossier&transform=&write=&view=tree&_=&uid[]=fichiercritique

Là encore, je tape dans le mille !
Ça fonctionne comme je le souhaite et je récupère le fichier voulu.
C’est un fichier spécial contenant mon email ainsi que mon mot de passe (chiffrés, heureusement)
Après d’autres tests, j’ai pu découvrir que l’on peut agir sur la plupart des dossiers contenus dans le serveur du disque virtuel en les déplaçant, supprimant, renommant, etc…

29/09/2017
J’ai contacté la cyberdéfense SFR et ai reçu une réponse 2h plus tard m’informant que la chose était prise très au sérieux !
Le soir même, je recevais un coup de fil me remerciant chaleureusement et m’informant que tout serait fait pour palier à ce problème. Le Webmail était mis en maintenance le temps que le problème soit résolu.

02/10/2017
Webmail de retour, je demande un compte de test afin de faire des recherches plus approfondies et que les soucis que je rencontre puissent être ciblés plus rapidement.
Bon, les disques virtuels n’étant pas de retour à ce moment-là, j’ai décidé de chercher autre part.


Recherches approfondies
Avec mon compte tout neuf, j’ai modifié toutes les informations qu’il était possible afin de capter les différents formulaires disponibles.
Après avoir tenté en vain différentes SQL Injection, je me suis tourné vers les XSS.
J’ai vu que les formulaires ne disposaient pas de tokens, rendant possible de modifier les préférences d’une victime sans que celle-ci ne s’en rende compte.
Pas mal… mais pas suffisant !
J’essaye donc d’envoyer directement une requête via XMLHttp pour récupérer le contenu de la réponse mais, heureusement pour l’opérateur, les requêtes CORS sont désactivées !
Du coup, en modifiant encore certaines requêtes dans les formulaires, j’ai pu voir que divers champs étaient mal sécurisés et permettaient l’injection de XSS.

Il est donc possible, en envoyant une page spéciale à une victime, de modifier ses préférences et d’injecter une XSS persistante pour faire ce qu’on souhaite.



Bon, c’est déjà mieux… mais encore ?
Après avoir vu tout ça, je me suis finalement penché sur l’envoi de mail pour pousser plus loin la criticité de ces différentes vulnérabilités.
Premièrement, je remarque immédiatement qu’il n’y a pas de tokens sur l’envoie de mails…
Parfait, voyons s’il y a une XSS possible….
Je modifie donc le sujet, le nom de l’expéditeur et le corps du mail…
Malheureusement, sans succès... Quoi que ?
Je refais un essai, mais plutôt que d’essayer d’envoyer des choses précises, je me contente d’envoyer ca :
<img src="https://site.com/image.jpg"kuromatae=test><br> Réception du mail, les double quotes sont transformées en simple quotes dans le sujet et l’expéditeur…
Dans le corps du mail, par contre, on voit bien l’image…
Ainsi que mon paramètre !



A partir de là, j’ai essayé différents vecteurs XSS et, après beaucoup d’essais, j’en ai finalement trouvé un qui m’intéressait !
La balise marquee… Couplée à l’event onstart, ça permet tout simplement d’exécuter le code javascript que l’on souhaite.
A ce moment-là, j’ai su qu’il me serait possible de faire quelque chose de vraiment critique.



Worm XSS

Encore une fois, quand notre ordinateur est infecté, une des choses qui nous inquiète le plus, c’est de savoir comment on va se débarrasser du virus et s’il ne s’est pas propagé sur nos clés USB, téléphone, autres ordinateurs…
Ici, c’est le même principe mais pour un site web !
Le but va être de faire un Worm un minimum persistant qui pourrait se propager tout seul chez l’intégralité des clients.
Tout ce dont nous avons besoin, c’est de la « persistance », de la « propagation » et de pouvoir « récupérer » ce qu’on souhaite.
Si vous avez suivi plus haut, vous pouvez voir qu’on a tout ce qu’il nous faut ! Pour la propagation, il nous suffira d’envoyer un mail à n’importe quelle adresse @numericable.
A l’ouverture du mail, la personne se fera infecter via les différentes préférences du webmail et, enverra un mail infecté à tous ses contacts afin que ceux-ci soient aussi infectés.
La propagation d’un Worm via un Webmail peut être très rapide, en imaginant qu’il y ait 10 millions de comptes et que chaque compte ait 2-3 contacts @numericable, en une semaine grand maximum la sécurité de la totalité des comptes aurait été compromise.



05/10/2017
Je recontacte la cyberdéfense pour leur signaler les XSS et les CSRF, le même jour ils me répondent que tout sera fait pour corriger au plus vite les vulnérabilités pointées du doigt.

09/10/2017
On me confirme que les vulnérabilités ont bien été corrigées, après vérification il semblerait qu’il ne soit plus possible d’attaquer les victimes par l’envoi de mail.



Conclusion

On notera que l’attaque était rendue un minimum compliquée :
Il était par exemple impossible de récupérer les cookies de la victime et donc de « voler » son compte.
Aussi, le worm nécessitait que la victime affiche automatiquement ses mails en HTML et non en plain text.
Enfin, lorsque celui-ci avait infecté le webmail de la victime, il fallait qu’elle aille écrire un nouveau mail pour qu’il se lance, je n’ai trouvé aucun point permettant de le lancer automatiquement dès l’ouverture du site.