COVER · RISIKO

Protocol Hack

Nicht der Code ist schuld, sondern wer die Schlüssel hat

Was kann passieren

Fast jedes Protokoll hat Stellen mit besonderen Rechten. Jemand muss Parameter setzen, Verträge ersetzen oder im Notfall anhalten können.

Diese Rechte hängen an Schlüsseln. Und Schlüssel hängen an Menschen, Rechnern und Verfahren - also an allem, was sich nicht in Code prüfen lässt.

Der Schlüssel wird erlangtDurch Täuschung eines Mitarbeiters, durch Schadsoftware auf dessen Gerät, durch einen kompromittierten Dienstleister.
Die Oberfläche wird verändertNicht der Vertrag wird angegriffen, sondern die Seite, über die Menschen ihn bedienen. Sie zeigt einen gewöhnlichen Vorgang und veranlasst einen anderen.
Ein Dienstleister wird angegriffenProtokolle nutzen fremde Bausteine. Wer einen davon kontrolliert, wirkt auf alle, die ihn einbinden.

Wie daraus ein finanzieller Schaden entsteht

Wer die Verwaltungsrechte hat, muss keinen Fehler suchen. Er darf ohnehin.

Mit solchen Rechten lassen sich je nach Protokoll Mittel abziehen, Parameter so verstellen, dass Positionen verwertbar werden, oder Verträge gegen andere austauschen. Für die Blockchain ist das kein Angriff, sondern eine erlaubte Handlung - ausgeführt von einer Adresse, die dazu berechtigt ist.

Der Schaden trifft die Einleger, ohne dass sie etwas falsch gemacht hätten und ohne dass der Code fehlerhaft wäre.

Ein dokumentierter Fall

DOKUMENTIERTER FALLBybit und Safe{Wallet}, Februar 2025
Am 21. Februar 2025 flossen von der Handelsplattform Bybit Kryptowerte im Gegenwert von etwa 1,5 Milliarden US-Dollar ab. Nach den Untersuchungsberichten begann der Vorgang nicht bei Bybit, sondern bei einem Dienstleister: Angreifer übernahmen den Rechner eines Entwicklers der Mehrfachunterschrift-Anwendung Safe{Wallet}, erbeuteten dort Sitzungsnachweise und brachten darüber veränderten Code in die Weboberfläche ein, über die Verantwortliche Überweisungen freigeben. Als diese kurz darauf eine geplante Umbuchung bestätigten, zeigte die Oberfläche einen gewöhnlichen Vorgang an, während unterschrieben wurde, was die Angreifer vorbereitet hatten.

Der Fall zeigt die Eigenart dieser Gruppe von Vorfällen: Die Unterschriften waren gültig, die Unterzeichner berechtigt, der Vertrag fehlerfrei. Verändert worden war das, was die Unterzeichner zu sehen bekamen.

Kann das Gegenstand eines Covers sein?

Grundsätzlich ja, aber die Abgrenzung ist heikler als beim Smart-Contract-Risiko.

Denn hier stellt sich die Frage, wo der Angriff stattgefunden hat. Im Protokoll? Beim Betreiber? Bei einem Dienstleister? Bei der Person, die freigegeben hat? Wordings schneiden entlang dieser Linie, und die Fälle liegen oft genau darauf.

DER NÜTZLICHSTE TEIL

Was das Wording beantworten muss

Sind Verwaltungsrechte erfasst?Oder deckt das Wording nur Fehler im Code? Ein Missbrauch berechtigter Rechte ist kein Codefehler.
Zählt der Angriff auf den Betreiber?Viele Produkte decken das Protokoll, nicht das Unternehmen dahinter.
Zählt ein Dienstleister?Wenn der Schaden über einen eingebundenen Fremdbaustein entsteht - ist das noch dasselbe Ereignis?
Was, wenn die Freigabe rechtmäßig war?Wurde getäuscht statt gebrochen, ist häufig ein Ausschluss einschlägig. Diese Zeile zuerst suchen.
Wer trägt die Beweislast?Bei einem Codefehler steht der Vorgang onchain. Bei einem erlangten Schlüssel liegt vieles außerhalb.
Ab wann gilt es als eingetreten?Mit dem Abfluss, mit der Feststellung durch den Betreiber, oder mit einem Bericht?
VORAUSGESETZT

Begriffe, die hier vorkommen

  • Hack und Exploit

    Die Unterscheidung, an der die meisten Wordings schneiden.

  • Signatur

    Warum eine gültige Unterschrift nicht heißt, dass das Richtige unterschrieben wurde.

  • Protokoll

    Wer in einem Protokoll überhaupt besondere Rechte hat.