~1,6 Mio. $ verloren: Moke Token, LpdFi-Exploits | BlockSec Weekly

In der vergangenen Woche (2026/08/03 - 2026/08/09) werden die folgenden 2 bemerkenswerten Sicherheitsvorfälle vorgestellt, mit einem Gesamtschaden von ungefähr 1,6 Mio. USD.

• LpdFi wurde ausgewählt, weil es das systemische Risiko verdeutlicht, manipulierbare AMM-Reserven sowohl für die Positionsbewertung als auch für die Zinseinlösung zu verwenden. Der Angreifer blähte zunächst das erfasste Kapital durch Spot-Preismanipulation auf, veränderte dann die Pool-Reserven durch eine direkte Einzahlung und sync(), um den überdimensionierten Zinsanspruch ausführbar zu machen. Dies unterstreicht die Bedeutung der Validierung der Solvenz über den gesamten Lebenszyklus einer Position, anstatt Einlagenbewertung, Zinsberechnung und Einlösung als unabhängige Vorgänge zu behandeln.
• Moke Token wurde ausgewählt, weil es zeigt, wie Schwachstellen in separaten Buchführungsmechanismen zu einem einzigen profitablen Angriff kombiniert werden können. Der Angreifer manipulierte einen Spot-Preis, um die Menge an einlösbaren MOKE aufzublähen, duplizierte LP-Reward-Einträge durch die Synchronisierung derselben LP-Token über mehrere Adressen und wandelte die resultierenden Token über das Dividendensystem in extrahierbares BNB um. Dies unterstreicht die Bedeutung manipulationsresistenter Preisquellen und einer Reward-Buchführung, die mit dem tatsächlichen Token-Besitz synchronisiert bleibt.

Wöchentliches Highlight: LpdFi-Protokoll

Dieser Vorfall wird hervorgehoben, weil derselbe manipulierbare AMM-Zustand sowohl die Verbindlichkeitsentstehung als auch die Vermögenseinlösung steuerte. Er zeigt, warum ein Protokoll die Solvenz über den gesamten Lebenszyklus einer Position validieren muss und Einlagenbewertung, Zinsakkumulierung und Einlösung nicht als unabhängige Schritte behandeln darf.

Am 3. August 2026 wurde das LpdFi-Protokoll auf der BNB Chain für ungefähr 697.000 USD ausgenutzt, wobei Mittel aus dem LPD/USDC-PancakeSwap-Paar abgezogen wurden. LpdFi leitete sowohl den erfassten Wert einer Position als auch deren späteren Zinsausschüttung aus demselben aktiven PancakeSwap-Paar ab, sodass die Manipulation dieses Paares beides verzerrte. Der Angreifer eröffnete eine Position, die weit über ihrem tatsächlichen Wert bewertet wurde, wartete auf die Zinsakkumulierung und verschob dann die Reserven des Paares, sodass der überdimensionierte Zinsanspruch ausgezahlt werden konnte, wodurch nahezu die gesamte Liquidität des Protokolls abgezogen wurde.

Hintergrund

LpdFi ist ein Yield-Protokoll, das auf dem LPD-Token aufgebaut ist. Ein Nutzer erstellt eine Position, indem er LPD einzahlt. Zum Zeitpunkt der Einzahlung bewertet das Protokoll die Einlage anhand des aktuellen LPD/USDC-PancakeSwap-Spot-Preises und speichert das Ergebnis als uAmount, ein USD-denominiertes Kapital für die Order. Die Order akkumuliert Zinsen pro Ausgabe, wobei jede Ausgabe einem täglichen Abrechnungszeitraum entspricht, und das Protokoll begrenzt die Gesamtzinsen jeder Order gegenüber dem erfassten Kapital.

Wenn ein Nutzer Zinsen beansprucht, wandelt das Protokoll die buchmäßigen Zinsen in USDC um, indem es Liquidität aus dem LPD/USDC-Paar mithilfe von LP-Token entfernt, die von LpdFi gehalten werden. Das eingelöste USDC wird dann zwischen dem Anspruchssteller und der Gebührenadresse aufgeteilt. Beide Enden des Positionslebenszyklus – die Bewertung bei der Einzahlung und die Auszahlung bei der Einlösung – lesen daher aus demselben aktiven PancakeSwap-Paar.

Schwachstellenanalyse

Die fehlerhaften Verträge sind 0xce6a...f295e und 0x3876...273604.

Die Grundursache ist, dass LpdFi den aktiven LPD/USDC-Spot-Preis und die Reserven als einzige Wahrheitsquelle sowohl für die Order-Buchführung als auch für die Zinseinlösung verwendete. Keiner der Werte ist sicher zu vertrauen: Beide werden aus Paar-Reserven abgeleitet, die ein Aufrufer mit ausreichend temporärer Liquidität innerhalb einer einzigen Transaktion verschieben kann.

Bei der Einzahlung berechnet buy() den Token-Betrag aus token.price():

LPD.price() liest die LPD/USDC-Reserven direkt über getReserves(), sodass sich das erfasste Kapital mit dem Spot-Preis bewegt:

Bei der Einlösung zahlt claimInterest() die aufgelaufenen Zinsen durch den Aufruf von removeLp() aus:

removeLp() berechnet, wie viele LP-Token aus der aktiven Reserve r1 (oder r0) verbrannt werden sollen:

Zwei Invarianten werden dadurch verletzt. Erstens kann, da das erfasste Kapital vom Spot-Preis abgeleitet wird, ein Kapital erfasst werden, das weit über dem tatsächlichen Wert der Einlage liegt, was die Zinsobergrenze erhöht. Zweitens hängt, da removeLp() den LP-Verbrennungsbetrag aus der aktiven Reserve berechnet, die Anzahl der LP-Token, die das Protokoll verbrennen muss, um eine bestimmte USDC-Auszahlung zu erfüllen, von einem Reservewert ab, der zum Zeitpunkt des Anspruchs nicht festgelegt ist.

Angriffsanalyse

Die folgende Analyse basiert auf den Transaktionen 0xbb5b85...41c3588 und 0x70bbe0...b3315d6.

• Schritt 1: In Block 113613923 nutzte der Angreifer Flash-Loan-Mittel, um einen großen USDC-zu-LPD-Swap im LPD/USDC-Paar durchzuführen. Dadurch wurde die LPD-Reserve des Pools reduziert und der von LPD.price() zurückgegebene Spot-Preis erhöht.

• Schritt 2: Während der Preis aufgebläht war, rief der Angreifer buy() auf, um eine überdimensionierte Order zu eröffnen. Zum manipulierten Spot-Preis bewertet, wurde die Einlage mit einem USD-Kapital von 140.324.732 erfasst.

• Schritt 3: Im nächsten Block, 113613924, überschritt der Angreifer die Ausgabegrenze des Protokolls. Obwohl nur ein Block vergangen war, behandelt das Protokoll jede Ausgabenänderung als täglichen Abrechnungszeitraum, sodass ein Zinszeitraum auf das aufgeblähte Kapital einlösbar wurde.

• Schritt 4: In der Einlösungstransaktion lieh sich der Angreifer 730.607,755349 USDC über PoolManager, übertrug 3.440,992868 USDC direkt an das LPD/USDC-Paar und rief sync() auf. Im ursprünglichen Reservezustand hätten die aufgeblähten Zinsen mehr LP-Token erfordert, als LpdFi hielt, sodass die Einlösung rückgängig gemacht worden wäre. Durch Erhöhung der erfassten USDC-Reserve des Paares von 718.619,888284 auf 722.060,881152 reduzierte der Angreifer den LP-Betrag, den removeLp() verbrennen musste, und brachte ihn innerhalb des tatsächlichen LP-Guthabens des Protokolls.

• Schritt 5: Der Angreifer rief claimInterest(0) auf. Das aufgeblähte Kapital ergab 701.623,66 USDC an einlösbaren Zinsen für eine Ausgabe. Nach der Reservemanipulation musste removeLp() nur noch 1.678.049,359669 LP-Token verbrennen, was nahezu dem gesamten LP-Guthaben von LpdFi entsprach. Das Protokoll verbrannte etwa 97 % des gesamten LP-Angebots, übertrug 693.529,790711 USDC an den Angreifer, und der Angreifer zahlte den Flash Loan zurück und transferierte den Gewinn.

Fazit

Dieser Vorfall resultierte aus der Verwendung manipulierbarer AMM-Spot-Reserven als einzige Wahrheitsquelle für sowohl die Order-Buchführung als auch die Einlösung. Bewertung und Einlösung wurden als unabhängige Vorgänge behandelt, die denselben aktiven Pool lesen, sodass ein zum manipulierten Preis erfasstes Kapital niemals mit der tatsächlichen Deckung des Pools abgeglichen wurde.

Das Protokoll sollte aktive AMM-Reserven nicht als einzige Wahrheitsquelle für Order-Kapital oder Auszahlungsbuchführung verwenden. Sicherere Designs bewerten jede Einzahlung über eine manipulationsresistente Preisquelle, wie einen zeitgewichteten Durchschnittspreis mit Aktualitäts- und Abweichungsprüfungen, anstatt einer Spot-Bewertung, und erzwingen eine Solvenzprüfung vor der Einlösung, damit ein Anspruch niemals mehr Deckung verbrennen kann, als die Position tatsächlich beigetragen hat.

Weitere Vorfälle dieser Woche

Moke Token

Am 3. August 2026 wurde Moke Token auf der BNB Chain für ungefähr 906.000 USD durch Spot-Preisabhängigkeit in Kombination mit duplizierter LP-Buchführung ausgenutzt. Der Angreifer manipulierte einen Spot-Preis, um die Menge an einlösbaren MOKE aufzublähen, übertrug sie in den LP-Dividendenvertrag, löste den Dividendenprozess aus, um das MOKE gegen BNB zu verkaufen, und sammelte dann das BNB über duplizierte LP-Einträge ein.

Hintergrund

Moke Token ist ein BNB-Chain-Ökosystem, das auf Nutzerbeteiligung, verzögerter MOKE-Freigabe, LP-Rewards und Empfehlungsanreizen aufgebaut ist. Nutzer beteiligen sich mit USDT und AC. Anstatt MOKE sofort zu erhalten, gewährt jede Beteiligung eine zukünftige MOKE-Freigabe, die von MokeRelease verwaltet wird und im Laufe der Zeit einlösbar wird.

Wenn ein Nutzer einen Anspruch stellt, wandelt der Vertrag den freigegebenen USDT-Wert mithilfe des festgelegten MOKE/USDT-Preises in MOKE um und überträgt das entsprechende MOKE aus dem Reservepool an den Nutzer. Diese freigegebenen Token sind standardmäßig beschränkt und können nur an autorisierte Handler-Adressen übertragen werden, wie z. B. Verträge zum Hinzufügen von Liquidität. Nutzer, die LP-Token halten, erhalten dann BNB-Ausschüttungen aus den Steuer- und Dividendenpools des Protokolls basierend auf ihrem LP-Anteil.

Schwachstellenanalyse

Die fehlerhaften Verträge sind 0x684d...b302a7 und 0x5ae5...eba377.

Die erste Grundursache ist die Spot-Preisabhängigkeit. getMokeUsdtPrice() leitet den MOKE/USDT-Preis aus den WBNB/USDT- und WBNB/MOKE-Paaren ab, ohne manipulationsresistente Preisquelle:

Die zweite Grundursache ist die duplizierte LP-Buchführung. _syncUserLP() erfasst das LP-Guthaben eines Nutzers, indem es lpToken.balanceOf(user) in userLPRecord[user] einliest. Da die Aktualisierung manuell ausgelöst wird und nur auf dem aktuellen Guthaben basiert, können dieselben LP-Token über mehrere Adressen verschoben und bei jeder synchronisiert werden, wodurch das gesamte erfasste LP-Guthaben und die damit verdienten Dividenden-Rewards aufgebläht werden:

Angriffsanalyse

Die folgende Analyse basiert auf den Transaktionen 0xc0f1df...e26154 und 0x077604...756a8f.

• Schritt 1: Etwa 10 Tage vor dem Exploit bereitete der Angreifer ein Freigabe-Kontingent vor, indem er USDT über die participate-Funktion in MokeVault einzahlte und ein MOKE-Freigabe-Kontingent im Wert von 45.000 USDT erhielt, das täglich zu 5,5 % freigeschaltet wurde.

• Schritt 2: Der Angreifer prägte MOKE/WBNB-LP-Token und rief syncUserLP in MokeLPDividend auf, um das LP-Guthaben zu erfassen, übertrug dann dieselben LP-Token an eine andere Adresse und wiederholte die Synchronisierung, wodurch duplizierte LP-Einträge für einen Satz von Token erstellt wurden.

• Schritt 3: Der Angreifer nutzte Flash Loans, um eine große Menge BNB zu leihen und tauschte sie im WBNB/USDT-Paar gegen USDT, wodurch der Spot-Preis von USDT in die Höhe getrieben wurde. Der Angreifer aktualisierte dann den MOKE-Preis in MokeRelease, und der festgelegte MOKE-Preis fiel stark.

• Schritt 4: Mit dem manipulierten MOKE-Preis rief der Angreifer claim in MokeRelease auf und löste ein Kontingent im Wert von 24.766 USDT für MOKE-Token ein, wobei er weit mehr MOKE erhielt, als dem tatsächlichen Wert des Kontingents entsprach.

• Schritt 5: Der Angreifer übertrug das freigegebene MOKE in den auf der Whitelist stehenden MokeLPDividend-Vertrag und rief distributeDividend auf, wodurch das MOKE gegen BNB verkauft wurde. Der Angreifer nutzte dann die Adressen, die duplizierte LP-Guthaben erfasst hatten, um claimDividend aufzurufen und das verteilte BNB einzusammeln, wobei insgesamt 1.546 BNB erhalten wurden.

Fazit

Moke Token kombinierte zwei unabhängige Schwachstellen: einen Spot-Preis, der mit einem Flash Loan verschoben werden konnte, und eine Dividendenbuchführung, die dieselben LP-Token mehr als einmal zählte. Keine der beiden allein wäre so schädlich gewesen wie beide zusammen.

Protokolle sollten momentane Spot-Preise für sicherheitskritische Berechnungen vermeiden und stattdessen eine manipulationsresistente Quelle verwenden. Jede auf Token-Guthaben basierende Buchführung muss zusammen mit den Guthabenänderungen selbst aktualisiert werden, damit dieselben Token nicht über mehrere Adressen hinweg gezählt werden können.