Comment le cloud d'une startup a été pris en charge par un simple formulaire d'envoi de courriels

Prévenir la prise de contrôle totale du nuage par des attaques SSRF

Voici l'histoire d'un attaquant qui a eu accès aux buckets Amazon S3 d'une startup, à des variables d'environnement et à divers secrets d'API internes, le tout par le biais d'un simple formulaire qui envoie un courrier électronique. Bien qu'il s'agisse d'une histoire vraie, je garde le nom de la startup secret.

Comment ils sont entrés

Tout commence par une application PHP qui envoie un courrier électronique. Pour charger certaines images fantaisistes en pièces jointes, l'application doit les télécharger. En PHP, c'est facile. Vous utilisez la fonction file_get_contents et c'est là que tout commence.

Bien entendu, certaines des données saisies par les utilisateurs pour ce courrier électronique n'ont pas été entièrement vérifiées ou codées en HTML, et un utilisateur a donc pu inclure une image telle que <img src=’evil.com’/>. En théorie, ce n'est pas si mal, mais malheureusement, cette fonction PHP est très puissante et peut faire bien plus que charger des images sur l'internet. Elle peut également lire des fichiers locaux et, plus important encore, des fichiers sur le réseau local au lieu d'Internet.

Au lieu de evil.com, l'attaquant a saisi une URL locale spéciale. Vous pouvez utiliser cette URL pour obtenir les informations d'identification IAM liées au rôle du serveur AWS EC2 que vous exécutez à l'aide d'une simple requête GET.

<img src=’http://169.254.169.254/latest/meta-data/'>

Le résultat est que l'attaquant a reçu un courriel contenant les identifiants IAM du serveur EC2 dans une pièce jointe de la boîte aux lettres. Ces clés permettent à l'attaquant d'usurper l'identité de ce serveur lorsqu'il communique avec divers services AWS. À partir de là, tout s'écroule...

Pourquoi cela est-il possible ?

Le système qui charge ces clés IAM est appelé IMDSv1 et Amazon a publié une nouvelle version en 2019 appelée IMDSv2. Avec IMDSv2, vous devez envoyer une requête PUT avec un en-tête spécial pour obtenir vos informations d'identification IAM. Cela signifie qu'une simple fonction de chargement d'URL basée sur GET comme file_get_contents ne peut plus causer autant de dégâts.

On ne sait pas exactement quel sera le taux d'adoption d'IMDSv2 en 2023, mais il est clair qu'Amazon prend toujours des mesures pour augmenter son adoption et que nous voyons IMDSv1 encore utilisé dans la nature.

La compromission des clés IAM entraîne d'autres compromissions : Les buckets S3 ont pu être listés et leur contenu lu. Pour aggraver les choses, l'un des buckets S3 contenait un modèle de formation de nuages, qui contenait des variables d'environnement sensibles (par exemple les clés API de Sendgrid).

Comment défendre mon infrastructure en nuage contre ce phénomène ?

Que peut-on faire pour éviter cette perte totale de données ? Vos développeurs pourraient être très prudents et veiller à utiliser une liste d'autorisations pour les URL qu'ils transmettent à file_get_contents. Ils pourraient même vérifier que le contenu qu'ils reçoivent est une image s'ils s'attendent à une image. En réalité, il est difficile d'éviter ce genre d'erreurs en tant que développeur.

Il serait préférable de s'assurer que votre infrastructure dispose de défenses supplémentaires contre ces attaques. Notre nouvelle intégration avec AWS au sein d'Aikido Security vous alertera si votre cloud ne prend pas activement l'une des mesures suivantes. Chacune de ces mesures aurait permis d'arrêter cette attaque, mais nous recommandons de toutes les mettre en œuvre. Utilisez notre compte d'essai gratuit pour voir si votre cloud est déjà défendu contre ces menaces. Découvrez comment Aikdido protège votre application contre les vulnérabilités ici.

Mesures à prendre :

1. Migrer vos nœuds EC2 IMDSv1 existants pour utiliser IMDSv2
2. Ne stockez aucun secret dans l'environnement de vos serveurs web ou dans les modèles de formation de nuages. Utilisez un outil tel que AWS Secrets Manager pour charger les secrets au moment de l'exécution.
3. Lorsque vous attribuez des rôles IAM à vos serveurs EC2, veillez à ce qu'ils soient assortis de conditions supplémentaires, telles que la restriction de leur utilisation à l'intérieur de votre réseau AWS local (votre VPC). L'exemple ci-dessous permet à votre serveur de lire dans S3, mais uniquement si le serveur EC2 communique via un point d'extrémité VPC spécifique. Cela n'est possible qu'à partir de votre réseau, de sorte que l'attaquant n'aurait pas été en mesure d'accéder aux fichiers S3 depuis son ordinateur local.

{
"Version": "2012-10-17",
"Statement": [
        {
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
                }
            }
        }
    ]
}

À propos de "The Kill Chain" (La chaîne de la mort)

The Kill Chain est une série d'histoires réelles d'attaquants atteignant les joyaux de la couronne d'entreprises de logiciels en enchaînant de multiples vulnérabilités. Rédigée par Willem Delbare, elle s'appuie sur ses dix années d'expérience dans la création et le soutien de startups SaaS en tant que directeur technique. Les récits proviennent directement du réseau de Willem et se sont réellement produits.