Ich habe kürzlich wieder mal beiläufig die Sicherheits-Event-Ankündigung von Dusk Network für den Monat Januar durchgesehen. Eigentlich wollte ich nur wissen, was damals genau passiert ist – aber am Ende habe ich mich ständig über eine Frage gegrübelt: Warum unterscheiden sich die Formulierungen in der ursprünglichen Ankündigung und die Details in dem späteren Incident-Report so stark?
Am 17. Januar sagte Dusk, dass das Monitoring eine „ungewöhnliche Aktivität“ in den Team-verwalteten Wallets festgestellt habe. Daraufhin pausierten sie den Bridge-Service, deaktivierten die betreffenden Adressen und generierten sie neu. Außerdem hoben sie hervor, dass „keine Nutzerfonds betroffen“ seien.
Wenn man nur diese Ankündigung betrachtet, wirkt das gesamte Ereignis recht begrenzt.
Doch die nachträgliche Analyse vom 10. März lieferte deutlich mehr Details. Dusk erklärte, dass der Angreifer einen unbefugten Zugriff auf eine signierte Wallet erlangt habe. Auf der On-Chain-Seite folgten daraufhin mehrere DUSK-Transfers, darunter 9.000, 89.700, 274 Millionen sowie etwa 806,8 Millionen DUSK. Ein Teil der Gelder wurde außerdem über die Bridge auf die BNB Smart Chain übertragen. Der letzte Bridge-Versuch von rund 8,91 Millionen DUSK scheiterte schließlich nach der Schließung der Bridge.
Hier steckt eigentlich eine sehr interessante Informationslücke.
Dass Dusk sagt, die Nutzerfonds seien nicht betroffen gewesen, ist nicht im Widerspruch zu dem später offengelegten Angriffsprozess. Aber der Eindruck „keine Nutzer haben verloren“ steht in völlig anderem Verhältnis zu „mehrere Millionen Token wurden zeitweise transferiert“ – das weckt beim Leser ein ganz anderes Gefühl.
Was mich besonders beschäftigt, sind Architekturthemen. Dusk räumte später ein, dass das alte Design Signierung, Ereignisbehandlung und Netzwerkverbindungen in einem relativ konzentrierten Operationspfad zusammenführte. Anschließend wurden diese Bereiche getrennt und verstärkt.
Vielleicht ist das einfach ein normaler Kommunikationsprozess bei Sicherheitsvorfällen, und ich möchte allein aufgrund der Formulierungen keine Schlussfolgerung ziehen.
Wenn Dusk jedoch das Ziel hat, Service-Privacy und die Einhaltung regulatorischer Anforderungen für Finanzanwendungen zu gewährleisten, dann lohnt es sich ernsthaft zu untersuchen: Wo genau verläuft die Sicherheitsgrenze – und wie viel echte Risiko können die Nutzer tatsächlich sehen?
Wenn jemand diese On-Chain-Transaktionen, den Bridge-Signierungsablauf oder spätere Architekturänderungen verfolgt hat, würde ich sehr gern wissen: Was habt ihr wirklich herausgefunden?
#dusk $DUSK @Dusk
Am 17. Januar sagte Dusk, dass das Monitoring eine „ungewöhnliche Aktivität“ in den Team-verwalteten Wallets festgestellt habe. Daraufhin pausierten sie den Bridge-Service, deaktivierten die betreffenden Adressen und generierten sie neu. Außerdem hoben sie hervor, dass „keine Nutzerfonds betroffen“ seien.
Wenn man nur diese Ankündigung betrachtet, wirkt das gesamte Ereignis recht begrenzt.
Doch die nachträgliche Analyse vom 10. März lieferte deutlich mehr Details. Dusk erklärte, dass der Angreifer einen unbefugten Zugriff auf eine signierte Wallet erlangt habe. Auf der On-Chain-Seite folgten daraufhin mehrere DUSK-Transfers, darunter 9.000, 89.700, 274 Millionen sowie etwa 806,8 Millionen DUSK. Ein Teil der Gelder wurde außerdem über die Bridge auf die BNB Smart Chain übertragen. Der letzte Bridge-Versuch von rund 8,91 Millionen DUSK scheiterte schließlich nach der Schließung der Bridge.
Hier steckt eigentlich eine sehr interessante Informationslücke.
Dass Dusk sagt, die Nutzerfonds seien nicht betroffen gewesen, ist nicht im Widerspruch zu dem später offengelegten Angriffsprozess. Aber der Eindruck „keine Nutzer haben verloren“ steht in völlig anderem Verhältnis zu „mehrere Millionen Token wurden zeitweise transferiert“ – das weckt beim Leser ein ganz anderes Gefühl.
Was mich besonders beschäftigt, sind Architekturthemen. Dusk räumte später ein, dass das alte Design Signierung, Ereignisbehandlung und Netzwerkverbindungen in einem relativ konzentrierten Operationspfad zusammenführte. Anschließend wurden diese Bereiche getrennt und verstärkt.
Vielleicht ist das einfach ein normaler Kommunikationsprozess bei Sicherheitsvorfällen, und ich möchte allein aufgrund der Formulierungen keine Schlussfolgerung ziehen.
Wenn Dusk jedoch das Ziel hat, Service-Privacy und die Einhaltung regulatorischer Anforderungen für Finanzanwendungen zu gewährleisten, dann lohnt es sich ernsthaft zu untersuchen: Wo genau verläuft die Sicherheitsgrenze – und wie viel echte Risiko können die Nutzer tatsächlich sehen?
Wenn jemand diese On-Chain-Transaktionen, den Bridge-Signierungsablauf oder spätere Architekturänderungen verfolgt hat, würde ich sehr gern wissen: Was habt ihr wirklich herausgefunden?
#dusk $DUSK @Dusk