Hallo! Wir haben kürzlich mit RBK.money Processing aktiv am Cyber-Polygon The Standoff teilgenommen - hier erstellen sie ein virtuelles Modell einer gesamten Metropole mit all ihrer Infrastruktur, Kraftwerken, Geschäften und anderen wichtigen Elementen. Und dann lassen sie das blaue Team (6 Teams in diesem Jahr) und das rote Team (29 Teams in diesem Jahr) in diesen digitalen Zwilling der Stadt, der erste schützt die gesamte Infrastruktur, der zweite versucht aktiv, etwas zu brechen.
aus dem Film "Blade Runner 2049"
Natürlich haben wir unsere Verarbeitung zu der Veranstaltung gebracht, über die Sie in den vorherigen Beiträgen unseres Blogs lesen können. Die Verarbeitung war Teil der Bankund lieferte Finanz- und Zahlungsdienste für Einwohner der Cyberstadt, betreute die Ausgabe von Zahlungskarten und ermöglichte den Verkauf von Waren und Dienstleistungen.
In diesem Beitrag möchte ich Ihnen erzählen, wie Hacker uns kaputt gemacht haben (Spoiler-Alarm: und nicht) und wie wir uns selbst ein paar Mal in den Fuß geschossen haben, als wir unsere Lösung vorbereitet und bereitgestellt haben. Und ja, die Hauptsache ist, dass es für uns ursprünglich eine Win-Win-Situation war: Sie werden uns nicht brechen, was bedeutet, dass wir nicht umsonst so zuversichtlich in unsere Verarbeitung sind, dass wir sie in Open Source stellen und jetzt an Hacker weitergeben. Sie werden es brechen - im Allgemeinen großartig, wir werden sehen, wo die Schwächen waren, und wir werden in Bezug auf die Sicherheit für unsere Kunden noch besser geschützt sein.
Wir haben die Cyber-Stadt in greifbarer Eile infiltriert: Dies ist eine unserer ersten Bereitstellungen in Kubernetes (zuvor haben wir alles mit Salt-Zuständen bereitgestellt), und wir mussten neue Installationsansätze verwenden. Und die Folgen dieses Ansturms ließen nicht lange auf sich warten.
Tipps für Hacker
Noch bevor wir die Verarbeitung in einer Cyberstadt eingeführt haben, haben wir dort bewusst zwei Schwachstellen hinterlassen.
Die erste ist eine Sicherheitsanfälligkeit im Zusammenhang mit Karten-Tokenisierungsmethoden. Diese Methoden waren anfällig für Schwachstellen in Form von Wiederholungsangriffen, dh die Karte konnte in einem Geschäft erfolgreich tokenisiert werden, und mit diesem Token kam sie zu einem anderen und wurde dort wiederverwendet. Wir hofften schüchtern, dass die Sicherheitslücke gefunden wird, aber leider.
Die zweite ist eine einfache Abrechnung des Haupthändlers. Wir haben nur einen Oligarchenhändler gegründet, es war eine juristische Person, die Online-Shops in der Cyberstadt besaß. Und dieser Geldbeutel hatte ziemlich einfache Anmeldeinformationen, dh ein Passwort wie Parolec0 hätte im Prinzip verletzt werden können . Aber es ging auch nicht los.
Aber unsere eigenen Pfosten kamen hoch.
In Eile - Sie können nicht alles schützen
Ein aufmerksamer Leser wird aus dem Punkt über den Haupthändler schließen - Moment mal, Sie haben einen einzigen Oligarchen, der alle Online-Shops besitzt, es reicht aus, einen solchen Online-Shop zu hacken, und Sie können auf den Rest zugreifen. Nun ja, sie haben nicht so schnell über diesen Moment nachgedacht.
Und tatsächlich war es nach dem Hacken dieses Händlers möglich, seinen API-Schlüssel für unsere Verarbeitung zu erhalten und diese Verarbeitung vollständig zu verwalten. Genau das ist passiert - die Angreifer haben eine Drittanbieterlösung, einen Online-Unterhaltungsladen der Stadt, gehackt, von dort den API-Schlüssel unseres Händlers erhalten, ihn zu unserer Verarbeitung gebracht und eine Methode aufgerufen, mit der Sie Ihren Online-Shop ein- und ausschalten können. Und da eine juristische Person alle Einzelhandelsgeschäfte in der ganzen Stadt besaß, wurden sie alle ausgeschaltet.
Im Prinzip ist dies richtig, wenn Sie ein kräftiger gieriger Oligarch sind, der sich alles geschnappt hat - leiden. Wir haben Schlussfolgerungen gezogen und beschlossen, den Geldbeutel unverzüglich zu enteignen, indem wir 5 weitere unabhängige juristische Personen sowie für jedes separate „Login-Passwort“ - und API-Schlüsselpaar geschaffen haben. Ich denke, dass wir in den nächsten Wettbewerben versuchen werden, die Situation im Geschäftsbereich noch realistischer zu machen.
Und es "flog" auch wegen der Besonderheiten des Kuber vorbei.
In Kubernetes, der Haupt - Repository für den Zustand des Clusters ist ETCD , ein nützliches verteiltes System , auf das Sie sehr aufbauen können, sehr zuverlässig Dinge. Die Latenz von Festplatten ist jedoch zu kritisch.
Wie ich schrieb, haben wir die Verarbeitung in einer virtuellen Cyber-City-Umgebung bereitgestellt. Es gab ziemlich aktive Angriffe auf die mit uns benachbarten Objekte, und sobald eines dieser „lauten“ Objekte in unseren Datenspeicher verschoben wurde, war die Infrastruktur eines der Teilnehmer lange Zeit und dauerhaft defekt. Und obwohl wir in diesem Fall de facto kein Ziel waren und in diesem Moment niemand die Verarbeitung unterbrach, funktionierte es normal weiter, aber der Cluster selbst begann sich wild zu verlangsamen, die Festplatten konnten es einfach nicht bewältigen (sie bemerkten, dass die Ausgabe des Befehls ls -l ungefähr 19 dauerte Sekunden). Es stellte sich heraus, dass eine Art DoS herauskam, und in einer Nacht schickten wir unsere Standardkatzen auf alle Anfragen.
Nach dieser Situation haben uns die Organisatoren von The Standoff auf andere Festplatten verschoben, dh sie haben eine virtuelle Maschine ausgeschaltet und eine andere an einem anderen Ort eingeschaltet. Danach fing unser verteiltes DBMS glücklich ein gespaltenes Gehirn auf, die Hälfte der Knoten enthielt eine Information, die andere Hälfte und konnte nicht wirklich mit sich selbst übereinstimmen. Im Kampf wären wir natürlich mehr mit Migration verwechselt worden und hätten dies nicht zugelassen. Und in einer Testumgebung war es viel einfacher, einfach alles, was verfügbar war, zu knallen und neu zu installieren, was wir übrigens 2 Stunden lang getan haben. Warum ich das betone - weil wir in zwei Stunden einen vollwertigen Workflow mit allen Komponenten bereitgestellt haben und Sie dies mit unserer Verarbeitung im Kampf in Ihrem Unternehmen tun können. Die klassische Verarbeitung wird normalerweise in Unternehmen mit einer Laufzeit von 3 Monaten eingesetzt.
Also, was Split-Brain betrifft, ist alles ein Ansturm. Wir haben gerade / tmp auf einem der Knoten unter der Wurzel heruntergefahren . Wer wusste, dass das CSI LVM- Modul , das lokale Volumes von Hardware auf Pods verteilt, heimlich (!) Ein dauerhaftes Kuber-Volume in / tmp bereitstellt . So stellte sich heraus, dass wir mit unseren eigenen Händen die Daten unter den Füßen des DBMS, das sich darauf drehte, zerstört haben. Trotz der Tatsache, dass wir den Speicher für einige der Knoten in den Basisclustern abgerissen haben, funktionierte alles für uns bis zum ersten Neustart der virtuellen Maschine, als sie begannen, uns auf neue Seiten zu übertragen.
Das Blue-Team schaltet langsam seine Verteidigung aus ...
Eines Tages beschloss das blaue Team, den externen Schutz (Firewall usw.) auszuschalten. Das heißt, die ersten Tage versuchten Hacker, Systeme mit dieser Art von aktiviertem Schutz zu brechen, und dann - ohne. Wir hatten auch eine WAF von Drittanbietern, die beim Eintritt mit njinks als Modul unseren Datenverkehr geladen und geschützt hat.
Und dann kam der Tag, wir gingen, um WAF auszuschalten und stellten fest, dass es bereits ausgeschaltet war. Vor zwei Tagen. Weil wir großartig sind und es eilig haben (ja, ja), haben wir Ingress-Kubernetes eingerichtet, die eine WAF-Instanz hatten. Und alles wäre in Ordnung, aber WAF erreichte den Kontrollserver einfach nicht, konnte die Lizenzdatei nicht von ihm herunterladen, zuckte mit den Schultern und schaltete einfach die Sünde aus. Und es stellt sich heraus, dass all diese zwei Tage, an denen wir „mit dem enthaltenen Schutz brechen“, tatsächlich ohne diesen Schutz saßen.
Trotzdem waren wir nicht kaputt.
Eine weitere Bestätigung der These, dass Eile schädlich ist (wenn Sie nicht genug von den vorherigen haben) - die Situation mit unserem Betrugsbekämpfung. Ich habe es in früheren Blog- Beiträgen beschrieben , es gibt eine magische Kiste mit einer Reihe von Regeln. Betrugsbekämpfung schützt vor dem Platzen von Bankkarten, Zahlungsversuchen an verschiedenen Orten / IP / E-Mail und anderen unfreundlichen Handlungen. Wir sagten dem Verteidigungsteam, dass wir alle diese Regeln sorgfältig selbst aufstellen würden.
Und wir haben es geschafft - wir haben alle Betrugsbekämpfungsregeln sorgfältig festgelegt. Auf unserem Battle Server RBK.money statt der Installation für The Standoff. Die URLs der Benutzeroberfläche in der Adressleiste des Browsers sind kitschig. Das heißt, der Betrugsbekämpfung war zu dieser Zeit eine Schachtel mit einer stillen mysteriösen Leere.
Dies wurde zu einem der erfolgreichen Vektoren für Wiederholungen:
Zum Beispiel hatten sie zuvor eine Internetbank eines Drittanbieters gehackt, indem sie den PAN-Code der Karte (die Nummern selbst, die primäre Kontonummer), den Namen des Karteninhabers und das Gültigkeitsdatum gestohlen hatten. Danach, bereits in unserer Verarbeitung auf dieser PAN, begannen sie, CVVs zu sortieren. Und alles wäre in Ordnung, nach 3 Versuchen, die Karten zu sprengen, würden sie von unserem Betrugsbekämpfung blockiert. Wenn nur ... siehe oben.
Im Allgemeinen gab es viele solche lustigen Geschichten. Irgendwann wurden unsere Dienste nicht mehr aufgelöst und die Zeit auf den Knoten wurde von einigen Hosts nicht mehr zufällig synchronisiert.
Das erste, was sie taten, war natürlich, die falsche Konfiguration, die unverständliche Arbeit des Clusters, verantwortlich zu machen.
Mit DNS wurde das Problem schnell gelöst, indem CoreDNS-Pods direkt auf die Knoten verschoben wurden, auf denen dieser Datenverkehr nicht ausgelöst wurde. Wir hatten jedoch Glück mit NTP. Glücklicherweise haben wir keinen großen Zeitversatz festgestellt, und beim Erstellen eines Clusters konnten die Knoten immer noch synchronisiert werden.
Es stellte sich heraus, dass auf Firewall-Ebene irgendwann ausgehende NTP- und DNS-Anforderungen für einige Knoten deaktiviert waren. Anscheinend hat jemand die Filtrationsmuttern zu fest angezogen.
Andere Angriffe
Angriffe auf andere nahe gelegene Cyber-City-Ziele waren zeitweise ebenfalls erfolgreich, einschließlich solcher wie wir im Cyber-City-Finanzsystem.
Es ist gut, dass wir die Alarm-URLs über dem Gummiband und in der Überwachung nicht verwechselt haben und sie ziemlich genau und schnell genug gesehen haben.
Zum Beispiel wie beim Hacken unseres Oligarchen und des zurückgezogenen API-Schlüssels. Es wurde um 22.17 Uhr Moskauer Zeit gehackt. Um 22.22 Uhr bemerkten wir dies auf unserer Seite und meldeten es sofort den Verteidigern und Organisatoren. Wir haben übrigens festgestellt, dass dank der krummen Verwendung der API - die Hacker haben bei der ersten Anforderung einen seltsamen Inhaltstyp-Header übergeben, der als seltene Methode unserer API bezeichnet wird, und einige andere Nuancen - dies der Grund war, die Warnung auszulösen.
Wenn das System normal und automatisch arbeitet, fällt selten alles gleichzeitig zusammen. Aber wenn so etwas passiert, bedeutet das, dass jemand mit seinen Händen mit der API spielt. Hier ist die Warnung und es hat funktioniert.
Wenn es sich nicht um eine Cyberstadt handelt, sondern um reale Situationen dieser Art, geschieht alles noch schneller. In solchen Fällen blockiert das System automatisch die Aktionen des Händlers, sodass nichts von seinem Konto abgebucht wird und im Prinzip seine Arbeit und sein Geschäft nicht beeinträchtigt, Panik auslöst und verbindet bereits lebende Mitarbeiter
Für die Zukunft
Das Cyber City Hacking-Format ist, kein Scherz, die Zukunft der Informationssicherheit. Wir werden auf jeden Fall wieder hierher kommen, alle Fehler berücksichtigen und über die Infrastruktur und die Geschäftspläne nachdenken, damit sie so realitätsnah wie möglich sind. Im Idealfall möchte ich im Allgemeinen, dass Mitarbeiter der Zentralbank oder der staatlichen Dienste zu denselben Schlussfolgerungen kommen - um ihre Infrastruktur im Kampf zu testen, die Möglichkeit zu bieten, Schwachstellen zu finden und für Benutzer und Unternehmen noch besser und zuverlässiger zu werden.
Und es war wirklich sehr cool und hat Spaß gemacht. Tatsächlich haben wir eine große Anzahl von Chaos Monkey- Fällen erhalten, die nicht unbedingt in der Produktion reproduziert werden müssen. Wir haben die Verarbeitung auf Angriffe getestet, nachdem wir in zwei Tagen mehr Angriffe erhalten haben, als wir regelmäßig in sechs Monaten erhalten haben.
Wir haben viel gelernt und vor allem gesehen, dass unser Produkt, das wir für uns und für Sie schreiben, bei Cyber City-Teilnehmern beliebt ist. Für unsere IT war es eine starke Motivation - schließlich ist es schön, wenn Menschen das Ergebnis Ihrer Arbeit nutzen, auch wenn dies der Fall ist Fall und für ganz bestimmte Zwecke.
Es hat uns sehr gut gefallen und wir wollen MEHR.
Warten Sie im nächsten Standoff mit noch interessanteren Schemata, mehr Zahlungsfunktionen und neuen Angriffsmethoden auf uns!