Chez Orca Security, les clients sont la priorité dans tout ce que fait l’équipe, y compris dans la recherche de vulnérabilités. L’objectif premier est toujours de protéger les clients et leur parc informatique. Avant d’annoncer publiquement la vulnérabilité de CloudFormation, Orca Security a travaillé avec AWS pour s’assurer que le problème était corrigé afin d’éviter de mettre leurs clients, et ceux d’AWS, en danger.

Qu’est-ce que la vulnérabilité Zero-Day de BreakingFormation ?

Les utilisateurs d’AWS connaissent peut-être CloudFormation, un service qui permet de provisionner facilement les ressources AWS (telles que les instances EC2 et les buckets S3) à l’aide de modèles. CloudFormation permet également d’utiliser des appels API pour créer et configurer dynamiquement des ressources. Orca Security a découvert une vulnérabilité de type zero-day qui a permis de compromettre un serveur dans CloudFormation, ce qui a permis d’exécuter en tant que service d’infrastructure AWS.

L’exploitation d’une anomalie dans la façon dont CloudFormation rend les modèles a permis de déclencher une vulnérabilité XXE, utilisée pour lire des fichiers et effectuer des requêtes HTTP au nom du serveur. Le serveur contenait plusieurs binaires de service contenant la logique côté serveur AWS, ainsi que des fichiers de configuration pour la connexion aux points de terminaison et aux services AWS internes.

L’équipe de recherche pense, compte tenu des données trouvées sur l’hôte (y compris les informations d’identification et les données impliquant des points de terminaison internes), qu’un attaquant pourrait abuser de cette vulnérabilité pour contourner les limites des locataires, ce qui lui donnerait un accès privilégié à toute ressource dans AWS.

Voici à quoi ressemble une divulgation de fichier (les informations des employés d’AWS sur le côté droit de l’écran ont été expurgées) :
La première vidéo : https://drive.google.com/file/d/1zq8mbPxcaJ1htWZMKG7z6HKnVgIl-am0/view?usp=drivesdk La deuxième vidéo : https://drive.google.com/file/d/1iYU9n_RIDHeC-6X-E4OTKVamyDreQFwu/view?usp=drivesdk
[Generally, the first one mainly needs censoring on the right side of the screen (only once the users appear on the screen). Note - the format needs to still be visible (the file format being a username and the separations with “ :”).
In the second one, we might want to zoom in a bit on the right side after the data pops up.]

Orca Security ne souhaitait pas interférer avec le fonctionnement du service. Pour vérifier à qui appartenaient ces informations d’identification, mais de manière non invasive, l’équipe as utilisé les informations d’identification divulguées pour présigner une URL S3, puis utilisé le SSRF pour essayer d’accéder à son propre bucket S3 afin de voir quelle identité était impliquée. Les journaux qui en résultent indiquent à qui appartiennent ces informations d’identification. Le résultat a été une entrée de journal CloudTrail d’accès refusé, avec l’identité indiquée ci-dessous :

Remarque : le champ " userIdentity " montre qu’un service AWS, non pas le principal service public de CloudFormation mais plutôt un service interne utilisé par AWS, a essayé d’accéder à leur bucket de stockage.

Réformer les rangs

Le problème a été immédiatement signalé à AWS, qui a agi rapidement pour le résoudre. L’équipe de sécurité d’AWS a codé un correctif en moins de 25 heures, et celui-ci a été déployé dans toutes les régions AWS en 6 jours.

Les chercheurs d’Orca Security ont aidé à tester le correctif pour s’assurer que cette vulnérabilité était correctement résolue et ne pouvait plus être exploitée.
Chronologie :
• 09/09/2021 - Vulnérabilité signalée à l’équipe de sécurité d’AWS.
• 10/09/2021 - AWS indiquent qu’ils avaient apporté un changement de code et commencé à le déployer.
• 15/09/2021 - Le changement de code a atteint toutes les régions AWS.