Welche Risiken bestehen, wenn Sie Ihr Wallet mit einer neuen, nicht verifizierten dApp verbinden?

Risiken einer Wallet-Verbindung mit nicht verifizierten dApps

1. Wenn ein Benutzer sein Wallet mit einer nicht verifizierten dezentralen Anwendung verbindet, erteilt er oft weitreichende Berechtigungen, ohne den Umfang vollständig zu verstehen. Viele dApps verlangen eine unbegrenzte Token-Genehmigung , was es dem Vertrag ermöglicht, Vermögenswerte wiederholt ohne weitere Zustimmung abzuheben.

2. Schädliche Verträge können eine Logik einbetten, die bei der Verbindung automatische Übertragungen auslöst, insbesondere wenn das Wallet Token mit Transfer-Hooks oder Wiedereintrittsschwachstellen enthält. Dies hat zu zahlreichen Vorfällen geführt, bei denen Benutzer innerhalb von Sekunden nach der Genehmigung einer Transaktion ihr gesamtes Guthaben verloren haben.

3. Gefälschte Schnittstellen ahmen legitime Protokolle nach und verleiten Benutzer dazu, Phishing-Payloads zu signieren, die als Standard-Verbindungsanfragen getarnt sind. Diese Payloads können böswillige Signaturanfragen enthalten, die unter dem Deckmantel „Wallet Connect“ oder „Login“ willkürliche Vertragsaufrufe autorisieren.

4. Einige dApps werden auf obskuren EVM-kompatiblen Ketten mit minimaler Knoteninfrastruktur bereitgestellt, was die Wahrscheinlichkeit von Front-Running-, Sandwich-Angriffen oder sogar Kettenreorganisationen erhöht, die erwartete Zustandsübergänge ungültig machen – wodurch Benutzer einem stillen Geldverlust ausgesetzt werden.

5. Wallet-Erweiterungen wie MetaMask überprüfen nicht die Integrität des Vertragsbytecodes, bevor sie Signaturanfragen stellen. Eine einzelne kompromittierte Abhängigkeit im Frontend einer dApp – etwa eine gekaperte CDN-gehostete Bibliothek – kann bösartige Signaturlogik direkt in den Browserkontext des Benutzers einschleusen.

Muster zur Nutzung von Token-Genehmigungen

1. Ältere ERC-20-Genehmigungen bleiben bei Protokoll-Upgrades und Kettenmigrationen aktiv. Angreifer nutzen dies aus, indem sie alte Genehmigungen für neu bereitgestellte bösartige Verträge mit identischen Funktionsselektoren wiederverwenden.

2. Genehmigungen für Proxy-Verträge sind besonders gefährlich, da die zugrunde liegende Implementierung ohne Benutzerbenachrichtigung aktualisiert werden kann. Ein Angreifer, der den Admin-Schlüssel kontrolliert, kann jederzeit die Logik austauschen, um genehmigte Token zu entziehen.

3. Einige dApps verwenden erlaubnisbasierte Genehmigungen außerhalb der Kette, sodass Benutzer EIP-712-Nachrichten signieren müssen. Wenn das Domänentrennzeichen falsch konfiguriert ist oder die Nachrichtenstruktur nicht eindeutig ist, können Signaturen über Netzwerke hinweg wiedergegeben oder für nicht autorisierte Übertragungen umgewidmet werden.

4. Wallets zeigen bei Genehmigungsaufforderungen selten vollständige ABI-codierte Anrufdaten an. Benutzer können nicht überprüfen, ob die Genehmigung auf eine echte Token-Adresse oder einen Lookalike abzielt, der von einem Angreifer mit ähnlichen Prüfsummenschreibweise- oder Unicode-Homograph-Tricks eingesetzt wurde.

Schwachstellen in der Frontend-Lieferkette

1. Es wurde beobachtet, dass Analyseskripte von Drittanbietern, die über npm-Abhängigkeiten eingeschleust wurden, private Schlüssel aus In-Memory-Wallet-Objekten herausfilterten, wenn Entwickler versehentlich vertrauliche Referenzen im globalen Bereich offenlegten.

2. Kompromittierte UI-Frameworks, die von dApp-Buildern verwendet werden, enthalten manchmal versteckte Ereignis-Listener, die Tastenanschläge während mnemonischer Eingabefelder erfassen – selbst wenn diese Felder über CSS deaktiviert oder ausgeblendet sind.

3. Browser-Erweiterungskonflikte führen zu Race-Conditions, bei denen Wallet-Anbieter Signaturanfragen nicht korrekt abfangen, was dazu führt, dass unformatierte Transaktionsübertragungen mit falschen Parametern oder Nonces signiert werden.

4. Nicht-minimierte JavaScript-Bundles enthalten oft fest codierte API-Schlüssel, Wallet-Adressen oder Testnet-Anmeldeinformationen, die Angreifer abkratzen und umfunktionieren, um vertrauenswürdige Backend-Dienste zu simulieren und gleichzeitig den Datenverkehr über bösartige Relayer weiterzuleiten.

Täuschungstaktiken auf Netzwerkebene

1. Rogue-RPC-Endpunkte stellen einen gefälschten Blockchain-Status bereit und zeigen gefälschte Token-Salden oder gefälschte Transaktionsbestätigungen an, um falsches Vertrauen zu erwecken, bevor irreversible Aktionen eingeleitet werden.

2. DNS-Poisoning-Angriffe leiten Benutzer, die versuchen, offizielle dApp-Domänen zu besuchen, auf gespiegelte Websites um, die identische Benutzeroberflächen hosten, aber auf von Angreifern kontrollierte Smart Contracts verweisen.

3. Man-in-the-Middle-Proxys fangen WebSocket-Verbindungen zwischen Wallets und dApps ab und ändern die Antwortnutzdaten, um ausstehende Genehmigungen zu verbergen oder Warnbanner zu unterdrücken, die durch bekannte betrügerische Vertragsadressen ausgelöst werden.

4. Testnet-Faucets, die mit dApp-Onboarding-Flows gebündelt sind, setzen manchmal neben legitimen auch bösartige Verträge ein und ermutigen Benutzer, mit beiden zu interagieren – wodurch Vertrauen aufgebaut wird, bevor ausbeuterische Logik im Mainnet eingeführt wird.

Häufig gestellte Fragen

F: Kann eine dApp Geld stehlen, indem sie einfach mein Wallet verbindet, ohne eine Transaktion zu unterzeichnen? A: Ja. Die Verbindung allein bewegt keine Gelder, aber viele dApps fordern sofort Token-Genehmigungen an oder rufen Delegatecall-Muster auf, die beliebigen Code unter Verwendung des Wallet-Kontexts des Benutzers ausführen.

F: Beseitigt die Verwendung einer Hardware-Wallet diese Risiken? A: Nein. Hardware-Wallets schützen private Schlüssel, signieren aber dennoch vom Frontend angeforderte Transaktionen. Wenn die dApp irreführende Informationen anzeigt oder irreführende Anrufdaten erstellt, signiert das Hardwaregerät diese wie angewiesen.

F: Ist die Verbindung zu Open-Source-dApps automatisch sicher? A: Nicht unbedingt. Öffentlicher Quellcode garantiert keine Bereitstellungsintegrität. Angreifer setzen häufig modifizierte Versionen geprüfter Verträge mit subtilen Änderungen ein – wie z. B. geänderte Eigentümeradressen oder hintertürige Fallback-Funktionen –, die statische Analysetools umgehen.

F: Warum zeigen einige Wallet-Erweiterungen Warnungen an, andere jedoch nicht? A: Das Warnverhalten hängt von den Echtzeit-Reputationsdatenbanken für Vertragsadressen ab, die vom Erweiterungsanbieter verwaltet werden. Diese Datenbanken hinken neuen Implementierungen hinterher und decken häufig weniger bekannte Ketten oder frisch abgeschlossene Verträge nicht ab.