Zum Inhalt springen
Financial Context Wiki

Address Poisoning (Adressvergiftung)

Beim Address Poisoning wird eine ähnlich aussehende Empfängeradresse in den Transaktionsverlauf oder eine andere vertrauenswürdig wirkende Oberfläche eingeschleust, damit eine spätere Zahlung an den Angreifer kopiert wird; angegriffen wird die Empfängerprüfung, nicht die echte Adresse oder ihr Schlüssel.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Address Poisoning ist Betrug durch Empfängeraustausch. Ein Angreifer erzeugt eine andere Adresse, deren sichtbarer Präfix und Suffix einem vertrauenswürdigen Empfänger ähneln, und bringt sie in den Transaktionsverlauf oder eine andere vertrauenswürdig wirkende Oberfläche ein. Er hofft, dass ein Absender diese ähnlich aussehende Adresse später kopiert und eine gültige Zahlung an sie signiert. Der Angriff ändert weder die legitime Adresse noch bricht er deren privaten Schlüssel oder veranlasst den Konsens, die Übertragung fehlzuleiten.

Der eingeschleuste Eintrag kann aus einer echten Transaktion mit dem nativen Asset, einer standardkonformen Token-Übertragung mit Wert null oder einem von einem anderen Token-Vertrag emittierten Log stammen. Aktivitätsseiten von Wallets und Explorern sind abgeleitete Ansichten: Eine als „gesendet“ bezeichnete Zeile kann aus Event-Feldern stammen und nicht aus einer äußeren Transaktion, die von der angezeigten from-Adresse signiert wurde. Absender und Ziel der äußeren Transaktion, aufgerufener Vertrag, Event-emittierender Vertrag, indizierte Felder und tatsächliche Saldoänderungen sind getrennt zu prüfen.

Eine ERC-55-Prüfsumme hilft, einige versehentliche Tippfehler zu erkennen; eine andere Angreiferadresse kann jedoch selbst syntaktisch gültig sein und eine korrekte Prüfsumme besitzen. Gewöhnliche 20-Byte-EVM-Adressen bezeichnen auch nicht die beabsichtigte Chain, das Asset, die Empfängerrolle, ein Deposit-Memo oder den Vertragsaufruf. Eine sichere Zahlungsanweisung bindet all diese Tatsachen an das vollständige Ziel.

Address Poisoning (Adressvergiftung)
0 / 5
0 Artikel überprüft; 5 noch ungelöste Punkte

Der Abschluss dieser Überprüfung beweist nicht, dass ein Vermögenswert, eine Transaktion oder ein System sicher ist.

Funktionsweise

Der Angreifer beobachtet ein öffentliches Zahlungsmuster und sucht nach einer Vanity-Adresse, die mit den Zeichen übereinstimmt, welche die Wallet verkürzt anzeigt. Die Übereinstimmung ausgewählter Hex-Zeichen klont kein Konto: Die unsichtbaren Bytes bleiben verschieden, und der Angreifer kontrolliert den neuen Schlüssel. Eine winzige Übertragung kann diese echte Adresse in den Verlauf bringen. Unabhängig davon verlangt ERC-20, dass Übertragungen mit Wert null wie normale Übertragungen behandelt werden und Transfer emittieren. Ein Nullwert-Eintrag beweist daher allein weder Fälschung noch Kompromittierung, Autorisierung oder wirtschaftlichen Verlust.

Ein bösartiger Token-Vertrag kann außerdem sein eigenes Transfer(victim, lookalike, 0)-Log emittieren. Dieses Log ist ein echter, dem emittierenden Vertrag zuzurechnender Belegdatenpunkt; es ist jedoch kein Event des kanonischen Asset-Vertrags und beweist nicht, dass das Opfer die äußere Transaktion signiert hat. Ein Indexer, der Aktivität anhand von Event-Topics ohne ausreichenden Vertrags- und Aufrufkontext klassifiziert, kann trotzdem eine irreführende Ausgangszeile anzeigen.

Die entscheidende Kontrolle ist die endgültige Zahlungsabsicht. Sie muss Chain und Netzwerk, natives Asset oder exakten Token-Vertrag, vollständige Empfängeradresse, Empfängertyp, Betrag und Raw Units sowie etwaige Calldata, Memo, Destination Tag oder Gültigkeitsdauer binden. Deposit-Adressen von Börsen, Bridges, Proxies und Einmalrouten können veralten oder mehr als eine Adresse erfordern. Clipboard-Malware und manipulierte QR-Codes sind andere Angriffe, doch dieselbe vollständige Zielprüfung erkennt die Ersetzung vor dem Signieren.

Namen und Testzahlungen sind unterstützende Kontrollen, keine Identitätsnachweise. Einen ENS-Namen zum Signierzeitpunkt für die beabsichtigte Chain und den jeweiligen Datensatz auflösen; wird ein Reverse-Name angezeigt, muss er vorwärts zur selben Adresse zurückaufgelöst werden. Ein kleiner Test hilft nur, wenn der Empfänger ihn unabhängig bestätigt und die Hauptzahlung dasselbe fixierte Ziel wiederverwendet. Erneutes Kopieren aus dem Verlauf verwirft diesen Schutz.

Gehen Sie wie folgt vor:

  1. Chain, Netzwerk, Asset und exakten Token-Vertrag, Empfängertyp, Adressformat, Betrag sowie Memo, Tag, Calldata, Version oder Ablauf anhand einer authentifizierten unabhängigen Quelle festlegen.
  2. Name oder QR-Code einmal auflösen, Format und Prüfsumme validieren und die vollständigen Zielbytes an die beabsichtigte Chain binden; Reverse-Namen vorwärts bestätigen, statt ein Label als Identität zu behandeln.
  3. Ziel mit einer kontrollierten Allowlist, einem Adressbuch oder einer signierten Rechnung vergleichen, nie mit dem Transaktionsverlauf; für neue oder wesentlich geänderte Empfänger eine unabhängige oder doppelte Genehmigung verlangen.
  4. Exakte unsignierte Transaktion dekodieren: natives to von einem Token- oder Bridge-Vertrag unterscheiden und in der Calldata Empfänger, Token, Raw-Betrag, Genehmigung, Deadline und Zielsemantik prüfen.
  5. Gegebenenfalls einen kleinen Test an das fixierte Ziel senden und eine unabhängige Empfängerbestätigung einholen; für die Hauptzahlung keine Adresse erneut aus dem Verlauf kopieren.
  6. Hauptübertragung nur aus dem verifizierten Datensatz signieren, vollständiges Ziel und Betrag auf einer vertrauenswürdigen Anzeige vergleichen und danach Beleg, emittierenden Vertrag, Logs und Saldoänderungen auf der richtigen Chain prüfen.
  7. Bei Verdacht auf Poisoning oder Fehlüberweisung weitere Zahlungen stoppen, Hashes und Belege sichern und gegebenenfalls Empfängerdienst, Emittent oder Strafverfolgung sofort kontaktieren; Einfrieren, Rückgabe und Wiederherstellung als bedingt, niemals als sicher behandeln.

Beispiele

  • Verkürzung verbirgt den Unterschied. Die legitime Adresse 0x12ab1111111111111111111111111111111189ef und die Angreiferadresse 0x12ab9999999999999999999999999999999989ef werden beide als 0x12ab...89ef dargestellt. Sie teilen 4 + 4 = 8 angezeigte Hex-Zeichen, unterscheiden sich aber in allen 32 mittleren Zeichen. Nur die dargestellten Enden zu vergleichen ergibt eine falsche Übereinstimmung; der Vergleich aller Bytes nicht.
  • Aufwand der Vanity-Suche. Die Übereinstimmung von k = 8 ausgewählten Hex-Zeichen erfordert erwartungsgemäß 16^8 = 4,294,967,296 Kandidaten. Bei angenommenen 50,000,000 candidates/s beträgt die erwartete Zeit 4,294,967,296 / 50,000,000 = 85.89934592 s. Dies veranschaulicht einen Suchraum, nicht eine zugesicherte Laufzeit oder Warnschwelle einer Wallet.
  • Log gegenüber Zustand. Ein Token-Vertrag emittiert Transfer(victim, lookalike, 0). Der Saldo des Opfers verändert sich von 250,000.000000 auf 250,000.000000, die Differenz beträgt also 0.000000; ein Aktivitätsindex kann dennoch eine Übertragungszeile anzeigen. Emittierenden Vertrag und Aufrufautorisierung prüfen: Die Zeile allein beweist weder Wertbewegung noch eine Signatur des Opfers.
  • Ein Test muss das Ziel fixieren. Eine Treasury plant 50,000 USDC, sendet 1 USDC an eine verifizierte Adresse, erhält eine unabhängige Bestätigung und sendet 49,999 USDC aus demselben fixierten Datensatz: 1 + 49,999 = 50,000 USDC. Kopiert das Personal für den zweiten Teil erneut eine ähnlich aussehende Adresse aus dem Verlauf, schützt der Test die Zahlung von 49,999 USDC nicht mehr.

Risiken

  • Ein Absender kopiert eine Lookalike-Adresse aus einem vergifteten Transaktionsverlauf.
  • Eine verkürzte Oberfläche verbirgt die abweichenden mittleren Zeichen.
  • Ein Vanity-Präfix oder -Suffix wird mit Empfängeridentität verwechselt.
  • Eine ERC-20-Übertragung mit Wert null erzeugt eine irreführende Verlaufszeile.
  • Ein gefälschter Token oder sein Log wird für kanonische Asset-Aktivität gehalten.
  • Ein Indexer klassifiziert Event-Felder falsch oder korrigiert sie zu spät.
  • Name, Symbol oder Icon eines Spam-Tokens imitiert ein vertrauenswürdiges Asset.
  • Clipboard-Malware ersetzt vor dem Signieren eine verifizierte Adresse.
  • Ein lokales oder synchronisiertes Adressbuch ist vergiftet oder veraltet.
  • Eine Allowlist bindet die falsche Chain, das falsche Asset, die falsche Rolle oder Adressversion.
  • Eine Warnung wegen ungültiger oder fehlender Prüfsumme wird ignoriert.
  • Eine gültige Prüfsumme wird als Nachweis der Empfängeridentität missverstanden.
  • ENS-Auflösung ändert sich, nutzt den falschen Coin Type oder ist veraltet.
  • Ein Reverse-Name wird ohne Forward-Bestätigung angezeigt.
  • Nach einer Testzahlung wird erneut aus einer nicht vertrauenswürdigen Quelle kopiert.
  • Deposit-Adresse, Netzwerk, Memo oder Tag einer Börse ist falsch oder abgelaufen.
  • Ziel und erforderliche Calldata einer Bridge, eines Proxys oder Vertrags werden missverstanden.
  • Ein Signierer prüft selbst auf einem Hardwaregerät nur verkürzten Text.
  • Eine Übertragung an den falschen Empfänger wird vor einem Eingriff kanonisch.
  • Das Opfer vertraut auf ein Ermessen des Emittenten beim Einfrieren oder auf einen Recovery Scam.

Häufige Irrtümer

  • Address Poisoning bedeutet, dass Wallet, Schlüssel oder Blockchain gehackt wurden. Der übliche Angriff nutzt die Empfängerauswahl aus, während gültige Kryptografie und Konsens die falsch signierte Absicht ausführen.
  • Eine Nullwert-Zeile muss eine gefälschte On-Chain-Transaktion sein. Standardkonforme Übertragungen und echte Logs können den Wert null haben; Quelle und Zustandswirkung sind zu prüfen.
  • Übereinstimmende Enden plus Prüfsumme beweisen den Empfänger. Eine andere gültige Adresse kann bei sichtbaren Zeichen übereinstimmen und ihre eigene gültige Prüfsumme haben.
  • Ein erfolgreicher Test schützt automatisch die nächste Übertragung. Der Schutz entfällt, wenn die Hauptzahlung nicht dasselbe fixierte und bestätigte Ziel verwendet.
  • Wallet, Validator oder Token-Emittent können eine Zahlung immer rückgängig machen. Befugnisse und Kooperation zur Wiederherstellung hängen von Asset, Dienst, Rechtsraum, Beweisen und Zeitpunkt ab.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...