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
~$4.72M Lost: TAC, Transit Finance & More | BlockSec Weekly
Security Insights

~$4.72M Lost: TAC, Transit Finance & More | BlockSec Weekly

This BlockSec weekly security report covers 3 notable attack incidents identified between May 11 and May 17, 2026, across TRON, TON, and Ethereum, with total estimated losses of approximately $4.72M. Three incidents are analyzed in detail: the highlighted $1.88M Transit Finance exploit on TRON, where a deprecated swap bridge contract with lingering token approvals was exploited through arbitrary calldata forwarding; the $2.8M TAC TON-to-EVM bridge exploit caused by missing canonical wallet verification in the jetton deposit flow; and the $46.75K Boost Hook exploit on Ethereum, where spot price manipulation on a Uniswap V4 hook-based perpetual protocol forced the protocol to buy tokens at inflated prices using its own reserves.

~$15.9M Lost: Trusted Volumes, Wasabi & More | BlockSec Weekly
Security Insights

~$15.9M Lost: Trusted Volumes, Wasabi & More | BlockSec Weekly

This BlockSec bi-weekly security report covers 11 notable attack incidents identified between April 27 and May 10, 2026, across Sui, Ethereum, BNB Chain, Base, Blast, and Berachain, with total estimated losses of approximately $15.9M. Three incidents are analyzed in detail: the highlighted $1.14M Aftermath Finance exploit on Sui, where a signed/unsigned semantic mismatch in the builder-fee validation allowed an attacker to inject a negative fee that was converted into positive collateral during settlement; the $5.87M Trusted Volumes RFQ authorization mismatch on Ethereum; and the $5.7M Wasabi Protocol infrastructure-to-contract-control compromise across multiple EVM chains.

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

Best Security Auditor for Web3

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

BlockSec Audit