Free Web Application Ethical Hacking Course (Includes Server-side request forgery SSRF)

Vulnérabilités SSRF et techniques d'exploitation : Analyse approfondie

Introduction aux SSRF et configuration initiale

C'est un exemple classique de vulnérabilités SSRF... la première chose que tout pentester vérifierait est l'hôte local.

• L'utilisation du navigateur intégré à Burp Suite permet de capturer toutes les requêtes HTTP pour analyse. Bien que la version professionnelle soit utilisée ici, l'édition communautaire gratuite suffit pour la plupart des exercices. La démonstration commence par l'interception d'une requête POST vers /product/stock qui contient un paramètre API_stock prenant une URL comme valeur. Cette URL pointe vers un système interne (http://stock.shop.net:8080), révélant immédiatement une potentielle vulnérabilité SSRF (Server-Side Request Forgery).
• L'analyse montre que ce paramètre URL n'est pas correctement validé, permettant potentiellement d'accéder à des ressources internes. L'exemple concret donné est la suppression d'un utilisateur (Carlos) en redirigeant la requête vers l'interface d'administration interne, confirmant ainsi la vulnérabilité. Cette démonstration illustre comment une application publique peut servir de pont pour attaquer des systèmes internes en exploitant les relations de confiance entre composants.
• La méthodologie typique d'exploitation SSRF est expliquée : vérification de l'hôte local en premier, puis scan de ports sur d'autres serveurs internes, et enfin recherche de vulnérabilités permettant l'exécution de code à distance. Cette approche progressive sera développée dans les laboratoires suivants.

Présentation des concepts SSRF et contexte de formation

La falsification de requêtes côté serveur est l'un des risques de sécurité les plus critiques auxquels sont confrontées les applications Web aujourd'hui.

• L'intervenant Rena Kalil présente sa chaîne YouTube dédiée à la sécurité web, couvrant en profondeur diverses vulnérabilités comme les injections SQL, les injections de commandes, et particulièrement les SSRF qui font partie du Top 10 des risques critiques identifiés par l'OWASP. Ces vulnérabilités permettent à un attaquant d'exploiter les relations de confiance entre systèmes pour accéder à des ressources internes.
• Différents formats d'apprentissage sont proposés : contenu gratuit sur YouTube, cours structurés sur Udemy avec support, et une Académie offrant un accès complet à tous les contenus avec support via Discord. Cette approche pédagogique vise à rendre la sécurité accessible à différents niveaux de budget et d'engagement.
• L'importance des SSRF est soulignée par des cas réels comme la fuite de données chez Capital One, où cette vulnérabilité a permis d'accéder à des millions de données sensibles. L'expertise de l'intervenant, basée sur son expérience en consulting, apporte une crédibilité pratique aux concepts théoriques présentés.

Modélisation d'une application vulnérable aux SSRF

Que se passe-t-il si ces paramètres... sont contrôlables par l'utilisateur et ne sont pas correctement validés en arrière-plan ?

• Un scénario d'application e-commerce moderne est présenté, avec une architecture distribuée comprenant une application publique, un système interne de gestion des stocks, et un service tiers de paiement. Cette séparation fonctionnelle crée des relations de confiance qui peuvent être exploitées via SSRF.
• Deux fonctionnalités critiques sont analysées : la vérification du stock (via requête interne) et le processus d'achat (délégué à un service externe). L'accent est mis sur le manque fréquent de validation des URL dans ces requêtes intersystèmes, permettant à un attaquant de détourner ces fonctionnalités pour accéder à d'autres ressources.
• L'exemple montre comment modifier l'URL de vérification de stock pour accéder à une interface d'administration interne, contournant ainsi les contrôles d'accès. L'impact potentiel est triple : atteinte à la confidentialité (accès aux données), à l'intégrité (modification/suppression) et à la disponibilité (perturbation des services).

Techniques avancées d'exploitation SSRF

Je pourrais commencer à enchaîner les vulnérabilités... exploiter la SSRF pour effectuer un contournement d'authentification.

• Au-delà de l'accès simple à des interfaces internes, les SSRF permettent des attaques plus sophistiquées comme le scanning de ports sur le réseau interne pour identifier d'autres services vulnérables. Un exemple est donné avec la découverte d'un serveur ColdFusion vulnérable à un contournement d'authentification.
• Le chaining de vulnérabilités est expliqué : combiner une SSRF avec d'autres failles (comme Shellshock) pour obtenir une exécution de code à distance. Cette technique est comparée à l'attaque réelle contre Capital One où la SSRF a permis d'accéder aux métadonnées EC2 puis à des buckets S3.
• La distinction entre SSRF "inband" (réponse visible directement) et "aveugle" (nécessitant l'exfiltration des données) est introduite, préparant le terrain pour les laboratoires pratiques qui suivront ces différents scénarios.

Laboratoire 1 : SSRF de base contre le serveur local

Modifiez l'URL de vérification des stocks pour accéder à l'interface d'administration sur localhost.

• Le premier laboratoire pratique présente une application avec une fonctionnalité de vérification de stock vulnérable. La solution consiste à modifier le paramètre URL pour pointer vers localhost/admin, permettant ainsi d'accéder à une interface d'administration interne normalement inaccessible.
• La méthodologie pas à pas inclut : l'interception de la requête avec Burp, l'identification du paramètre vulnérable, la modification de l'URL cible, et la confirmation de la vulnérabilité par la suppression réussie d'un utilisateur. Cette approche démontre comment exploiter une SSRF sans authentification préalable.
• Une observation importante est notée : l'accès direct à l'interface admin est bloqué, mais possible via la SSRF, illustrant la relation de confiance entre l'application publique et les composants internes. Ce pattern est courant dans les architectures microservices modernes.

Laboratoire 2 : SSRF contre un autre système backend

Analysez le port du réseau interne pour identifier les serveurs Web fonctionnant sur 192.168.0.X.

• Ce laboratoire complexifie le scénario en nécessitant d'abord l'identification du serveur interne via un scan de ports. L'outil Intruder de Burp est utilisé pour bruteforcer les adresses IP du réseau 192.168.0.1-255 sur le port 8080.
• La technique montre comment interpréter les codes de réponse HTTP pour identifier les serveurs actifs (réponse 200 vs 500). Une fois le serveur admin identifié (192.168.0.142), la même méthode que le lab1 est appliquée pour supprimer l'utilisateur cible.
• Ce lab met en lumière les risques des réseaux internes mal segmentés, où un seul point d'entrée vulnérable peut compromettre l'ensemble de l'infrastructure. L'absence d'authentification entre services internes est critiquée comme une pratique dangereuse courante.

Laboratoire 3 : SSRF aveugle avec exploitation Shellshock

Utilisez une charge utile Shellshock contre le serveur interne pour exfiltrer le nom d'utilisateur du système.

• Ce lab expert combine SSRF aveugle avec l'exploitation de Shellshock. L'extension Burp Collaborator est utilisée pour détecter les interactions hors bande, cruciales pour les SSRF sans retour visible.
• La technique sophistiquée consiste à : injecter une payload Shellshock dans l'en-tête User-Agent, faire appel à un serveur Collaborator pour recevoir les callbacks, et exfiltrer les résultats de commandes via des requêtes DNS. La commande 'whoami' est exécutée avec succès, prouvant l'exécution de code à distance.
• Ce scénario reproduit des attaques réelles où les attaquants doivent être créatifs pour exfiltrer des données sans feedback direct. L'importance des outils comme Collaborator pour les tests hors bande est soulignée.

Défenses contre les SSRF : approche en profondeur

Adoptez une approche de défense en profondeur avec des contrôles au niveau application et réseau.

• Au niveau application : validation stricte des entrées (whitelisting des schémas/ports/URL), suppression des réponses brutes, et désactivation des redirections HTTP. L'inefficacité des blacklists et regex est démontrée par des cas réels de contournement.
• Au niveau réseau : segmentation des fonctions sensibles, politiques de pare-feu deny-by-default, et isolation des composants critiques. Cette défense en profondeur limite l'impact même si une SSRF est découverte.
• L'accent est mis sur l'éducation des développeurs aux bonnes pratiques de codage sécurisé, souvent absente des formations traditionnelles. Des ressources pédagogiques sont proposées pour combler cette lacune.

Conclusion et ressources pour approfondir

La Web Security Academy est la référence en matière de sécurité Web.

• Les laboratoires utilisés proviennent de la Web Security Academy de PortSwigger, considérée comme une référence dans le domaine. La difficulté progressive des exercices permet une montée en compétence structurée.
• L'importance des programmes de bug bounty et des carrières en sécurité est soulignée comme moyen légal et professionnel d'appliquer ces compétences. Les ressources gratuites (YouTube) et payantes (Udemy, Académie) sont présentées comme complémentaires.
• Le partage de connaissances et la contribution à la communauté sont encouragés comme éléments clés pour améliorer la sécurité globale des applications web. La session se termine par une invitation à s'abonner aux chaînes des intervenants pour continuer l'apprentissage.