Détails techniques du piratage de Capital One Bank sur AWS

Le 19 juillet 2019, Capital One Bank a reçu un message dont toute entreprise moderne a peur - une fuite de données s'est produite. Elle a touché plus de 106 millions de personnes. 140 000 numéros de sécurité sociale aux États-Unis, un million de numéros de sécurité sociale au Canada. 80 000 comptes bancaires. Désagréable, d'accord?

Malheureusement, le piratage n'a pas eu lieu du tout le 19 juillet. Il s'est avéré que Paige Thompson, alias Erratic , l'a exécutée entre le 22 et le 23 mars 2019. Il y a presque quatre mois . En fait, ce n'est qu'avec l'aide de consultants externes que Capital One a su que quelque chose s'était passé.

Ancienne employée d'Amazon arrêtée, elle risque une amende de 250 000 $ et cinq ans de prison ... mais il y a beaucoup de négativité. Pourquoi? Parce que de nombreuses entreprises qui ont été piratées essaient d'écarter la responsabilité du renforcement de leur infrastructure et de leurs applications dans un contexte de cybercriminalité croissante.

Dans tous les cas, vous pouvez facilement rechercher sur Google cette histoire. Nous n'entrerons pas dans le théâtre, mais parlons du côté technique des choses.

D'abord, que s'est-il passé?

Chez Capital One, il y avait environ 700 godets S3 que Paige Thompson a copiés et dégonflés.

Deuxièmement, s'agit-il d'un autre cas d'une stratégie de compartiment S3 mal configurée?

Non, pas cette fois. Ici, elle a eu accès à un serveur avec un pare-feu mal configuré et à partir de là, elle a mené toute l'opération.

Attendez, comment est-ce possible?

Eh bien, commençons par nous connecter au serveur, bien que nous ayons peu de détails. On nous a seulement dit que cela s'était produit à travers un «pare-feu mal configuré». Donc, quelque chose d'aussi simple que de mauvais paramètres de groupe de sécurité ou la configuration du pare-feu d'application Web (Imperva) ou du pare-feu réseau (iptables, ufw, shorewall, etc.). Capital One a seulement plaidé coupable et déclaré avoir fermé le trou.

Stone a déclaré que Capital One n'avait pas initialement remarqué la vulnérabilité du pare-feu, mais a répondu rapidement dès qu'il l'a découvert. Bien sûr, cela a été aidé par le fait que le pirate aurait laissé les informations d'identification clés accessibles au public, a déclaré Stone.

Si vous souhaitez savoir pourquoi nous ne nous penchons pas sur cette partie, sachez qu'en raison d'informations limitées, nous ne pouvons que spéculer. Cela est inutile étant donné que le hack dépendait de l'écart laissé par Capital One. Et s'ils ne nous en disent pas plus, nous énumérerons simplement toutes les façons possibles dont Capital One a laissé son serveur ouvert en combinaison avec toutes les façons possibles dont quelqu'un pourrait utiliser l'une de ces différentes options. Ces lacunes et ces méthodes peuvent aller des oublis incroyablement stupides à des schémas incroyablement complexes. Compte tenu de l'éventail des possibilités, cela se transformera en une longue saga sans véritable conclusion. Par conséquent, nous nous concentrerons sur l'analyse de la partie où nous avons les faits.

Donc la première conclusion: sachez ce que vos pare-feu permettent

Établissez une politique ou un processus pour vous assurer que SEULEMENT ce qui est ouvert l'est. Si vous utilisez des ressources AWS, telles que des groupes de sécurité ou des listes de contrôle d'accès réseau, la liste de contrôle pour la vérification peut évidemment être longue ... mais comme de nombreuses ressources sont créées automatiquement (c'est-à-dire CloudFormation), vous pouvez également automatiser leur audit. Qu'il s'agisse d'un script de fortune qui recherche de nouveaux objets à la recherche de défauts, ou quelque chose comme un audit de sécurité dans un processus CI / CD ... il existe de nombreuses options faciles pour éviter cela.

La partie «amusante» de l'histoire est que si Capital One avait fermé le trou depuis le début ... rien ne serait arrivé. Et donc, franchement, il est toujours choquant de voir à quel point quelque chose de très simple devient la seule raison pour laquelle une entreprise de piratage informatique. Surtout aussi grand que Capital One.

Donc, le pirate à l'intérieur - que s'est-il passé ensuite?

Eh bien, après avoir pénétré dans l'instance EC2 ... beaucoup de choses peuvent mal se passer. Vous marchez presque le long d'un couteau si vous permettez à quelqu'un d'aller aussi loin. Mais comment est-elle entrée dans le seau S3? Pour comprendre cela, discutons des rôles d'IAM (rôles IAM).

Ainsi, une façon d'accéder aux services AWS est d'être un utilisateur. D'accord, c'est assez évident. Mais que se passe-t-il si vous souhaitez donner à d'autres services AWS, par exemple vos serveurs d'applications, un accès à vos compartiments S3? Pour cela, il existe des rôles IAM. Ils se composent de deux éléments:

1. Politique de confiance - quels services ou quelles personnes peuvent utiliser ce rôle?
   
2. Politique d'autorisations - que permet ce rôle?

Par exemple, vous souhaitez créer un rôle IAM qui permettra aux instances EC2 d'accéder au compartiment S3: tout d'abord, il configure une stratégie de confiance pour le rôle, afin que EC2 (l'ensemble du service) ou des instances spécifiques puissent prendre le relais. Assumer un rôle signifie qu'ils peuvent utiliser des autorisations de rôle pour effectuer des actions. Deuxièmement, la politique d'autorisations permet au service / personne / ressource qui "a assumé le rôle" de faire quelque chose sur S3, que ce soit l'accès à un compartiment spécifique ... ou à plus de 700, comme dans le cas de Capital One.

Une fois que vous êtes dans une instance EC2 avec le rôle IAM, vous pouvez obtenir des informations d'identification de plusieurs manières:

1. Vous pouvez demander des métadonnées d'instance à http://169.254.169.254/latest/meta-data
   
   Entre autres choses, à cette adresse, vous pouvez trouver le rôle IAM avec l'une des clés d'accès. Bien sûr, seulement si vous êtes dans une instance.
   
2. Utiliser AWS CLI ...
   
   Si l'interface de ligne de commande AWS est installée, elle est chargée avec les informations d'identification des rôles IAM, le cas échéant. Il ne reste plus qu'à travailler sur l'instance. Bien sûr, si leur politique de confiance était ouverte, Page pourrait le faire directement.

Ainsi, l'essence des rôles IAM est qu'ils permettent à une ressource d'agir À PARTIR DE VOTRE NOM sur D'AUTRES RESSOURCES.

Maintenant que vous comprenez les rôles d'IAM, nous pouvons parler de ce que Page Thompson a fait:

1. Elle a accédé au serveur (instance EC2) à travers un trou dans le pare-feu
   
   Qu'il s'agisse de groupes de sécurité / ACL ou de leurs propres pare-feu d'applications Web, le trou était probablement assez facile à fermer, comme indiqué dans les documents officiels.
   
2. Une fois sur le serveur, elle a pu agir "comme si" elle était le serveur
   
3. Étant donné que le rôle de serveur IAM permettait à S3 d'accéder à ces 700+ compartiments, elle a pu y accéder

Désormais, elle ne pouvait exécuter que la commande List Buckets , puis la commande Sync de l'AWS CLI ...

---

Capital One Bank estime les dommages causés par le piratage à un montant de 100 à 150 MILLIONS de dollars . Pour éviter de tels dommages, les entreprises investissent tant dans la protection de l'infrastructure cloud, des DevOps et des experts en sécurité. Et quelle est la valeur et la rentabilité de la transition vers le cloud? À tel point que même face à de plus en plus de problèmes de cybersécurité, le marché global du cloud public a progressé de 42% au premier trimestre 2019 !

La morale de cette histoire: vérifiez votre sécurité; effectuer des audits réguliers; respecter le principe du moindre privilège pour les politiques de sécurité.

(Vous pouvez voir le rapport juridique complet ici).