Lundi, un ancien Amazone employé a été arrêté et accusé d’avoir volé plus de 100 millions de demandes de crédit de consommateurs à Capital One. Depuis lors, beaucoup ont émis l’hypothèse que la violation était peut-être le résultat d’une faille « zero-day » inconnue auparavant, ou d’une attaque « d’initié » dans laquelle l’accusée a profité d’un accès obtenu subrepticement de son ancien employeur. Mais de nouvelles informations indiquent que les méthodes qu’elle a déployées sont bien comprises depuis des années.
Ce qui suit est basé sur des entretiens avec près d’une douzaine d’experts en sécurité, dont un qui est au courant des détails de l’enquête en cours sur la violation. Étant donné que cet incident traite de concepts quelque peu jargonnés et ésotériques, une grande partie de ce qui est décrit ci-dessous a été considérablement simplifiée. Quiconque cherche une explication plus technique des concepts de base référencés ici devrait explorer certains des nombreux liens inclus dans cette histoire.
Selon une source ayant une connaissance directe de l’enquête sur la violation, le problème découlait en partie d’une mauvaise configuration Pare-feu d’application Web open source (WAF) que Capital One utilisait dans le cadre de ses opérations hébergées dans le cloud avec Amazon Web Services (AWS).
Connu comme « ModSécurité« , ce WAF est déployé avec l’open-source apache Serveur Web pour fournir des protections contre plusieurs classes de vulnérabilités que les attaquants utilisent le plus souvent pour compromettre la sécurité des applications Web.
La mauvaise configuration du WAF a permis à l’intrus de tromper le pare-feu pour qu’il relaie les demandes à une ressource back-end clé sur la plate-forme AWS. Cette ressource, connue sous le nom de service « métadonnées »est chargé de transmettre des informations temporaires à un serveur cloud, y compris les informations d’identification actuelles envoyées par un service de sécurité pour accéder à toute ressource dans le cloud à laquelle ce serveur a accès.
Dans AWS, l’utilisation exacte de ces informations d’identification dépend des autorisations attribuées à la ressource qui les demande. Dans le cas de Capital One, le WAF mal configuré pour une raison quelconque s’est vu attribuer trop d’autorisations, c’est-à-dire qu’il était autorisé à répertorier tous les fichiers dans n’importe quel compartiment de données et à lire le contenu de chacun de ces fichiers.
Le type de vulnérabilité exploité par l’intrus dans le piratage de Capital One est une méthode bien connue appelée « Contrefaçon de requête côté serveur” (SSRF), dans laquelle un serveur (dans ce cas, le WAF de CapOne) peut être amené à exécuter des commandes qu’il n’aurait jamais dû être autorisé à exécuter, y compris celles qui lui permettent de parler au service de métadonnées.
Evan Johnsonresponsable de l’équipe de sécurité des produits chez Nuageuxrécemment écrit une colonne facile à digérer sur le piratage de Capital One et les défis de la détection et du blocage des attaques SSRF ciblant les services cloud. Johnson a déclaré qu’il convient de noter que les attaques SSRF ne font pas partie la douzaine de méthodes d’attaque pour lesquels des règles de détection sont embarquées par défaut dans le WAF exploité dans le cadre de l’intrusion Capital One.
« SSRF est devenu la vulnérabilité la plus grave à laquelle sont confrontées les organisations qui utilisent des clouds publics », a écrit Johnson. « L’impact de SSRF est aggravé par l’offre de clouds publics, et les principaux acteurs comme AWS ne font rien pour y remédier. Le problème est courant et bien connu, mais difficile à prévenir et n’a aucune atténuation intégrée à la plate-forme AWS.
Johnson a déclaré qu’AWS pourrait remédier à cette lacune en incluant des informations d’identification supplémentaires dans toute demande envoyée au service de métadonnées, comme Google l’a déjà fait avec sa plate-forme d’hébergement cloud. Il a également reconnu que cela pourrait briser beaucoup de rétrocompatibilité au sein d’AWS.
« Il y a beaucoup de connaissances spécialisées qui accompagnent l’exploitation d’un service au sein d’AWS, et pour quelqu’un sans connaissance spécialisée d’AWS, [SSRF attacks are] pas quelque chose qui apparaîtrait sur n’importe quel guide de configuration critique », a déclaré Johnson dans une interview avec BreachTrace.
« Vous devez apprendre comment fonctionne EC2, comprendre le système de gestion des identités et des accès (IAM) d’Amazon et comment vous authentifier auprès d’autres services AWS », a-t-il poursuivi. « Beaucoup de personnes utilisant AWS s’interfaceront avec des dizaines de services AWS et écriront des logiciels qui orchestrent et automatisent de nouveaux services, mais au final, les gens se penchent vraiment sur AWS, et cela s’accompagne de nombreuses connaissances spécialisées difficiles à apprendre. et difficile à obtenir correctement.
Dans une déclaration fournie à BreachTrace, Amazon a déclaré qu’il est inexact d’affirmer que la violation de Capital One a été causée par AWS IAM, le service de métadonnées d’instance ou AWS WAF de quelque manière que ce soit.
« L’intrusion a été causée par une mauvaise configuration d’un pare-feu d’application Web et non par l’infrastructure sous-jacente ou l’emplacement de l’infrastructure », indique le communiqué. « AWS fournit constamment des services et des fonctionnalités pour anticiper les nouvelles menaces à grande échelle, offrant plus de capacités et de couches de sécurité que les clients ne peuvent trouver nulle part ailleurs, y compris dans leurs propres centres de données, et lorsqu’il est largement utilisé, correctement configuré et surveillé, offre une sécurité inégalée – et la piste record pour les clients de plus de 13 ans dans l’utilisation sécurisée d’AWS fournit une preuve sans ambiguïté que ces couches fonctionnent.
Amazon a souligné plusieurs services (principalement à la carte) qu’il propose aux clients d’AWS pour aider à atténuer bon nombre des menaces qui ont été des facteurs clés de cette violation, notamment :
–Conseiller d’accèsqui permet d’identifier et de délimiter les rôles AWS qui peuvent avoir plus d’autorisations que nécessaire ;
–GuardDutyconçu pour déclencher des alarmes lorsque quelqu’un analyse des systèmes potentiellement vulnérables ou déplace des quantités inhabituellement importantes de données vers ou depuis des endroits inattendus ;
–Le WAF d’AWSqui, selon Amazon, peut détecter les techniques d’exploitation courantes, y compris les attaques SSRF ;
–Amazone Macieconçu pour découvrir, classer et protéger automatiquement les données sensibles stockées dans AWS.
Guillaume Bengstonanciennement ingénieur senior en sécurité chez Netflixa écrit une série d’articles de blog l’année dernière sur la façon dont Netflix a construit ses propres systèmes pour détecter et empêcher compromission des informations d’identification dans AWS. Fait intéressant, Bengston a été embauché il y a environ deux mois pour être directeur de la sécurité du cloud pour Capital One. Je suppose que Capital One souhaite maintenant avoir réussi à l’attirer plus tôt.
Riche mouette est fondateur et directeur de la technologie chez DisruptOPS, une entreprise qui aide les entreprises à sécuriser leur infrastructure cloud. Mogull a déclaré que l’un des principaux défis pour les entreprises qui déplacent leurs opérations de centres de données physiques tentaculaires et coûteux vers le cloud est que très souvent les employés chargés de gérer cette transition sont des développeurs d’applications et de logiciels qui ne sont peut-être pas aussi imprégnés qu’ils le devraient en matière de sécurité.
« Il existe un manque de compétences et de connaissances de base que tout le monde dans l’industrie se bat pour combler en ce moment », a déclaré Mogull. « Pour ces grandes entreprises qui font ce changement, elles doivent apprendre toutes ces nouvelles choses tout en conservant leurs anciennes. Je peux vous sécuriser plus facilement dans le cloud que sur site dans un centre de données physique, mais il y aura une période de transition au fur et à mesure que vous acquerrez ces nouvelles connaissances.
Image : Une capitale
Depuis que la nouvelle de la brèche de Capital One a éclaté lundi, BreachTrace a reçu de nombreux e-mails et appels téléphoniques de responsables de la sécurité qui cherchaient désespérément plus d’informations sur la façon dont ils peuvent éviter de devenir la proie des faux pas qui ont conduit à cette brèche colossale (en effet, ces demandes étaient une partie de l’impulsion derrière cette histoire).
Certaines de ces personnes comprenaient des dirigeants de grandes banques concurrentes qui n’ont pas encore plongé dans le cloud aussi profondément que Capital One. Mais ce n’est probablement pas exagéré de dire qu’ils font tous la queue devant le plongeoir.
Il a été intéressant d’observer au cours des deux dernières années comment divers fournisseurs de cloud ont réagi aux pannes majeures sur leurs plates-formes – très souvent peu de temps après avoir publié des post-mortem détaillés sur les causes sous-jacentes de la panne et ce qu’ils font pour prévenir de tels événements dans l’avenir. Dans le même ordre d’idées, ce serait merveilleux si ce type de comptabilité publique s’étendait à d’autres grandes entreprises à la suite d’une brèche massive.
Je n’ai pas beaucoup d’espoir que nous obtiendrions officiellement de tels détails de Capital One, qui a refusé de commenter le dossier et m’a renvoyé à leur déclaration sur la violation et à la La plainte du ministère de la justice contre le pirate. C’est probablement à prévoir, étant donné que l’entreprise est déjà confronté à un recours collectif pour violation et est susceptible d’être ciblé par d’autres poursuites judiciaires à l’avenir.
Mais tant que la réponse publique et privée aux violations de données reste orchestrée principalement par des avocats (ce qui est certainement le cas actuellement dans la plupart des grandes entreprises), tout le monde continuera à ne pas pouvoir apprendre et éviter ces mêmes erreurs.