Am 2. Januar 2021 (07:25 Uhr Pekinger Zeit) meldete unser Überwachungssystem ThunderForecast eine Reihe verdächtiger Transaktionen in Richtung des yCREDIT Smart Contracts. Anschließend nutzten wir das von unserem Forschungsteam entwickelte EthScope-System, um diese Transaktionen zu analysieren und zu bestätigen, dass alle gemeldeten Transaktionen bösartig waren. In diesem Blog erläutern wir die Details des Angriffs.
Details
Der Angriff ist auf die Inkonsistenz der Anzahl der geprägten Token mit der beabsichtigten Anzahl zurückzuführen. Daher kann der Angreifer zu einem niedrigeren Preis deutlich mehr yCREDIT-Token erhalten. Diese Token können dann mit Gewinn verkauft werden.
Die anfällige Funktion befindet sich in der _deposit-Funktion des StableYieldCredit Contracts.
Im Folgenden werden wir eine Angriffstransaktion verwenden, um den gesamten Prozess zu veranschaulichen.
Der Angreifer übertrug zunächst 1e-8 WBTC und 331,335 yCredit-Token in den WBTC-yCREDIT Pair Pool. Dann zahlte der Angreifer 0,5 WBTC in den StableYieldCredit-Contract ein, um den Angriff zu starten.
Speziell wird der _value mit dem amount (0,5) des token (0x2260fac5e5542a773aa44fbcfedf7c193bc2c599 - WBTC) basierend auf dem Preis-Oracle-Anbieter ChainLink berechnet (Zeile 480, _value ist 1466786010075). Die Absicht ist, den Wert des eingezahlten WBTC in USD zu berechnen. Dann wird der Contract die Anzahl der yCREDIT-Token (_value - fee) an denjenigen übertragen, der den WBTC eingezahlt hat (den Angreifer). Das liegt daran, dass der Wert von yCREDIT gleich einem USD ist (wie vom System vorgesehen). Alles ist in Ordnung, abgesehen davon, dass der Angreifer einen kleinen Betrag an fee verliert.
Darüber hinaus wird der Contract den eingezahlten WBTC dem WBTC-yCREDIT Pair Pool hinzufügen. Das liegt daran, dass der eingezahlte WBTC an Liquidität verlieren würde, wenn er im Contract gesperrt wäre. Daher wurde zunächst der Wert des Token-Paares (WBTC zu yCREDIT), das in den Pool eingebracht werden soll, berechnet. Dieser Wert wird mit der Funktion _addLiquidity berechnet. Grundsätzlich wird er basierend auf den bestehenden Reserven im Pool berechnet. Da der Pool nur 1e-8 WBTC und 331,335 yCREDIT-Token enthält, beträgt der berechnete amountA 44 (amountB ist 1466786010075). Das bedeutet, der Angreifer gibt nur 44e-8 WBTC aus (Zeile 485) und erhält 14667,86010075 - fee = 14594,52080025 yCREDIT-Token (Zeile 493). Gleichzeitig verlassen eine kleine Menge WBTC (1e-8 + 44e-8) und (331,335 + 14667,86010075) yCREDIT-Token den Pool.
Um Gewinne zu erzielen, kann der Angreifer die erhaltenen 14594,52080025 yCREDIT-Token einfach an Börsen handeln. Interessanterweise ist der Prozess zur Gewinnmitnahme in dieser Transaktion weitaus komplizierter als nötig. Wir haben auch eine clevere Angriffsstrategie in anderen Transaktionen beobachtet.
An dem Angriff sind eine Reihe von Transaktionen beteiligt, darunter (aber nicht beschränkt auf) die folgenden.
Update
03.01.2020: Es gibt einen neuen Smart Contract, der die Schwachstelle behebt.
Zeitplan
- 01.01.2021 23:25 UTC, Angriffe wurden von unserem System erfasst
- 02.01.2021 16:20 UTC, dieser Blog wird veröffentlicht
