Qu’est-ce que le SSRF (Server-Side Request Forgery) ? Exemples et Prévention

Chaque jour, des milliers de nouvelles vulnérabilités émergent, créant de nouvelles opportunités pour les hackers. Les cybercriminels ne prennent pas de pauses ni de vacances ! Ils travaillent activement à compromettre vos systèmes.

L’importance de rester en avance sur les dernières vulnérabilités ne peut être suffisamment soulignée dans un paysage de menaces en constante évolution. Cette fois, nous allons aborder la vulnérabilité de falsification de requête côté serveur. Sans plus tarder, explorons comment fonctionne le SSRF, comment détecter les vulnérabilités SSRF dans vos applications, et quelles mesures doivent être prises pour les prévenir.

Qu’est-ce que la Falsification de Requête Côté Serveur ?

La vulnérabilité, officiellement appelée Server-Side Request Forgery (SSRF), figure dans le Top 10 OWASP comme un risque majeur pour la sécurité des applications. Les hackers de tout type profitent de la vulnérabilité SSRF pour abuser des fonctionnalités serveur et envoyer des requêtes sortantes arbitraires depuis un serveur.

En encodant une URL, en manipulant les en-têtes HTTP et en altérant la traversée de chemin d’URL, les acteurs malveillants peuvent effectuer des requêtes non autorisées vers une URL spécifique. Les vulnérabilités SSRF peuvent entraîner une interruption de service et, dans certains cas, une prise de contrôle totale du système.

Types d’Attaques par Falsification de Requête Côté Serveur

Si vous vous demandez quelles sont les différentes attaques SSRF, nous sommes là pour clarifier les choses. En fonction de la façon dont le serveur répond à la requête initiale, il existe trois types de SSRF :

SSRF Aveugle

Le SSRF aveugle survient lorsque le serveur hôte ne renvoie aucune donnée visible aux cyberattaquants. Les cybercriminels cherchent à modifier ou supprimer des fichiers critiques, à modifier les paramètres du serveur et à ajuster les permissions des utilisateurs ou des fichiers, plutôt que de simplement voler des données spécifiques sur le serveur. Rien n’est renvoyé du serveur au fraudeur, ce qui rend la détection de ces attaques particulièrement difficile jusqu’à ce que les dommages soient causés.

En général, le SSRF aveugle est le plus difficile à exploiter, mais il peut conduire à un déni de service (DoS) et à une exécution de code à distance complète sur le serveur ou d’autres composants back-end.

SSRF Semi-Aveugle

Dans ce scénario, l’instance semi-aveugle renvoie des données partielles sur une requête résultante. L’attaquant obtient ainsi accès à certaines données confidentielles, mais pas à l’ensemble complet. Cela peut inclure des informations telles que des messages d’erreur ou des temps de réponse. Le SSRF semi-aveugle est souvent suffisant pour valider la vulnérabilité, mais il n’expose pas de données sensibles.

SSRF Non-Aveugle

Le SSRF non-aveugle est généralement le plus néfaste de tous, car les données d’une URL arbitraire peuvent être récupérées et renvoyées aux entités malveillantes qui ont effectué la requête. Après une attaque SSRF non-aveugle réussie, les opérateurs malveillants repartent avec un accès aux ressources réseau restreintes qui les aideront à lancer d’autres attaques.

Comment les Acteurs Malveillants Peuvent-ils Exploiter le SSRF ?

Les vulnérabilités SSRF peuvent survenir dans divers types de logiciels, langages de programmation et plateformes, tant que le logiciel fonctionne dans un environnement en réseau. En d’autres termes, si les attaquants peuvent contrôler la destination des requêtes côté serveur, cela ouvre la porte à une multitude de failles de sécurité, leur permettant potentiellement de :

• Contourner les listes blanches d’adresses IP
• Injecter des requêtes HTTP malveillantes dans le système cible
• Contourner les contrôles du pare-feu
• Effectuer une exécution de code à distance (RCE)
• Pivoter dans les réseaux d’entreprise pour exploiter d’autres vulnérabilités
• Détourner et rediriger des requêtes HTTP légitimes vers un serveur contrôlé par l’attaquant
• Scanner les réseaux liés au serveur vulnérable, internes ou externes
• Lire des fichiers de configuration ou des données sensibles depuis le serveur web
• Initier une attaque DDoS (Déni de Service Distribué) en envoyant des requêtes vers des ressources externes
• Accéder aux pages d’état et interagir avec les API en tant que serveur web
• Récupérer des informations sensibles, telles que des mots de passe ou des clés API
• Abuser de la relation de confiance entre le serveur vulnérable et d’autres systèmes

Les attaques SSRF sont particulièrement délicates car elles sont souvent combinées avec d’autres vulnérabilités. Cette combinaison permet aux attaquants d’établir une emprise sur le serveur qui sert de base à une exploitation ultérieure.

Souvent, l’objectif principal d’une attaque SSRF est de voler une grande quantité de documents ou une base de données d’enregistrements d’entreprise. Cela peut entraîner une perte de confiance des clients, une baisse des revenus, des responsabilités juridiques et des pénalités financières.

Comment Détecter le SSRF ?

Que pouvons-nous faire concrètement pour détecter cette vulnérabilité ? Dans le contexte du SSRF, les étapes suivantes doivent être suivies pour détecter de telles vulnérabilités :

• Identifier les entrées potentielles permettant de construire des URL ou d’initier des requêtes vers des serveurs externes, telles que les paramètres GET ou POST et les en-têtes.
• Tester chaque entrée en essayant différentes URL ou adresses IP. Cela devrait inclure les ressources internes, localhost et d’autres valeurs spéciales.
• Examiner comment l’application répond à des entrées diverses, en cherchant spécifiquement des signes de vulnérabilités SSRF. Vérifier les indications telles que la capacité d’accéder à des ressources internes ou d’extraire des données.
• Consigner toutes les vulnérabilités découvertes, en détaillant l’entrée qui a causé la vulnérabilité, le type de vulnérabilité et son impact potentiel.

Exemples Réels

Maintenant que nous avons les bases du SSRF, explorons quelques incidents de ce type d’attaques survenus dans la réalité.

Capital One

Un bon exemple d’attaque SSRF est celui où Capital One a été piraté et les données d’environ 106 millions de personnes aux États-Unis et au Canada ont été divulguées en ligne. Comment la violation s’est-elle déroulée ?

Le hacker a réussi à recevoir une réponse contenant des identifiants en raison d’une mauvaise configuration du pare-feu de l’application web. Cela a permis au hacker de se connecter au serveur où Capital One stockait ses données et d’accéder aux fichiers clients.

Microsoft Exchange

Plus récemment, le groupe de menace Hafnium a été découvert en train d’infecter le logiciel de messagerie Microsoft Exchange Server. La violation de Microsoft Exchange en 2021 impliquait quatre vulnérabilités, mais la vulnérabilité SSRF a notamment permis à des entités malveillantes de s’authentifier en tant que serveur Exchange et d’exécuter du code à distance via PowerShell. C’est un autre exemple de la façon dont une source de confiance compromise peut faire escalader les attaques.

Le groupe, opérant depuis la Chine, ciblait les systèmes de messagerie utilisés par 30 000 cabinets d’avocats américains, établissements d’enseignement supérieur, chercheurs en maladies infectieuses, groupes de réflexion sur les politiques, sous-traitants de la défense et organisations non gouvernementales.

Services Microsoft Azure

Le 17 janvier 2023, des failles de sécurité exposant les services Microsoft Azure aux attaques SSRF ont été découvertes. Deux vulnérabilités ne nécessitaient pas d’authentification, permettant aux acteurs malveillants de les exploiter sans compte Azure. Après avoir identifié des vulnérabilités dans Azure API Management, Azure Functions, Azure Machine Learning et Azure Digital Twins, Microsoft a rapidement résolu ces problèmes.

Heureusement, dans ce cas, une validation d’entrée supplémentaire pour les URL vulnérables a été mise en place en temps opportun, et les vulnérabilités n’ont causé aucun dommage aux services ou à l’infrastructure Azure. Néanmoins, l’entreprise a bien pris conscience du risque des attaques par falsification de requête côté serveur.

Prévention et Atténuation du SSRF

Sans les bons processus préventifs en place, la sécurité de vos applications est une grande inconnue. Comme pour la plupart des vulnérabilités, la prévention est la meilleure approche pour éliminer les failles SSRF.

• Effectuer une validation des entrées. Ne faites pas confiance aveuglément aux entrées — vérifiez toujours leur authenticité.
• Mettre en liste blanche les noms de domaine ou les adresses IP auxquels votre application doit accéder. Minimiser la surface d’attaque. Dans les réseaux internes, cela signifie généralement qu’un serveur ne devrait autoriser que les requêtes contenant des URL figurant sur une liste prédéfinie et rejeter toutes les autres.
• Utiliser l’encodage d’URL. Un encodage et un décodage appropriés des entrées utilisateur constituent un mécanisme de défense en profondeur supplémentaire qui atténue le risque que des URL malveillantes soient traitées par le serveur.
• Effectuer des tests de pénétration incluant un élément humain pour exploiter les vulnérabilités. Vous pouvez également utiliser des outils de test de sécurité pour exécuter des tests de simulation.
• Désactiver les schémas d’URL inutilisés. Cette approche vise à n’autoriser que les schémas d’URL utilisés par votre application pour effectuer des requêtes, limitant ainsi les possibilités pour l’attaquant d’utiliser des schémas potentiellement dangereux comme file://, phar://, gopher://, data:// ou dict://.
• Appliquer le principe du moindre privilège, où le système accorde l’accès uniquement aux utilisateurs autorisés.
• Segmenter le réseau. En séparant les réseaux internes des réseaux externes, vous réduisez la surface d’attaque et rendez plus difficile l’accès des hackers aux systèmes internes.
• Comme bonne pratique de sécurité, corriger les mauvaises configurations.
• Former les employés aux risques associés au SSRF et aux moyens de les éliminer.
• Documenter et tirer des enseignements des vulnérabilités SSRF découvertes pour améliorer les procédures de test et prévenir les occurrences futures.
• La mise à jour régulière des logiciels apporte un niveau de prévention supplémentaire.

La prévention est en effet plus intelligente que d’attendre que des attaquants hostiles frappent en premier.

Comment QAwerk Peut-il Aider ?

Les tests de pénétration sont une étape essentielle dans le cycle de gestion des vulnérabilités, visant à renforcer la sécurité de vos systèmes. Avec l’aide des testeurs de pénétration de QAwerk, vous pouvez contrer des menaces sophistiquées avec facilité et rapidité.

Nous sommes là pour analyser vos réseaux, serveurs et applications afin de trouver, analyser et signaler les vulnérabilités de piratage. Nos testeurs qualifiés réalisent des tests de pénétration en boîte noire, grise et blanche pour révéler les failles de sécurité. Grâce à notre large expertise, nous pouvons identifier même les vulnérabilités les plus insaisissables.

En Conclusion

Les vulnérabilités SSRF peuvent apparaître de manière inattendue, mettant potentiellement en péril la sécurité de votre entreprise. Pour éviter que cela ne se produise, des tests de pénétration doivent être effectués régulièrement. Cela rendra la tâche plus difficile aux acteurs malveillants qui tentent de compromettre vos systèmes.

Les tests de pénétration sont un processus proactif qui ne mérite pas d’être négligé. Gardez cela à l’esprit et restez en sécurité avec QAwerk !