Analyse des FEGtoken-Sicherheitsvorfalls: Der Teufel steckt im Detail

Am 15. Mai 2022 um ca. 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, und der Gesamtwert betrug etwa 1,3 Millionen US-Dollar (laut 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 uns mit den Details befassen, 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 Funktion swapToSwap vom Aufrufer der Funktion angegeben werden. Daher konnte der Angreifer dies ausnutzen, um eine willkürliche Genehmigung zu erhalten (siehe Zeile 682 der Funktion swapToSwap).

Bisher ist nichts Neues, da es sich erneut 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 existiert ein subtiler Trick, und hier wird es interessant.

0x2 Angriffsanalyse

0x2.1 Vorläufige Angriffsanalyse

Wir nehmen eine Angriffstransaktion auf BSC als Beispiel, um das Angriffsprotokoll zu veranschaulichen, und die entsprechende Angriffspur, die auf das Asset 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 Funktion swapToSwap auf und übergibt einen gefälschten path als ersten Parameter, was dazu führt, dass der FEGexPRO-Vertrag 114 fBNB zum Ausgeben von path genehmigt.
• Schritt 4: Durchführung einer weiteren Genehmigung durch Aufrufen der Funktionen depositInternal und swapToSwap. Der FEGexPRO-Vertrag genehmigt einen weiteren path zum Ausgeben von 114 fBNB.

Der Angreifer startet Schritt 4 wiederholt, um weitere Genehmigungen zu erhalten. Schließlich nutzt der Angreifer die genehmigten gefälschten paths, um das gesamte fBNB von FEGexPRO abzuschöpfen und einen Teil davon in BNB umzutauschen, um den Flashloan zurückzuzahlen.

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

ALLERDINGS, um diesen Angriff vollständig zu verstehen, gibt es noch ein weiteres Problem zu behandeln: Selbst wenn der FEGexPRO-Vertrag den gefälschten path genehmigt, basiert die approve-Operation auf der Tatsache, dass die balances2 des Benutzers sofort reduziert werden (Zeile 684 der Funktion swapToSwap), d. h. die genehmigten Mittel stammen aus genau dem im Schritt 3 eingezahlten Betrag. Mit anderen Worten, der Angreifer genehmigt nur die ihm/ihr gehörenden eingezahlten Mittel für den gefälschten path. Danach sollte der Angreifer aufgrund der Verringerung von balances2 keine Genehmigungen für andere gefälschte paths erteilen.

Daher stellt sich die Frage: Was ist der genaue Trick, den der Angreifer anwendet, um weitere Genehmigungen zu erhalten und zusätzlichen Gewinn zu erzielen?

0x2.2 Fortgeschrittene Angriffsanalyse

Um die Frage zu beantworten, kehren wir zur Funktion swapToSwap zurück. Nach sorgfältiger Prüfung des Codes stellten wir fest, dass der hier angewandte Trick nicht nur ein gefälschter path ist, sondern auch ein gefälschter swap, 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 zu erteilen, indem die Funktion depositInternal aufgerufen wird, um den Einzahlungsbetrag des Angreifers wiederherzustellen.

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

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

Daher stellt der Angreifer in Schritt 4 zuerst den Einzahlungsbetrag wieder her, indem er die Funktion depositInternal aufruft, und führt dann die Genehmigung und den gefälschten swap durch, indem er die Funktion swapToSwap aufruft. Beachten Sie, dass der vom Angreifer verwendete Einzahlungsbetrag nur fast 0 (d. h. 1 / 1e18) fBNB beträgt, sodass die Funktion depositInternal die balances2 des Angreifers auf fast denselben Betrag wie in Schritt 3 wiederherstellen würde, 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 anzumerken, dass der oben beschriebene Angriff nur einer der Angriffspfade ist, die vom Angreifer ausgenutzt wurden. In derselben Angriffstransaktion zielte der Angreifer auch auf das Asset FEG ab:

0x3 Die Grundursache

Hier fassen wir die Grundursache dieses Angriffs zusammen:

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

Durch die Kombination dieser beiden Faktoren gelang es dem Angreifer, alle Gelder aus dem Opfervertrag abzuschöpfen.

0x4 Weitere verwandte Angriffe

Zum Zeitpunkt der Erstellung dieses Berichts haben wir auch weitere verwandte Angriffe von einem anderen Angreifer beobachtet.

Auch hier wurden Verträge, die sowohl auf Ethereum als auch auf BSC bereitgestellt wurden, angegriffen. Interessanterweise unterscheiden sich die Angriffspuren von der gerade besprochenen. Obwohl die Opferverträge nicht Open-Source sind, vermuten wir stark, dass der Angreifer dieselbe Schwachstelle mit einer ähnlichen Angriffsmethode ausgenutzt hat.

0x5 Erkenntnis

Ein sicheres DeFi-Projekt zu schaffen ist keine leichte Aufgabe. Neben der Code-Prüfung glauben wir, dass die Community proaktiv den Projektstatus überwachen sollte, um den Angriff zu blockieren, bevor er überhaupt stattfindet.

Über BlockSec

BlockSec ist ein führendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen widmet sich der Verbesserung der Sicherheit und Benutzerfreundlichkeit für die aufstrebende Web3-Welt, um deren breite Akzeptanz zu fördern. Zu diesem Zweck bietet BlockSec Dienstleistungen für Smart Contract- und EVM-Chain-Sicherheitsaudits, die Phalcon-Plattform für die proaktive Entwicklung und Abwehr von Bedrohungen, die MetaSleuth-Plattform für die Nachverfolgung und Untersuchung von Geldern sowie die MetaDock-Erweiterung für Web3-Entwickler, um effizient in der Kryptowelt zu surfen.

Bis heute hat das Unternehmen über 300 angesehene Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und in zwei Finanzierungsrunden von namhaften Investoren wie Matrix Partners, Vitalbridge Capital und Fenbushi Capital zehn Millionen US-Dollar erhalten.

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