Wie Sie eine Transaktion lesen, bevor Sie sie signieren

Zwei der größten Verluste in unserem Vorfall-Tracker teilen sich einen Mechanismus, und es ist nicht der, den man erwartet. Niemand hat einen Schlüssel erraten. Den signierenden Personen wurde eine Transaktion angezeigt, und sie bestätigten eine andere.

In diesem Leitfaden geht es um die Lücke zwischen dem, was eine Website über die Wirkung einer Transaktion sagt, und dem, was die Transaktion tatsächlich tut — und darum, welcher Bildschirm diesen Widerspruch auflöst.

Warum die Lücke existiert

Wenn Sie mit einer Webanwendung interagieren, die eine Transaktion signiert haben möchte, geschehen mehrere Dinge gleichzeitig. Die Seite konstruiert eine Transaktion. Ihre Wallet empfängt sie. Ihre Wallet — oder ein angeschlossenes Hardware-Gerät — zeigt eine Darstellung davon an. Sie bestätigen.

Die Beschreibung, die Sie auf der Seite lesen, wird von der Seite selbst verfasst. Sie ist Werbetext für die Transaktion. Sie ist nicht aus der Transaktion abgeleitet, und nichts zwingt beide zur Übereinstimmung.

Beim Vorfall bei Bybit war genau das der gemeldete Fehler: eine Routineüberweisung, bei der die ausgeführte Nutzlast von dem abwich, was die Signaturoberfläche anzeigte. Nach der eigenen Mitteilung des FBI wurden rund 1,5 Mrd. US-Dollar bewegt. Mehrere signierende Personen bestätigten. Ihnen allen wurde dieselbe Falschdarstellung angezeigt, sodass ihre Mehrzahl nichts brachte.

Die Hierarchie der Bildschirme

Nicht alle Anzeigen verdienen gleiches Vertrauen. In absteigender Reihenfolge:

1. Der eigene Bildschirm einer Hardware-Wallet. Er wird vom Gerät aus der Transaktion erzeugt, die es tatsächlich signieren soll. Er ist das Glied der Kette, das eine kompromittierte Webseite am schwersten beeinflussen kann — und genau deshalb hat das Gerät überhaupt einen Bildschirm.
2. Der Bestätigungsdialog Ihrer Wallet-Software. Besser als die Seite, aber er läuft auf demselben Rechner und, im Fall einer Browser-Erweiterung, in einer Umgebung, die er sich mit der Seite teilt.
3. Die Beschreibung auf der Webseite. Nützlich, um die Absicht zu verstehen. Wertlos als Überprüfung.

Die Kompromittierung des Ledger Connect Kit zeigt das genau. Schadcode wurde in eine Bibliothek eingeschleust, die von vielen Dapps geladen wird, und stellte den Nutzern eine leerräumende Transaktion vor. Nutzer, die vor der Bestätigung den Gerätebildschirm lasen, konnten eine Überweisung erkennen, um die sie nicht gebeten hatten. Nutzer, die von der Seitenbeschreibung aus bestätigten, konnten das nicht.

Worauf Sie tatsächlich achten sollten

Auf dem Gerätebildschirm, bei einer Überweisung:

• Die Zieladresse — die vollständige, nicht die ersten und letzten vier Zeichen. Address-Poisoning-Angriffe funktionieren gerade dadurch, dass sie Adressen erzeugen, deren Enden mit einer zuvor von Ihnen genutzten übereinstimmen.
• Betrag und Vermögenswert. Prüfen Sie beides, einschließlich der Position des Dezimaltrennzeichens.
• Das Netzwerk. Die richtige Transaktion auf der falschen Chain ist trotzdem ein Verlust.

Bei einer Contract-Interaktion:

• Die aufgerufene Funktion, sofern das Gerät sie dekodieren kann. Ein unerwartetes approve, setApprovalForAll oder permit, während Sie glaubten, zu staken oder etwas abzuholen, ist das Signal zum Abbruch.
• Die Spender- oder Operator-Adresse in einer Freigabe, denn das ist die Adresse, die Sie autorisieren — nicht der Contract, den Sie zu nutzen glauben.
• Warnungen zum Blind Signing. Wenn das Gerät meldet, dass es nicht dekodieren kann, was es signieren soll, ist das eine Information und kein Hindernis.

Bestätigung über einen zweiten Kanal

Bestätigen Sie bei allem, was von Bedeutung ist, das Ziel über einen anderen Kanal als denjenigen, der die Transaktion vorschlägt. Wenn eine Seite eine Adresse liefert und dieselbe Seite bestätigt, dass die Adresse korrekt ist, haben Sie nichts überprüft. Das ist die organisatorische Fassung derselben Kontrolle: Verfahren für große Überweisungen verlangen deshalb eine Bestätigung über einen getrennten Weg, weil ein einzelner kompromittierter Kanal in sich stimmig sein kann.

Wovor Sie das nicht schützt

• Eine Freigabe, die Sie bereits erteilt haben. Transaktionen ab heute sorgfältig zu lesen ändert nichts an einer laufenden Erlaubnis aus dem vergangenen Jahr. Siehe Ihre Freigaben prüfen.
• Eine kompromittierte Recovery-Phrase. Keine noch so große Sorgfalt beim Signieren hilft, wenn jemand anderes das Konto rekonstruieren kann.
• Ein Protokoll, das selbst fehlerhaft ist. Eine vollkommen legitime Transaktion in einen verwundbaren Contract ist dieser Schwachstelle dennoch ausgesetzt. An den meisten Vorfällen in unserem Tracker sind Nutzer beteiligt, die genau das signiert haben, was sie beabsichtigten.
• Ermüdung. Das ist die eigentliche Grenze. Niemand liest die hundertste Routinefreigabe mit der Sorgfalt, die er der ersten entgegenbrachte, und Angriffe sind genau darauf ausgelegt.

Die ehrliche Zusammenfassung

Zu lesen, was man signiert, ist die eine Kontrolle, die mehrere der von uns erfassten Verluste verhindert hätte, und sie ist zugleich wirklich schwer durchzuhalten. Handhaben Sie sie mit Augenmaß: kleine Routineinteraktionen brauchen kein Zeremoniell, und jede Transaktion, deren Verlust für Sie ins Gewicht fiele, verdient den Gerätebildschirm, die vollständige Adresse und eine Pause.