DotSwap-V1-Exploit entzieht rund 8,5 BTC – Verluste auf 685.000 US-Dollar geschätzt

Am 25. Oktober wurde die veraltete Version der Trading-Plattform DotSwap, DotSwap V1, bei einem Angriff kompromittiert. Dabei wurden rund 8,5 BTC im damaligen Wert von etwa 685.000 US-Dollar gestohlen.

Der Vorfall verdeutlicht eine wachsende Sicherheitsherausforderung bei Bitcoin-basierten Anwendungen: Selbst wenn Nutzer mit dezentralen Assets interagieren, können zentrale Schwachstellen durch Backend-Autorisierung, verwahrte Liquiditätsinfrastrukturen und automatisierte Signaturdienste entstehen.

Laut einem Vorfall-Update von On Nexus wurde die betroffene Plattform offline genommen. Das Team untersucht den Angriff, verfolgt die gestohlenen Gelder und arbeitet mit Börsen sowie Partnern aus dem Bereich Blockchain-Analyse zusammen.

Was ist bei DotSwap V1 passiert?

DotSwap V1 nutzte ein serverseitiges Signaturmodell zur Verwaltung von Liquiditätspools. Die Liquiditätsinfrastruktur wurde über eine verwahrte Multisignatur-Struktur betrieben. Das bedeutete, dass eingezahlte BTC nicht direkt von den einzelnen Liquiditätsanbietern kontrolliert wurden, sondern vom Signaturprozess der Plattform.

Der Angreifer nutzte Berichten zufolge einen veralteten Signaturmechanismus aus, der im Backend von V1 weiterhin aktiv war. Über einen Zeitraum von rund vier Stunden interagierten automatisierte Skripte mit den verfügbaren Schnittstellen der Plattform und verschoben schrittweise Gelder aus den V1-Liquiditätspools und Nutzerkonten.

Der Angriff beschränkte sich nicht auf einen einzelnen Token oder Endpunkt. Die Skripte testeten Berichten zufolge die Schnittstellen der Plattform und zielten auf Assets im Zusammenhang mit 99 Runes-Token ab. Dadurch konnte der Angreifer Schwachstellen in der gesamten Anwendungsumgebung identifizieren und ausnutzen.

Der Gesamtschaden wurde auf ungefähr folgende Werte geschätzt:

• 8,5 BTC gestohlen
• Etwa 685.000 US-Dollar an betroffenen Geldern
• Einlagen von Liquiditätsanbietern bei DotSwap V1 betroffen
• Nutzerkontrollierte Wallets außerhalb der Plattform nicht betroffen

DotSwap V1 wurde inzwischen abgeschaltet. On Nexus erklärte, man arbeite an der Wiederherstellung der damit verbundenen Dienste und werde eine umfassendere Analyse des Vorfalls sowie einen Plan für die betroffenen Nutzer veröffentlichen.

Warum Liquiditätsanbieter die Hauptopfer waren

Die wichtigste Unterscheidung bei diesem Vorfall betrifft den Unterschied zwischen von der Plattform verwalteten Geldern und Assets, die sich in der eigenen Wallet eines Nutzers befinden.

Liquiditätsanbieter, die BTC in DotSwap V1 eingezahlt hatten, waren der Verwahrungs- und Signaturarchitektur der Plattform ausgesetzt. Obwohl das System Multisignatur-Kontrollen nutzte, war der Signaturprozess weiterhin mit Backend-Diensten verbunden, die über Anwendungsschnittstellen abgefragt und ausgelöst werden konnten.

Das zeigt, dass ein Multisignatur-Schutz allein operative Risiken nicht beseitigt. Wenn Autorisierungslogik, API-Berechtigungen, Signaturrichtlinien oder serverseitige Kontrollen fehlerhaft konzipiert sind, kann ein Angreifer möglicherweise trotzdem gültige Transaktionen erzeugen.

Nutzer, die ihre Assets in selbstverwahrten Wallets hielten und sie nicht in V1-Pools eingezahlt hatten, waren von dem Vorfall hingegen nicht betroffen. Ihre privaten Schlüssel blieben außerhalb der kompromittierten Plattformumgebung.

Diese Unterscheidung ist entscheidend, um die Risiken von Liquiditätspools zu verstehen:

Ein Protokoll kann zwar die Abwicklung über die Blockchain durchführen und dennoch bei Verwahrung, Signierung, Preisermittlung, Routing oder Zugriffskontrolle auf zentrale Infrastruktur angewiesen sein.

Nutzer sollten daher nicht nur prüfen, ob eine Anwendung „on-chain“ arbeitet. Ebenso wichtig ist, wo die Signaturhoheit liegt, wer die Auszahlungsberechtigungen kontrolliert und ob eingezahlte Gelder von einem Backend-System eingefroren oder umgeleitet werden können.

Ein mögliches Beispiel für KI-gestützte Angriffautomatisierung

On Nexus ordnete den Vorfall einem aktuellen Trend zu, bei dem KI-gestützte oder hochgradig automatisierte Angriffe eine zunehmende Rolle spielen.

Der Einsatz von Automatisierung kann Geschwindigkeit und Umfang eines Exploits erheblich steigern. Statt eine Funktion nach der anderen manuell zu testen, kann ein Angreifer programmgesteuert:

1. Offen zugängliche API-Endpunkte entdecken
2. Eine große Zahl von Anfragen senden
3. Antworten über verschiedene Assets hinweg vergleichen
4. Uneinheitliches Autorisierungsverhalten erkennen
5. Ungewöhnliche Signatur- oder Auszahlungspfade identifizieren
6. Transaktionen in schneller Folge ausführen

In einer Umgebung, die Dutzende Tokenverträge und Handelsrouten unterstützt, erleichtert Automatisierung die Erkennung kleiner Implementierungsunterschiede, die bei routinemäßigen manuellen Tests möglicherweise unbemerkt bleiben.

Die übergeordnete Erkenntnis lautet, dass Sicherheitsteams sich inzwischen gegen Angriffe wappnen müssen, die herkömmliche Skripte mit immer leistungsfähigeren KI-Agenten kombinieren. API-Erkennung, Schwachstellenklassifizierung, Erstellung von Transaktionen und Überwachung können durch automatisierte Werkzeuge beschleunigt werden.

Dadurch werden Ratenbegrenzung, die Isolierung von Endpunkten, Anomalieerkennung, die Durchsetzung von Signaturrichtlinien und die Echtzeitüberwachung von Transaktionen für Plattformen digitaler Assets immer wichtiger.

Was der Vorfall über die Runes-Infrastruktur zeigt

Das Runes-Ökosystem hat die Bandbreite fungibler Assets erweitert, die auf Bitcoin ausgegeben und gehandelt werden können. Die Infrastruktur für diese Assets befindet sich jedoch noch im Aufbau. Viele Anwendungen sind auf eine Kombination aus Indexern, Off-Chain-Diensten, verwahrten Pools und spezialisierter Handelslogik angewiesen.

Daraus ergeben sich mehrere Risikobereiche:

• Abhängigkeit von Indexern: Wallet-Guthaben und Token-Zustände können auf Drittanbieter-Indexern beruhen.
• Backend-Autorisierung: Eine Plattform kann zentrale APIs verwenden, um zu bestimmen, ob eine Transaktion signiert werden darf.
• Verwahrte Liquidität: Nutzer können BTC in Pool-Wallets einzahlen, die von der Anwendung verwaltet werden.
• Komplexität von Verträgen und Assets: Die Unterstützung vieler Runes-Assets erhöht die Zahl der Routen, Schnittstellen und Sonderfälle, die getestet werden müssen.
• Operative Konzentration: Ein einziger kompromittierter Signaturdienst kann mehrere Pools gleichzeitig betreffen.

Wer den Handel mit Runes oder die Bereitstellung von Liquidität in Betracht zieht, sollte vor einer Einzahlung das Verwahrungsmodell des jeweiligen Projekts prüfen. Die Benutzeroberfläche einer Plattform kann dezentral wirken, während wichtige Kontrollfunktionen weiterhin zentralisiert sind.

Hintergrundinformationen zum Bitcoin-Asset-Ökosystem bieten die Bitcoin-Entwicklerdokumentation und der Bitcoin-Optech-Newsletter, die regelmäßig über Entwicklungen bei Bitcoin-Protokollen, Wallets und Infrastruktur berichten.

Praktische Sicherheitshinweise für Krypto-Nutzer

1. Prüfen, ob die Gelder unter eigener Kontrolle bleiben

Vor der Bereitstellung von Liquidität oder der Einzahlung von Assets sollte geklärt werden, ob die Plattform Gelder bewegen kann, ohne dass eine Transaktion direkt von der eigenen Wallet signiert wird.

Unter anderem sollten folgende Fragen gestellt werden:

• Werden Einzahlungen an eine vom Nutzer oder von der Plattform kontrollierte Adresse gesendet?
• Wer besitzt die privaten Schlüssel?
• Erfolgt die Signierung lokal, über ein Hardware-Gerät oder auf einem Server?
• Können Administratoren Auszahlungen pausieren oder Signaturregeln ändern?
• Sind Auszahlungslimits und Überwachungsmechanismen öffentlich dokumentiert?

Die Antworten können das Risikoprofil des Dienstes maßgeblich verändern.

2. Veraltete Produkte als potenzielle Angriffsflächen betrachten

Der Vorfall bei DotSwap V1 zeigt, warum alte Versionen einer Plattform nicht mit aktiven Diensten verbunden bleiben sollten. Selbst wenn eine neue Version über bessere Kontrollen verfügt, können veraltete APIs, Signaturpfade und Kontoberechtigungen weiterhin ausnutzbar sein.

Projekte sollten eingestellte Produkte vollständig außer Betrieb nehmen, indem sie:

• API-Zugangsdaten widerrufen
• Alte Signaturberechtigungen entfernen
• Nicht verwendete Endpunkte deaktivieren
• Dienstschlüssel austauschen
• Veraltete Datenbanken von Produktionssystemen trennen
• Die frühere Infrastruktur auf unerwartete Aktivitäten überwachen

3. Assets nicht in einer einzigen Anwendung konzentrieren

Liquiditätsanbieter sollten eine Diversifizierung über verschiedene Wallets, Protokolle und Verwahrungsmodelle hinweg in Betracht ziehen. Die Konzentration großer BTC-Beträge in einer einzigen Anwendung kann die Auswirkungen eines einzelnen Exploits oder eines operativen Ausfalls verstärken.

Dadurch lässt sich das Protokollrisiko zwar nicht beseitigen, aber die Wahrscheinlichkeit verringern, dass ein einzelner Vorfall das gesamte Portfolio betrifft.

4. Wallet-Aktivitäten und Berechtigungen überwachen

Nutzer sollten regelmäßig Wallet-Guthaben, verbundene Anwendungen, aktive Kontositzungen und die Transaktionshistorie überprüfen. Unerwartete Signaturanfragen, unbekannte Auszahlungsadressen oder neue Geräteanmeldungen sollten als mögliche Warnsignale betrachtet werden.

Bei Transaktionen mit hohem Wert sollten Nutzer unabhängig überprüfen:

• Die Zieladresse
• Asset und Betrag
• Das Netzwerk
• Die Transaktionsgebühr
• Die Domain der Anwendung
• Die endgültigen, von der Wallet angezeigten Transaktionsdetails

5. Verstehen, dass Multisignatur nicht mit vollständiger Dezentralisierung gleichzusetzen ist

Multisignatur-Strukturen können die Widerstandsfähigkeit eines Systems erhöhen. Ihre Wirksamkeit hängt jedoch davon ab, wie die Signaturberechtigten verteilt sind und wie die Autorisierung durchgesetzt wird.

Wenn alle Signaturberechtigten von derselben Organisation kontrolliert werden, mit demselben Backend verbunden sind oder derselben fehlerhaften Policy-Engine unterliegen, kann das System weiterhin über einen wesentlichen zentralen Ausfallpunkt verfügen.

Die Sicherheit hängt von der gesamten Signaturarchitektur ab – nicht allein davon, dass mehrere Signaturen erforderlich sind.

Worauf betroffene Nutzer achten sollten

Nutzer, die mit DotSwap V1 verbunden waren, sollten sich vor Phishing-Nachrichten in Acht nehmen, die Rückerstattungen, Entschädigungen oder Notfall-Tools für Auszahlungen versprechen. Angreifer nutzen öffentliche Vorfälle häufig aus, indem sie sich als Projektteams ausgeben und Opfer auf gefälschte Websites leiten.

Betroffene Nutzer sollten:

• Nur verifizierten Kommunikationskanälen des Projekts folgen
• Niemals Seed-Phrasen oder private Schlüssel auf Websites eingeben
• Unaufgeforderte Rückerstattungsformulare als verdächtig betrachten
• Transaktions-IDs und Einzahlungsnachweise sichern
• Die Blockchain unabhängig überprüfen
• Die betreffenden Wallet-Adressen auf Bewegungen überwachen
• Vor jeder Signatur auf einen offiziellen Wiederherstellungs- oder Anspruchsprozess warten

Ein seriöses Support-Team wird niemals die Wiederherstellungsphrase einer Wallet verlangen, um den Besitz zu verifizieren oder eine Rückerstattung zu bearbeiten.

Allgemeine Hinweise zum Schutz digitaler Assets bietet die Cybersicherheitsberatung der CISA, unter anderem zu Phishing, Kontosicherheit und schädlichen Aktivitäten.

Die weitreichenden Folgen für DeFi- und Bitcoin-Anwendungen

Der Exploit bei DotSwap V1 ist nicht nur die Geschichte einer einzelnen verwundbaren Plattform. Er zeigt einen grundlegenden Spannungsbereich der Kryptoindustrie: Anwendungen können ihren Nutzern eine dezentrale Oberfläche bieten, während sie im Hintergrund auf zentrale Komponenten angewiesen sind.

Mit der Reifung Bitcoin-basierter Finanzanwendungen müssen Sicherheitsprüfungen mehr abdecken als nur den Code von Smart Contracts. Audits sollten auch folgende Bereiche untersuchen:

• API-Authentifizierung und -Autorisierung
• Serverseitige Signaturdienste
• Schlüsselverwaltung und Isolierung der Signaturberechtigten
• Datenbankberechtigungen
• Systeme zur Asset-Indizierung
• Upgrade- und Abschaltverfahren
• Überwachung und Reaktion auf Sicherheitsvorfälle
• Notfallmechanismen für Auszahlungen

Im Jahr 2025 wird dieser Prüfprozess durch den zunehmenden Einsatz automatisierter Agenten und KI-gestützter Entwicklung noch wichtiger. Schnellere Softwareentwicklung und automatisierte Interaktionen können die Angriffsfläche vergrößern, wenn sich die Sicherheitskontrollen nicht im gleichen Tempo weiterentwickeln.

Für Nutzer bleibt ein klares Verständnis der Verwahrung der verlässlichste Schutz. Assets, die direkt in einer selbstverwahrten Wallet gehalten werden, sind anderen Risiken ausgesetzt als Assets, die in einen plattformkontrollierten Pool eingezahlt wurden. Kein Modell ist risikofrei, doch die Ursachen und Quellen der Risiken unterscheiden sich erheblich.

Die Rolle von Hardware-Wallets in einer sichereren Self-Custody-Strategie

Eine Hardware-Wallet kann die Anfälligkeit gegenüber serverseitigen Kompromittierungen verringern, indem sie private Schlüssel von internetverbundenen Anwendungen isoliert. Bei der Interaktion mit dezentralen Anwendungen können Nutzer Transaktionsdetails auf einem speziellen Signaturgerät überprüfen und genehmigen, statt sich ausschließlich auf eine Browseroberfläche zu verlassen.

Die Hardware-Wallets von OneKey sind für Self-Custody-Workflows ausgelegt und bieten unter anderem einen Offline-Schutz der Schlüssel sowie die Bestätigung von Transaktionen direkt auf dem Gerät. Sie beseitigen weder Risiken durch Smart Contracts, Phishing und schädliche Benutzeroberflächen noch die Marktvolatilität. Sie können Nutzern jedoch dabei helfen, die Kontrolle über Assets zu behalten, die nicht bewusst in verwahrte Plattformen oder Liquiditätspools eingezahlt wurden.

Das grundlegende Prinzip ist einfach: Vor der Bereitstellung von Liquidität oder der Autorisierung einer Transaktion sollten Nutzer verstehen, wer die Gelder kontrolliert, was sie signieren und ob die Plattform Assets ohne ihre direkte Zustimmung bewegen kann.

Der Verlust von rund 8,5 BTC bei DotSwap V1 unterstreicht, warum Verwahrungsarchitektur, Signaturberechtigungen und operative Sicherheit ebenso viel Aufmerksamkeit verdienen wie der Nutzen eines Tokens oder das Handelsvolumen. In einem zunehmend automatisierten Krypto-Umfeld bleiben informierte Selbstverwahrung und die sorgfältige Überprüfung von Transaktionen zentrale Schutzmaßnahmen.