Über sichere Speicherung hinaus, Teil 1: Sichere Zahlungs- und Signaturabläufe gestalten

Binance beschreibt in seiner vorläufigen Darstellung des Vorfalls vom 30.10.2026, dass ein gestohlenes Deployment-Token Zugang zu einem internen Signierdienst und Transaktionen außerhalb des normalen Auszahlungsprozesses ermöglichte [1]. Auf diesem offengelegten Weg konnte der Angreifer Signaturen anfordern, ohne zuvor den privaten Schlüssel der Wallet auszulesen.

Hier zielt der Angreifer auf die Signierfähigkeit des Systems. Sichere Aufbewahrung, einschließlich Verschlüsselung und Hardware-Isolierung, kann den Schlüssel schützen, aber nicht feststellen, ob eine Zahlung geschäftlich gültig autorisiert wurde. Daraus ergibt sich die Frage: Wie erhält ein nicht autorisierter Vorgang eine gültige Signatur?

Um diese Frage zu beantworten, muss nachvollzogen werden, wie aus einer geschäftlichen Anfrage eine signierte und ausgeführte Transaktion wird. Eine über eine Wallet ausgeführte Zahlung durchläuft die geschäftliche Autorisierung, die Erstellung der Transaktion, die Signierung sowie die Ausführung und Abwicklung [2, 3]. Die Abbildung stellt dem Missbrauch dieses Ablaufs einen weiteren Weg zur Signierfähigkeit gegenüber: die Wiederherstellung des Schlüssels durch Fehler bei der Implementierung der Kryptografie.

Die Reihe Beyond Secure Storage leitet aus realen Vorfällen Grundsätze für Design und Implementierung ab, um diesen Risiken zu begegnen. Teil 1, Designing Secure Payment and Signing Workflows, untersucht, wie Angreifer die Signierfähigkeit des ursprünglichen Systems missbrauchen, ohne dessen private Schlüssel zu erlangen. Teil 2, Implementing Wallet Cryptography Securely, untersucht Implementierungsfehler, durch die Angreifer Schlüssel wiederherstellen und eigenständig signieren können. Keiner der beiden Wege erfordert es, das geschützte Geheimnis direkt zu stehlen.

Abschnitt 1 untersucht anhand realer Vorfälle Risiken und übersehene Annahmen entlang des Zahlungsablaufs und leitet daraus Prüfungen für Design und Implementierung ab, um ihnen zu begegnen. Abschnitt 2 geht davon aus, dass diese Prüfungen einen nicht autorisierten Vorgang nicht verhindert haben, und untersucht, wie sich die daraus entstehenden Verluste begrenzen lassen. Abschnitt 3 erläutert, wie Designprüfungen, Audits, Penetrationstests und Übungen sowohl die Prävention als auch die Verlustbegrenzung überprüfen können.

1. Gestaltung zur Verhinderung nicht autorisierter Vorgänge

Derselbe Zahlungsablauf kann unterschiedlichen geschäftlichen Zwecken dienen. Die Abbildung zeigt drei typische Vorgänge bei der Verwahrung: Einzahlungen begründen Kontoguthabenansprüche, Auszahlungen erfolgen auf Kundenanweisung und Treasury-Transfers setzen institutionelle Finanzierungsentscheidungen um.

Validierte Einzahlungen erzeugen eine Kontogutschrift, aber keine automatische Zahlungsanweisung. Eine Auszahlung erfordert eine separate Kundenanfrage und Genehmigung; ein Treasury-Transfer geht von einer institutionellen Finanzierungsentscheidung aus. Beide durchlaufen anschließend die Erstellung der Transaktion, die Signierung sowie die Ausführung und Abwicklung. Bei der gemeinschaftlichen Verwahrung erfasst das Hauptbuch die Ansprüche der Kunden, ohne dass die Vermögenswerte für jeden Kunden an einer eigenen Adresse verbleiben müssen.

Drei typische Vorgänge bei der Verwahrung. Eine funktionale Trennung schafft für sich genommen weder unabhängige Identitäten noch Berechtigungsgrenzen.

Für diese Vorgänge gibt es unterschiedliche Gründe, Mittel zu bewegen. Andere Geschäftsvorgänge können dieselben Phasen durchlaufen, aber andere Nachweise oder Genehmigungen erfordern. In jeder Phase stellt sich aus Sicherheitssicht die Frage, ob Zahlungsgrundlage, Transaktion, Nutzung der Signierberechtigung und Abwicklung weiterhin dem beabsichtigten Vorgang entsprechen.

Jede dieser Phasen kann zu einem Punkt werden, an dem ein Angreifer beeinflusst, was signiert oder ausgeführt wird. Eine gefälschte Anfrage kann den Anschein einer Zahlungsverpflichtung erwecken; bei der Erstellung der Transaktion kann ein nicht genehmigter Vorgang an die Stelle des genehmigten treten; kompromittierte Berechtigungen können Zugang zum Signieren eröffnen; und Fehler bei der Ausführung oder Abwicklung können dazu führen, dass eine unerwünschte Berechtigung weiter nutzbar bleibt oder eine ungerechtfertigte Zahlung ausgelöst wird.

Die folgende Tabelle ordnet die Risiken den Phasen des Ablaufs und den Fällen zu, anhand derer sie untersucht werden.

Phase des Ablaufs	Sicherheitsfrage	Untersuchter Fall
1,1 · Zahlungsgrundlage und Autorisierung	Liegen der Zahlung eine echte Anfrage, die Berechtigung zur Verfügung über die Mittel und eine gültige Genehmigung zugrunde?	Gefälschte Auszahlungsanfragen bei Bitget [4]; Kompromittierung der Konto- und Risikologik bei BigONE [5, 6]
1,2 · Erstellung und Überprüfung der Transaktion	Bildet die vollständige Transaktionsnutzlast den genehmigten Vorgang ab?	Täuschender Weg von einem Transfer zur Übernahme bei Bybit [7, 8]; veränderte Transaktionsantwort bei Kiln/SwissBorg [9, 10]
1,3 · Signierautorisierung und Schlüsselnutzung	Wer kann signieren oder ändern, wer signieren darf?	Übernahme der Schlüsselrichtlinie bei Resolv [11]; berichteter Zugang zum Signierdienst bei Binance [1]
1,4 · Ausführung und Abwicklung	Wann kann eine signierte Berechtigung zur Ausführung genutzt werden, und was rechtfertigt die nächste Auszahlung?	Verzögerte Ausführung bei Drift und irrtümliche Rückerstattung bei Chainflip [12, 13, 14]

1,1 Zahlungsgrundlage und Autorisierung

Bevor eine Zahlung zur Erstellung der Transaktion und zur Signierung übergeht, muss die Institution feststellen, dass eine echte Anfrage vorliegt, dass die anfragende Partei zur Verfügung über die Mittel berechtigt ist und dass für den angegebenen Vorgang eine gültige Genehmigung vorliegt. Ein Kundenguthaben oder eine authentifizierte interne Anfrage allein belegt nicht alle drei Voraussetzungen.

Fehlerfälle: Fingierte Zahlungsgrundlage

Beim Vorfall von Bitget am 24.09.2026 nutzte der Angreifer ein Sicherheitsprodukt eines Drittanbieters aus, um hochprivilegierte interne Zugangsdaten zu erlangen. Laut der offiziellen Darstellung von Bitget wurden diese Zugangsdaten verwendet, um betrügerische Auszahlungsbefehle an das Wallet-System zu senden. Dies führte zu Transfers, die dessen bestehende Risikokontrollen umgingen [4]. Die Befehle gelangten über internen Zugang in den Zahlungsprozess, doch dieser Zugang belegte weder eine legitime Kundenanweisung noch eine Treasury-Entscheidung.

BigONE legte am 16.07.2025 nicht autorisierte Bewegungen aus Hot Wallets offen und erklärte, dass seine privaten Schlüssel sicher geblieben seien. BigONE Eurasia führte den Vorfall auf der globalen Plattform auf Änderungen an der produktiven Konto- und Risikokontrolllogik zurück [5, 6]. Das weist auf ein verwandtes Problem hin: Die Aufzeichnungen und Regeln, mit denen eine Zahlung begründet wird, können selbst verändert werden. Die öffentliche Darstellung legt weder die detaillierten Anfrageaufzeichnungen noch die Signier-API offen; daher belegt sie nicht denselben Angriffsmechanismus wie im Fall von Bitget.

Diese Fälle zeigen, welches Risiko entsteht, wenn interner Zugang oder Kontodaten als ausreichende Grundlage für eine Zahlung gelten: Ein Angreifer kann die Zugangsdaten, Aufzeichnungen oder Regeln verändern, auf denen diese Entscheidung beruht.

Zu überprüfende Kontrollen

Bei Design- und Implementierungsprüfungen sollte daher kontrolliert werden, ob sich jede Anfrage auf eine echte geschäftliche Grundlage zurückführen lässt und ob die Partei, die sie einreicht, auch die zugehörigen Nachweise fingieren oder die Anfrage genehmigen kann.

Herkunft, Integrität und Autorisierung der Anfrage überprüfen. Jede Zahlung muss auf eine echte Kundenanweisung, ein geschäftliches Ereignis oder eine institutionelle Entscheidung zurückführbar sein, mit Nachweisen für die Berechtigung zur Verfügung über die Mittel und für die Genehmigung. Es ist zu überprüfen, dass Änderungen an der Anfrage und den zugehörigen Nachweisen nachvollziehbar bleiben und dass fingierte oder veränderte Nachweise nicht allein deshalb eine Autorisierung begründen können, weil sie von einem internen Dienst stammen oder mit einem Kontostand übereinstimmen.
Validierung und Genehmigung von der Erstellung der Anfrage unabhängig halten. Die Partei, die eine Anfrage einreicht, darf nicht zugleich deren Nachweise fingieren oder die Anfrage genehmigen können. Diese Trennung muss sowohl bei operativen als auch bei administrativen Berechtigungen bestehen bleiben. Es ist zu überprüfen, ob Änderungen an Aufzeichnungen, Genehmigungsregeln oder Rollenzuweisungen – einschließlich manueller Ausnahmen und Wiederherstellungsverfahren – einer einzigen Partei die Kontrolle sowohl über die Anfrage als auch über die Prüfungen ermöglichen könnten, die sie zurückweisen sollen.

Ist die Zahlungsgrundlage unabhängig festgestellt, stellt sich als Nächstes die Frage, ob die Transaktion den genehmigten Vorgang abbildet.

1.2 Erstellung und Überprüfung der Transaktion

Nach der Genehmigung einer Zahlungsanfrage wandelt die Komponente zur Transaktionserstellung sie in die unsignierten Daten um, die zur Signierung übermittelt werden. Die vollständige Transaktionsnutzlast – einschließlich Zieladresse, Betrag, Vorgang und etwaiger Änderungen an der Kontrolle über die Wallet – muss die genehmigte Anfrage abbilden. Die Genehmigung eines Transfers autorisiert keine zusätzlichen Vorgänge; die Überprüfung muss die tatsächlich zu signierenden Daten untersuchen, nicht nur deren Beschreibung in einer Benutzeroberfläche.

Fehlerfälle: Signierte Vorgänge weichen von der Genehmigung ab

Bybit beabsichtigte, ETH von einer Cold Wallet auf eine Warm Wallet zu übertragen. Laut dem offiziellen Update beruht der Angriff auf kompromittierten Zugangsdaten eines Safe-Entwicklers. Diese ermöglichten den Zugriff auf die Infrastruktur des Anbieters und die Täuschung der Unterzeichner [7]. Safe prüft über execTransaction Signaturen für Transaktionsfelder, darunter to, value, data und operation [15]. Die kompromittierte Benutzeroberfläche ließ die erwartete Übertragung jedoch unverändert erscheinen, während sie vor der Signierung bösartige Feldwerte einsetzte. Die Signaturen waren für diese ausgetauschten Bytes gültig [7].

Die daraus resultierende Transaktion nutzte DELEGATECALL, um die Implementierung der Wallet zu ändern. Dadurch konnte der Angreifer Vermögenswerte abziehen, ohne dass die ursprünglichen Eigentümer erneut zustimmen mussten [7, 8]. Der genehmigte Geschäftsvorgang war eine Übertragung; der signierte Vorgang änderte, wer die Wallet kontrollieren konnte. Eine Prüfung des angezeigten Empfängers oder des unmittelbaren Transaktionswerts hätte nicht belegt, dass der gesamte Vorgang der Genehmigung entsprach.

Der Vorfall bei Kiln/SwissBorg zeigt, dass bösartige Transaktionen auch durch die Veränderung eines laufenden Dienstes zur Transaktionserstellung eingeschleust werden können. Kiln berichtete, dass ein kompromittiertes GitHub-Token über CI-Workflows zum Zugriff auf Zugangsdaten für die Produktionsumgebung führte. Der Angreifer veränderte einen laufenden Kubernetes-Pod, ohne dessen bereitgestelltes Image zu ändern. So gab der Pod neben einer legitimen Transaktion zur Deaktivierung eines Solana-Stakes auch eine Änderung der Auszahlungsberechtigung zurück. Die Unterzeichner des Kunden im Verwahrungssystem genehmigten die hinzugefügte Transaktion; Kiln datiert die Signierung auf den 31. August und die Entdeckung auf den 08.09.2025 [9]. Auch SwissBorg führte die Manipulation der Transaktion auf die Infrastruktur des Anbieters zurück. Die Parteien waren sich uneinig darüber, wie nutzbar die damals verfügbaren Dekodierungswerkzeuge waren und wie gut sie sich integrieren ließen [10].

Zu überprüfende Kontrollen

Bybit und Kiln/SwissBorg zeigen, wie eine Transaktion von dem abweichen kann, was der Unterzeichner zu genehmigen beabsichtigte. Die Genehmigung muss an den vollständigen Vorgang gebunden sein, und die Prüfung muss die tatsächliche Transaktion unabhängig von dem Dienst untersuchen, der sie erstellt oder angezeigt hat.

Die Genehmigung an den vollständigen Vorgang binden. Die Genehmigung muss sämtliche Auswirkungen der Transaktion abdecken, einschließlich jeder Änderung der Kontrolle über Vermögenswerte oder der Übertragung von Ausführungsbefugnissen [16]. Änderungen außerhalb dieses Umfangs erfordern eine erneute Genehmigung. Prüfen Sie, dass ausgetauschte oder hinzugefügte Vorgänge nicht die Genehmigung für eine legitime Zahlung übernehmen können und dass bei erneuten Versuchen eine Genehmigung nicht wiederverwendet werden kann, um zusätzliche Zahlungen zu autorisieren.
Die Transaktion und ihre Auswirkungen unabhängig prüfen. Vergleichen Sie die tatsächlich zur Signierung übermittelten Daten mit dem genehmigten Geschäftsvorgang. Berücksichtigen Sie dabei jede Transaktion in einem Batch sowie ihre Auswirkungen auf Vermögenswerte und Berechtigungen. Die Prüfung muss unabhängig von dem Dienst sein, der die Transaktion erstellt oder anzeigt. Prüfen Sie, ob dieser Dienst die Prüfinstanz verändern oder deren Prüfungen umgehen kann und ob irreführende Anzeigen oder veränderte Transaktionen zurückgewiesen werden.

Die vorstehenden Prüfungen klären, ob die Transaktion dem genehmigten Auftrag entspricht. Bei der Signierung stellt sich eine weitere Frage: Kann jemand den Schlüssel ohne die erforderliche geschäftliche Autorisierung nutzen – direkt oder durch eine Änderung der Zugriffsberechtigungen?

1,3 Autorisierung der Signierung und Schlüsselnutzung

Eine geprüfte Transaktion muss den Signierdienst über einen autorisierten Aufrufer erreichen. Schlüsselrichtlinien und Administratorrollen bestimmen, wer den betreffenden Schlüssel nutzen und wer diesen Zugriff ändern darf. Die Berechtigung, eine Signierung aufzurufen, autorisiert nicht jede Transaktion. Ebenso darf die Berechtigung zur Verwaltung des Dienstes keinen ungeprüften Weg zur Signierung eröffnen. Diese Phase umfasst daher sowohl die Schlüsselnutzung für den genehmigten Vorgang als auch die Befugnis, den Schlüsselzugriff zu verwalten.

Fehlerfälle: Kompromittierter Zugriff auf die Signierung

Der Vorfall bei Resolv vom 22.03.2026 zeigt, wie eine Änderung der Richtlinie für den Schlüsselzugriff einen Weg zur Signierung eröffnen kann. Für die Ausgabe von Token sah der Minting-Prozess vor, dass ein Nutzer Sicherheiten hinterlegt und ein autorisierter Off-Chain-Dienst die Ausgabe abschließt. Der offizielle Vorfallbericht zeichnet nach, wie der Zugriff auf ein Repository und eine Cloud-Umgebung zu einer höher privilegierten Rolle führte. Nachdem frühere Zugriffsversuche abgewiesen worden waren, änderte der Angreifer mit dieser Rolle die Zugriffsrichtlinie des Signierschlüssels. Dadurch erhielt er in einem Cloud-Schlüsselverwaltungsdienst die Berechtigung zur Signierung, für die sowohl Berechtigungen auf Identitätsebene als auch eine Zugriffsrichtlinie auf Schlüsselebene erforderlich waren [11].

Indem der Angreifer änderte, wer signieren konnte, konnte er die Ausgabe von Token außerhalb des vorgesehenen Zusammenhangs mit den hinterlegten Sicherheiten autorisieren, ohne den ursprünglichen Unterzeichner überzeugen zu müssen. Der Bericht belegt die Kontrolle über die Signierbefugnis, nicht die Extraktion des Rohmaterials des privaten Schlüssels.

Das vorläufige Update von Binance zu seinem Vorfall vom 30.10.2026 beschreibt einen anderen Weg zur Signierbefugnis. Laut Binance ermöglichten kompromittierte Geräte von Mitarbeitern und ein internes KI-Tool den Zugriff auf die Geräte von Wallet-Ingenieuren; anschließend wurde ein gestohlenes Token für Container-Bereitstellungen verwendet, um einen Container bereitzustellen und bösartige Skripte auszuführen. Der Angreifer erlangte unbefugten Zugriff auf den internen Wallet-Signierdienst und löste Transaktionen außerhalb des normalen Auszahlungsprozesses aus [1]. Dieser Bericht stellt eine Verbindung zwischen der Berechtigung zur Bereitstellung und dem Zugriff auf den Signierdienst her, legt aber nicht offen, welche internen Berechtigungsprüfungen genau umgangen wurden. Anders als bei der von Resolv gemeldeten Änderung der Schlüsselrichtlinie erfolgte der offengelegte Einstieg hier über die Betriebsumgebung des Signierdienstes.

Zu überprüfende Kontrollen

Diese Fälle verdeutlichen das Risiko, außerhalb des vorgesehenen Geschäftsablaufs Zugriff auf die Signierung zu erlangen oder zu nutzen. Bei Überprüfungen sollte festgestellt werden, ob jeder Weg zur Signierung eine geschäftliche Autorisierung durchsetzt – auch Wege, die durch Richtlinienänderungen oder Berechtigungen zur Bereitstellung eröffnet werden.

Geschäftliche Autorisierung für jeden Weg zur Signierung durchsetzen. Die Berechtigung zur Nutzung eines Schlüssels begründet keine Autorisierung für einen bestimmten Vorgang [17, 18, 19]. Beschränken Sie die Schlüsselnutzung auf den genehmigten geschäftlichen Umfang und prüfen Sie, dass andere Aufrufer oder ein direkter Zugriff diese Beschränkung nicht umgehen können. Die Durchsetzung der Autorisierung muss unabhängig von einem Aufrufer bleiben, der beliebige Signieranfragen einreichen kann. Wo ein Zugriffsweg diese Anforderung nicht durchsetzen kann, dokumentieren Sie die Lücke und bewerten Sie ihre Folgen gemäß Abschnitt 2.
Änderungen der Signierbefugnis kontrollieren. Administrator- und Bereitstellungsberechtigungen können Zugriff auf die Signierung schaffen, selbst wenn die ursprüngliche Identität nicht signieren kann [20, 21, 22]. Trennen Sie die Schlüsselnutzung von der Befugnis, Signierrichtlinien, Identitäten oder bereitgestellten Code zu ändern, und verlangen Sie eine unabhängige Genehmigung solcher Änderungen. Prüfen Sie, dass keine Partei ihre kombinierten Berechtigungen nutzen kann, um sich selbst Zugriff auf die Signierung zu verschaffen oder die für diesen Zugriff geltenden geschäftlichen Prüfungen zu entfernen.

Autorisierungsprüfungen dürfen nicht mit der Ausstellung einer Signatur enden: Die Transaktion muss weiterhin unter den genehmigten Bedingungen ausgeführt und ihr Ergebnis korrekt abgewickelt werden.

1,4 Ausführung und Abwicklung

Die Autorisierung muss auch nach der Signierung Bestand haben – bei der Übermittlung an das Netzwerk, der Ausführung und der Abwicklung der zugehörigen Geschäftsvorgänge und reservierten Guthaben. Eine Signatur ist kein Nachweis für eine abgeschlossene Zahlung. Die Ausführung muss innerhalb des Umfangs und der Gültigkeitsbedingungen der Autorisierung bleiben; bei der Abwicklung muss festgestellt werden, welche Verpflichtung erfüllt wurde und ob tatsächlich eine weitere Zahlung fällig ist. Weder eine vorhandene Signatur noch eine beobachtete Übertragung allein kann eine neue Zahlungsverpflichtung begründen.

Fehlerfälle: Missbrauch signierter Befugnisse und Rückkopplung bei der Abwicklung

Drift veranschaulicht, wie eine irreführende Signieranfrage eine Befugnis hinterlassen kann, die sich später nutzen lässt. Bei dem Vorfall vom 01.04.2026 wurden vorab eingeholte Genehmigungen in Solana-Transaktionen mit Durable Nonces festgehalten und später eingereicht, um die Administratorbefugnis zu übernehmen [12]. Eine Durable Nonce steuert die Gültigkeit einer Transaktion; sie unterscheidet sich von der geheimen Nonce, die bei der kryptografischen Signierung verwendet wird. Sie ermöglicht die Offline-Einreichung oder eine verzögerte Einreichung ohne den üblichen Ablauf der Gültigkeit eines aktuellen Blockhashs, obwohl Änderungen am Zustand von Konten oder Programmen die Ausführung weiterhin verhindern können. Wird die Durable Nonce fortgeschrieben, werden Transaktionen ungültig, die an den alten Wert gebunden sind [23].

Im Recovery-Update vom 16. April schlug Drift dedizierte Signiergeräte, eine Prüfung außerhalb der primären Signieroberfläche, zeitliche Sperrfristen für kritische Administratoraktionen und die Deaktivierung von Durable Nonces für Unterzeichner vor [24]. Diese Maßnahmen betreffen sowohl das, was Unterzeichner genehmigen, als auch den Zeitpunkt, zu dem der signierte Vorgang ausgeführt werden kann. Sie wurden als Wiederherstellungsplan angekündigt; aus dem Update geht nicht hervor, dass sie bereits umgesetzt waren.

Chainflip unterscheidet zwischen Swaps von Kunden, Auszahlungen an Liquiditätsanbieter (LPs) und internen Vorgängen zur Einziehung von Einzahlungen, sogenannten Fetches [25]. Auf Tron können Transaktions-Memos Swap-Anweisungen enthalten. Laut dem Bericht von Chainflip vom 15. September über den Vorfall vom 12.09.2026 reichte ein Angreifer einen von Validatoren signierten Fetch mit einem fehlerhaften Memo ein, das er kontrollierte. Die Witnessing-Schicht deutete den Vorgang fälschlich als fehlgeschlagenen Swap und veranlasste zusätzlich zu den regulären LP-Auszahlungen Rückerstattungen. Dadurch wurden sechs Auszahlungen doppelt ausgeführt [13, 14].

Durch den Fehler wurde eine interne Vermögensbewegung als Beleg für eine neue Verpflichtung gegenüber einem Kunden gewertet. Chainflip hatte Memos auch dann interpretiert, wenn Transfers in seinen Vault in andere Contract-Aufrufe eingebettet waren. Die Korrektur beschränkte die Interpretation von Swap-Memos auf einfache TRX-Transfers oder direkte TRC-20-Transfers und schloss eingebettete Aufrufe aus [14]. Ein gültig signierter Fetch hatte einen eigenen Zweck; seine Ausführung rechtfertigte keine zusätzliche Rückerstattung.

Zu prüfende Kontrollen

Signierte Transaktionen können länger als erwartet ausführbar bleiben, und Rückmeldungen zur Ausführung können fälschlich als neue Zahlungsverpflichtung verstanden werden. Bei Prüfungen sollte daher kontrolliert werden, ob die Ausführungsbedingungen tatsächlich durchgesetzt werden und ob jede Auszahlung oder Rückerstattung einer echten, noch offenen Verpflichtung entspricht.

Die genehmigten Ausführungsbedingungen durchsetzen. Signierte Transaktionen müssen weiterhin dem genehmigten Umfang, der Gültigkeitsdauer und den Stornierungsbedingungen unterliegen. Prüfen Sie, ob alte Transaktionen nach Ablauf, Stornierung oder einer Änderung der Autorisierung noch ausgeführt werden können. Verknüpfen Sie die maßgeblichen Bedingungen mit dem signierten Vorgang und prüfen Sie, ob die Blockchain-Regeln oder die Ausführungslogik der Wallet sie durchsetzen; ein Eintrag im Geschäftssystem allein reicht nicht aus.
Nur echte, noch offene Verpflichtungen begleichen. Jede Auszahlung oder Rückerstattung muss einer tatsächlichen Verpflichtung entsprechen, die noch nicht beglichen wurde. Erhalten Sie die Verbindung zwischen dem ursprünglichen Geschäftsvorgang, den Zahlungsversuchen und den bestätigten Ergebnissen. Prüfen Sie, dass Wiederholungsversuche, doppelte Benachrichtigungen, ungewisse Ergebnisse oder interne Transfers keine ungerechtfertigte Zahlung auslösen können und dass die Regeln zur Interpretation von Ausführungsnachweisen nicht so geändert werden können, dass diese Prüfungen umgangen werden.

2. Gestaltung zur Begrenzung von Verlusten und zur Ermöglichung der Reaktion auf Vorfälle

Abschnitt 1 nutzte Erkenntnisse aus Vorfällen, um Risiken in den Abläufen sowie die zu ihrer Behebung erforderlichen Prüfungen von Design und Implementierung zu ermitteln. Hier gehen wir davon aus, dass diese Prüfungen einen unautorisierten Vorgang nicht verhindert haben – sei es aufgrund einer Auslassung, eines Implementierungsfehlers oder einer Umgehung. Das Design muss dann begrenzen, wie viel der Angreifer bewegen kann, weiterhin gefährdete Mittel berücksichtigen und die Möglichkeit erhalten, Missbrauch zu erkennen und weitere Mittelabflüsse zu stoppen. Diese Maßnahmen zur Verlustbegrenzung müssen vor einem Vorfall zusammen mit den präventiven Kontrollen konzipiert und getestet werden.

Die Tabelle fasst drei Designziele zur Begrenzung von Verlusten und zur Ermöglichung der Reaktion auf Vorfälle zusammen.

Designziel	Sicherheitsfrage	Prüfungsschwerpunkt
2,1 · Unabhängig durchgesetzte Ausgabenlimits	Kann das System kumulierte Mittelabflüsse begrenzen, wenn unautorisierte Zahlungen erfolgen?	Unabhängige Durchsetzung; konsistente kumulative Erfassung; Schutz vor Änderung oder Umgehung der Limits
2,2 · Bestände, Nachfüllungen und noch ausstehende signierte Transaktionen	Wie viel könnte verloren gehen, bevor der Angriff eingedämmt wird?	Zugängliche Guthaben und spätere Mittelzuflüsse; Beschränkungen für Nachfüllungen; Mittel, die durch noch ausstehende signierte Berechtigungen gefährdet sind
2,3 · Unabhängige Überwachung und Reaktion auf Vorfälle	Kann das System unautorisierte Vorgänge erkennen und weitere Mittelabflüsse stoppen?	Vertrauenswürdige Nachweise; handlungsrelevante Warnmeldungen; wirksame und unabhängig verfügbare Reaktionskontrollen

2,1 Unabhängig durchgesetzte Ausgabenlimits

Selbst wenn eine unautorisierte Zahlung die vorherigen Prüfungen passiert, sollte das System begrenzen, wie viel mit ihr und nachfolgenden Zahlungen bewegt werden kann. Dafür ist ein Budget erforderlich, das außerhalb des angenommenen Kontrollbereichs des Angreifers durchgesetzt wird und sowohl einzelne Transaktionen als auch kumulierte Ausgaben abdeckt. Ein konfiguriertes Limit setzt keine solche Grenze, wenn der kompromittierte Genehmigungsdienst oder die Signaturkomponente es deaktivieren oder umgehen kann.

Limits unabhängig von der Zahlungsgenehmigung durchsetzen. Auch eine Zahlung, die die Autorisierungsprüfungen besteht, muss Ausgabenlimits unterliegen, die außerhalb des angenommenen Kontrollbereichs des Angreifers durchgesetzt werden. Prüfen Sie, ob alle Wege zur Signierung und Ausführung diese Limits einhalten, einschließlich alternativer Ausführungswege [26, 27], und ob der Angreifer ihre Durchsetzung weder ändern noch deaktivieren kann. Wo kein unabhängiges Limit durchgesetzt werden kann, darf ein konfiguriertes Budget nicht als Grenze für Verluste dargestellt werden.
Kumulierte Ausgaben begrenzen, nicht nur einzelne Zahlungen. Legen Sie den Geltungsbereich, den Zeitraum und die Bewertungsgrundlage jedes Budgets fest und erfassen Sie abgeschlossene Zahlungen und reservierte Beträge konsistent. Prüfen Sie, dass wiederholte Anfragen, parallele Vorgänge und Wiederholungsversuche das Budget nicht in der Summe überschreiten oder Reservierungen vorzeitig freigeben können. Wenn Limits von Vermögenspreisen abhängen, prüfen Sie, dass manipulierte, veraltete oder nicht verfügbare Preise die zulässigen Ausgaben nicht erhöhen können.

2,2 Bestände, Nachfüllungen und noch ausstehende signierte Transaktionen

Die nächste Frage ist, welche Mittel gefährdet bleiben, während die Institution den Angriff erkennt und eindämmt. Wallet-Guthaben, Nachfüllungen und noch ausstehende signierte Berechtigungen bestimmen dieses Risiko, einschließlich der Mittel, die nach Beginn des Vorfalls eingehen. Bewerten Sie diese Faktoren gemeinsam mit den durchsetzbaren Limits aus Abschnitt 2,1; ein aktueller Kontostand allein ist keine Schätzung des möglichen Verlusts.

Die Mittel begrenzen, auf die ein Angreifer zugreifen könnte. Bewerten Sie die gesamte Reichweite der betroffenen Signaturberechtigung über Vermögenswerte hinweg, einschließlich anderer Wallets, Blockchains und Contracts. Berücksichtigen Sie vorhandene Guthaben und spätere Mittelzuflüsse. Nachfüllungen müssen eine unabhängige Autorisierung und ein kumuliertes Limit haben. Prüfen Sie, dass wiederholte Mittelabflüsse keine fortlaufenden Nachfüllungen aus dem Treasury auslösen können und dass neue Mittelzuführungen umgeleitet oder gestoppt werden können, ohne weiterhin eingehende Einzahlungen zu übersehen.
Mittel berücksichtigen, die durch noch ausstehende signierte Berechtigungen gefährdet sind. Das Stoppen neuer Signierungen macht bereits ausgegebene Transaktionen oder Autorisierungen nicht zwangsläufig ungültig. Ermitteln Sie die Mittel, die damit noch bewegt werden können, ohne dieselben Vermögenswerte doppelt zu zählen. Prüfen Sie, dass bestätigte Zahlungen als ausgegeben erfasst und ihre Reservierungen abgeglichen werden, während Reservierungen für nicht ausgeführte Transaktionen bestehen bleiben, bis verlässliche Nachweise belegen, dass sie nicht mehr ausgeführt werden können. Ein lokaler Timeout oder eine Stornierungsanfrage allein darf die erfasste Risikoexposition nicht verringern.

2,3 Unabhängige Überwachung und Reaktion auf Vorfälle

Limits und Kontrollen für die Mittelzuführung begrenzen potenzielle Verluste; Überwachung und Reaktion bestimmen, wie lange ein Angreifer weiter agieren kann. Die Institution benötigt Nachweise, die Missbrauch auch dann sichtbar machen, wenn der Zahlungsdienst die Vorgänge als gültig behandelt, sowie einen Reaktionsweg, der nutzbar bleibt, wenn die normale Betriebsumgebung nicht verfügbar oder kompromittiert ist.

Die vorläufige Darstellung von Binance zeigt, warum das Abschalten einer Anwendung allein dafür möglicherweise nicht ausreicht: Dadurch wurde eine bestehende EIP-7702-Delegation nicht aufgehoben. Der Widerruf erforderte On-Chain-Transaktionen und in der dortigen MPC-Implementierung ein gesondert konzipiertes Verfahren [1]. Dies war eine Einschränkung dieser Implementierung, keine grundsätzliche Unfähigkeit von MPC, Berechtigungen zu widerrufen. Erkennung und Eindämmung müssen daher getrennt geprüft werden: Verlässliche Nachweise müssen zu einer Maßnahme führen, die den Verlustpfad tatsächlich unterbricht.

Unautorisierte Aktivitäten anhand unabhängig geschützter Nachweise erkennen. Vergleichen Sie geschäftliche Genehmigungen mit Signaturaktivitäten und Ausführungsergebnissen und überwachen Sie Änderungen an Berechtigungen und Kontrollregeln. Der betroffene Dienst darf die Nachweise, auf die sich die Überwachung stützt, nicht umschreiben können. Prüfen Sie, dass vom Ablauf akzeptierte Vorgänge auch dann handlungsrelevante Warnmeldungen auslösen können, wenn sie nicht mit der geschäftlichen Autorisierung übereinstimmen – selbst wenn lokale Aufzeichnungen fehlen oder manipuliert wurden.
Reaktionskontrollen verfügbar und wirksam halten. Sorgen Sie für eine unabhängige Berechtigung, neue Signierungen und Mittelzuführungen zu stoppen sowie, soweit unterstützt, noch ausstehende Transaktionen ungültig zu machen oder fortbestehende Berechtigungen zu widerrufen. Prüfen Sie, dass eine Reaktion auch dann möglich bleibt, wenn der gewöhnliche Betriebszugang nicht verfügbar oder kompromittiert ist, und dass die Maßnahmen weitere Mittelabflüsse tatsächlich blockieren. Ermitteln Sie die verbleibende Risikoexposition und den Bedarf an externer Abstimmung; das Stoppen einer Anwendung widerruft signierte Berechtigungen nicht von selbst, und eine Rückgewinnung von Vermögenswerten kann nicht vorausgesetzt werden.

3. Validierung von Design und Implementierung

Die vorangegangenen Abschnitte fragen, ob Prüfungen im Arbeitsablauf unautorisierte Vorgänge verhindern und ob sich Verluste begrenzen lassen, wenn dies nicht gelingt. Bei der Validierung müssen beide Ziele im eingesetzten System untersucht werden, einschließlich des Zusammenwirkens der Kontrollen entlang des Mittelflusses. Die folgenden Methoden liefern ergänzende Erkenntnisse:

Bewertung der Architektur und des Sicherheitsdesigns prüft, ob Mittelfluss, Zuständigkeitsgrenzen und Abhängigkeiten zwischen den Kontrollen die angestrebten Ziele der Prävention und Verlustbegrenzung unterstützen. Dabei sollten die Annahmen offengelegt werden, auf denen die Unabhängigkeit der Kontrollen und die Verlustgrenzen beruhen.
Audit von Code und Konfiguration überprüft, ob der eingesetzte Code, die Konfiguration und die Berechtigungen die vorgesehenen Prüfungen umsetzen. Dazu gehören auch Ausnahmen und alternative Pfade, über die sich die Prüfungen umgehen ließen.
Penetrationstests untersuchen, ob sich Schwachstellen in Anwendungen und Infrastruktur kombinieren lassen, um Autorisierungs- oder Verlustbegrenzungskontrollen zu umgehen. Ihr Umfang sollte vollständigen Wegen folgen, die Mittel nehmen können, statt bei einzelnen Komponenten zu enden.
Angriffs- und Reaktionsübungen überprüfen, ob die Überwachung zu rechtzeitigem Handeln führt und ob Ausgabenlimits, Pausierungen und der Entzug von Berechtigungen zusammenwirken. Sie sollten feststellen, welche Mittel weiterhin gefährdet sind und wie lange eine wirksame Eindämmung dauert.

Für jedes Validierungsszenario sind der Vorgang, der zurückgewiesen werden sollte, oder der Verlust, der begrenzt werden sollte, sowie die angenommenen Fähigkeiten des Angreifers anzugeben. Halten Sie das beobachtete Ergebnis, eine etwaige verbleibende Risikoexposition und die Bedingungen fest, auf denen eine angegebene Verlustgrenze beruht. Wiederholen Sie relevante Prüfungen nach wesentlichen Änderungen an Code, Konfiguration oder Berechtigungen.

Externe Sicherheitsteams oder Fachleute können interne Teams bei diesen Bewertungen, Audits, Tests und Übungen ergänzen. Ihre Prüfung sollte abdecken, wie Zahlungslogik, Signaturinfrastruktur und betriebliche Berechtigungen zusammenwirken, und Belege für die Fähigkeiten des Systems zur Prävention und Verlustbegrenzung liefern.

4. Fazit

Die hier untersuchten Angriffe zeigen Autorisierungsfehler von der ursprünglichen Zahlungsanforderung über die Erstellung, Signierung und Ausführung der Transaktion bis hin zur Abwicklung. Sie zeigen auch, was ein System benötigt, um Verluste zu begrenzen, sobald ein Angreifer diese Kontrollen überwunden hat. Die daraus abgeleiteten Designprinzipien umfassen Prävention, Eindämmung und die Tests, die erforderlich sind, um beides in der Praxis zu bewerten.

Die zentrale Schlussfolgerung lautet: Der Schutz privater Schlüssel allein gewährleistet nicht, dass signierte Vorgänge autorisiert sind. Der tatsächlich ausgeführte Vorgang muss einer echten Geschäftsentscheidung entsprechen. Zudem müssen unabhängige Kontrollen die Folgen begrenzen, wenn Prüfungen im Arbeitsablauf einen unautorisierten Vorgang nicht verhindern. Dazu muss der gesamte Arbeitsablauf überprüft werden, einschließlich der Berechtigungen, mit denen sich seine Prüfungen ändern lassen, und der Werkzeuge, die benötigt werden, um weitere Verluste zu erkennen und zu stoppen.

Diese Analyse konzentrierte sich auf den Missbrauch der Signaturfähigkeit des ursprünglichen Systems. Teil 2, Wallet-Kryptografie sicher implementieren, befasst sich mit einem anderen Weg: Implementierungsfehlern, durch die Angreifer private Schlüssel vorhersagen oder rekonstruieren können, ohne die geschützten Geheimnisse direkt zu stehlen, und anschließend außerhalb des ursprünglichen Arbeitsablaufs signieren können.