Les attaques “SSRF”, ou “Server-Side Request Forgery” sont une catégorie de vulnérabilités apparue pour la première fois dans la dernière mise à jour du top 10 de l’OWASP des plus grands risques dans les applications Web. En 2019, les données personnelles de plus de 100 millions d’utilisateurs avaient fuité à cause d’une vulnérabilité SSRF. Et, plus récemment, ce sont pas moins de 4 services chez Azure étaient vulnérables à cette attaque jusqu’à fin 2022.
Il peut arriver, pour les besoins de l’application, que le serveur sur lequel celle-ci est hébergée ait besoin de faire lui-même une requête à un autre serveur (par exemple pour appeler un micro-service, une application tierce, via des webhooks…). En exploitant une SSRF, un attaquant va faire en sorte de modifier la requête effectuée pour l’envoyer vers l’URL de son choix.
Pour avoir la possibilité d’exploiter une SSRF, il faut donc que l’URL de la requête forgée soit (entièrement ou partiellement) modifiable par un utilisateur, depuis le frontend.
💡 Vulnérabilité
Ce sont des chercheurs d’Orca Security qui ont découvert des SSRF dans 4 services d’Azure :
- Azure API Management
- Azure Functions
- Azure Machine Learning
- Azure Digital Twins
Prenons l’exemple de la vulnérabilité dans Azure Functions (l’équivalent des Lambda chez AWS ou des Google Cloud Functions). Elle avait l’avantage (ou l’inconvénient !) d’être exploitable sans être authentifié sur la plateforme.
Pour découvrir la vulnérabilité, les chercheurs ont exploré la console Azure. Ils ont créé une Azure Function et ont observé les requêtes effectuées par le navigateur depuis l’interface.
Une requête en particulier était envoyée sur l’URL https://functions.azure.com/api/passthrough. Le corps de la requête était un objet composé de trois champs : url (l’url de la Function créée), method (GET), et headers (des headers HTTP). Les chercheurs ont donc supposé que le serveur exécutait une requête GET sur l’url de l’Azure Function. Pour vérifier leur hypothèse, ils ont remplacé l’URL par celle d’un serveur qu’ils contrôlaient : le serveur en question recevait bien une requête effectuée depuis l’IP 52.143.137.148 (une IP qui appartient à Microsoft, ce qu’on peut facilement vérifier avec la commande whois).
Deux éléments supplémentaires rendent l’attaque encore plus intéressante :
- il n’y a pas besoin d’être authentifié sur Azure pour envoyer la requête à /api/passthrough
- la réponse à la requête forgée est renvoyée dans le navigateur (dans le cas contraire, quand on n’a pas de retour sur la requête forgée, on parle de Blind SSRF, plus difficile à exploiter)
Maintenant que la vulnérabilité est confirmée, comment l’exploiter ?
Les chercheurs ont fait en sorte que le serveur s’appelle lui-même pour découvrir quels services étaient actifs et non exposés sur Internet. Ils ont notamment scanné tous les ports, et ont découvert que le port 41692 était ouvert. Ils ont ensuite essayé d’identifier des routes, et ont trouvé un healthcheck, un endpoint utilisé pour savoir si l’application tourne toujours sur le serveur (http://127.0.0.1:41692/healthcheck).
Dans les environnements Cloud, les SSRF permettent souvent de récupérer des méta-données (comme des clefs d'authentification). Cependant, Microsoft ayant mis en place des mécanismes de défense en profondeur, les chercheurs n’ont pas pu utiliser la SSRF pour compromettre d’autres serveurs.
🛡 Comment se protéger
- Ne jamais laisser l’utilisateur contrôler tout ou partie de l’URL d’une requête effectuée côté serveur
- Si possible, faire une allow-list des requêtes autorisées
- Dans le cas où, pour des raisons métier, il est impossible de faire une allow-list (par exemple dans le cas de webhooks), faire une deny-list de toutes les adresses internes qui ne devraient pas être appelées par le serveur (plus facile à dire qu’à faire !)
- Utiliser au maximum des librairies éprouvées, et faire appel à un expert : il est souvent possible d’abuser les protections mises en place contre les SSRF. Pour prendre un exemple concret : localhost, cible privilégiée lors d’une SSRF (le serveur s’appelle lui-même, ce qui permet d’atteindre des services non exposés) peut être appelée via toutes les URLs suivantes (selon les implémentations) :
🏹 Pour aller plus loin
- L’article de Orca Security listant les 4 SSRF découvertes
- L’article de Orca Security détaillant l’attaque sur Azure Functions
- Le rapport du Microsoft Security Response Center
- La cheatsheet de protection contre les SSRF de l’OWASP
- Explication de l’attaque SSRF sur Capital One
- Une simulation pour “revivre” l’attaque SSRF sur Capital One
Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité par mail security@theodo.fr.
