DeepReview (https://deepreview.app/) est un projet créé par des étudiants de l’INSA et de l’EFREI : c’est une plateforme type CTF pour découvrir ou approfondir l’audit de code, avec une approche par des vulnérabilités réelles (CVE) plutôt que des exercices théoriques. Elle convient parfaitement pour les débutants qui souhaitent être guidés dans la compréhension de CVE potentiellement complexes sans avoir les connaissances nécessaires en cybersécurité ou dans un langage en particulier.
Le projet étant une belle initiative, et DSecBypass étant particulièrement attaché à cet univers CTF / autodidacte, nous avons décidé d’y jeter un coup d’œil avec trois objectifs : flagger, acquérir de nouvelles connaissances, contribuer si possible à ce projet en vérifiant sa sécurité.
Devenir premier, et de loin
A l’époque où nous avons démarré les challenges, il existait 10 exercices accessibles à tout le monde et 1 exercice accessible aux profils sponsors. Soit 11 exercices.
Sous forme de quizz, les exercices sont plutôt simples et rapide à valider aussi nous avons eu rapidement 10/11 de réussite comme plusieurs autres joueurs à ce moment.
En analysant un peu les exercices alors présents sur la plateforme, on peut rapidement découvrir que les créateurs ont utilisé un dépôt Github existant pour pouvoir lancer leur projet avec un minimum de contenu. Le challenge sponsor était en revanche une création originale, mais dont l’accès était restreint. Le dépôt est le suivant : https://github.com/mhzcyber/vulnerable.codes/tree/main/challenges. DeepReview suit d’ailleurs le format des exercices du dépôt Github avec les extraits de codes vulnérables, plusieurs questions permettant de guider le joueur dans la compréhension de la vulnérabilité, ainsi que des aides (« Hints ») et des références.
La plateforme web héberge donc ces exercices et permet d’envoyer les réponses au serveur, lequel les vérifie puis valide le challenge une fois qu’elles sont toutes justes.
La validation des réponses passe par une requête POST avec le numéro de la réponse (un entier qui s’incrémente dans l’URL) et la réponse attendue (un numéro de ligne, un nom de fonction, etc.). Par exemple ici nous envoyons « funcName » comme réponse à la question numéro 89.
Autre point important, le numéro des réponses se suit au sein d’un même challenge : si le challenge possède trois réponses et que la première et un POST sur « /challenges/89/check_answer/ », alors les deux suivantes seront 90 et 91.
Si l’on se met à la place des créateurs, on imagine qu’il serait intéressant d’importer tous les exercices du dépôt en une fois puis de n’exposer que quelques challenges choisi et les débloquer facilement au fur et à mesure. On peut donc imaginer que les réponses des exercices qui ne sont pas encore exposés sur le front de DeepReview ont quand même été intégrés au niveau backend. Si le contrôle d’accès est mal réalisé, nous serons alors dans une vulnérabilité IDOR classique qui nous permettra de valider des challenges que personne d’autre ne peut valider (à moins d’avoir la même idée que nous).
Pour tester notre théorie, il suffit de prendre un challenge du dépôt qui n’est pas encore exposé sur la plateforme, prendre une réponse qui a peu de chances d’avoir été modifiée (les numéros de ligne de code peuvent varier entre la plateforme et le dépôt Github), puis bruteforcer l’ID de réponse jusqu’à ce qu’elle soit valide. Ainsi nous sauront que les réponses attenantes permettront de valider le challenge « fantôme ». C’est ce que nous avons fait avec Burp Intruder :
Dans cette capture d’écran nous voyons la fonctionnalité Intruder de Burp qui itère sur le numéro de réponse en envoyant « find_editor » à chaque fois jusqu’à trouver une réponse valide (grep-extract « Correct »: « true » dans la réponse du serveur). Ici, c’est la réponse numéro 72 qui correspondait à cet exercice.
En validant les autres réponses de l’exercice fantôme, nous parvenons donc à flagger le challenge alors même qu’il n’est pas proposé et arrivons à 11/11 de complétion sans même avoir fait le challenge sponsor !
Nous le notifions bien sûr immédiatement aux créateurs de la plateforme grâce à leur Discord :
Le bug a été rapidement fixé. Nous avions préconisé de corriger le défaut de permission ET de passer sur des UUIDv4 pour référencer les réponses afin de ne plus pouvoir les énumérer dans le cas où une autre IDOR venait à être exploitable mais les UUID n’ont pas encore été implémentés à la date d’écriture de cet article. Le statut « sponsor » nous a gentiment été attribué pour nous remercier d’avoir aidé à sécuriser DeepReview :
Nous nous sommes donc empressés de flagger l’exercice sponsor, création originale de DeepReview, passant ainsi à 12/10 de complétion.
C’est un beau projet : n’hésitez pas à venir découvrir les exercices existants et à contribuer en proposant de nouveaux challenges sur leur Discord !
🛡️ DSecBypass vous accompagne sur les audits de sécurité de vos API et applications web. N’hésitez pas à nous contacter pour des informations complémentaires et/ou un devis personnalisé 📝.
