Comprendre la vulnérabilité web Server-Side Request Forgery (1/2)

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).

 

Qu’est-ce que les 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.

 

Mais d’où vient cette brèche ?

Schéma Server-Side Request Forgery

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 :Example SSFR.PHP - Get picture

 

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 :

  • file_get_contents()
  • fopen()
  • fread()
  • fsockopen()
  • curl_exec()

Cette vulnérabilité SSRF ne se limite bien sûr pas à PHP et le même principe peut être retrouvé avec chaque technologie web.

 

Différents types de SSRF

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 :

  • Boolean-Based : la réponse du serveur est différente que la ressource existe ou non
  • Error-Based : une erreur, HTTP (404 ou 500) par exemple, permettant de déduire les ressources existantes ou non
  • Time-Based : dans le cas où la réponse du serveur reste la même que la ressource existe ou non, le temps de réponse peut quant à lui varier de manière significative

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.

 

Remédiation

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 :

  • Les noms DNS et/ou adresses IP autorisées
    • En l’absence de localhost et 0.0.1, cela empêchera l’accès aux services/fichiers du serveur.
    • L’accès illégitime au réseau interne sera empêché.
  • Les protocoles autorisés
    • L’utilisation de file://, sftp://, sera alors empêché.

Nous verrons dans un prochain article qu’il existe de nombreuses manières de contourner des filtres par liste noire via l’utilisation de protocoles particuliers et d’URL malignes.