Contrefaçon de requête côté serveur (SSRF)

Qu’est-ce que SSRF ?

La contrefaçon de requête côté serveur (SSRF) est une vulnérabilité qui permet à un pirate malveillant d’envoyer une requête depuis le back-end du logiciel vers un autre serveur ou vers un service local. Le serveur ou le service qui reçoit cette demande pense que la demande provient de l’application et qu’elle est légitime.

Gravité:		grave
Prévalence:		découvert régulièrement
Portée:		peut apparaître dans tous les logiciels en réseau
Impact technique :		accès à des ressources privilégiées
Conséquences dans le pire des cas :		compromis complet du système
Solution rapide:		nettoyer les données de l’utilisateur dans les appels vers d’autres serveurs

Comment fonctionne la contrefaçon de requête côté serveur ?

Lorsque vous créez un logiciel en réseau, vous devez souvent adresser des requêtes à d’autres serveurs. Les développeurs les utilisent généralement pour récupérer des ressources distantes, telles que des mises à jour logicielles, ou pour importer des métadonnées à partir d’une autre application. De telles requêtes ne sont généralement pas dangereuses, mais si elles sont mal implémentées, elles peuvent rendre le logiciel vulnérable à la falsification des requêtes côté serveur.

Une vulnérabilité SSRF peut être introduite lorsque vous utilisez des données d’entrée utilisateur pour créer une demande, par exemple, lors de la création d’une URL. Pour effectuer une attaque SSRF, un attaquant peut alors modifier une valeur de paramètre dans le logiciel vulnérable pour créer ou contrôler des requêtes provenant de ce logiciel et allant vers d’autres serveurs ou même le même serveur.

Les vulnérabilités SSRF peuvent apparaître dans n’importe quel type de logiciel informatique, dans presque tous les langages de programmation et sur n’importe quelle plate-forme, tant que le logiciel fonctionne dans un environnement en réseau. La plupart des vulnérabilités SSRF se produisent dans les applications Web et autres applications en réseau, mais elles peuvent également apparaître dans le logiciel serveur lui-même.

En plus des vulnérabilités SSRF régulières (non aveugles), il existe également d’autres types de SSRF. Celles-ci incluent des vulnérabilités SSRF aveugles, où l’attaquant ne reçoit directement aucune donnée de la ressource attaquée. Les attaquants peuvent utiliser SSRF aveugle pour déclencher des actions qu’ils ne peuvent déclencher qu’à partir d’un réseau interne.

SSRF est classé comme CWE-918 . Notez également qu’en raison de sa gravité, SSRF est le seul type de vulnérabilité qui a sa propre catégorie dans la liste OWASP Top 10 2021 . 

Exemple d’attaque SSRF d’application web

L’exemple le plus courant de SSRF dans les applications Web est lorsque l’attaquant peut saisir ou influencer une URL de service tiers à laquelle l’application Web fait une demande.

Code vulnérable

Le code suivant a été écrit pour générer une image PNG importée d’une autre URL comme si elle faisait partie de votre propre page HTML.

  if (isset($_GET['url'])) {
    $url = $_GET['url'];
    $image = fopen($url, 'rb');
    header("Content-Type: image/png");
    fpassthru($image);
  }
?>

Notez que l’attaquant a le contrôle total du paramètre url . Ils peuvent envoyer des requêtes GET arbitraires à n’importe quelle adresse IP externe, y compris celles du réseau local, et aux ressources du serveur qui héberge l’application vulnérable ( localhost ).

Le vecteur d’attaque

En utilisant l’application vulnérable, l’attaquant peut faire la requête suivante aux serveurs web Apache avec mod_status activé (qui est la configuration par défaut) :

GET /?url=http://localhost/server-status HTTP/1.1

En conséquence, l’attaquant reçoit des informations détaillées sur la version du serveur, les modules installés, etc. Cela aide l’attaquant à rechercher davantage de vulnérabilités potentielles.

Outre les schémas d’ URL http et https , les attaquants peuvent également utiliser des schémas d’URL hérités dans leurs charges utiles, tels que le schéma de fichier , pour essayer d’accéder aux fichiers sur le système local ou le réseau interne.

GET /?url=file:///etc/passwd HTTP/1.1

Cette charge utile fournira à l’attaquant le contenu du fichier / etc/passwd du serveur hébergeant l’application vulnérable.

Certaines applications peuvent permettre aux attaquants d’utiliser des schémas d’URL exotiques. Par exemple, si l’application utilise cURL pour faire des requêtes, un attaquant peut utiliser le schéma d’URL dict pour faire des requêtes à n’importe quel hôte sur n’importe quel port et envoyer des données personnalisées.

GET /?url=dict://localhost:11211/stat HTTP/1.1

La requête ci-dessus entraînera la connexion de l’application à localhost sur le port 11211 et l’envoi de la chaîne stat . Le port 11211 est le port par défaut utilisé par le service de mise en cache Memcached. Ce port n’est normalement pas exposé au réseau extérieur, mais il est accessible depuis localhost , dans ce cas via SSRF.

Conséquences potentielles d’une attaque SSRF

Un attaquant a deux objectifs principaux lorsqu’il tente une attaque par falsification de requête côté serveur :

• Accès aux ressources privilégiées : Les pirates malveillants utilisent généralement des attaques SSRF pour cibler des ressources internes avec des adresses IP privées ou situées derrière des pare-feu, ou pour accéder à des services disponibles via l’interface de bouclage ( http://127.0.0.1 ) du serveur exploité. Cela peut inclure, par exemple, les métadonnées du service cloud Azure/AWS ( http://169.254.169.254 ), les API internes et, dans certains cas, même les fichiers privilégiés sur le serveur vulnérable. Les attaquants peuvent même utiliser SSRF pour l’analyse des ports locaux.
• Masquer la source réelle de la connexion : par exemple, un attaquant peut utiliser SSRF même s’il a un accès direct à la ressource, juste pour brouiller les pistes. De cette façon, les tentatives d’accès semblent provenir du back-end de l’application locale qui est vulnérable à SSRF, et non directement de l’attaquant, ce qui rend l’investigation plus gênante. L’attaquant peut également utiliser votre serveur vulnérable pour attaquer quelqu’un d’autre, ce qui donne l’impression que vos systèmes sont à l’origine de l’attaque réelle.

Pour ces raisons, les exploits SSRF constituent généralement une étape d’attaque préliminaire avant d’exploiter une autre vulnérabilité. Par exemple:

• L’attaquant peut d’abord exécuter SSRF pour accéder à une application critique située sur un autre serveur, accessible uniquement à partir du réseau interne, puis utiliser SQLi pour accéder à la base de données derrière cette application métier.
• L’attaquant peut également utiliser SSRF pour accéder à une application locale installée sur le serveur hébergeant une application avec une vulnérabilité d’exécution de code à distance (RCE) , puis utiliser cette application pour obtenir un accès complet au shell, puis exploiter une vulnérabilité du système d’exploitation pour devenir root. accès au serveur.

Par conséquent, dans le pire des cas, si SSRF est combiné à d’autres vecteurs d’attaque tels que RCE, XXE, XSS, CSRF ou SQLi, cela peut permettre aux attaquants de prendre le contrôle total d’un serveur vulnérable ou d’accéder à des données hautement sensibles.

Exemples de vulnérabilités SSRF connues

• La brèche de Capital One en 2019 . Paige Thompson a acquis des clés d’accès AWS en exploitant SSRF pour accéder au service de métadonnées AWS EC2. Grâce à ces clés, Thompson a pu répertorier et synchroniser les buckets S3 sur un disque local, et ainsi avoir accès à toutes les données qu’ils contiennent.
• Les attaques Microsoft Exchange de 2021 . Le groupe Hafnium a exploité la vulnérabilité CVE-2021-26855 SSRF, qui leur a permis de s’authentifier d’abord en tant que serveur Exchange, puis d’intensifier les attaques.

Comment détecter les vulnérabilités SSRF ?

La meilleure façon de détecter les vulnérabilités SSRF dépend de si elles sont déjà connues ou inconnues.

• Si vous n’utilisez que des logiciels commerciaux ou open source et que vous ne développez pas de logiciels vous-même, vous trouverez peut-être qu’il suffit d’identifier la version exacte du système ou de l’application que vous utilisez. Si la version identifiée est vulnérable à SSRF, vous pouvez supposer que vous êtes sensible à cette vulnérabilité SSRF. Vous pouvez identifier la version manuellement ou utiliser un outil de sécurité approprié, par exemple un logiciel d’analyse de la composition logicielle (SCA) dans le cas d’applications Web ou un analyseur de réseau dans le cas de systèmes et d’applications en réseau.Si vous développez votre propre logiciel ou souhaitez potentiellement trouver des vulnérabilités SSRF inconnues (jours zéro) dans des applications connues, vous devez être en mesure d’exploiter avec succès la vulnérabilité SSRF pour être certain qu’elle existe. Dans de tels cas, vous devez soit effectuer des tests d’intrusion manuels avec l’aide de chercheurs en sécurité ou de testeurs d’intrusion, soit utiliser un outil de test de sécurité capable d’exploiter automatiquement les vulnérabilités (ce qui n’est possible que pour les tests de sécurité Web). 

Lorsque vous traitez avec un logiciel personnalisé, notez que les vulnérabilités de contrefaçon de requête côté serveur ne sont pas faciles à détecter à l’aide d’outils simples, car les trouver nécessite une approche combinée. Vous pouvez identifier certaines vulnérabilités SSRF qui impliquent l’accès à d’autres serveurs simplement en fonction de votre capacité à accéder à ces serveurs. C’est ainsi que de nombreuses vulnérabilités SSRF sont détectées par Acunetix et Netsparker. Ces deux outils incluent un service d’écoute externe et chaque fois qu’une analyse amène votre application à envoyer une requête HTTP à ce service, vous avez la preuve d’une vulnérabilité SSRF.

Cependant, dans le cas d’attaques SSRF qui ciblent le serveur d’applications Web lui-même ou des services internes uniquement, un tel service tiers n’est pas suffisant. Dans de tels cas, vous devez vérifier s’il est possible d’accéder aux ressources locales typiques, telles que les fichiers accessibles au public dont vous savez qu’ils existent sur le serveur. Cela peut également être automatisé avec des outils professionnels, mais des tests de pénétration supplémentaires sont toujours recommandés pour détecter les cas moins courants.

Comment prévenir les vulnérabilités SSRF dans les applications Web ?

La seule façon de garantir que votre code n’aura pas de vulnérabilité SSRF est de ne pas utiliser de données provenant de l’entrée de l’utilisateur lorsque vous accédez à d’autres serveurs. Malheureusement, de nombreuses applications ont besoin de telles fonctionnalités et dans ces cas, vous devez plutôt explorer des solutions moins que parfaites. Comme pour la plupart des autres vulnérabilités logicielles, ces solutions reposent principalement sur la validation et le nettoyage des entrées. Cependant, n’oubliez pas qu’il n’existe pas de méthode universelle car les options disponibles dépendent fortement des fonctionnalités de l’application et des exigences de l’entreprise.

Évitez d’utiliser des listes noires ou des expressions régulières pour filtrer les entrées des utilisateurs. Il y a toujours un risque que les attaquants trouvent des méthodes pour les contourner. Dans le cas de SSRF, un attaquant peut employer une redirection HTTP, un service DNS générique tel que xip.io , ou même un encodage IP alternatif . Si vous devez absolument vous fier à une liste noire, assurez-vous de valider correctement la saisie de l’utilisateur. Par exemple, n’autorisez pas les demandes aux points de terminaison avec des adresses IP privées (non routables) ( RFC 1918 ).

La prévention de la SSRF nécessite une approche combinée

Les méthodes combinées suivantes vous aideront à éviter la plupart des vulnérabilités SSRF, mais vous devez réaliser qu’elles ne sont pas parfaites, même lorsqu’elles sont toutes utilisées ensemble. C’est pourquoi des tests de sécurité sont nécessaires même avec les meilleures pratiques de codage sécurisé .

• Liste blanche : Vous devez mettre en liste blanche les noms d’hôtes (noms DNS) ou les adresses IP auxquels votre application doit accéder. Cependant, cette méthode à elle seule n’empêchera pas les attaquants, par exemple, d’exécuter une analyse de port sur le serveur en liste blanche ou d’accéder à d’autres ressources sur ce serveur.
• Gestion des réponses : Si votre application affiche ou traite des données reçues d’autres serveurs, vous devez vous assurer que la réponse que vous avez reçue est dans un format attendu. Vous ne devez jamais envoyer le corps de la réponse brute au client. Cependant, cela ne protège pas contre les attaques SSRF aveugles.
• Contrôle de schéma : si votre application utilise uniquement HTTP ou HTTPS pour effectuer des requêtes, n’autorisez que ces schémas d’URL. Si vous désactivez tous les autres schémas d’URL, l’attaquant ne pourra pas utiliser l’application Web pour effectuer des requêtes à l’aide de schémas potentiellement dangereux tels que file , dict , ftp et gopher .

Comment atténuer les attaques SSRF ?

Les méthodes pour atténuer les attaques SSRF sont différentes selon le type de logiciel qui présente ces vulnérabilités.

• Dans le cas de logiciels personnalisés, tels que des applications Web, le seul moyen d’atténuer de manière permanente le SSRF est d’éviter d’inclure l’entrée de l’utilisateur dans les appels effectués vers d’autres serveurs. Toutes les autres méthodes sont imparfaites et nécessitent une approche combinée personnalisée en fonction de l’application.
• Dans le cas de SSRF connus dans un logiciel tiers, vous devez vérifier les derniers avis de sécurité pour un correctif et mettre à jour vers une version non vulnérable (généralement la dernière version).

Dans le cas de SSRF zero-day dans un logiciel tiers, vous ne pouvez compter que sur des règles WAF (pare-feu d’application Web) temporaires pour l’atténuation. Cependant, cela ne fait que rendre le SSRF plus difficile à exploiter et n’élimine pas la cause première.

Protéger les cibles potentielles

L’atténuation de SSRF nécessite de se concentrer non seulement sur l’application potentiellement vulnérable, mais également sur les cibles possibles d’une attaque SSRF. Cela inclut de s’assurer que même si vous avez une vulnérabilité SSRF quelque part dans votre réseau interne, les services locaux sur le réseau ne peuvent pas être abusés via ce SSRF.

Par exemple, des services tels que Memcached, Redis, Elasticsearch et MongoDB ne nécessitent pas d’authentification par défaut car ils s’exécutent généralement sur des réseaux internes. Si vous n’activez pas l’authentification, les attaquants peuvent accéder à ces services via des vulnérabilités de contrefaçon de requête côté serveur dans d’autres applications.

Par conséquent, pour protéger vos informations sensibles et garantir la sécurité des applications Web, vous devez activer l’authentification dans la mesure du possible afin de minimiser le risque d’attaques SSRF sur les services locaux.