Sicherheitsvorfall: ~4.000 BTC (~320 Mio. $) aus Liquid Federation Wallet abgezogen
Hackers have withdrawn ~4k BTC (~$320M) from the Liquid Federation wallet
Die Liquid Network Sidechain wurde nach einem Sicherheitsvorfall pausiert: Vermeintliche White-Hat-Hacker haben rund 4.000 BTC (ca. 320 Mio. $) aus dem Liquid Federation Wallet abgezogen. Das Blockstream-Team versucht, die Angreifer über eine signierte On-Chain-Nachricht zu kontaktieren. Die Gelder wurden über den SideSwap PAK (Peg-out Authorization Key) transferiert, obwohl dieser Schlüssel nicht kompromittiert wurde. Börsen wurden informiert und haben LBTC-Einzahlungen und -Auszahlungen gestoppt. Andere Liquid-Assets wie USDT, DePix und RWAs sind nicht betroffen. Bridge-Nodes wurden deaktiviert, sodass keine neuen Transaktionen möglich sind.
Live by the sidechain, die by the sidechain.
- cypherpunks01
Es scheint, als könnte ein Bug im Elements-Rangeproof-Cache ausgenutzt worden sein. Der Fix für das verdächtige Problem wurde erst letzte Woche committet und Angreifer hätten die öffentlichen Commits überwachen und den Bug ausnutzen können, bevor der Fix überhaupt gepusht wurde?
Eine Art selbsterfüllende Prophezeiung, wenn das stimmt – das ist jedenfalls eine führende Theorie.
Fix: Range-Proof-Cache an Asset und Scriptpubkey binden
https://github.com/ElementsProject/elements/commit/c26d719c2...
- rgbrgb
Hier gibt es eine interessante Diskussion über Open Source, das normalerweise als sicherer gilt, weil mehr Leute auf den Code schauen, aber tatsächlich weniger sicher sein kann, weil ein versehentlicher Merge sofort von LLMs ausgenutzt werden kann. Hat Geheimhaltung jetzt einen viel größeren Sicherheitswert als zuvor?
- Daviey
- nullc
Ich habe 2017 bei Blockstream gearbeitet und die ursprünglichen kryptografischen Range Proofs entwickelt, die die Vorfahren des hier beteiligten Codes sind. Die Schwachstellen hier und das gesamte Liquid-Produkt, wie es heute existiert, stammen jedoch aus der Zeit nach meiner Mitarbeit im Unternehmen (während ich dort war, befand es sich in der Anfangsentwicklung, wurde aber ganz anders konzipiert, als es schließlich umgesetzt wurde), und ich habe es seitdem nicht genau verfolgt.
Aber ich habe mir das Problem kurz angesehen, basierend auf den Transaktionen und der GitHub-Historie.
Das zugrunde liegende Problem hing mit dem Validierungs-Cache zusammen. Signaturen und Beweise sind teuer zu validieren; um die Leistung zu verbessern und bestimmte DoS-Angriffe zu verhindern, wird ihre Validierung gecacht. Es ist wichtig, dass der Schlüssel, der im Cache verwendet wird, alles erfasst, was in die Validierungsentscheidung einfließt (obwohl es zur Verhinderung einiger Angriffe wichtig ist, dass nicht zu viel in den Schlüssel einfließt, sonst kann ein Angreifer mit gültigen Beweisen, die an unbedeutend unterschiedliche Transaktionen angehängt sind, den Cache überfluten).
Mir scheint, dass es eine seit langem bestehende Schwachstelle gab – die auf die Einführung der Unterstützung mehrerer Assets zurückgeht – die zu einer Konsensspaltung/DoS führen konnte. Aber bei einer oberflächlichen Überprüfung kann ich keinen Weg finden, dies in einen Diebstahl umzuwandeln. Ich sehe, wie jemand eine ungültige Transaktion erstellen könnte, die von Knoten fälschlicherweise akzeptiert würde, die Cache-Zustände aus einer konstruierten vorherigen Transaktion haben, aber die Wege, die mir einfallen, führen dazu, dass die ungültige Transaktion nur Assets verbrennt – nicht direkt sehr nützlich. [Bi ...]
- skinfaxi
Warum sagen sie, dass es White-Hat-Hacker sind?