Comment le cloud d'une startup a été compromis par un simple formulaire d'envoi d'e-mails

Prévenir la prise de contrôle totale du cloud via des attaques SSRF

C'est l'histoire d'un attaquant qui a obtenu l'accès aux buckets Amazon S3, aux variables d'environnement et à divers secrets d'API internes d'une startup, le tout via un simple formulaire qui envoie un e-mail. Bien que ce soit une histoire vraie, je garde le nom de la startup secret.

Comment ils ont pénétré

Tout commence avec une application PHP qui envoie un e-mail. Pour charger certaines des images sophistiquées dans l'e-mail en tant que 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 les choses sérieuses commencent.

Bien sûr, une partie de la saisie utilisateur pour cet e-mail n'a pas été entièrement vérifiée ou encodée en HTML, et ainsi un utilisateur pourrait inclure une image telle que <img src=’evil.com’/>En théorie, ce n'est pas si grave, mais malheureusement, cette fonction PHP est très puissante et peut faire bien plus que charger des images depuis Internet. Elle peut également lire des fichiers locaux et, plus important encore : des fichiers sur le réseau local plutôt que sur Internet.

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

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

Le résultat fut que l'attaquant a reçu un e-mail contenant les identifiants IAM du serveur EC2 en pièce jointe dans la boîte aux lettres. Ces clés donnent à l'attaquant la capacité d'usurper l'identité de ce serveur lors des interactions avec divers services AWS. Tout se dégrade à partir de là...

Pourquoi cela est-il même possible en premier lieu ?

Le système qui charge ces clés IAM s'appelle 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 identifiants 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 dommages.

On ne sait pas clairement quel est le taux d'adoption d'IMDSv2 en 2023, mais il est clair qu'Amazon prend toujours des mesures pour augmenter son adoption et nous voyons IMDSv1 encore utilisé sur le terrain.

La compromission des clés IAM entraîne d'autres compromissions : les buckets S3 pouvaient être listés et leur contenu lu. Pour aggraver les choses, l'un des buckets S3 contenait un template CloudFormation, qui contenait des variables d'environnement sensibles (par exemple, des clés API Sendgrid).

Comment défendre mon infrastructure cloud contre cela ?

Maintenant, que pourrait-on faire pour prévenir cette perte totale de données ? Vos développeurs pourraient être très prudents et veiller à utiliser une liste blanche (allowlist) 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. La réalité est cependant que ce genre d'erreurs est difficile à éviter pour un développeur.

Il serait bien 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, à elle seule, aurait stoppé cette attaque particulière, 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 Aikido protège votre application contre les vulnérabilités ici.

Mesures à prendre :

1. Migrez vos nœuds EC2 IMDSv1 existants pour utiliser IMDSv2
2. Ne stockez aucun secret dans l'environnement de vos serveurs web ou dans les templates CloudFormation. Utilisez un outil tel que AWS Secrets Manager pour charger les secrets au runtime.
3. Lors de l'attribution de rôles IAM à vos serveurs EC2, assurez-vous qu'ils comportent des conditions supplémentaires, telles que la restriction de leur utilisation uniquement au sein de votre réseau AWS local (votre VPC). L'exemple ci-dessous permet à votre serveur de lire depuis S3, mais uniquement si le serveur EC2 communique via un endpoint VPC spécifique. Cela n'est possible qu'à partir de votre réseau, de sorte que l'attaquant n'aurait pas pu accéder aux buckets S3 depuis sa machine locale.

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

A propos de « The Kill Chain »

La Kill Chain est une série d'histoires réelles d'attaquants atteignant les joyaux de la couronne des entreprises logicielles en enchaînant plusieurs vulnérabilités. Écrit par Willem Delbare, tirant parti de ses dix ans d'expérience dans la création et le soutien de startups SaaS en tant que CTO. Les récits proviennent directement du réseau de Willem et sont tous réellement arrivés.