Binances 6,3-Milliarden-Dollar-Vorfall: Was geschah und wie sich das Risiko verringern lässt

Die vorläufigen Erkenntnisse von Binance beschreiben kompromittierte Mitarbeitercomputer im Juni und September, gefolgt von einem umfassenderen Eindringen über interne KI-Werkzeuge am 20. Oktober. Die Angreifer erreichten die Computer zweier Kollegen und fanden ein Token für die Bereitstellung von Containern. Am 29. Oktober nutzten sie es, um Schadcode bereitzustellen, der die Wallet-Signatursysteme erreichte und unbefugte Überweisungen auslöste.

Die Angreifer nutzten den Signaturdienst auch, um eine EIP-7702-Delegation zu erstellen: eine Berechtigung, mit der von ihnen kontrollierter Code für eine Ethereum-Wallet handeln konnte. Diese Berechtigung bestand auf der Blockchain unabhängig von den Auszahlungssystemen von Binance. Ein Auszahlungsstopp konnte sie nicht entfernen. Binance musste sie gesondert auf der Blockchain widerrufen.

Entscheidend ist der Unterschied zwischen dem Stoppen einer Aktivität und dem Entziehen der dafür nötigen Befugnis. Ein Gerät auszutauschen, Zugangsdaten für die Bereitstellung zu widerrufen und eine Berechtigung in einem anderen System aufzuheben, betrifft jeweils einen anderen Teil des Angriffs.

Ein Laptop, ein Bereitstellungssystem und ein sensibler Dienst erfüllen unterschiedliche Aufgaben. Das Risiko wächst, wenn der Zugriff auf eines automatisch den Zugang zum nächsten eröffnet. Mit einem gestohlenen Token kann ein Angreifer möglicherweise Software ersetzen. Diese Software kann anschließend mit Berechtigungen handeln, die der Beschäftigte selbst nie direkt hatte.

Vier Fragen helfen dabei, Ansatzpunkte zum Unterbrechen dieser Kette zu finden:

1. Offenlegung von Zugangsdaten. Welchen Produktionszugriff kann ein Angreifer über das Gerät eines Beschäftigten erlangen?
2. Bereitstellungsrechte. Wer kann den Code ändern, der mit diesem Zugriff ausgeführt wird?
3. Autorisierung im Dienst. Welche Aktionen akzeptiert ein sensibler Dienst von diesem Code?
4. Dauerhafter Zugriff. Welche neuen Berechtigungen könnten nach dem Deaktivieren des ursprünglichen Kontos bestehen bleiben?

Ziel ist es, die Weitergabe von Befugnissen zwischen Systemen zu begrenzen und jeden während des Angriffs geschaffenen zusätzlichen Zugriff zu erkennen und zu widerrufen. Die folgenden Abschnitte untersuchen vier Kontrollen, die dieses Ziel unterstützen.

Kontrolle 1. Zugangsdaten reduzieren, die ein Laptop offenlegen kann

Zugangsdaten sind für einen Angreifer nützlich, weil ein anderes System sie als Nachweis einer Befugnis akzeptiert. Weniger Produktionszugangsdaten auf Mitarbeitergeräten bedeuten weniger Möglichkeiten zum Diebstahl, wenn ein Werkzeug, ein Repository oder eine Browsersitzung kompromittiert wird.

Für Routinearbeiten benötigt ein Beschäftigter oft nur die Berechtigung, eine Aktion anzufordern, etwa einen Dienstneustart. Die Zugangsdaten für deren Ausführung können bei einer getrennten Ausführungsidentität bleiben. Das Risiko zu reduzieren bedeutet daher sowohl unnötige Kopien zu entfernen als auch die verbleibenden Zugangsdaten zu verwalten:

• Ersetzen Sie routinemäßigen Direktzugriff nach Möglichkeit durch eng definierte Aktionen.
• Verwenden Sie getrennte Identitäten für unterschiedliche Aufgaben und begrenzen Sie deren Umfang und Gültigkeitsdauer.
• Führen Sie ein Verzeichnis der Zugangsdaten, ihrer Verantwortlichen und ihrer Widerrufsverfahren.

Damit wird der Grundsatz aus den OWASP-Empfehlungen zur Geheimnisverwaltung umgesetzt: den menschlichen Umgang mit Geheimnissen reduzieren und jeder Identität nur die benötigten Zugriffe gewähren. Ein kompromittierter Rechner legt dann weniger wiederverwendbare Zugangsdaten offen, und das Reaktionsteam kennt die Verantwortlichen für die noch zu widerrufenden Daten.

Kontrolle 2. Bereitstellungsrechte als Produktionsrechte behandeln

Ein Geheimnis kann vor einer Person verborgen und dennoch für den von ihr bereitgestellten Code verfügbar sein. Wer diesen Code ändern kann, kann möglicherweise das Geheimnis lesen, eine interne API aufrufen oder als Dienstkonto der Anwendung handeln. Bereitstellungszugriff muss deshalb anhand der Berechtigungen der resultierenden Workload bewertet werden.

Die OWASP-Empfehlungen zur CI/CD-Sicherheit betrachten Repository-Änderungen, Pipeline-Konfiguration und Ausführungshosts als Teile desselben Sicherheitsproblems. Der Schutz muss sowohl den Code vor der Bereitstellung als auch seine Berechtigungen danach erfassen:

• Verlangen Sie Reviews für Produktionscode und schützen Sie den Repository-Branch, den die Automatisierung ausführt.
• Kontrollieren Sie neben dem Hauptskript auch Änderungen an Aufgabendefinitionen, Abhängigkeiten und Eingaben beim Start.
• Gewähren Sie Workloads nur die Zugangsdaten und Netzwerkzugriffe, die sie für ihre Funktion benötigen.

Zwei Gruppen von Kontrollen müssen zusammenwirken. Repository- und Bereitstellungsberechtigungen bestimmen, wer den Code ändern darf. Getrennte Richtlinien für Identitäten, Hosts und Netzwerk begrenzen die Möglichkeiten des Codes während der Ausführung. Zentrale Geheimnisverwaltung reduziert die Offenlegung, während diese Richtlinien das Programm einschränken, das das Geheimnis verwendet.

Kontrolle 3. Die Aktion autorisieren, nicht nur den Aufrufer

Ein Signaturdienst kann seinen privaten Schlüssel verbergen und trotzdem eine schädliche Signaturanfrage akzeptieren. Dasselbe gilt für Datenbanken oder Cloud-APIs: Die Authentifizierung einer Workload identifiziert den Aufrufer, während die Autorisierung festlegt, was er tun darf.

OWASP empfiehlt, die Autorisierung bei jeder Anfrage zu prüfen und den Zugriff ohne ausdrückliche Erlaubnis zu verweigern. Beim empfangenden Dienst bedeutet das, sowohl die Aktion als auch ihr Ziel zu prüfen: erlaubte Zahlungsempfänger und Beträge, Datenbankoperationen oder Infrastrukturänderungen.

Das Ergebnis sollte ein Dienst sein, der die angeforderte Aktion auch dann bewertet, wenn der Aufrufer bereits als vertrauenswürdig gilt. Die Automatisierung regelt, wie Arbeit angefordert wird. Der empfangende Dienst regelt, welche Aktionen er akzeptiert.

Kontrolle 4. Während des Angriffs geschaffene Zugriffe widerrufen

Ein Angreifer kann eine legitime Identität verwenden, um weitere Zugangsdaten hinzuzufügen oder zusätzliche Berechtigungen zu vergeben. MITRE ATT&CK dokumentiert Kontomanipulation als Möglichkeit, Zugriff aufrechtzuerhalten oder zu erweitern, etwa durch zusätzliche Cloud-Zugangsdaten und SSH-Schlüssel. Das Deaktivieren der ursprünglichen Sitzung entfernt diese Änderungen nicht zwangsläufig.

Die Blockchain-Delegation bei Binance zeigt, warum Reaktionsteams die Berechtigungen im betroffenen System selbst untersuchen müssen. Die Eindämmung muss sowohl den ursprünglichen Zugang als auch die darüber geschaffenen Befugnisse abdecken:

• Begrenzen Sie, welche Automatisierungsidentitäten weitere Zugangsdaten erstellen oder Berechtigungen vergeben dürfen.
• Berücksichtigen Sie neu angelegte Konten, Sitzungen und Delegationen im Reaktionsplan.
• Prüfen Sie den Widerruf im System, das die Berechtigung durchsetzt, statt eine gestoppte Aufgabe als Nachweis der Eindämmung zu betrachten.

Diese Schritte liefern dem Reaktionsteam eine definierte Menge von Identitäten und Berechtigungen, die es untersuchen und widerrufen kann. Außerdem wird die Eindämmung überprüfbar: Das Team kann feststellen, ob jeder bekannte Weg zum betroffenen Dienst tatsächlich geschlossen wurde.

Diese Kontrollen wirken auf unterschiedlichen Ebenen: dem Mitarbeitergerät, dem Bereitstellungssystem, dem empfangenden Dienst und dem Reaktionsprozess. Jede Ebene benötigt einen Verantwortlichen und ein Verfahren, mit dem sich prüfen lässt, ob ihre Einschränkungen auch bei einer kompromittierten anderen Ebene Bestand haben.

Plattformen zur Automatisierungsverwaltung adressieren den Teil dieses Problems zwischen der Anfrage eines Beschäftigten und der Ausführung in Produktion. In Semaphore UI kann ein Team eine definierte Aufgabe vorbereiten, festlegen, wer sie ausführen oder ändern darf, und sie mit einer getrennten Identität ausführen. Die Autorisierung im Zieldienst und der Widerruf andernorts geschaffener Berechtigungen bleiben Aufgabe dieser Systeme und des Reaktionsteams.

Betrachten wir einen Bereitschaftsingenieur, der einen API-Dienst neu starten muss. Ein Verantwortlicher bereitet ein Playbook und eine Task Template vor, die Zielhosts und Ablauf des Neustarts festlegen. Der Ingenieur startet die Aufgabe und liest das Ergebnis, ohne eine SSH-Sitzung zur Produktionsumgebung zu öffnen. Die beiden folgenden Wege führen denselben Neustart aus, legen die Ausführungszugangsdaten jedoch in unterschiedliche Hände.

Der Neustartablauf entsteht in vier zusammenhängenden Schritten: eine eingeschränkte Ausführungsidentität erstellen, die Ausführungs- und Änderungsrechte der Nutzer festlegen, die Ausführungsumgebung wählen und das Ergebnis sichtbar machen. Sind diese Schritte umgesetzt, lässt sich derselbe Ansatz auf Bereitstellungen übertragen.

Eine gestohlene Operatorsitzung kann weiterhin die Aktionen anfordern, die das Konto ausführen darf. Selbst ein erlaubter Neustart kann einen Dienst stören, wenn er wiederholt ausgelöst wird. Testen Sie den konfigurierten Ablauf in der Staging-Umgebung mit einem realistischen Operatorkonto. Prüfen Sie sowohl dessen Möglichkeiten als auch die Reaktion des Teams auf Missbrauch:

• Aufgaben- und Eingabeberechtigungen. Probieren Sie die tatsächlichen Rollen und Startoptionen aus, einschließlich alternativer Branches, Inventare und Argumente.
• Zugriff über die vorgesehene Aktion hinaus. Prüfen Sie den Zugriff auf andere Vorlagen, Zugangsdaten und Produktionssysteme, einschließlich der Reichweite des Runner-Prozesses.
• Erkennung und betriebliche Auswirkungen. Bestätigen Sie, wer Ergebnisse erhält, wer unerwartete Aktivitäten untersucht und ob wiederholte Ausführungen untragbare Störungen verursachen können.
• Widerruf. Testen Sie den Widerruf von Sitzungen und Tokens und ermitteln Sie Berechtigungen, die die Ausführungsidentität andernorts erstellen könnte.

Dokumentieren Sie die verbleibenden Zugriffe des Testkontos und schließen Sie jeden Weg, der über den Zweck der Aktion hinausgeht. Nach der Übung sollte das Team wissen, was eine gestohlene Sitzung tun könnte und wie es diesen Missbrauch erkennt und eindämmt.

Zugriffskontrollen wirken zusammen mit Endgeräteschutz und einem Team, das angemessen reagieren kann. Gestalten Sie den vorbereiteten Ablauf so bequem, dass niemand auf gemeinsame Schlüssel und undokumentierte Abkürzungen zurückgreifen muss. Unterstützen Sie ihn durch einige alltägliche Praktiken:

• Führen Sie unbekannte Installationsprogramme und Bewerbungsaufgaben in isolierten Wegwerfumgebungen aus, ohne Unternehmenszugangsdaten, Host-Mounts oder Zugriff auf interne Netzwerke.
• Machen Sie es einfach, verdächtige Aktivitäten früh und ohne Schuldzuweisungen zu melden. Geben Sie einen klaren Kontakt und einen Ablauf zur Vorfallreaktion vor.
• Prüfen Sie Zugriffe bei veränderten Aufgaben, halten Sie ein kontrolliertes Notfallzugriffsverfahren bereit und üben Sie den Widerruf vor einem Vorfall.

Diese Praktiken verbinden Prävention, Erkennung und Wiederherstellung mit dem Arbeitsalltag. Sie helfen, das Zugriffsmodell bei veränderten Zuständigkeiten aktuell zu halten, und geben dem Team bei verdächtigen Ereignissen einen vertrauten Reaktionsweg.

Die zentrale Lehre ist, zu begrenzen, wie viele Befugnisse eine kompromittierte Identität ansammeln kann. Weniger Zugangsdaten auf Laptops, geprüfte Automatisierung, eingeschränkte Ausführungshosts und Autorisierung in Produktionsdiensten reduzieren jeweils die möglichen Wege eines Angreifers.

Semaphore macht mehrere dieser Kontrollen zu einem wiederholbaren Ablauf: vorbereitete Aufgaben, getrennte Ausführungs- und Bearbeitungsrechte, zentral bereitgestellte Zugangsdaten und sichtbare Ausführungsnachweise. Operatoren erhalten die für ihre Arbeit nötigen Aktionen, während die Verantwortlichen die Kontrolle über den zugrunde liegenden Code und die Zugangsdaten behalten.

Beginnen Sie mit einer häufig genutzten Produktionsaktion: Bereiten Sie deren Aufgabenvorlage vor, vergeben Sie die nötigen Operatorberechtigungen und prüfen Sie den resultierenden Zugriff, bevor Sie die ersetzte Direktverbindung abschaffen. Ein sinnvoller Fortschrittsmaßstab ist, wie wenig ein Angreifer mit dem nächsten kompromittierten Konto tun kann.