~88 Mio. $ verloren: COLDCARD- & LULA-Exploits

In der vergangenen Woche (27.07.2026 - 02.08.2026) werden die folgenden 2 bedeutenden Sicherheitsvorfälle vorgestellt, die zusammen für Verluste von rund 88 Mio. $ verantwortlich sind.

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

* Der Verlust bei COLDCARD variiert je nach Verifizierungsmethode: Die angezeigten ~1.370 BTC (~88 Mio. $) sind das öffentlich nachvollziehbare On-Chain-Minimum (coldcardwatch.com); die Abstimmung über private Kanäle (Galaxy Research, aus dem Austausch mit 73 Opfern) beziffert den Wert höher, auf etwa 1.596 BTC und bis zu ~2.055 BTC (~130 Mio. $), wenn vermutete, aber unbestätigte Abflüsse mit einbezogen werden.

Gründe für die Auswahl

LULA: Eine privilegierte Token-Funktion, die die Guthaben eines AMM-Paars verschieben und eine Resynchronisierung der Reserven erzwingen kann, wird durch Preismanipulation zu einem wiederholbaren Mechanismus zum Abziehen von Liquidität.
COLDCARD: Ein Build- und Integrationsfehler in der Wallet-Firmware leitete die Seed-Erzeugung unbemerkt über einen deterministischen Software-Fallback um, was die Entropie-Garantien unterminierte und die Seed-Wiederherstellung in eine Offline-Suche verwandelte, die in einen groß angelegten Verlust von Geldern eskalierte.

Highlight der Woche: COLDCARD

Wir haben COLDCARD als Highlight dieser Woche ausgewählt, weil ein Entropie-Fehler in der Wallet den größten Verlust des Zeitraums verursachte. Die Grundursache, eine Build-Absicherung, die prüfte, ob ein Konfigurations-Makro existierte, statt ob es aktiviert war, ist die Art von stillem Integrationsfehler, den funktionale Tests nicht erkennen können, und die Lektion gilt für jedes System, bei dem On-Chain-Sicherheit von Off-Chain-Zufälligkeit abhängt.

COLDCARD, eine Bitcoin-Hardware-Wallet, veröffentlichte 2021 eine Firmware, die Wallet-Seeds mit einer deterministischen Software-Quelle erzeugte, statt mit dem vorgesehenen Hardware-Zufallszahlengenerator (RNG) [1][2]. Der Fehler wurde erst Ende Juli 2026 in großem Maßstab ausgenutzt, als betroffene Wallets ab dem 30. Juli in On-Chain-Wellen leergeräumt wurden: Öffentlich bestätigte Verluste belaufen sich auf mindestens 1.370 BTC (~88 Mio. $, beim Preis von 64.099 $ am 5. Aug.) [3], während privat bestätigte Berichte die Zahl auf bis zu etwa 1.596 BTC beziffern [4]. Die Grundursache war ein Build- und Konfigurationsfehler, der die Seed-Erzeugung auf einen Software-Fallback umleitete, statt auf den vorgesehenen Hardware-RNG. Bei betroffenen Geräten verwandelte dies die Seed-Wiederherstellung von einem kryptografisch unmöglichen Problem in eine Offline-Suche.

Hintergrund

COLDCARD ist eine Bitcoin-Hardware-Wallet. Die privaten Schlüssel und Adressen einer Wallet werden alle aus einem einzigen Geheimwert abgeleitet, ihrem Seed, sodass die Sicherheit jeder Self-Custody-Wallet auf zwei Eigenschaften dieses Seeds beruht: dass er geheim bleibt und dass er bei der Erzeugung unvorhersehbar ist. Hardware-Wallets existieren größtenteils, 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, die der Unvorhersehbarkeitsanforderung zugrunde liegt, ist weiterhin die Entropie der Zufallsbytes, die zu ihrer Erzeugung verwendet werden. Wenn diese Bytes reproduziert werden können, kann auch der Seed reproduziert werden. Die Intuition dahinter ist ein Safe, dessen Kombination durch Würfeln bestimmt wird: Sind die Würfel gezinkt, steht der Safe für jeden offen, der die Verzerrung kennt, egal wie stark das Schloss ist.

Bei einer Wallet bedeutet „gezinkte Würfel" einen schwachen Zufallszahlengenerator. Von Hardware-Wallets wird erwartet, dass sie die Seed-Entropie von einem echten Hardware-Zufallszahlengenerator (TRNG) auf ihrem sicheren Mikrocontroller beziehen, da ein Software-Pseudozufallsgenerator (PRNG) deterministisch ist: Kennt man seinen internen Zustand und seine Aufrufhistorie, lässt sich seine Ausgabe exakt reproduzieren. 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 unmöglichen Problem in eine Offline-Suche verwandelt.

Die Firmware von COLDCARD legte zwei separate RNG-Schnittstellen frei. MicroPython lieferte eine STM32-Plattformschicht, die das globale Symbol rng_get() bereitstellte, das die Krypto-Bibliothek der Wallet erwartete, während COLDCARD zusätzlich einen eigenen board-lokalen Hardware-RNG-Wrapper unterhielt. Beide Schnittstellen sind dafür vorgesehen, Hardware-Entropie zu liefern, und die Krypto-Bibliothek der Wallet erreicht eine davon über ein einziges globales RNG-Symbol, das beim Build der Firmware aufgelöst wird.

Schwachstellenanalyse

Die Grundursache war ein Build- und Integrationsfehler rund um das Konfigurations-Makro MICROPY_HW_ENABLE_RNG. Die Produktions-Board-Konfiguration von COLDCARD setzte dieses Makro auf 0, da die Firmware ihren eigenen board-lokalen Hardware-RNG-Wrapper verwenden sollte, statt die Hardware-RNG-Implementierung von MicroPython. Der Pfad zur Wallet-Erzeugung war jedoch auf ngu.random.bytes(32) migriert worden, und der STM32-Pfad der Krypto-Bibliothek hing letztlich vom globalen Symbol rng_get() ab, das von MicroPython aufgelöst wurde.

Die Problemkette war:

generate_seed()
  -> ngu.random.bytes(32)
  -> libngu CHIP_TRNG_32()
  -> rng_get()
  -> MicroPython STM32 RNG module
  -> Yasmarang software fallback because MICROPY_HW_ENABLE_RNG == 0

Die Board-Konfiguration deaktivierte den Hardware-RNG-Zweig von MicroPython:

// We have our own version of this code.
#define MICROPY_HW_ENABLE_RNG (0)

Die Krypto-Bibliothek behandelte das Makro weiterhin als ausreichenden Beweis für einen Hardware-RNG [5], da sie vor dem Aufruf von rng_get() nur prüfte, ob das Makro existierte:

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 Makro, das als 0 definiert ist, ist trotzdem definiert, sodass die #ifndef-Prüfung erfolgreich ist und der Build gelingt. Da MicroPython seine RNG-Implementierung anhand des Werts des Makros und nicht anhand seiner Existenz auswählt, leitete MICROPY_HW_ENABLE_RNG == 0 rng_get() auf den Software-Fallback-Zweig um, statt auf den board-lokalen Wrapper von COLDCARD [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 die Analyse von Block [7] fest, dass zu ngu.random keine kryptografische Entropie hinzugefügt wurde, sodass die Wallet-Erzeugung deterministisch werden kann, sobald der Fallback-Zustand und die Aufrufhistorie bekannt sind (der Hinweis von Coinkite [2] grenzt den Mk2/Mk3-Bereich etwas enger ein, nämlich auf v4.0.1-v4.1.9). Für Mk4/Q/Mk5 wurde Material aus dem Secure Element gehasht, aber nur vier Bytes wurden an ngu.random.reseed() übergeben, wodurch das sichere Reseeding auf ein einzelnes 32-Bit-Zustandswort begrenzt war — ein weit geringerer Suchraum, als Nutzer an Wallet-Entropie erwarten. Das Hashen der letzten 32 Zufallsbytes 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, die man nachverfolgen könnte. Es handelte sich um ein Offline-Problem der Seed-Wiederherstellung, gefolgt von On-Chain-Abflüssen. Die Voraussetzung war, dass betroffene Nutzer ihre Wallet-Seeds über den anfälligen ngu.random.bytes(32)-Pfad erzeugt hatten, sodass ihr Seed-Material von einem reproduzierbaren Software-Fallback-Zustand abhing, statt von voller Hardware-Entropie. Eine zweite, abgeleitete Voraussetzung ist, dass sich die betroffenen Wallets allein aus dem Seed ableiten ließen: Eine starke, eindeutige BIP-39-Passphrase mischt über PBKDF2 unabhängige, vom Nutzer bereitgestellte Entropie hinzu, die der RNG-Fehler nie berührte, wodurch solche Wallets außerhalb der reinen Seed-Aufzählung liegen, und der Umfang der Abflüsse 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 Kandidaten-RNG-Zustände anhand von Geräte-Metadaten, Boot-Zeitpunkten, RTC/SysTick-Annahmen und plausibler RNG-Aufrufhistorie ein oder zählte sie auf.
Für jeden Kandidatenzustand leitete der Angreifer Kandidaten-Wallet-Seeds ab und prüfte sie offline gegen öffentliche Wallet-Daten wie Adressen, xpubs oder erzeugte ö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 eine Reihe von Adress-Abflüssen, die am 30. Juli begann. Eine unabhängige heuristische On-Chain-Überwachung [3] identifiziert mehrere Abfluss-Wellen mit insgesamt mindestens 1.370 BTC (etwa 88 Mio. $, bei einer Bewertung der Coins zum BTC-Preis von 64.099 $ am 5. Aug.), die aus 4.580 verifizierten Adressen abgezogen wurden – ein verifiziertes Minimum und keine Gesamtsumme. Ein privater Kanal [4], bestätigt durch den Austausch mit 73 Opfern, beziffert die Zahl unterdessen auf bis zu etwa 1.596 BTC, mit einem Anstieg auf 2.055 BTC (~130 Mio. $), sobald vermutete, aber unbestätigte Abflüsse hinzugerechnet werden.

Fazit

Der COLDCARD-Vorfall war ein Versagen bei der Entropie-Erzeugung: Die sicherheitskritische API zur Seed-Erzeugung löste sich unbemerkt in einen deterministischen Software-PRNG-Fallback auf, statt in den vorgesehenen Hardware-RNG, da eine Build-Absicherung prüfte, ob ein Konfigurations-Makro existierte, statt ob es aktiviert war. Bei betroffenen Geräten verwandelte dies die Seed-Wiederherstellung von einem kryptografisch unmöglichen Problem in eine Offline-Suche, und das Ergebnis waren über 1.370 BTC [3], die in mehreren Wellen abgezogen wurden (Zählungen über private Kanäle beziffern es auf etwa 1.596 bis 2.055 BTC [4]).

Das zentrale technische Versagen besteht darin, dass die ausgelieferte Firmware nie nachwies, dass ihre sicherheitskritischste API tatsächlich den vorgesehenen Hardware-RNG erreichte. Drei Praktiken hätten dies verhindert: Build-Absicherungen für kryptografische Entropie müssen sowohl die Existenz als auch den Wert eines Makros prüfen; Entropie-Fallbacks müssen im Fehlerfall sperren (fail closed), statt unbemerkt durch einen Software-PRNG ersetzt zu werden; und die Verifizierung des finalen Firmware-Images sollte die Herkunft von Symbolen und den End-to-End-Entropiefluss abdecken, nicht nur, dass der Code kompiliert. Ein betroffener Seed kann nicht vor Ort repariert werden; seine Gelder sollten auf eine Wallet verschoben werden, die mit fester Firmware erstellt wurde, und eine starke, eindeutige Passphrase verringert die unmittelbare Gefährdung, ohne den Seed zu reparieren [2].

Das Fehlerbild ist es wert, hervorgehoben zu werden: Zufälligkeitsfehler dieser Art sind für funktionale Tests unsichtbar, da jeder erzeugte Seed für sich genommen gültig ist. Der Defekt liegt nicht in irgendeiner einzelnen Ausgabe, sondern in der Quelle, die sie erzeugt hat: Da diese Quelle vorhersehbar und reproduzierbar ist, fallen die Seeds insgesamt in einen kleinen, aufzählbaren Bereich. Off-Chain-Komponenten zur Schlüsselerzeugung verdienen erstklassige Sicherheitsprüfung.

Referenzen

Weitere Vorfälle dieser Woche

LULA

LULA, ein BEP-20-Token auf der BNB Chain, verlor am 29. Juli 2026 rund 578.000 $ durch einen Fehler in der Geschäftslogik seines Token-Vertrags. Ein für Angreifer erreichbarer Pfad konnte die privilegierte Funktion recycle() auslösen, die es dem Rental-Vertrag ermöglichte, LULA direkt aus dem PancakeSwap-V2-Paar zu übertragen und anschließend sync() aufzurufen, wodurch die Reserven des Paares an die manipulierten Guthaben angepasst wurden. 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 wieder gegen fast das gesamte USDT ein [1].

Hintergrund

LULA ist ein BEP-20-Token auf der BNB Chain mit einem vermietungsbasierten Team-Belohnungsmechanismus. Berechtigte Adressen sammeln ausstehende Team-Belohnungen in einem Rental-Vertrag an und beanspruchen sie über claimTeamReward(). Während des Beanspruchungsvorgangs ruft der Rental-Vertrag die Funktion recycle() des Tokens auf, um LULA für die Belohnungsausschüttung zu erhalten. recycle() kann nicht von beliebigen Nutzern aufgerufen werden; nur der Rental-Vertrag ist berechtigt, es auszuführen.

Der Einstiegspunkt claimTeamReward() enthält eine „Nur-EOA"-Prüfung. Er unterstützt direkte Aufrufe von externen Konten (EOAs), bei denen msg.sender == tx.origin gilt, und unterstützt zudem EIP-7702-delegierte Aufrufe, indem er das Präfix des delegierten Codes prüft.

Bei einem automatisierten Market Maker (AMM) bepreist ein Paar Swaps anhand seiner gespeicherten Reserven, und diese Reserven werden über die sync()-Funktion des Paares aktualisiert, die sie auf die aktuellen Token-Guthaben des Paares setzt. Normalerweise entsprechen die Reserven echtem Handel, da sie sich mit Swaps und Liquiditätsereignissen bewegen, aber das Token-Guthaben eines Paares kann auch durch eine direkte Übertragung verändert werden, und sync() übernimmt in die gespeicherten Reserven, welches Guthaben auch immer vorhanden ist – manipuliert oder nicht.

Schwachstellenanalyse

Die Grundursache war, dass LULA.recycle() es dem Rental-Vertrag ermöglicht, LULA direkt aus dem PancakeSwap-V2-Paar zu übertragen und anschließend sync() aufzurufen, wodurch die Reserven des Paares an die manipulierten Guthaben angepasst wurden [1].

Da sync() die Reserven auf das jeweils im Paar verbleibende LULA-Guthaben 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 liegt, bepreist das Paar eine kleine Menge LULA als nahezu das gesamte USDT wert.

Angriffsanalyse

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

Schritt 1: Der Angreifer finanzierte die Manipulation, indem er ~197,05 Mio. USDT anhäufte. 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 nutzte die ~197,05 Mio. USDT, um über den PancakeSwap-V2-Router einen großen USDT -> LULA-Swap durchzuführen. Dies senkte die LULA-Reserve des Paares von etwa 8 Mio. LULA drastisch auf 24.022 LULA, während die USDT-Seite auf rund 197,64 Mio. USDT anstieg.
Schritt 3: Der Angreifer rief den Belohnungspfad über mehrere EIP-7702-Wallets auf. Jede Wallet rief claimTeamReward() beim Rental-Vertrag auf, der daraufhin LULA.recycle() auslöste, wodurch die LULA-Reserve des Paares von 24.022 LULA auf 0,004 LULA schrumpfte, während das Paar weiterhin eine sehr große USDT-Seite hielt.
Schritt 4: Der Angreifer leitete einen letzten PancakeSwap-V2-Swap über den Router, wobei er nur ~4.749 LULA in das Paar einbrachte und ~197,64 Mio. USDT dafür erhielt.
Schritt 5: Der Angreifer zahlte alle Flash-Loans zurück und erzielte einen Gewinn von rund 578.000 $.

Fazit

Der Token LULA auf der BNB Chain wurde durch einen Fehler in der Geschäftslogik seines Token-Vertrags um rund 578.000 $ ausgenutzt: Ein für Angreifer erreichbarer Pfad konnte die privilegierte Funktion recycle() auslösen, wodurch der Rental-Vertrag LULA direkt aus dem PancakeSwap-V2-Paar übertragen und anschließend sync() aufrufen konnte, wobei die Reserven des Paares auf die manipulierten Guthaben resynchronisiert wurden. Der Angreifer löste dies wiederholt aus, um den Preis des Paares zu verzerren und eine kleine Menge LULA wieder gegen fast das gesamte USDT einzutauschen.

Ein Token-Vertrag sollte niemals einen privilegierten Pfad offenlegen, der die Guthaben eines AMM-Paares verschieben und eine Resynchronisierung der Reserven erzwingen kann, da dies die Preiskontrolle in die Hände von jedem legt, der diesen Pfad erreichen kann. Tokens, die mit AMM-Paaren integriert sind, müssen die Reserven des Paares an echte, marktgetriebene Änderungen des Guthabens gebunden halten, und jede Logik, die Pool-Reserven zur Preisbildung liest, sollte diese als manipulierbar und nicht als maßgeblich behandeln.

Referenzen

[1] Analyse des LULA-Exploits von BlockSec Phalcon

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden dabei helfen, Code-Audits durchzuführen (einschließlich Smart Contracts, Blockchain und Wallets), Angriffe in Echtzeit abzufangen, Vorfälle zu analysieren, illegale Gelder zurückzuverfolgen und AML/CFT-Verpflichtungen zu erfüllen – über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg.

BlockSec hat mehrere Blockchain-Sicherheitspapiere auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks blockiert, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von mehreren Milliarden abgesichert.