Bon nombre de nos clients se questionnent sur l’utilité et la méthode pour auditer leur plateforme cloud. Comment s’y prendre ? Pourquoi le faire ? Dans cet article, nous répondons à ces problématiques en les plaçant au cœur des enjeux actuels du cloud.
Pourquoi le faire ?
Aussi évident que cela puisse paraître, la conformité et, par-dessus tout, la sécurité s'appliquent au sens large à tout ce que vous possédez. Le réflexe est de s’assurer qu’un attaquant qui mettrait la main sur votre cloud soit incapable d’élever ses privilèges pour tenter une quelconque action. Dans le pire des cas, il doit être assez ralenti pour que vos mesures de détection alertent votre SOC et que des correctifs soient mis en place à temps.
Il est aussi important de rappeler que le cloud reste l'un des trophées les plus lucratifs qu'un attaquant puisse obtenir. Ne l’oubliez pas : l’attaquant n’est attiré que par une chose, l’argent ! Vos credentials AWS compromis se revendent actuellement sur des forums underground entre 100 € et 1500 €, voire plus en fonction des permissions attribuées au rôle de l'utilisateur. Sans parler de l’étape qui suit l’accès initial : rançongiciel, surfacturation, ou destruction de votre réputation de domaine si celui-ci sert à des campagnes de phishing.
Comment s’y prendre ?
À la différence d’une application web, un pentest "Black Box" pur n'est pas l'approche la plus rentable. Il vaut mieux partir du principe que l’accès est déjà compromis : l’attaquant a le temps pour lui, vous non. Afin de couvrir largement votre surface cloud, il est préférable de ne pas perdre de temps à chercher comment entrer, mais plutôt de simuler ce qui se passe une fois à l'intérieur.
Pour coller au réalisme, il faut comprendre comment les attaquants obtiennent cet accès initial. Le plus souvent, des bots scannent Internet à la recherche de fichiers Javascript oubliés contenant les credentials d'un stagiaire, ou de répertoires .git exposés qui laissent traîner des secrets dans les précédents commits. Plus sophistiqué encore : l'exploitation d'une CVE permettant de récupérer les variables d'environnement de votre instance, ou une SSRF qui permet d'appeler l'IMDS et d'obtenir ainsi la première pièce du puzzle.
Notre recommandation est d'accorder aux tests un profil équivalent à celui d’un développeur. Ce profil, ni trop ni pas assez privilégié, permet de couvrir une surface exhaustive de vos assets.
Et après ?
source: https://github.com/ine-labs/AWSGoat
Une fois l'accès obtenu, nous ne cherchons pas de 0-day au sein même d’AWS, mais bien des fautes de configuration et des privilèges trop laxistes. Enchaînés les uns aux autres, ils nous permettent de pivoter vers des utilisateurs plus intéressants jusqu'à la prise de contrôle complète de votre environnement. C’est aussi le moment de s’assurer que les bonnes pratiques de sécurité sont en place. Pourquoi un développeur junior aurait-il le droit de créer un utilisateur et de lui attribuer le groupe "Administrator" ? C’est un cas réel, et bien trop fréquent.
Conclusion
En conclusion, l'audit de votre infrastructure cloud n'est pas une simple case à cocher pour la conformité, c'est une nécessité opérationnelle. Dans un environnement où une seule erreur de configuration peut exposer l'intégralité de vos données de production, tester la résistance de vos politiques IAM et de vos isolations réseau est le seul moyen de garder le contrôle. La question n'est plus de savoir si vous allez être ciblé, mais de savoir si vous avez laissé les clés sur la porte.