Analyse des FEGtoken-Sicherheitsvorfalls: Der Teufel steckt im Detail

Am 15. Mai 2022, gegen 20:20 Uhr (UTC), stellte unser Überwachungssystem fest, dass der FEGexPRO-Vertrag des FEGtoken-Projekts gehackt wurde. Der Angreifer startete eine Reihe von Angriffen sowohl im ETH- als auch im BSC-Mainnet, wobei der Gesamtwert etwa 1,3 Millionen US-Dollar betrug (gemäß der On-Chain-Nachricht, die vom Projekt gesendet wurde).

Weitere Informationen zu diesem Vorfall finden Sie auf dem offiziellen Twitter-Account dieses Projekts. In diesem Bericht werden wir die Details untersuchen, um die Grundursache dieses Vorfalls aufzudecken.

0x1 Schwachstellenanalyse: Auf den ersten Blick

Der anfällige FEGexPRO-Vertrag ist sowohl auf ETH als auch auf BSC bereitgestellt, und die anfällige Funktion des Vertrags ist swapToSwap, wie folgt:

Wie in den sozialen Medien hervorgehoben, kann der erste Parameter namens path der swapToSwap-Funktion vom Aufrufer der Funktion spezifiziert werden. Daher konnte der Angreifer dies ausnutzen, um eine willkürliche Genehmigung vorzunehmen (siehe Zeile 682 der swapToSwap-Funktion).

Bis jetzt ist nichts Neues, da es sich wieder einmal um einen Fall von nicht überprüften Parametern handelt. Die Angriffspur deutet jedoch darauf hin, dass dieser Angriff nicht einfach durch willkürliche Genehmigung klar dargestellt werden kann. Tatsächlich gibt es einen subtilen Trick, und hier wird es interessant.

0x2 Angriffsanalyse

0x2.1 Vorläufige Angriffsanalyse

Wir nehmen eine Angriffstransaktion auf BSC als Beispiel, um das Angriffsverfahren zu veranschaulichen, und die entsprechende Angriffspur, die auf den Vermögenswert fBNB abzielt, wird kurz zusammengefasst:

• Schritt 1: Vorbereitung von Geldern und gefälschten paths. Der Angreifer leiht sich einen Flashloan von etwa 915 BNB von DVM und tauscht einen Teil davon in 116 fBNB. Der Angreifer erstellt dann eine Reihe von Verträgen, die als gefälschte paths verwendet werden.
• Schritt 2: Einzahlung des Anfangsgeldes. Durch die Einzahlung von 115 fBNB in den FEGexPRO-Vertrag erhöht der Angreifer seinen balances2 im Opfervertrag.
• Schritt 3: Durchführung der willkürlichen Genehmigung. Der Angreifer ruft dann die swapToSwap-Funktion auf und übergibt einen gefälschten path als ersten Parameter, was dazu führt, dass der FEGexPRO-Vertrag den path zum Ausgeben von 114 fBNB genehmigt.
• Schritt 4: Vornehmen einer weiteren Genehmigung durch Aufrufen der depositInternal-Funktion und der swapToSwap-Funktion. Der FEGexPRO-Vertrag genehmigt einen weiteren path zum Ausgeben von 114 fBNB.

Der Angreifer führt Schritt 4 wiederholt aus, um weitere Genehmigungen zu erhalten. Schließlich verwendet der Angreifer die genehmigten gefälschten paths, um alle fBNB von FEGexPRO abzuzweigen und einige davon in BNB zu tauschen, um den Flashloan zurückzuzahlen.

Offensichtlich können wir leicht erkennen, dass der Vertrag den path-Parameter unbedingt hätte überprüfen müssen.

JEDOCH gibt es, um diesen Angriff vollständig zu verstehen, ein weiteres Problem zu klären: Selbst wenn der FEGexPRO-Vertrag den gefälschten path genehmigt, basiert die approve-Operation auf der Tatsache, dass der balances2 des Benutzers sofort verringert wird (Zeile 684 der swapToSwap-Funktion), d.h. das genehmigte Geld stammt aus genau dem Betrag, der in Schritt 3 eingezahlt wurde. Mit anderen Worten, der Angreifer genehmigt nur das Geld seines eigenen eingezahlten Geldes an den gefälschten path. Danach sollte der Angreifer aufgrund der Verringerung von balances2 keine Genehmigungen für andere gefälschte paths vornehmen.

Daher stellt sich die Frage: Was genau hat der Angreifer gespielt, um weitere Genehmigungen zu erhalten und zusätzlichen Gewinn zu erzielen?

0x2.2 Fortgeschrittene Angriffsanalyse

Um die Frage zu beantworten, kehren wir zur swapToSwap-Funktion zurück. Nach sorgfältiger Prüfung des Codes haben wir festgestellt, dass der hier gespielte Trick nicht nur ein gefälschter path, sondern auch ein gefälschter swap ist, was zu einer Inkonsistenz zwischen dem tatsächlichen Wert und dem aufgezeichneten Wert des Guthabens des Opfervertrags führt. Infolgedessen kann die Inkonsistenz genutzt werden, um die Genehmigung wiederholt durch Aufrufen der depositInternal-Funktion zu erteilen und so den Einzahlungsbetrag des Angreifers wiederherzustellen.

Insbesondere modifiziert die depositInternal-Funktion das balances2 eines Benutzers hauptsächlich basierend auf der Differenz zwischen Main.balanceOf des Vertrags und _totalSupply2 (Zeile 651 der depositInternal-Funktion).

Da die an swapToSwap übergebene path-Adresse ein vom Angreifer kontrollierter gefälschter path ist, wird tatsächlich nichts übertragen. Infolgedessen bleibt der Rückgabewert von Main.balanceOf derselbe wie in Schritt 3. Beachten Sie, dass _totalSupply2 in der swapToSwap-Funktion verringert wurde, solange der Angreifer einzahlt, wird das erhöhte balance2 zwangsläufig größer sein als der tatsächlich eingezahlte Betrag.

Daher stellt der Angreifer in Schritt 4 zunächst den Einzahlungsbetrag wieder her, indem er die depositInternal-Funktion aufruft, und nimmt dann die Genehmigung und den gefälschten swap vor, indem er die swapToSwap-Funktion aufruft. Beachten Sie, dass der vom Angreifer verwendete Einzahlungsbetrag nur fast 0 (d.h. 1 / 1e18) fBNB beträgt, sodass die depositInternal-Funktion das balances2 des Angreifers auf fast den gleichen Betrag wie in Schritt 3 wiederherstellt, wie oben erläutert (was auch durch die Spur der nächsten Genehmigung belegt wird).

Der Angreifer kann die Ernte vergrößern, indem er Schritt 4 wiederholt ausführt.

Schließlich ist erwähnenswert, dass der oben beschriebene Angriff nur einer der vom Angreifer ausgenutzten Angriffspfade ist. Allein in derselben Angriffstransaktion hat der Angreifer auch den Vermögenswert FEG ins Visier genommen:

0x3 Die Grundursache

Hier fassen wir die Grundursache dieses Angriffs zusammen:

• Erstens die willkürliche Genehmigung, die durch den nicht überprüften Parameter in der swapToSwap-Funktion verursacht wurde.
• Zweitens die Inkonsistenz zwischen dem tatsächlichen Wert und dem aufgezeichneten Wert des Guthabens des Opfervertrags aufgrund des gefälschten swaps in der swapToSwap-Funktion. Dies wurde verwendet, um die Genehmigungen wiederholt zu erteilen, indem der Einzahlungsbetrag des Angreifers wiederhergestellt wurde.

Durch die Kombination dieser beiden Faktoren konnte der Angreifer erfolgreich alle Gelder aus dem Opfervertrag abziehen.

0x4 Andere verwandte Angriffe

Zum Zeitpunkt der Erstellung dieses Berichts haben wir auch weitere verwandte Angriffe eines anderen Angreifers beobachtet.

Erneut wurden Verträge, die sowohl auf Ethereum als auch auf BSC bereitgestellt wurden, angegriffen. Interessanterweise unterscheiden sich die Angriffspfade von dem, den wir gerade besprochen haben. Obwohl die Opferverträge nicht Open-Source sind, vermuten wir stark, dass der Angreifer die gleiche Schwachstelle mit einer ähnlichen Angriffsmethode ausgenutzt hat.

0x5 Fazit

Die Sicherung eines DeFi-Projekts ist keine leichte Aufgabe. Neben der Code-Prüfung sind wir der Meinung, dass die Community proaktive Maßnahmen ergreifen sollte, um den Projektstatus zu überwachen, und den Angriff blockieren sollte, bevor er überhaupt stattfindet (block the attack before it even takes place).

Über BlockSec

BlockSec ist ein wegweisendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit der aufkommenden Web3-Welt, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Audits für Smart Contracts und EVM-Ketten, die Phalcon-Plattform für die Entwicklung von Sicherheitsmaßnahmen und die proaktive Blockierung von Bedrohungen, die MetaSleuth-Plattform für die Nachverfolgung und Untersuchung von Geldern sowie die MetaDock-Erweiterung für Web3-Entwickler zum effizienten Surfen in der Krypto-Welt an. Bis heute hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden von führenden Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital Millionen von US-Dollar erhalten.

Offizielle Website: https://blocksec.com/ Offizieller Twitter-Account: https://twitter.com/BlockSecTeam