Histoires de pentest
Cette série d’articles vous fait suivre Jean, un pentester imaginaire, dans ses missions de tests d’intrusions. Les clients et les histoires d’exploitations sont tout autant imaginaires, mais correspondent à la réalité et sont basées sur les expériences des experts DSecBypass.
Elle a vocation à vulgariser et rendre plus imagées les différentes offres de pentest.
L’audit de site web
Jean a beaucoup d’expérience sur le pentest de sites web : c’est un périmètre qui se recoupe avec les tests d’intrusion externes et parfois aussi les audits internes. Ce qu’il aime par-dessus tout c’est trouver des vulnérabilités logiques dans une application bien développée : les développeurs ont suivi les bonnes pratiques de développement sécurisé, ont utilisé des technologies modernes, mais n’ont pas anticipé certains cas d’utilisation. C’est à ce moment que les échanges avec les équipes du client sont les plus intéressants puisque ça permet d’aborder des sujets avancés. Toujours est-il que Jean ne rechigne pas non plus devant un site web codé en PHP il y a 10 ans et cochant toutes les cases du TOP10 OWASP 🙂
Aujourd’hui, Jean doit auditer le site web d’une société de courtiers en assurance. Ils disposent d’une application web qui permet aux employés de gérer facilement les clients, les assurances et exporter des rapports sur les différents indicateurs. Le périmètre est constitué de deux URL :
Les scénarios retenus sont :
-
- un scénario « Boîte noire » (blackbox) – le pentester ne dispose comme information que du périmètre de la mission ;
- un scénario « Boîte grise » (greybox) – l’auditeur se voit attribuer un ou plusieurs comptes sur l’application afin d’évaluer le modèle de permission et tester d’avantages de fonctionnalités.
Jean dispose pour ce pentest de deux comptes « employés » et deux comptes « managers » sur https://app[.]courtier.fictif, puis un compte « administrateur » sur https://admin-app[.]courtier.fictif/.
Il va ainsi pouvoir tester le modèle de permission verticalement (est-ce qu’un employé peut devenir manager ?) et horizontalement (est-ce qu’un employé peut accéder aux données d’un autre employé ?). Le compte administrateur permettra de tester les fonctionnalités seulement accessibles aux administrateurs de l’application.
Afin de suivre la logique des scénarios, le test d’intrusion démarrera par le scénario « boîte noire » : le pentester doit posséder le moins d’informations possibles pour simuler l’attaque d’un hacker non authentifié.
Après avoir vérifié les informations du mandat, Jean envoie un mail aux contacts de la mission afin de signifier le départ des tests.
Comme dans un audit externe, deux phases de reconnaissances sont exécutées : la reconnaissance passive, puis la reconnaissance active.
Il vérifie les données accessibles sur les moteurs de recherches grâce à des Dorks, analyse les différentes données DNS et de certificats disponibles de manière à élargir la surface d’attaque au maximum et posséder autant d’informations que possible.
Aujourd’hui il est chanceux, l’application initialement protégée par un pare-feu applicatif (WAF) peut être directement accédée, sans passer par le WAF, en utilisant l’adresse IP récupérée dans l’historique DNS. Il va donc pouvoir réaliser ses tests sans être bloqué, et remonter une première vulnérabilité.
Il lance ses outils de reconnaissance active : il scan les ports du serveur à la recherche de services ouverts à attaquer et commence à énumérer les fichiers, dossiers et applications exposés par les serveurs web.
Ces étapes de reconnaissances sont cruciales : elles permettent de trouver ce que les développeurs ou administrateurs systèmes ne pensaient pas avoir rendu accessible. Cela donne donc souvent accès à des informations intéressantes pour la suite de l’audit ou bien des fonctionnalités moins bien protégées.
En l’occurrence Jean découvre un fichier lié à la chaîne de déploiement continu qui donne accès aux versions des librairies utilisées et divulgue certains noms internes utilisés par le client. C’est donc une faiblesse qui sera remontée dans le rapport, mais surtout qui pourra avec un peu de chance être utilisé dans la suite de l’audit.
Mise à part ce problème, Jean décèle un défaut de configuration aux niveaux des entêtes HTTP et quelques librairies vulnérables mais non exploitables en l’état. Il a passé beaucoup de temps à analyser les API exposées mais n’a pas trouvé de vulnérabilités en scénario boîte noire. L’application est donc plutôt sécurisée face à un attaquant non-authentifié : un mécanisme de blocage existe sur le formulaire d’authentification, si le WAF n’avait pas été contourné Jean aurait été bloqué lors de l’énumération des dossiers et fichiers, et les technologies modernes utilisées incluent la sécurité « by design » et ont été correctement utilisées par les développeurs.
En revanche, les tests de sécurité authentifiés révèlent des problèmes critiques dans le modèle de permission :
- un employé peut lister les contrats d’un autre ;
- un manager peut modifier les informations d’employés d’autres managers ;
- un manager peut modifier son propre profil afin d’accéder aux dossiers qui ne lui sont pas octroyés.
Jean découvre également une vulnérabilité XSS stockée dans le nom de certaines pièces jointes. Elle permet à un employé d’injecter du code Javascript malveillant dans le navigateur d’un manager.
L’interface d’administration est, comme assez souvent, moins bien protégée et offre des fonctionnalités plus sensibles. Jean y découvre plusieurs injections XSS. Une fonctionnalité de configuration d’un dossier partagé l’interpelle : il en crée un nouveau et le fait pointer vers son serveur. Il reçoit la requête ce qui indique la présence d’une vulnérabilité SSRF. Il s’aperçoit également que l’application affiche le message que son serveur retourne. L’application étant hébergée dans AWS, Jean exploite la faille SSRF afin de récupérer les métadonnées de l’instance EC2 puis utilise ses outils favoris afin d’exploiter les clés AWS ainsi dérobées. Bien que le tenant ne soit pas suffisamment sécurisé puisque IMDSv2 n’est pas utilisé, les développeurs ont assigné un rôle limité à l’EC2 ce qui ne permet pas de prendre le contrôle du tenant.
L’audit de sécurité terminé, il communique de manière informelle au client une synthèse des résultats.
📚 Le lendemain il termine son rapport d’audit et l’envoie à un de ses collègues pour relecture et validation.
Il transmet ensuite le rapport au client de manière sécurisée, et échange avec les équipes et la direction sur les résultats de l’audit de sécurité du site web et le plan d’action grâce à la restitution en visioconférence.
🛡️ DSecBypass vous accompagne sur vos audits sécurité de sites web, avec des prestations de qualité et une expérience significative sur ce type de prestation. N’hésitez pas à nous contacter pour des informations complémentaires et/ou un devis personnalisé 📝.
