Nous pensons souvent qu’un pare-feu suffisamment restrictif protège l’accès aux services non ouverts. Nous croyons aussi que seule une machine compromise peut donner accès au reste du réseau interne.
Et bien nous avons tort, et c’est ce que nous allons voir avec une vulnérabilité des applications web : le Server-Side Request Forgery (SSRF).
A partir d’une application web vulnérable, les SSRF permettent d’interagir avec le serveur, afin d’en extraire des fichiers et de trouver ses autres services actifs. Mais cela ne s’arrête pas là. Il est également possible de scanner le réseau interne afin d’en cartographier les IP et Ports ouverts.
L’idée générale est la suivante : si une fonctionnalité permet d’interagir avec des ressources (exemple : chargement d’une image dans l’application ou redirection vers une page), alors l’attaquant pourra tenter de soumettre une requête au serveur de telle sorte que la ressource recherchée soit interne au serveur (fichiers, services, ressources disponibles en localhost seulement) ou à son réseau.
Prenons pour exemple la fonctionnalité suivante permettant à un utilisateur de changer sa photo de profil :
On remarque deux choses. D’une part, le paramètre url n’est pas contrôlé avant son utilisation dans file_get_contents($url), et d’autre part, le contenu est écrit (echo $content;) alors qu’une redirection a lieu.
Cette fonctionnalité est donc vulnérable au SSRF. Voici certaines exploitations possibles :
On voit ici que la vulnérabilité SSRF donne potentiellement de nombreuses possibilités à un attaquant. En fait, il ne s’agit ici que d’exemples appliqués à notre serveur de tests mais bien d’autres exploitations pourraient être réalisées en fonction des cas : XML External Entity (XXE), Cross-Site Scripting (XSS), injection de commande, etc.
Dans notre exemple ci-dessus, c’est la fonction file_get_contents qui ouvre la brèche. Cependant, d’autres fonctions (ici PHP) peuvent également en être la source, les plus classiques étant :
Cette vulnérabilité SSRF ne se limite bien sûr pas à PHP et le même principe peut être retrouvé avec chaque technologie web.
Nous avons vu un cas particulier de SSRF, car le contenu de la ressource chargée est retourné par le serveur (echo $content;). Pour cette raison, cette SSRF est appelée Content-Based. Ce type de SSRF est potentiellement le plus dangereux, car permettant d’extraire rapidement des données.
Dans d’autres cas, seuls des indices, directs ou indirects, peuvent permettre de déduire des informations sur le serveur ou le réseau interne :
Avec ces trois types d’indices, et bien qu’aucune donnée ne soit extraite, il reste possible de cartographier les ressources existantes sur le serveur et dans le réseau interne.
Il est indispensable de mettre en place des règles sur les ressources à charger.
Comme pour toute vulnérabilité faisant intervenir un contrôle sur les paramètres envoyés par le client, l’utilisation d’une liste noire n’est PAS recommandée, parce qu’il existera toujours une manière de contourner ce filtre. Préférez donc une liste blanche, c’est-à-dire n’autoriser que les ressources explicitées et refuser tout le reste. Il faudra alors définir :
Dans cet article suivant, nous montrons qu’il existe de nombreuses manières de contourner des filtres via l’utilisation d’URL et nous présenterons un outil pour exploiter plus facilement les SSRF.
