~88 Mio. $ verloren: COLDCARD & LULA Exploits

In der vergangenen Woche (2026/07/27 - 2026/08/02) werden die folgenden 2 bemerkenswerten Sicherheitsvorfälle vorgestellt, die zusammen Verluste von etwa 88 Millionen US-Dollar verursacht haben.

Datum	Vorfall	Typ	Geschätzter Verlust
2026/07/29	LULA	Fehler in der Geschäftslogik	~578.000 $
2026/07/30	COLDCARD	Fehlerhafte Entropiegenerierung	~1.370 BTC (~88 Mio. $)*

* COLDCARDs Verlust variiert je nach Bestätigungsmethode: Die angezeigten ~1.370 BTC (~88 Mio. $) stellen das öffentlich nachprüfbare On-Chain-Minimum dar (coldcardwatch.com); die Abstimmung über private Kanäle (Galaxy Research, aus der Korrespondenz mit 73 Opfern) liegt höher, bei etwa 1.596 BTC und bis zu ~2.055 BTC (~130 Mio. $), sobald mutmaßliche, aber nicht bestätigte Abflüsse einbezogen werden.

Auswahlgründe

LULA: Eine privilegierte Token-Funktion, die die Guthaben eines AMM-Paares verschieben und eine Neusynchronisierung der Reserven erzwingen kann, wird durch Preismanipulation zu einem wiederholbaren Primitiv zum Abschöpfen von Liquidität.
COLDCARD: Ein Build-und-Integrationsfehler in der Wallet-Firmware leitete die Seed-Generierung lautlos über einen deterministischen Software-Fallback um, untergrub dadurch die Entropiegarantien und machte die Seed-Wiederherstellung zu einer Offline-Suche, die sich zu einem großflächigen Fondsverlust ausweitete.

Wochenhighlight: COLDCARD

Wir haben COLDCARD als Highlight dieser Woche ausgewählt, da ein Wallet-Entropiefehler den größten Verlust des Zeitraums verursachte. Die Grundursache – eine Build-Absicherung, die prüfte, ob ein Konfigurationsmakro existierte, anstatt ob es aktiviert war – ist die Art von stillem Integrationsfehler, den Funktionstests nicht erkennen können; die Lehre daraus gilt für jedes System, bei dem die On-Chain-Sicherheit von Off-Chain-Zufälligkeit abhängt.

COLDCARD, eine Bitcoin-Hardware-Wallet, lieferte 2021 Firmware aus, die Wallet-Seeds mithilfe einer deterministischen Softwarequelle anstelle des vorgesehenen Hardware-Zufallszahlengenerators (RNG) generierte [1][2]. Der Fehler wurde erst Ende Juli 2026 in großem Maßstab ausgenutzt, als betroffene Wallets in On-Chain-Wellen ab dem 30. Juli geleert wurden: Öffentlich bestätigte Verluste belaufen sich auf mindestens 1.370 BTC (~88 Mio. $ zum Preis von 64.099 $ am 5. Aug.) [3], während privat bestätigte Berichte die Zahl auf etwa 1.596 BTC beziffern [4]. Die Grundursache war ein Build-und-Konfigurationsfehler, der die Seed-Generierung auf einen Software-Fallback anstelle des vorgesehenen Hardware-RNG umleitete. Für betroffene Geräte verwandelte dies die Seed-Wiederherstellung von einem kryptografisch nicht lösbaren Problem in eine Offline-Suche.

Hintergrund

COLDCARD ist eine Bitcoin-Hardware-Wallet. Die privaten Schlüssel und Adressen einer Wallet werden alle von einem einzigen geheimen Wert abgeleitet, dem Seed. Daher beruht die Sicherheit jeder Self-Custody-Wallet auf zwei Eigenschaften dieses Seeds: dass er geheim bleibt und dass er bei der Generierung unvorhersehbar ist. Hardware-Wallets existieren hauptsächlich, um die erste Eigenschaft zu schützen; dieser Vorfall ist ein Versagen der zweiten. Eine BIP-39-Seed-Phrase ist für Menschen lesbar, aber die Sicherheitseigenschaft hinter der Unvorhersehbarkeitsanforderung ist dennoch die Entropie der zufälligen Bytes, die zu ihrer Erstellung verwendet wurden. Können diese Bytes reproduziert werden, kann der Seed reproduziert werden. Die Analogie ist ein Safe, dessen Kombination durch das Würfeln ausgewählt wird: Sind die Würfel gezinkt, steht der Safe jedem offen, der die Verzerrung kennt – unabhängig davon, wie stark das Schloss ist.

Bei einer Wallet bedeuten „gezinkte Würfel" einen schwachen Zufallszahlengenerator. Von Hardware-Wallets wird erwartet, dass sie Seed-Entropie von einem Hardware-True-Random-Number-Generator (TRNG) auf ihrem sicheren Mikrocontroller beziehen, da ein Software-Pseudozufallsgenerator (PRNG) deterministisch ist: Bei bekanntem internen Zustand und Aufrufverlauf kann seine Ausgabe exakt wiederholt werden. Sind die Ausgaben des Generators vorhersehbar, kann sein Kandidatenbereich aufgezählt und mit öffentlichen Wallet-Daten – wie einer Adresse, einem xpub oder einem öffentlichen Schlüssel – abgeglichen werden, was die Seed-Wiederherstellung von einem kryptografisch nicht lösbaren Problem in eine Offline-Suche verwandelt.

COLDCARDs Firmware legte zwei separate RNG-Oberflächen frei. MicroPython lieferte eine STM32-Plattformschicht, die das globale rng_get()-Symbol bereitstellte, das die Krypto-Bibliothek der Wallet erwartete, während COLDCARD auch seinen eigenen board-lokalen Hardware-RNG-Wrapper pflegte. Beide Oberflächen sind dazu bestimmt, Hardware-Entropie zu liefern, und die Krypto-Bibliothek der Wallet erreicht eine davon über ein einzelnes globales RNG-Symbol, das beim Build der Firmware aufgelöst wird.

Schwachstellenanalyse

Die Grundursache war ein Build-und-Integrationsfehler rund um das Konfigurationsmakro MICROPY_HW_ENABLE_RNG. COLDCARDs Produktionsboard-Konfiguration setzte dieses Makro auf 0, da die Firmware beabsichtigte, ihren eigenen board-lokalen Hardware-RNG-Wrapper statt MicroPythons Hardware-RNG-Implementierung zu verwenden. Der Wallet-Generierungspfad war jedoch zu ngu.random.bytes(32) migriert worden, und der STM32-Pfad der Krypto-Bibliothek hing letztlich vom globalen rng_get()-Symbol ab, das durch MicroPython aufgelöst wurde.

Die Problemkette lautete:

generate_seed()
  -> ngu.random.bytes(32)
  -> libngu CHIP_TRNG_32()
  -> rng_get()
  -> MicroPython STM32 RNG-Modul
  -> Yasmarang-Software-Fallback, weil MICROPY_HW_ENABLE_RNG == 0

Die Board-Konfiguration deaktivierte MicroPythons Hardware-RNG-Zweig:

// Wir haben unsere eigene Version dieses Codes.
#define MICROPY_HW_ENABLE_RNG (0)

Die Krypto-Bibliothek betrachtete das Makro weiterhin als ausreichenden Nachweis eines Hardware-RNG [5], da sie lediglich prüfte, ob das Makro existierte, bevor sie rng_get() aufrief:

extern uint32_t rng_get(void);
#define CHIP_TRNG_32() rng_get()

#ifndef MICROPY_HW_ENABLE_RNG
#error "get a HW TRNG plz"
#endif

Diese Absicherung übersieht den gefährlichen Fall: Ein als 0 definiertes Makro ist dennoch definiert, sodass die #ifndef-Prüfung besteht und der Build erfolgreich ist. Da MicroPython seine RNG-Implementierung nach dem Wert des Makros und nicht nach seiner Existenz auswählt, leitete MICROPY_HW_ENABLE_RNG == 0 den Aufruf von rng_get() auf den Software-Fallback-Zweig anstelle von COLDCARDs board-lokalem Wrapper um [6]:

#if MICROPY_HW_ENABLE_RNG
    // STM32 Hardware-RNG
#else
    // Yasmarang-Software-Fallback
#endif

Die Folgen unterscheiden sich je nach Gerätegeneration. Für Mk2/Mk3-Firmware v4.0.0–v4.1.9 stellt Blocks Analyse [7] fest, dass ngu.random keine kryptografische Entropie hinzugefügt wurde, sodass die Wallet-Generierung deterministisch werden kann, sobald der Fallback-Zustand und der Aufrufverlauf bekannt sind (Coinkites Advisory [2] grenzt den Mk2/Mk3-Bereich etwas enger ein, auf v4.0.1–v4.1.9). Für Mk4/Q/Mk5 wurde Secure-Element-Material gehasht, aber nur vier Bytes wurden an ngu.random.reseed() übergeben, was den sicheren Reseed auf ein einzelnes 32-Bit-Zustandswort beschränkt – weit weniger effektiver Suchraum als die Wallet-Entropie, die Nutzer erwarten. Das Hashen der abschließenden 32 zufälligen Bytes kann die Entropie des Ergebnisses nicht erhöhen; es transformiert lediglich eine bereits begrenzte Kandidatenmenge.

Angriffsanalyse

Anders als bei einem Smart-Contract-Exploit gibt es bei diesem Vorfall keine einzelne On-Chain-Angriffstransaktion zum Nachverfolgen. Es handelte sich um ein Offline-Seed-Wiederherstellungsproblem, gefolgt von On-Chain-Leerungen. Die Voraussetzung war, dass betroffene Nutzer ihre Wallet-Seeds über den anfälligen ngu.random.bytes(32)-Pfad generiert hatten, sodass ihr Seed-Material von einem reproduzierbaren Software-Fallback-Zustand statt von vollständiger Hardware-Entropie abhing. Eine zweite, abgeleitete Voraussetzung ist, dass die betroffenen Wallets allein aus dem Seed ableitbar waren: Eine starke, einzigartige BIP-39-Passphrase mischt über PBKDF2 unabhängige, vom Nutzer bereitgestellte Entropie ein, die der RNG-Fehler nie berührt hat, was solche Wallets außerhalb der reinen Seed-Aufzählung stellt; das Ausmaß der Leerungen legt nahe, dass die meisten betroffenen Nutzer keine solche Passphrase gesetzt hatten. Von dort aus verlief die Wiederherstellung wahrscheinlich in drei Schritten:

Der Angreifer schränkte mögliche RNG-Zustände ein oder zählte sie auf, unter Verwendung von Gerätemetadaten, Boot-Timing, RTC/SysTick-Annahmen und plausiblem RNG-Aufrufverlauf.
Für jeden Kandidatenzustand leitete der Angreifer Kandidaten-Wallet-Seeds ab und überprüfte sie offline gegen öffentliche Wallet-Daten wie Adressen, xpubs oder generierte öffentliche Schlüssel.
Sobald ein Kandidat mit einer echten Wallet übereinstimmte, stellte der Angreifer den Seed wieder her, rekonstruierte die privaten Schlüssel und leerte die zugehörigen BTC.

On-Chain zeigte sich der Diebstahl als ein Ausbruch von Adressleerungen ab dem 30. Juli. Unabhängiges On-Chain-Heuristik-Tracking [3] identifiziert mehrere Leerungswellen mit insgesamt mindestens 1.370 BTC (etwa 88 Mio. $ bei Bewertung der Coins zum BTC-Preis von 64.099 $ am 5. Aug.) aus 4.580 verifizierten Adressen – ein verifiziertes Minimum, keine Gesamtsumme. Ein privater Kanal [4], bestätigt durch Korrespondenz mit 73 Opfern, beziffert die Summe auf bis zu etwa 1.596 BTC, steigend auf 2.055 BTC (~130 Mio. $), sobald mutmaßliche, aber nicht bestätigte Abflüsse hinzugerechnet werden.

Fazit

Der COLDCARD-Vorfall war ein Versagen der Entropiegenerierung: Die sicherheitskritische Seed-Generierungs-API wurde lautlos zu einem deterministischen Software-PRNG-Fallback aufgelöst statt zum vorgesehenen Hardware-RNG, da eine Build-Absicherung prüfte, ob ein Konfigurationsmakro existierte, anstatt ob es aktiviert war. Für betroffene Geräte verwandelte dies die Seed-Wiederherstellung von einem kryptografisch nicht lösbaren Problem in eine Offline-Suche, und das Ergebnis waren mehr als 1.370 BTC [3], die in mehreren Wellen abgezogen wurden (private Kanal-Zählungen beziffern es auf etwa 1.596 bis 2.055 BTC [4]).

Das grundlegende Engineeringversagen besteht darin, dass die ausgelieferte Firmware nie bewies, dass ihre sicherheitskritischste API tatsächlich den vorgesehenen Hardware-RNG erreichte. Drei Praktiken hätten es erkannt: Build-Absicherungen für kryptografische Entropie müssen sowohl die Existenz als auch den Wert des Makros prüfen; Entropie-Fallbacks müssen sicher scheitern, anstatt lautlos einen Software-PRNG einzusetzen; und die Verifizierung des endgültigen Firmware-Images sollte die Symbol-Herkunft und den End-to-End-Entropiefluss abdecken, nicht nur die erfolgreiche Kompilierung des Codes. Ein betroffener Seed kann nicht an Ort und Stelle repariert werden; seine Gelder sollten in eine Wallet verschoben werden, die mit korrigierter Firmware erstellt wurde, und eine starke, einzigartige Passphrase reduziert die unmittelbare Gefährdung, ohne den Seed zu reparieren [2].

Das Fehlerbild verdient besondere Beachtung: Zufälligkeitsfehler dieser Art sind für Funktionstests unsichtbar, da jeder generierte Seed individuell gültig ist. Der Defekt liegt nicht in einer einzelnen Ausgabe, sondern in der Quelle, die sie erzeugt hat: Da diese Quelle vorhersehbar und reproduzierbar ist, fallen die Seeds kollektiv in einen kleinen, aufzählbaren Bereich. Off-Chain-Schlüsselgenerierungskomponenten verdienen erstklassige Sicherheitsüberprüfung.

Referenzen

Weitere Vorfälle dieser Woche

LULA

LULA, ein BEP-20-Token auf der BNB Chain, verlor am 29. Juli 2026 etwa 578.000 $ durch einen Fehler in der Geschäftslogik seines Token-Contracts. Ein für Angreifer erreichbarer Pfad konnte seine privilegierte recycle()-Funktion auslösen, wodurch der Rental-Contract LULA direkt aus dem PancakeSwap-V2-Paar transferieren und anschließend sync() aufrufen konnte, was die Reserven des Paares auf die manipulierten Guthaben aktualisierte. Der Angreifer löste recycle() wiederholt aus, um die LULA-Reserve des Paares nahezu auf null zu reduzieren, und tauschte dann eine kleine Menge LULA gegen nahezu alle seine USDT [1].

Hintergrund

LULA ist ein BEP-20-Token auf der BNB Chain mit einem mietbasierten Team-Belohnungsmechanismus. Berechtigte Adressen häufen ausstehende Team-Belohnungen in einem Rental-Contract an und beanspruchen sie über claimTeamReward(). Im Verlauf des Anspruchsprozesses ruft der Rental-Contract die recycle()-Funktion des Tokens auf, um LULA für die Belohnungsverteilung zu erhalten. recycle() ist nicht von beliebigen Nutzern aufrufbar; nur der Rental-Contract ist berechtigt, sie auszuführen.

Der claimTeamReward()-Einstiegspunkt enthält eine „Nur-EOA"-Prüfung. Er unterstützt direkte Aufrufe von extern kontrollierten Konten, bei denen msg.sender == tx.origin gilt, und er unterstützt auch delegierte EIP-7702-Aufrufe durch Inspektion des delegierten Code-Präfixes.

Bei einem automatisierten Market Maker (AMM) berechnet ein Paar Swaps aus seinen gespeicherten Reserven, und diese Reserven werden über die sync()-Funktion des Paares aktualisiert, die sie auf die aktuellen Token-Guthaben des Paares setzt. Reserven verfolgen normalerweise echte Handelsaktivitäten, da sie sich mit Swaps und Liquiditätsereignissen bewegen, aber das Token-Guthaben eines Paares kann auch durch eine direkte Überweisung verändert werden, und sync() kopiert das jeweils vorhandene Guthaben – ob manipuliert oder nicht – in die gespeicherten Reserven.

Schwachstellenanalyse

Die Grundursache war, dass LULA.recycle() dem Rental-Contract erlaubt, LULA direkt aus dem PancakeSwap-V2-Paar zu transferieren und anschließend sync() aufzurufen, was die Reserven des Paares auf die manipulierten Guthaben aktualisiert [1].

Da sync() die Reserven auf das verbleibende LULA-Guthaben im Paar setzt, kann dieser privilegierte Pfad die LULA-Reserve des Paares beliebig weit absenken, während die USDT-Seite unberührt bleibt. Sobald die LULA-Reserve nahe null ist, bewertet das Paar eine kleine Menge LULA als nahezu alle seiner USDT wert.

Angriffsanalyse

Die folgende Analyse basiert auf der Transaktion 0xa219ab9...411d7c.

Schritt 1: Der Angreifer finanzierte die Manipulation durch die Ansammlung von ~197,05 Mio. USDT. Die Mittel stammten aus mehreren Flash-Loan- und Kreditquellen, darunter Moolah/Lista, Aave V3, Venus, PancakeSwap V3, PancakeSwap Vault, Uniswap V4 PoolManager und Uniswap V3.
Schritt 2: Der Angreifer verwendete die ~197,05 Mio. USDT, um einen großen USDT -> LULA-Swap über den PancakeSwap-V2-Router durchzuführen. Dies reduzierte die LULA-Reserve des Paares schlagartig von etwa 8 Mio. LULA auf 24.022 LULA, während die USDT-Seite auf etwa 197,64 Mio. USDT anstieg.
Schritt 3: Der Angreifer rief den Belohnungspfad über mehrere EIP-7702-Wallets auf. Jede Wallet rief claimTeamReward() im Rental-Contract auf, der daraufhin LULA.recycle() auslöste und die LULA-Reserve des Paares von 24.022 LULA auf 0,004 LULA schrumpfte, während das Paar noch eine sehr große USDT-Seite hielt.
Schritt 4: Der Angreifer leitete einen finalen PancakeSwap-V2-Swap über den Router, sendete nur ~4.749 LULA in das Paar und erhielt ~197,64 Mio. USDT heraus.
Schritt 5: Der Angreifer tilgte alle Flash Loans und erzielte einen Gewinn von etwa 578.000 $.

Fazit

Der LULA-Token auf der BNB Chain wurde durch einen Fehler in der Geschäftslogik seines Token-Contracts für etwa 578.000 $ ausgenutzt: Ein für Angreifer erreichbarer Pfad konnte seine privilegierte recycle()-Funktion auslösen, wodurch der Rental-Contract LULA direkt aus dem PancakeSwap-V2-Paar transferieren und anschließend sync() aufrufen konnte, um die Reserven des Paares auf die manipulierten Guthaben neu zu synchronisieren. Der Angreifer löste dies wiederholt aus, um den Preis des Paares zu verzerren und eine kleine Menge LULA gegen nahezu alle seine USDT zu tauschen.

Ein Token-Contract sollte niemals einen privilegierten Pfad freigeben, der die Guthaben eines AMM-Paares verschieben und eine Reserve-Neusynchronisierung erzwingen kann, da dadurch die Preiskontrolle an jeden weitergegeben wird, der diesen Pfad erreichen kann. Tokens, die mit AMM-Paaren integriert sind, müssen die Reserven des Paares an echte, marktgetriebene Guthabenänderungen binden, und jede Logik, die Pool-Reserven für die Preisgestaltung liest, sollte sie als manipulierbar und nicht als maßgeblich behandeln.

Referenzen

[1] BlockSec Phalkons Analyse des LULA-Exploits
Get Started with Phalcon Security
Detect every threat, alert what matters, and block attacks.
Try now for free