salut! Récemment, avec RBK.money Processing, nous avons pris une part active au cyber-polygone The Standoff - c'est à ce moment-là qu'ils créent un modèle virtuel d'une métropole entière avec toutes ses infrastructures, ses centrales électriques, ses magasins et d'autres éléments importants. Et puis ils ont laissé l'équipe bleue (6 équipes cette année) et l'équipe rouge (29 équipes cette année, respectivement) se joindre à ce jumeau numérique de la ville, la première protège toute cette infrastructure, la seconde tente activement de casser quelque chose.
du film "Blade Runner 2049"
Bien sûr, nous avons apporté notre traitement à l'événement, que vous pouvez lire dans les articles précédents de notre blog. Le traitement faisait partie de la banqueet a fourni des services financiers et de paiement aux résidents de la cyber-ville, assuré l'émission de cartes de paiement et rendu possible la vente de biens et de services.
Dans cet article, je veux vous dire comment les pirates nous ont cassés (alerte spoiler: et ne l'ont pas fait), ainsi que comment nous nous sommes tirés une balle dans le pied à plusieurs reprises lors du processus de préparation et de déploiement de notre solution. Et oui, l'essentiel est que pour nous, c'était au départ une situation gagnant-gagnant: ils ne nous briseront pas, ce qui signifie que ce n'est pas pour rien que nous sommes tellement confiants dans notre traitement que nous le mettons en open source et maintenant nous le donnons aux hackers. Ils le briseront - généralement génial, nous verrons où étaient les faiblesses, et nous deviendrons encore plus protégés en termes de sécurité pour nos clients.
Nous avons infiltré la cyber ville dans une précipitation tangible: c'est l'un de nos premiers déploiements dans Kubernetes (avant cela, nous avons tout déployé avec des états Salt), et nous avons dû utiliser de nouvelles approches d'installation. Et les conséquences de cette ruée ne se sont pas fait attendre.
Conseils aux pirates
Avant même de déployer le traitement dans une cyber-ville, nous y avons volontairement laissé deux points faibles.
Le premier est une vulnérabilité associée aux méthodes de tokenisation des cartes. Ces méthodes étaient sujettes à des vulnérabilités sous la forme d'attaques de relecture, c'est-à-dire que la carte pouvait être jetée avec succès dans un magasin, puis avec ce jeton, elle arrivait dans un autre et y était réutilisée. Nous espérions timidement que la vulnérabilité serait trouvée, mais hélas.
Le second est une simple comptabilité du commerçant principal. Nous n'avons créé qu'un seul marchand d'oligarques, c'était une entité juridique qui possédait des magasins en ligne dans la cyber-ville. Et ce sac d'argent avait des informations d'identification assez simples, c'est-à-dire qu'un mot de passe comme Parolec0, en principe, aurait pu être contusionné . Mais ça n'a pas décollé non plus.
Mais nos propres jambages sont montés.
Pressé - vous ne pouvez pas tout protéger
Un lecteur attentif conclura à partir du point sur le marchand principal - attendez une minute, vous avez un et seul oligarque qui possède tous les magasins en ligne, il suffit de pirater une de ces boutiques en ligne et vous pouvez accéder au reste. Eh bien, oui, ils n'ont pas pensé à ce moment à la hâte ..
Et en fait, après avoir piraté ce marchand, il était possible d'obtenir sa clé API pour notre traitement et de gérer pleinement ce traitement. En fait, c'est ce qui s'est passé: les attaquants ont piraté une solution tierce, un magasin de divertissement en ligne dans la ville, ont obtenu la clé API de notre marchand à partir de là, l'ont accompagnée dans notre traitement et ont appelé une méthode qui vous permet d'activer / désactiver votre boutique en ligne. Et comme une entité juridique possédait tous les points de vente dans toute la ville, ils se sont tous arrêtés.
En principe, c'est correct, si vous êtes un oligarque avide et lourd qui a tout saisi pour lui-même - souffrez. Nous avons tiré des conclusions et décidé de déposséder rapidement la bourse en créant 5 autres entités juridiques indépendantes, et pour chaque paire distincte de «mot de passe de connexion» et de clé API. Je pense que dans les prochains concours de ce genre, nous essaierons de rendre la situation encore plus proche de la réalité dans la partie commerciale.
Et aussi "survolé" à cause des particularités du kuber.
Dans Kubernetes, le référentiel principal de l'état du cluster est ETCD , un système distribué utile sur lequel vous pouvez créer des éléments très, très fiables. Mais il est trop critique de la latence des disques durs.
Comme je l'ai écrit, nous avons déployé le traitement dans un environnement de cyber-ville virtuelle. Il y a eu des attaques assez actives sur les objets à côté de nous, et une fois que l'un de ces objets «bruyants» a été déplacé vers notre banque de données, l'infrastructure de l'un des participants, qui a été interrompue pendant longtemps et de manière persistante. Et bien que de facto nous n'étions pas une cible dans ce cas, et à ce moment-là personne n'a interrompu le traitement, il a continué à fonctionner normalement, mais le cluster lui-même a commencé à ralentir énormément, les disques durs ne pouvaient tout simplement pas faire face (ils ont réussi à remarquer que la sortie de la commande ls -l prenait environ 19 secondes). Il s'est avéré qu'une sorte de DoS est sorti, et en une nuit, nous avons envoyé nos chats standard à toutes les demandes.
Après cette situation, les organisateurs de The Standoff nous ont déplacés vers d'autres disques, c'est-à-dire qu'ils ont désactivé une machine virtuelle et en ont activé une autre à un emplacement différent. Après cela, notre SGBD distribué a heureusement attrapé un cerveau divisé, la moitié des nœuds contenait une information, la moitié - une autre, et ne pouvaient pas vraiment être d'accord avec eux-mêmes. Au combat, nous aurions bien sûr été plus confus avec la migration et nous n'aurions pas permis cela. Et dans un environnement de test, il était beaucoup plus facile de planter tout ce qui était disponible et de le réinstaller, ce que nous avons fait, en passant, au fait, 2 heures. Pourquoi je le souligne - parce que nous avons déployé un flux de travail complet avec tous les composants en deux heures, et vous pouvez le faire avec notre traitement au combat dans votre entreprise. Le traitement classique est généralement déployé dans des entreprises de 3 mois.
Donc, à propos du cerveau divisé, tout est précipité. Nous venons de supprimer / tmp sur l'un des nœuds sous la racine . Qui savait que le module CSI LVM , qui distribue les volumes locaux du matériel aux pods, monte secrètement (!) Un volume Kuber persistant dans / tmp . Ainsi, il s'est avéré que de nos propres mains, nous avons démoli les données sous les pieds du SGBD qui tournait dessus. De plus, malgré le fait que nous ayons démoli le stockage de certains nœuds dans les clusters de base, tout a continué à fonctionner pour nous jusqu'au premier redémarrage de la machine virtuelle, qui s'est produit lorsqu'ils ont commencé à nous transférer vers de nouveaux côtés.
L'équipe bleue éteint lentement ses défenses ...
Un jour, l'équipe bleue a décidé de désactiver la protection externe (pare-feu, etc.). Autrement dit, les premiers jours, les pirates ont tenté de briser les systèmes avec ce type de protection activé, puis - sans. Nous avions également un WAF tiers, qui dans l'entrée avec njinks sous la forme d'un module a été chargé et protégé notre trafic.
Et puis le jour venu, nous sommes allés éteindre WAF et avons réalisé qu'il était déjà éteint. Il y a deux jours. Parce que nous sommes super et pressés (oui, oui), nous avons mis en place des kubernetes d'entrée, qui avaient une instance WAF. Et tout irait bien, mais WAF n'a tout simplement pas atteint le serveur de contrôle, n'a pas pu télécharger le fichier de licence à partir de celui-ci, a haussé les épaules et s'est simplement éteint du péché. Et il s'avère que tous ces deux jours où nous «rompons avec la protection incluse» étaient assis, en fait, sans cette protection.
Mais nous n'étions toujours pas brisés.
Une autre confirmation de la thèse selon laquelle se dépêcher est nuisible (si vous n'en avez pas assez des précédents) - la situation avec notre antifraude. Je l'ai décrit dans des articles de blog précédents , il y a une boîte magique avec un ensemble de règles. Antifraud protège contre le piratage des cartes bancaires, les tentatives de paiement à un moment donné à partir de différents endroits / IP / e-mail et d'autres actions hostiles. Nous avons dit à l'équipe de défense que nous établirions nous-mêmes toutes ces règles de manière réfléchie.
Et nous l'avons fait - nous avons soigneusement mis en place toutes les règles anti-fraude. Sur notre serveur de production RBK.money au lieu d'installer pour The Standoff. Les URL de l'interface utilisateur dans la barre d'adresse du navigateur sont ringardes. Autrement dit, l'antifraude à cette époque était une boîte avec un vide mystérieux silencieux.
C'est devenu l'un des vecteurs de succès pour les éditeurs:
Par exemple, ils avaient précédemment piraté une banque Internet tierce, volant le code PAN de la carte (les numéros eux-mêmes, le numéro de compte principal), le nom du titulaire de la carte et récupérant la date de validité. Après cela, déjà dans notre traitement sur ce PAN, ils ont commencé à trier les CVV. Et tout irait bien, après 3 tentatives pour casser les cartes, elles seraient bloquées par notre antifraude. Si seulement ... voir ci-dessus.
En général, il y avait beaucoup d'histoires amusantes. À un moment donné, nos services ont cessé de se résoudre et l'heure sur les nœuds a cessé d'être synchronisée, et de manière aléatoire, à partir de certains hôtes.
Bien sûr, la première chose qu'ils ont faite a été de blâmer une mauvaise configuration, le travail incompréhensible du cluster.
Avec DNS, le problème a été rapidement résolu en déplaçant les pods CoreDNS directement vers les nœuds où ce trafic ne s'est pas déclenché, mais avec NTP, nous avons eu de la chance - heureusement, nous n'avons pas détecté un décalage d'horloge important et lors de la création d'un cluster, les nœuds ont quand même réussi à se synchroniser.
Il s'est avéré qu'à un moment donné au niveau du pare-feu, les requêtes NTP et DNS sortantes étaient désactivées pour certains nœuds. Apparemment, quelqu'un a trop serré les écrous de filtration.
Autres attaques
Les attaques contre d'autres cibles de cyber-villes à proximité ont également parfois été couronnées de succès, y compris celles, comme nous, dans le système financier de la cyber-ville.
C'est bien que nous n'ayons pas confondu les urls d'alerte au-dessus de l'élastique et dans le monitoring, et les voyions assez précisément et assez rapidement.
Par exemple, comme dans le cas du piratage de notre oligarque et de la clé API retirée. Il a été piraté à 22 h 17, heure de Moscou. A 22h22, de notre côté, nous l'avons remarqué et immédiatement signalé aux défenseurs et aux organisateurs. Nous avons remarqué, en passant, grâce à l'utilisation tordue de l'API - les pirates ont passé un en-tête de type de contenu étrange dans la première requête, appelée méthode rare de notre API, et quelques autres nuances - c'était la raison pour laquelle l'alerte était déclenchée.
Lorsque le système fonctionne normalement et automatiquement, tout coïncide rarement en même temps. Mais si quelque chose comme ça se produit, cela signifie que quelqu'un joue avec l'API avec ses mains. Voici l'alerte et cela a fonctionné.
Si nous ne parlons pas d'une cyber-ville, mais de situations réelles de ce type, alors tout se passe encore plus vite.Dans de tels cas, le système bloque automatiquement les actions du commerçant afin que rien ne soit retiré de son compte et, en principe, ne nuit pas à son travail et à son entreprise, suscite la panique et relie les employés déjà vivants
Pour le futur
Le format de piratage de la cyber-ville est, sans blague, l'avenir de la sécurité de l'information. Nous reviendrons certainement ici, prendrons en compte toutes les erreurs et réfléchirons aux infrastructures et aux schémas commerciaux pour qu'ils soient aussi proches que possible de la réalité. Dans l'idéal, je souhaite généralement que les membres de la Banque centrale ou des services de l'État parviennent aux mêmes conclusions: tester leur infrastructure au combat, fournir une opportunité de trouver des vulnérabilités et devenir encore plus performants et plus fiables pour les utilisateurs et les entreprises.
Et c'était en fait très cool et amusant. En fait, nous avons reçu un grand nombre d' étuis Chaos Monkey qui ne seraient pas nécessairement reproduits en production, nous avons testé le traitement des attaques, ayant reçu plus d'attaques en 2 jours que nous n'en recevons régulièrement en 6 mois.
Nous avons beaucoup appris, et surtout, nous avons vu que notre produit, que nous écrivons pour nous et pour vous, est populaire parmi les participants aux cybercités, pour notre informatique, c'était une forte motivation - après tout, c'est bien quand les gens utilisent le résultat de votre travail, même si dans ce cas et à des fins très spécifiques.
Nous l'avons vraiment aimé et nous en voulons PLUS.
Dans le prochain Standoff, attendez-nous avec des schémas encore plus intéressants, plus de fonctions de paiement et de nouveaux vecteurs d'attaque!