Back to Blog

#6: Hundred Finance Vorfall: Katalysator für Präzisionsangriffe auf anfällige Protokoll-Forks

Code Auditing
February 16, 2024
7 min read

Am 16. April 2023 wurde Hundred Finance, ein Fork von Compound V2, angegriffen, was zu einem Verlust von rund 7,4 Millionen US-Dollar führte. Der Angriff beinhaltete zwei Hauptprobleme:

  • Ein Präzisionsverlustproblem (ein fehlerhaftes Rundungsproblem);
  • Leere Märkte, die es dem Hacker ermöglichten, den exchangeRate zu manipulieren.

Compound V2, das meistgeforkte Kreditprotokoll laut DeFiLlama, kann mit über 100 Forks aufwarten. Geprüft von OpenZeppelin und im Kampf erprobt, gelten seine Verträge als sicher. Dennoch hat der Angriff auf Hundred Finance gezeigt, wie Präzisionsverluste, insbesondere bei geringer Liquidität, die Sicherheit von DeFi-Protokollen kritisch beeinträchtigen können und eine Welle ähnlicher Exploits bei namhaften Forks wie Midas und Radiant auslösten.

Für ein tieferes Verständnis wird empfohlen, die vollständige Analyse zu konsultieren. Nachfolgend bieten wir eine knappe Einführung in diesen Vorfall und heben ihn als einen der zehn wichtigsten Sicherheitsvorfälle des Jahres 2023 hervor.

Hintergrund

Überblick über Hundred Finance

Hundred Finance ist ein Fork von Compound v2, der über mehrere Mainnets hinweg agiert und Chainlink-Orakel nutzt. Im Gegensatz zu traditionellen Kreditpraktiken erlauben DeFi-Kreditprotokolle wie Compound und Aave keine überbesicherten Kredite. Einfach ausgedrückt: Wenn Sie Token A im Wert von 100 US-Dollar einzahlen, können Sie nur Vermögenswerte im Wert von weniger als 100 US-Dollar ausleihen. Laut den Risikokontrollkoeffizienten der meisten Protokolle liegt dieses Verhältnis typischerweise zwischen 50 % und 80 %.

Für Kreditprotokolle gehören Preismanipulation und Reentrancy zu den gängigen Angriffsmethoden. Interessanterweise hatte Hundred Finance bereits im März 2022 einen Reentrancy-Angriff erlebt, aber dieser Vorfall schuf einen neuen Angriffsvektor.

hToken

Kreditprotokolle, die von Compound und Aave geforkt werden, erstellen für jeden zugrunde liegenden Token (Sicherheit) einen entsprechenden Buchungstoken. Für Hundred Finance:

  • USDC entspricht hUSDC
  • WBTC entspricht hWBTC

Der Umrechnungskurs zwischen dem zugrunde liegenden Token und dem hToken wird als exchangeRate bezeichnet.

  • Bei der Einzahlung von Vermögenswerten sollten Benutzer die mint() des hToken aufrufen.
  • Beim Abheben von Vermögenswerten sollte der Benutzer die redeem() des hToken aufrufen.

exchangeRate

Die folgende Formel dient zur Berechnung des exchangeRate: image

Wo:

  • getCash(): Die Menge des zugrunde liegenden Token-Guthabens, das von diesem hToken-Vertrag gehalten wird. Dies ist ein wichtiger Parameter, der manipuliert werden kann. Bitte merken Sie sich dies.
  • totalBorrows(): Die Menge des zugrunde liegenden Tokens, die derzeit vom Markt ausgeliehen ist, und die Menge, auf der Zinsen für die Lieferanten des Marktes erhoben werden.
  • totalReserves(): Reserven sind ein Buchhaltungseintrag in jedem hToken-Vertrag, der einen Teil der historischen Zinsen darstellt, die als Bargeld beiseite gelegt werden und durch die Protokollverwaltung abgehoben oder übertragen werden können.
  • totalSupply(): Die Anzahl der derzeit im Umlauf befindlichen Token in diesem hToken-Markt.

Hinweis: Der exchangeRate zwischen einem hToken und dem zugrunde liegenden Asset, z. B. (dai vs. hDai oder eth vs. hEth), beginnt bei 0,020 und steigt mit einer Rate, die dem sich verändernden Marktzinssatz entspricht.

Liquidation

Um faule Schulden zu verhindern, erlauben Kreditprotokolle jedem Benutzer, die Schulden eines anderen Benutzers zu liquidieren. Verwenden wir das folgende Beispiel zur Veranschaulichung:

  1. Alice zahlt BTC im Wert von 100 US-Dollar ein und leiht sich ETH im Wert von 70 US-Dollar.
  2. Wenn der Preis von ETH steigt oder der Preis von BTC fällt, können Alices Vermögenswerte die Liquidationsschwelle erreichen.
  3. Bob kann eine bestimmte Menge ETH verwenden, um Alices BTC zu liquidieren und Alices Schuld wieder auf ein gesundes Niveau zu bringen, um die Sicherheit der Protokollgelder zu gewährleisten (das Protokoll belohnt Benutzer, die eine Liquidation initiieren).

Liquidation ist nicht der Schwerpunkt dieses Angriffs, war aber am Angriff beteiligt. Hier müssen wir nur wissen, dass jeder Benutzer die Schulden eines anderen Benutzers mit einer Art von Token liquidieren kann, was den entsprechenden hToken reduziert.

Die Schwachstelle

Präzisionsverlustproblem

Der Hacker bewirkt, dass bei der Auszahlung von Sicherheiten über redeem() die Berechnung der abzuziehenden hToken-Menge zu 1,99999992 führt (sehr nah an 2, aber weniger als 2). Bei der Umwandlung in eine Ganzzahl in truncate() führt die Abrundung zu einem Endergebnis von 1.

exchangeRate

Die Berechnung des exchangeRate, wie bereits eingeführt, beinhaltet getCash(), was sich auf die Menge des zugrunde liegenden Guthabens bezieht, das vom hToken-Vertrag gehalten wird. _Durch die direkte Überweisung von zugrunde liegenden Tokens in den Vertrag (ohne mint, nur Überweisung) kann der Hacker den exchangeRate manipulieren. _ Es ist jedoch wichtig zu beachten, dass dieses exchangeRate-Problem allein die Sicherheit des Protokolls nicht beeinträchtigt; Hacker können damit nicht isoliert Gewinn erzielen. Im Kontext dieses Angriffs wurde es hauptsächlich genutzt, um die Gewinne des Hackers zu verstärken und es ihm zu ermöglichen, den Pool schnell zu leeren. Andernfalls verschiebt sich der Angriff von einem einzigen, entscheidenden Schlag zu einer Reihe von kleinen Stichen, die zahlreiche Iterationen erfordern, um eine signifikante Auswirkung zu erzielen.

Kurz gesagt, der Präzisionsverlust ist das Kernproblem dieses Angriffs.

Der Angriffsprozess

Hier ist die Angriffstransaktion, und wir werden nun den Phalcon Explorer verwenden, um diese komplexe Transaktion zu analysieren.

Transaktion: 0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451

  1. Leihen von 500 WBTC von Aave V3 über einen Flashloan.

  2. Redeem() aller zuvor erworbenen hWBTC, um den totalSupply von hWBTC auf 0 zurückzusetzen.

Das Ziel ist es, vorab Reserven mit einem Flashloan vorzubereiten und hWBTC als neuen Markt zurückzusetzen.

  1. Erstellen des zweiten Angriffskontrakts (im Folgenden als Angriffskontrakt 2 bezeichnet) und Übertragung aller WBTC (500,30063816 WBTC) an Angriffskontrakt 2.

  2. Mint() von hWBTC unter Verwendung von 4 WBTC zur Erzeugung von 200 hWBTC.

  3. Redeem() von 199,99999998 hWBTC, wodurch die hWBTC-Gesamtmenge bei 0,00000002 (2 wei hWBTC) verbleibt.

  4. Übertragung aller WBTC (500,30063816 WBTC) in hWBTC. Beachten Sie, dass direkte Überweisungen hWBTC nicht erhöhen; dies kann als Spende von WBTC an den Pool betrachtet werden. Der Hauptzweck dieses Schritts ist die Manipulation des zuvor erwähnten exchangeRate. Zu diesem Zeitpunkt beträgt der totalSupply von hWBTC immer noch 2 wei hWBTC, aber es gibt nun 500,30064194 WBTC, was den exchangeRate Hunderte Male höher als den ursprünglichen Wert macht.

  5. Leihen von 1021 Ether aus dem hETH-Markt.

  6. Redeem() von 50030063815 WBTC, wobei nach der Berechnung 1,9999992 hBTC abgezogen werden sollten, aber aufgrund des Präzisionsverlusts nur 1 hBTC abgezogen wird, was zu einem erheblichen Präzisionsverlust führt (fast 50 %). Zu diesem Zeitpunkt hat der Hacker 500 WBTC + 1021 Ether, was ihm erfolgreich 1021 Ether Gewinn einbringt.

  7. Der Angreifer liquidate() die verbleibenden hWBTC, setzt deren totalSupply auf 0 zurück, um sich auf weitere Angriffe auf andere Märkte vorzubereiten. Da fast alle WBTC in hWBTC abgehoben wurden, erledigt der Hacker dies mit nur 0,000002 Ether.

  8. Fortsetzung des Angriffs auf andere Märkte, um das gesamte Protokoll zu leeren.

  9. Rückzahlung des Flashloans an Aave.

Sicherheitsempfehlungen

Abhilfemaßnahmen für Kreditprotokolle

Dieses Problem ist weit verbreitet, insbesondere bei Forks von Compound und Aave. Ein proaktiver Ansatz beinhaltet, bei der Einführung neuer Märkte etwas Buchungstoken zu prägen, um sicherzustellen, dass der totalSupply niemals auf 0 fällt.

Abhilfemaßnahmen für das Präzisionsverlustproblem

Um die Reihe von Problemen aufgrund von Präzisionsverlusten besser zu umgehen, ist die Festlegung eines Mindestwerts in der Praxis eine wirksame Methode. Diese Strategie hilft, die erheblichen Auswirkungen von Präzisionsverlusten bei sehr kleinen Werten zu vermeiden.

Lesen Sie weitere Artikel in dieser Reihe:

Sign up for the latest updates
Newsletter - April 2026
Security Insights

Newsletter - April 2026

In April 2026, the DeFi ecosystem experienced three major security incidents. KelpDAO lost ~$290M due to an insecure 1-of-1 DVN bridge configuration exploited via RPC infrastructure compromise, Drift Protocol suffered ~$285M from a multisig governance takeover leveraging Solana's durable nonce mechanism, and Rhea Finance incurred ~$18.4M following a business logic flaw in its margin-trading module that allowed circular swap path manipulatio

~$7.04M Lost: GiddyDefi, Volo Vault & More | BlockSec Weekly
Security Insights

~$7.04M Lost: GiddyDefi, Volo Vault & More | BlockSec Weekly

This BlockSec weekly security report covers eight attack incidents detected between April 20 and April 26, 2026, across Ethereum, Avalanche, Sui, Base, HyperLiquid, and MegaETH, with total estimated losses of approximately $7.04M. The highlighted incident is the $1.3M GiddyDefi exploit, where the attacker did not break any cryptography or use a flash loan but simply replayed an existing on-chain EIP-712 signature with the unsigned `aggregator` and `fromToken` fields swapped out for a malicious contract, demonstrating how partial signature coverage turns any historical signature into a generic permit. Other incidents include a $3.5M Volo Vault operator key compromise on Sui, a $1.5M Purrlend privileged-role takeover, a $413K SingularityFinance oracle misconfiguration, a $142.7K Scallop cross-pool index injection, a $72.35K Kipseli Router decimal mismatch, a $50.7K REVLoans (Juicebox) accounting pollution, and a $64K Custom Rebalancer arbitrary-call exploit.

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis
Security Insights

The Decentralization Dilemma: Cascading Risk and Emergency Power in the KelpDAO Crisis

This BlockSec deep-dive analyzes the KelpDAO $290M rsETH cross-chain bridge exploit (April 18, 2026), attributed to the Lazarus Group, tracing a causal chain across three layers: how a single-point DVN dependency enabled the attack, how DeFi composability cascaded the damage through Aave V3 lending markets to freeze WETH liquidity exceeding $6.7B across Ethereum, Arbitrum, Base, Mantle, and Linea, and how the crisis forced decentralized governance to exercise centralized emergency powers. The article examines three parameters that shaped the cascade's severity (LTV, pool depth, and cross-chain deployment count) and provides an exclusive technical breakdown of Arbitrum Security Council's forced state transition, an atomic contract upgrade that moved 30,766 ETH without the holder's signature.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit