Lancez votre machine dédiée pour commencer à hacker
- 1Créez un compte gratuit, puis cliquez sur « Démarrer le Lab »Vous obtiendrez votre propre machine avec une adresse IP
- 2Explorez la cibleOuvrez l'IP dans votre navigateur et cherchez des vulnérabilités
- 3Trouvez et soumettez les flagsLes flags sont des textes secrets cachés dans le système - collez-les ci-dessous pour marquer des XP
- ~1-2 min de configuration
- Instance privée
- 30 min par session. Relancez-la gratuitement, autant de fois que vous voulez.
Qu'est-ce qu'une attaque SSRF ?
Une attaque par server-side request forgery (SSRF) pousse un serveur à émettre des requêtes HTTP à la place de l'attaquant. Lorsqu'une application va chercher une URL fournie par l'utilisateur - pour construire un aperçu de lien, générer une vignette ou appeler un webhook - un attaquant peut la pointer vers des adresses que le serveur peut atteindre mais pas lui : panneaux d'administration internes, bases de données et, le plus dangereux dans le cloud, le service de métadonnées de l'instance. Ce lab est bâti autour de ce schéma précis.
Comment fonctionne ce lab
Vous avez devant vous Previewly, un SaaS d'aperçu de liens qui transforme n'importe quelle URL en une carte enrichie en la récupérant côté serveur. Cette récupération n'a aucune liste blanche. En travaillant entièrement depuis le Terminal d'attaque avec curl et jq, vous transformez la fonction d'aperçu en primitive SSRF, atteignez le service de métadonnées à 169.254.169.254, lisez un secret fuité dans le user-data de l'instance pour le flag utilisateur, puis volez les identifiants temporaires du rôle IAM de l'instance. Rejouer ce jeton de session volé contre le control-plane interne trop permissif de Previewly vous donne le flag root. Chaque étape est pratique ; rien n'est simulé à votre place.
Pourquoi s'entraîner aux attaques SSRF et métadonnées cloud ?
La SSRF contre le service de métadonnées est l'une des attaques cloud les plus impactantes qui soient. Lors de la fuite Capital One de 2019, une faille SSRF a permis à une attaquante de lire des identifiants IAM depuis 169.254.169.254 et d'exfiltrer plus de 100 millions d'enregistrements depuis S3. Le correctif - IMDSv2, qui exige un jeton de session et bloque la SSRF naïve - est désormais standard, mais de nombreuses instances autorisent encore IMDSv1. Pratiquer toute la chaîne sur HackerDNA développe l'instinct de repérer une fonction de récupération d'URL vulnérable, de reconnaître l'endpoint de métadonnées et de comprendre pourquoi les rôles IAM à moindre privilège comptent.
Ce que vous apprendrez
- Identifier une server-side request forgery dans une fonction d'aperçu d'URL
- Exploiter une SSRF pour atteindre le service de métadonnées de l'instance cloud (IMDS)
- Extraire un secret fuité dans le user-data EC2 via le service de métadonnées
- Voler les identifiants temporaires du rôle IAM depuis l'endpoint security-credentials
- Rejouer un jeton de session volé contre une API interne trop permissive
- Reconnaître la mauvaise configuration IMDSv1 qui permet le vol d'identifiants cloud
