Skip to content

Mes contributions sécurité : mi-2016

Lors de mes débuts en tant que « bug hunter », j’écrivais les détails techniques des bugs remontés à chaque trouvaille, c’est par manque de temps que j’ai arrêté de procéder ainsi. Je vous expose donc au sein d’un même article toutes les vulnérabilités que j’ai remonté et qui ont été corrigées depuis ce début d’année.

CMS en ligne payant : e-monsite.com

  • Date de découverte : Avril 2016
  • Date de correction : Avril 2016
  • Type : Reflected-XSS

e-monsite.com est un CMS en ligne, entendez par la qu’il s’agit d’un CMS de type WordPress mais dont l’interface d’administration est hébergée chez l’éditeur (en ligne donc). Je ne m’attaque d’habitude pas à ce genre de cible, mais en naviguant sur le site web d’un jeu auquel je joue fréquemment, j’ai découvert une faille de type Reflected XSS des plus classique dans via la fonction recherche.

Cette faille XSS de type réfléchie exploitait la réinscription de la recherche dans le code source de la page réponse. et plus précisément dans la balise « head » et « title« . Un simple code JS n’était donc pas exécuté :

<head>
  <title>Recherche : mon injection <script>alert(1)</script></title>
</head>
<body>[...]

Un tel code d’injection dans une balise « head » puis « title » n’a effectivement aucun effet, il suffisait donc de s’extraire de ces balises puis de s’intégrer dans le body proprement pour exécuter n’importe quel code HTML/JavaScript :

<head>
  <title>Recherche : </title></head><body> mon injection <script>alert(1)</script></title>
</head>
<body>[...]

Après un premier échange avec le webmaster du site web lebusmagique.com, j’ai compris qu’il utilisait en réalité le CMS e-monsite.com, ce que je n’avais pas réussi à voir après mes recherches. L’équipe de développement à donc ensuite été avertie et, après quelques clarifications sur les impacts et la production d’une vidéo démo, la faille a été corrigée.

Voici un PoC vidéo exposant l’exploitation de l’XSS, notamment dans le but de réécrire toute la page web et d’y intégrer une fausse mire d’authentification :

Il est à souligner ici que depuis une faille découverte sur un site web, c’était en fait tous les sites web utilisant le CMS e-monsite.com qui étaient vulnérables de la même manière (à partir du moment où ceux-ci intégraient le système natif de recherche). Cela a donc contribué à corriger plusieurs sites web en une seule fois, ce qui est l’avantage d’utiliser un CMS :  la recherche et la correction des vulnérabilités y est « mutualisée ».

Site gouvernemental : justice.fr

  • Date de découverte : 13/05/2016
  • Date de correction : 13/05/2016
  • Type : Reflected XSS

Il s’agit là d’un de mes « trophés » les plus prestigieux en tant que chasseur de bug et également de la réaction/correction la plus rapide qu’il m’ai été donné de voir pour le moment. Après un tweet exposant un article de loi dans ma Tweet List, je décide de me rendre sur le site justice.fr , le site officiel d’accès à la Justice, et son interface 2.0 très user friendly.

Ici, c’est également le système de recherche qui était vulnérable à une faille de type Reflected-XSS. Il se trouve que le site justice.fr semble utiliser le CMS Drupal 7. La fonction de recherche vulnérable viens selon moi d’un développement custom ou d’un plug-in. Quoi qu’il en soit, celui-ci réinscrivait la recherche de l’utilisateur sans passer par une phase de sanitization dans une partie JavaScript du code source :
justice-fr-01
Un payload fonctionnel nécessitait donc de sortir de la définition de la variable Javascript que l’on voit sur la capture d’écran ci-dessus. L’attaquant était alors libre d’injecter n’importe quel code Javascript dans la page retour. Voici un payload fonctionnel :

http://www.justice.fr/recherche/all/x"; alert("XSS"); x="ok

Il engendrait la présence du code suivant dans la page de retour :
Après soumission au CERT-FR (dépendant de l’ANSSI), la vulnérabilité a été remontée au FSSI (Fonctionnaire de sécurité des systèmes d’information) du Ministère de la Justice et corrigée. La vulnérabilité a été remontée un vendredi midi et a été corrigée avant la fin de journée sur le site justice.fr ! Une performance qui mérite d’être soulignée 🙂

Open-source / Web : PHPList version 3.2.4

PHPList est une application web très utilisée dans le monde du marketing, elle permet d’envoyer des spams campagnes d’email et de gérer ces mêmes campagnes. C’est en recevant un énième spam dans ma boite mail que j’ai eu envie d’auditer cette solution.

J’ai notamment trouvé une faille de type CSRF qui permettait de modifier les templates de mail (Draft) et une XSS Stored sur le nom de ce même templates de campagnes. En chaînant ces deux vulnérabilités, un attaquant pouvait donc facilement piéger un utilisateur pour qui modifie le nom d’un template de campagne mail afin d’y intégrer du code JavaScript qui lui ferait envoyer son token de session.

L’attaquant pouvait donc procéder à une session hijacking au travers une stored XSS en mode authentifié, sans avoir besoin d’un compte pour s’authentifier.

Le chaînage des vulnérabilités est de loin la partie la plus intéressante d’un audit à mon sens. Il s’agit en effet, en fin d’audit ou après avoir trouvé plusieurs vulnérabilités, de savoir les utiliser ensemble afin de générer un scénario réaliste d’exploitation. C’est ce qui fait qu’une faille de type user enumeration puisse aboutir à un brute force de compte, ou alors qu’une simple self XSS couplée à une faille de type CSRF visant un admin puisse amener à une compromission totale d’une application web (par exemple).

Open-source / Web : processMaker version 3.0.1.7

ProcessMaker est un CMS dédié à la gestion des workflow et des échanges en entreprise. J’ai eu envie d’auditer la sécurité de ce CMS en le croisant sur Bitnami dans la section « Dernièrement mis à jour« , ce qui est souvent le cas des outils Open-Source que j’audite.

En jouant un peu avec ProcessMaker, j’ai pu trouver quelques vulnérabilités de types XSS (Cross Site Scripting) Stored et Reflected. Également, différents vulnérabilités de type CSRF permettant à un attaquant de piéger un utilisateur ou un administrateur afin de réaliser des actions sur le CMS (création/suppression d’item par exemple).

Une des vulnérabilités XSS était exploitable en mode non authentifié, ce qui est dangereux car ces failles peuvent être trouvées par des attaquants facilement (souvent dans un formulaire d’enregistrement ou d’authentification) et ainsi exploitées facilement pour l’affichage d’une fasse mire de login pour un utilisateur pas encore connecté.

L’échange avec l’équipe de développement a été très cordial, bien que la correction ait pris plusieurs mois à paraître, ils ont répondu rapidement à mon premier mail, ce qui permet de savoir si notre avertissement est oui ou non pris en charge.

Open-Source / Web : Mautic version 1.3.0

Mautic est une sorte de CMS dédié au métier du marketing, il s’agit d’une application web Open-Source que j’ai téléchargé en mode pré-installée sur le site Bitnami (comme à mon habitude). Sur la version 1.3.0, j’ai pu trouver une vulnérabilité de type User Enumeration, une attaque DoS (Denial Of Service), une Stored XSS et 3 CSRF.

L’attaque par User Enumeration était des plus classique car elle exploitait la fonction de réinitialisation du mot de passe, en tant qu’utilisateur non authentifié, utiliser la fonction de réinitialisation du mot de passe permettait de voir si l’adresse mail sur laquelle on souhaitait réinitialiser notre mot de passe était valide (existante) ou non, un simple script Python couplé à une liste d’adresses mail permettaient alors de lister un grand nombre de compte mail. C’est une faille classique sur ce genre de fonction, il est généralement préféré de diffuser un message d’erreur qui ne permette pas de distinguer une adresse mail (ou non de compte) qui existe ou qui n’existe pas.

L’attaque DoS était a coupler avec cette attaque par User Enumeration, pour chaque compte trouvé, le mot de passe était réinitialisé de façon active, sans validation d’un mail envoyé à l’utilisateur comme il est généralement recommandé. Ainsi, trouver une adresse mail validé résultait en une réinitialisation du mot de passe du compte associé. Couplé à une attaque sur plusieurs dizaines ou centaines de comptes valides, la plate-forme visée devient alors inutilisable (surtout si l’attaque est passée en boucle). Cela peut au moins engendrer une perturbation de l’expérience utilisateur et optionnellement une saturation de l’helpDesk et du service d’envoi de mail.

Open-Source / Audit de code: SSHC

  • Date de découverte : Juin 2016
  • Date de correction : N/A
  • Type : encrypted data leak
  • Advisory : N/A

Il s’agit là aussi d’une expérience très intéressante car c’est la première faille de sécurité que je découvre en mode audit de code. C’est en m’intéressant dans le cadre de mon autre site web it-connect.fr aux solutions de type Putty pour Linux que j’ai trouvé SSHC, un outil très utile qui permet de stocker dans une base chiffrée les connexions (serveur, port et mot de passe) et apportant ainsi un système de menu pour initialiser une connexion.

J’expose plus précisément la vulnérabilité trouvée dans cet article : SSHC : faille découverte via audit de code

Il s’agissait concrètement d’un laps de temps durant lequel la base de données, normalement chiffrée, se retrouvait stockée en clair dans le système de fichier. Un utilisateur présent sur le même système pouvait alors lire/copier cette base « temporaire » et ainsi obtenir les informations de connexion SSH.

Voici une vidéo qui expose l’exploitation de cette vulnérabilité, je me présente en tant qu’utilisateur standard d’une machine sur laquelle un autre utilisateur (root) utilise SSHC, je lui pique sa base de donnée SSHC grâce un petit script bash :

Après quelques échanges avec l’unique développeur du projet, la faille a été corrigée son Github 🙂

Flowthings.io, un bug bounty raté

J’ai également eu l’occasion de trouver une faille de sécurité dans le cadre d’un bug bounty ! Une première car cela constituait un de mes objectifs 2016 🙂

Hélas, la restitution ne s’est pas passée comme je l’aurais souhaité car une journée après avoir remonté la vulnérabilité sur la plateforme BugCrowd, le client a fermé son programme bug bounty, la vulnérabilité est donc connu du client mais toujours présente.

Je ne vais donc pas donner trop de détail technique mais il s’agissait concrètement d’une vulnérabilité de type user enumeration qui était exploitable au travers un mécanisme accessible une fois authentifié. Un attaquant était donc capable de lister tous les logins existants sur la plateforme Saas de flowthings.io, un service cloud-based d’aide à la création de solutions IoT (Internet of Things).

Mon objectif concernant la réussite d’un programme bug bounty est donc à moitié rempli et je compte bien le valider prochainement, affaire à suivre.

Et les autres…

Entre les sites web qui ne répondent pas à mes avertissements et dont les vulnérabilités sont toujours présentes et exploitables et les projets Open-Source qui (selon moi) commencent à avoir une tête tellement énorme qu’ils ne lisent même plus mes mails, il me reste une bonne trentaine d’advisories non publiés dans mes notes. Par choix ou par manque de correctif, ils dorment donc tranquillement, laissant à des attaquants n’ayant pas les mêmes intentions que les miennes les exploiter, qu’il en soit ainsi ! 🙂

Concrètement, j’ai décidé il y a quelques mois d’arrêter d’avertir à tout va lorsque je trouvais des vulnérabilités à droite à gauche, ce qui, avec ma (modeste) montée en compétence, a commencé à devenir un peu trop fréquent. J’ai donc fait le choix de choisir un peu plus précisément les organismes, produits et sites web à avertir ou non, ce qui ne m’empêche pas de chercher des failles un peu partout. Voir cet article pour plus d’info : Pourquoi je n’alerte plus les sites web de leurs failles de sécurité

Je fait une croix assez large sur les sites web non réputés qui possèdent la plupart du temps un webmastering out-sourcé (boite de développement externes) ou les entreprises que je ne porte pas dans mon estime, ce qui est un choix tout à fait personnel. Outre les produits Open-source, qui constitue mon scope principal, et les bugs bounty -qui sont fait pour cela- j’ai récemment fait une exception en ce début d’année sur le site de justice.fr, qui était pour moi un avertissement nécessaire et également sur un CMS en ligne propriétaire dans le cadre d’un site de jeu vidéo que je fréquente souvent.

Pour conclure, tous ses rapports et ses vulnérabilités remontées constituent un très grand apport personnel en terme d’expérience, tant sur le plan technique que sur un plan plus général. Échanger avec les responsables d’infrastructures et les équipes de développement de différents pays afin de les aider à corriger leurs applications est gratifiant et j’encourage les débutants et expérimentés à faire de même. Dépasser le cadre professionnel pour aider, par exemple, des outils open-source ou des organismes à but non lucratif permet de se sentir un minimum utile au travers un apport de compétence, et recevoir un simple « Merci » suffit à égayer des journées ennuyeuses 🙂

Concernant les récompenses proposées par les divers correspondants de ces différentes remontées de vulnérabilités, je n’ai pour l’instant rien eu de magique. Dans la plupart des cas, je demande à ce que mon nom soit cité dans la release news, ce qui permet de me faire connaître un peu plus dans le monde de la chasse aux bugs (exemple de PHP List : https://www.phplist.org/newslist/phplist-3-2-5-whats-new/). Lorsqu’une récompense monétaire est proposée, j’oriente généralement les entreprises à faire un don à l’ARSEP (Fondation pour l’aide à la recherche sur la sclérose en plaques), tel que mentionné dans mon profil PacketStormSecurity, bien que je n’ai pas l’impression que cela ai fait fureur pour l’instant, je persévère ! 🙂

Note : Je vous encourage également à être prudent quant aux actions que vous menez sur des environnements de production 😉 et n’oubliez pas le Responsible Disclosure !

N’hésitez pas à partager vos expériences et vos avis ! De mon côté je rédigerai sûrement un article similaire d’ici la fin d’année ou avant si j’ai assez d’expérience à partager.

Partager :
Published inAdvisory et Contributions

One Comment

  1. Bravo !!
    Bonne continuation / chasse 🙂

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *