En savoir plus sur les requêtes falsifiées côté serveur (SSRF)

Pour suivre nos dernières actualités n'oubliez pas de vous abonner :
Publicité :

comment protéger votre réseau des attaquants



Les cyberattaques réussies commencent souvent au "périmètre du réseau".

À mesure qu'une entreprise se développe, il devient de plus en plus difficile de sécuriser les centaines et les milliers de machines du réseau. 

Souvent, tout ce dont un attaquant a besoin pour compromettre un réseau, c'est d'un seul bug sur une machine accessible au public ! 

Aujourd'hui, nous allons parler d'une vulnérabilité courante sur le périmètre du réseau : SSRF, comment elle permet aux attaquants de pivoter dans le réseau d'une entreprise, et comment l'empêcher.

Qu’entendons nous par SSRF?

SSRF, ou Server-Side Request Forgery, est une vulnérabilité qui se produit lorsqu'un attaquant peut envoyer des requêtes au nom d'un serveur.

Elle permet aux attaquants de "falsifier" les signatures des requêtes du serveur vulnérable, et donc d'occuper une position privilégiée sur un réseau, de contourner les contrôles du pare-feu et d'accéder aux services internes.

Par exemple, imaginons qu'il existe un serveur Web public sur le réseau d'une entreprise : public.exemple.com.

public.example.com héberge un service proxy situé à l'adresse public.example.com/proxy qui récupère la page Web spécifiée dans le paramètre URL et l'affiche à l'utilisateur. Par exemple, lorsque l'utilisateur accède à l'URL :

https://public.example.com/proxy?url=google.com

L'application Web affiche la page d'accueil de "google.com".




Google homepage

Disons maintenant que admin_panel.example.com est un serveur interne hébergeant un panneau d'administration caché. 

Pour s'assurer que seuls les employés peuvent accéder au panneau d'administration, le contrôle d'accès a été mis en place de manière à ce que le panneau ne soit pas accessible via l'internet - uniquement à partir d'une IP interne valide, comme le poste de travail d'un employé. 

Maintenant, que se passe-t-il si un utilisateur accède à l'URL suivante ?

https://public.example.com/proxy?url=admin_panel.example.com

Sans mécanisme de protection SSRF, l'application web afficherait le panneau d'administration à l'utilisateur parce que la requête provient de public.example.com, une machine de confiance sur le réseau !

Les demandes non autorisées qui seraient normalement bloquées par les contrôles du pare-feu, comme la récupération du panneau d'administration à partir d'une machine extérieure à l'entreprise, sont maintenant autorisées. 

En effet, la protection qui existe sur le périmètre du réseau, entre les serveurs Web accessibles au public et les machines Internet, n'existe pas entre les machines du réseau de confiance ou entre public.exemple.com et admin_panel.exemple.com.


Drawing of how SSRF works

Photo by the author.

En utilisant la possibilité de "falsifier" les requêtes des serveurs de conformance, un attaquant peut désormais effectuer toutes sortes de manigances sur le réseau. 

En fonction des autorisations accordées au serveur vulnérable, un attaquant peut être en mesure de lire des fichiers sensibles, d'effectuer des appels API internes et d'accéder à des services internes tels que des panneaux d'administration cachés.

Prévenir le SSRFs

Les SSRF se produisent lorsque les serveurs doivent envoyer des requêtes pour obtenir des ressources externes. 

Par exemple, lorsque vous publiez un lien sur Twitter, le serveur doit aller chercher une image sur ce site externe pour créer une vignette. 

Il s'agit d'un comportement normal et nécessaire. Mais si le serveur n'empêche pas les utilisateurs d'accéder à des ressources internes, des vulnérabilités SSRF apparaissent.

Pour éviter les SSRF, vous devez valider l'URL fournie par l'utilisateur. En fonction des ressources externes que vous essayez d'extraire à l'aide de ce point de terminaison, vous pouvez mettre en place une liste blanche ou une liste noire pour filtrer les URL.

Tout d'abord, vous pouvez vérifier si l'URL appartient à une liste blanche approuvée si vous savez d'où vous devez récupérer les ressources. Par exemple, si vous ne récupérez que des images d'un serveur particulier, vous pouvez limiter les demandes à cette adresse IP ou à ce nom d'hôte.

Si vous utilisez une liste blanche, veillez à corriger les vulnérabilités de redirection ouverte dans les domaines figurant sur la liste blanche.

Si les attaquants trouvent une redirection ouverte dans un domaine de la liste blanche, ils peuvent demander une URL de la liste blanche qui redirige vers une URL interne restreinte.

Assurez-vous également que les regex que vous utilisez sont correctement conçus. Par exemple, un modèle de regex faible qui vérifie simplement si une URL contient le domaine légitime peut être facilement contourné avec ces URL :

https://victim.com.attacker.com

https://attacker.com/victim.com

En revanche, si vous devez permettre aux utilisateurs d'aller chercher des ressources à partir d'emplacements arbitraires, vous devez utiliser une liste noire pour limiter l'accès aux ressources internes sensibles. Lorsque vous utilisez une liste noire, assurez-vous que vous tenez compte des différents schémas d'encodage. Par exemple, votre liste noire filtre-t-elle les mêmes URL, mais en codage hexadécimal, octal, dword, URL et mixte ? Et tient-elle compte des adresses IPv4 et IPv6 internes ?

Les attaquants peuvent contourner les listes noires, même si elles sont bien conçues, en utilisant des redirections. Les attaquants peuvent utiliser une URL qu'ils contrôlent mais qui redirige vers l'adresse figurant sur la liste noire. Par exemple, ils peuvent héberger une page qui redirige vers l'adresse locale comme ceci :

<?php header(“location: http://127.0.0.1"); ?>

Ainsi, lorsque votre serveur demande la page de l'attaquant, il est en fait redirigé vers une adresse interne restreinte. Vous pouvez empêcher ce type d'attaque en désactivant la prise en charge du suivi des redirections dans votre client Web.

Une autre façon pour les attaquants de contourner les protections des listes noires consiste à modifier les enregistrements DNS d'un domaine qu'ils contrôlent et à le faire pointer vers des adresses internes. Par exemple, ils peuvent créer un enregistrement DNS A et faire en sorte que http://attacker.com soit résolu vers une adresse interne sensible. Lorsque votre serveur demande http://attacker.com, il pense que ce domaine est situé à l'adresse interne et accède à cette adresse à la place ! Ainsi, lorsque vous validez des noms de domaine, vous devez également vous assurer que le domaine fourni par l'utilisateur ne se résout pas en une adresse IP interne.

Les SSRF sont une vulnérabilité dangereuse qui peut compromettre un réseau entier. Mais elles peuvent être évitées avec une bonne dose de diligence et un filtrage approprié.

C'est tout pour la leçon de sécurité d'aujourd'hui. Merci de nous avoir lu !


Tu as bien aimé l'article ou tu as mal aux yeux :

Le lien du PDF

Article écrit par :
Mikael Monjour
Data et Automatisation