Nr. 6: Der Hundred Finance-Vorfall: Katalysator für die Welle präzisionsbezogener Exploits in anfälligen Fork-Protokollen

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

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

Compound V2, laut DeFiLlama das am häufigsten geforkte Lending-Protokoll, kann auf über 100 Forks verweisen. Seine Verträge wurden von OpenZeppelin geprüft und haben sich in der Praxis bewährt und gelten als sicher. Der Angriff auf Hundred Finance verdeutlichte jedoch, wie Präzisionsverluste, insbesondere bei geringer Liquidität, die Sicherheit von DeFi-Protokollen kritisch beeinträchtigen können, was eine Welle ähnlicher Exploits bei bekannten Forks wie Midas und Radiant auslöste.

Für ein tieferes Verständnis wird empfohlen, die vollständige Analyse zu lesen. Im Folgenden bieten wir eine prägnante 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 auf mehreren Mainnets operiert und Chainlink-Oracles verwendet. Im Gegensatz zu traditionellen Finanzkreditpraktiken erlauben DeFi-Kreditprotokolle wie Compound und Aave keine überbesicherten Kredite (Anm. d. Ü.: gemeint ist die Kreditvergabe ohne hinreichende Sicherheiten). Einfach ausgedrückt: Wenn Sie Token A im Wert von 100 $ einzahlen, können Sie nur Vermögenswerte im Wert von weniger als 100 $ leihen. Gemäß den Risikokontrollkoeffizienten der meisten Protokolle liegt dieses Verhältnis typischerweise zwischen 50 % und 80 %.

Zu den gängigen Angriffsmethoden für Kreditprotokolle gehören Preismanipulation und Reentrancy. Interessanterweise war Hundred Finance bereits im März 2022 von einem Reentrancy-Angriff betroffen, aber dieser Vorfall schuf einen neuen Angriffsvektor.

hToken

Kreditprotokolle, die von Compound und Aave forken, erstellen für jeden zugrunde liegenden Token (Sicherheit) einen entsprechenden Accounting-Token. Für Hundred Finance gilt:

USDC entspricht hUSDC
WBTC entspricht hWBTC

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

Beim Einzahlen von Vermögenswerten sollten Benutzer die mint()-Funktion des hTokens aufrufen.
Beim Abheben von Vermögenswerten sollte der Benutzer die redeem()-Funktion des hTokens aufrufen.

exchangeRate

Das Folgende ist die Formel zur Berechnung des exchangeRate:

Wobei:

getCash(): Der Betrag des zugrunde liegenden Token-Guthabens, das sich im Besitz dieses hToken-Vertrags befindet. Dies ist ein Schlüsselparameter, der manipuliert werden kann. Bitte merken Sie sich das.
totalBorrows(): Der Betrag des zugrunde liegenden Tokens, der derzeit vom Markt verliehen ist und auf den Zinsen an die Anbieter des Marktes gutgeschrieben werden.
totalReserves(): Reserven sind ein Buchhaltungseintrag in jedem hToken-Vertrag, der einen Teil der historischen Zinsen darstellt, die als Bargeld beiseitegelegt wurden; diese können durch die Governance des Protokolls abgehoben oder übertragen werden.
totalSupply(): Die Anzahl der Token, die derzeit in diesem hToken-Markt im Umlauf sind.

Hinweis: Der exchangeRate zwischen einem hToken und dem zugrunde liegenden Vermögenswert (z. B. Dai vs. hDai oder Eth vs. hEth) beginnt bei 0,020 und steigt mit einer Rate, die dem Zinseszinssatz des Marktes entspricht.

Liquidation

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

Alice hinterlegt BTC im Wert von 100 $ und leiht sich ETH im Wert von 70 $.
Wenn der Preis für ETH steigt oder der Preis für BTC fällt, kann Alices Vermögen den Liquidationsschwellenwert erreichen.
Bob kann eine bestimmte Menge ETH verwenden, um Alices BTC zu liquidieren und Alices Schulden wieder auf ein gesundes Niveau zu bringen, um die Sicherheit der Gelder des Protokolls zu gewährleisten (das Protokoll belohnt Benutzer, die eine Liquidation einleiten).

Die Liquidation steht nicht im Mittelpunkt dieses Angriffs, war aber in den Angriff involviert. Hier müssen wir nur wissen, dass jeder Benutzer die Schulden eines anderen Benutzers mit einer Token-Art liquidieren kann, was den entsprechenden hToken reduziert.

Die Schwachstelle

Präzisionsverlustproblem

Der Hacker sorgt dafür, dass bei der Abhebung von Sicherheiten durch redeem() die Berechnung des abzuziehenden Betrags an hToken 1,99999992 ergibt (sehr nahe an 2, aber weniger als 2). Bei der Umwandlung in eine Ganzzahl in truncate() führt das Abrunden zu einem Endergebnis von 1.

exchangeRate

Die Berechnung des exchangeRate, wie bereits eingeführt, beinhaltet getCash(), welches sich auf den Betrag des zugrunde liegenden Guthabens bezieht, das sich im Besitz des hToken-Vertrags befindet. Durch das direkte Übertragen von zugrunde liegenden Token in den Vertrag (ohne mint, einfach durch Überweisung) kann der Hacker den exchangeRate manipulieren. Es ist jedoch wichtig zu beachten, dass dieses Wechselkursproblem allein die Sicherheit des Protokolls nicht gefährdet; Hacker können isoliert nicht davon profitieren. Im Kontext dieses Angriffs wurde es hauptsächlich ausgenutzt, um die Gewinne des Hackers zu vervielfachen, was es ihm ermöglichte, den Pool schnell zu leeren. Andernfalls würde sich der Angriff von einem einzigen, entscheidenden Schlag zu einer Reihe kleinerer Stiche entwickeln, die zahlreiche Iterationen erfordern würden, um eine signifikante Wirkung zu erzielen.

Kurz gesagt, der Präzisionsverlust ist das Hauptproblem bei diesem Angriff.

Der Angriffsprozess

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

Transaktion: 0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451

Leihen Sie 500 WBTC von Aave V3 durch einen Flashloan.
Redeem Sie alle zuvor erworbenen hWBTC, setzen Sie den totalSupply von hWBTC auf 0 zurück.

Das Ziel davor ist es, Reservemittel mittels Flashloan vorzubereiten und hWBTC als neuen Markt zurückzusetzen.

Erstellen Sie den zweiten Angriffsvertrag (im Folgenden als Angriffsvertrag 2 bezeichnet) und übertragen Sie alle WBTC (500,30063816 WBTC) auf Angriffsvertrag 2.
Mint() hWBTC unter Verwendung von 4 WBTC, um 200 hWBTC zu erzeugen.
Redeem() 199,99999998 hWBTC, wodurch der hWBTC-Gesamtbetrag auf 0,00000002 (2 Wei hWBTC) sinkt.
Übertragen Sie alle WBTC (500,30063816 WBTC) in hWBTC. Beachten Sie, dass direkte Übertragungen hWBTC nicht erhöhen; es kann als Spende von WBTC an den Pool angesehen werden. Der Hauptzweck dieses Schrittes ist es, den zuvor erwähnten exchangeRate zu manipulieren. An diesem Punkt bleibt der totalSupply von hWBTC bei 2 Wei hWBTC, aber es sind nun 500,30064194 WBTC vorhanden, was den exchangeRate auf das Hundertfache des ursprünglichen Wertes ansteigen lässt.
Leihen Sie 1021 Ether aus dem hETH-Markt.
Redeem() 50030063815 WBTC, wobei nach der Berechnung eigentlich 1,9999992 hBTC abgezogen werden sollten, aber aufgrund des Präzisionsverlusts wird nur 1 hBTC abgezogen, was einen signifikanten Präzisionsverlust (fast 50 %) erzeugt. An diesem Punkt hat der Hacker 500 WBTC + 1021 Ether und damit erfolgreich 1021 Ether gewonnen.
Der Angreifer führt liquidate() auf die verbleibenden hWBTC aus, wodurch dessen totalSupply auf 0 zurückgesetzt wird, um sich auf die Fortsetzung der Angriffe auf andere Märkte vorzubereiten. Da fast alle WBTC innerhalb von hWBTC abgehoben wurden, schafft der Hacker dies mit nur 0,000002 Ether.
Fahren Sie mit dem Angriff auf andere Märkte fort und entleeren Sie das gesamte Protokoll.
Zahlen Sie den Flashloan an Aave zurück.

Sicherheitsempfehlungen

Schadensbegrenzung für Kreditprotokolle

Dieses Problem ist weit verbreitet, insbesondere bei Forks von Compound und Aave. Ein proaktiver Ansatz besteht darin, bei der Einführung neuer Märkte einen Accounting-Token zu minten, um sicherzustellen, dass der totalSupply niemals auf 0 geht.

Schadensbegrenzung für das Problem des Präzisionsverlusts

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