Détails techniques du hack Capital One sur AWS

Le 19 juillet 2019, Capital One a reçu le message que redoute toute entreprise moderne : une violation 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, n'est-ce pas ?

Malheureusement, le piratage n’a pas eu lieu le 19 juillet. Il s'avère que Paige Thompson, alias. Erratique, l'a commis entre le 22 et le 23 mars 2019. C'est il y a presque quatre mois. En fait, ce n’est qu’avec l’aide de consultants externes que Capital One a pu découvrir que quelque chose s’était passé.

Un ancien employé d'Amazon a été arrêté et risque une amende de 250 XNUMX dollars et cinq ans de prison... mais il reste encore beaucoup de négativité. Pourquoi? Parce que de nombreuses entreprises victimes de piratages tentent d’ignorer la responsabilité de renforcer leur infrastructure et leurs applications face à la montée de la cybercriminalité.

Quoi qu’il en soit, vous pouvez facilement rechercher cette histoire sur Google. Nous n'entrerons pas dans le drame, mais parlons de technique côté de la question.

Tout d’abord, que s’est-il passé ?

Capital One avait environ 700 compartiments S3 en fonctionnement, que Paige Thompson a copiés et siphonnés.

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

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

Attends, comment est-ce possible ?

Eh bien, commençons par nous connecter au serveur, même si nous n'avons pas beaucoup de détails. On nous a seulement dit que cela s'était produit via un « pare-feu mal configuré ». Donc, quelque chose d'aussi simple que des paramètres de groupe de sécurité incorrects ou une configuration du pare-feu d'application Web (Imperva) ou du pare-feu réseau (iptables, ufw, Shorewall, etc.). Capital One a seulement admis sa culpabilité et déclaré avoir comblé le trou.

Stone a déclaré que Capital One n'avait pas initialement remarqué la vulnérabilité du pare-feu, mais avait agi rapidement une fois qu'il en avait pris conscience. Cela a certainement été facilité par le fait que le pirate informatique aurait laissé des informations d'identification clés dans le domaine public, a déclaré Stone.

Si vous vous demandez pourquoi nous n'approfondissons pas cette partie, sachez qu'en raison du nombre limité d'informations, nous ne pouvons que spéculer. Cela n’a aucun sens étant donné que le hack dépendait d’un trou laissé par Capital One. Et à moins qu'ils ne nous en disent plus, nous allons simplement énumérer toutes les façons possibles pour Capital One de laisser son serveur ouvert en combinaison avec toutes les façons possibles pour quelqu'un d'utiliser l'une de ces différentes options. Ces défauts et techniques peuvent aller d’oublis extrêmement stupides à des modèles incroyablement complexes. Compte tenu de l’éventail des possibilités, cela deviendra une longue saga sans véritable conclusion. Par conséquent, concentrons-nous sur l’analyse de la partie où nous avons des faits.

Le premier point à retenir est donc le suivant : sachez ce que vos pare-feu autorisent.

Établissez une politique ou un processus approprié pour garantir que SEUL ce qui doit être ouvert est ouvert. Si vous utilisez des ressources AWS telles que des groupes de sécurité ou des ACL réseau, la liste de contrôle à auditer peut évidemment être longue... mais tout comme de nombreuses ressources sont créées automatiquement (par exemple CloudFormation), il est également possible d'automatiser leur audit. Qu'il s'agisse d'un script fait maison qui analyse les nouveaux objets à la recherche de failles, ou de quelque chose comme un audit de sécurité dans un processus CI/CD... il existe de nombreuses options simples pour éviter cela.

La partie « drôle » de l’histoire est que si Capital One avait bouché le trou en premier lieu… rien ne serait arrivé. Et donc, franchement, c'est toujours choquant de voir à quel point quelque chose assez simple devient la seule raison pour laquelle une entreprise est piratée. Surtout un aussi gros que Capital One.

Alors, hacker à l'intérieur, que s'est-il passé ensuite ?

Eh bien, après avoir pénétré dans une instance EC2... beaucoup de choses peuvent mal tourner. Vous marchez pratiquement sur le fil d’un couteau si vous laissez quelqu’un aller aussi loin. Mais comment est-il arrivé dans les buckets S3 ? Pour comprendre cela, parlons des rôles IAM.

Ainsi, une façon d’accéder aux services AWS consiste à être un utilisateur. D'accord, celui-ci est assez évident. Mais que se passe-t-il si vous souhaitez donner à d'autres services AWS, tels que vos serveurs d'applications, l'accès à vos compartiments S3 ? C'est à cela que servent les 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 à un compartiment S3 : tout d'abord, le rôle est défini pour avoir une politique de confiance selon laquelle EC2 (l'ensemble du service) ou des instances spécifiques peuvent « reprendre » le rôle. Accepter un rôle signifie qu'ils peuvent utiliser les autorisations du 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 n'importe quoi sur S3, qu'il s'agisse d'accéder à 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, vous pouvez trouver le rôle IAM avec n'importe laquelle des clés d'accès à cette adresse. Bien sûr, seulement si vous êtes dans une instance.

2. Utilisez l'AWS CLI...

   Si l'AWS CLI 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 À TRAVERS l'instance. Bien sûr, si leur politique de confiance était ouverte, Paige pourrait tout faire directement.

L'essence des rôles IAM est donc qu'ils permettent à certaines ressources d'agir EN VOTRE NOM sur d'AUTRES RESSOURCES.

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

1. Elle a accédé au serveur (instance EC2) via 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 à combler, comme indiqué dans les documents officiels.

2. Une fois sur le serveur, elle a pu agir « comme si » elle était elle-même le serveur
3. Étant donné que le rôle de serveur IAM autorisait S3 à accéder à ces plus de 700 compartiments, il a pu y accéder

A partir de ce moment, il ne lui restait plus qu'à exécuter la commande List Bucketspuis la commande Sync à partir de l'AWS CLI...

Capital One Bank estime les dégâts du piratage entre 100 et 150 MILLIONS de dollars. Prévenir de tels dommages est la raison pour laquelle les entreprises investissent autant dans la protection de l’infrastructure cloud, dans le DevOps et dans les experts en sécurité. Et quelle est la valeur et la rentabilité du passage au cloud ? À tel point que même face aux défis de plus en plus nombreux en matière de cybersécurité Le marché global du cloud public a augmenté de 42 % au premier trimestre 2019.!

Moralité de l'histoire : vérifiez votre sécurité ; Effectuer des audits réguliers ; Respecter le principe du moindre privilège pour les politiques de sécurité.

(il est Vous pouvez consulter le rapport juridique complet).

Source: habr.com