Am 2. Januar 2021 (07:25 Uhr Pekinger Zeit) meldete unser Überwachungssystem ThunderForecast eine Reihe verdächtiger Transaktionen gegen den yCREDIT Smart Contract. Anschließend nutzten wir das von unserem Forschungsteam entwickelte System EthScope, um diese Transaktionen zu analysieren und zu bestätigen, dass alle gemeldeten Transaktionen bösartig sind. In diesem Blog erläutern wir die Angriffsdetails.
Details
Der Angriff beruht darauf, dass die Anzahl der geprägten Tokens nicht mit der beabsichtigten übereinstimmt. Dadurch kann der Angreifer deutlich mehr yCREDIT-Tokens zu einem niedrigeren Preis erhalten. Diese Tokens können dann gewinnbringend verkauft werden.
Die anfällige Funktion befindet sich in der _deposit-Funktion des StableYieldCredit-Vertrags.
Im Folgenden werden wir eine Angriffstransaktion verwenden, um den gesamten Vorgang zu veranschaulichen.
Der Angreifer transferierte zunächst 1e-8 WBTC und 331,335 yCredit-Tokens in den WBTC-yCREDIT-Paar-Pool. Anschließend zahlte der Angreifer 0,5 WBTC in den StableYieldCredit-Vertrag ein, um den Angriff zu starten.
Insbesondere wird der _value anhand des amount (0,5) des token (0x2260fac5e5542a773aa44fbcfedf7c193bc2c599 - WBTC) basierend auf dem Preis-Orakel-Anbieter ChainLink berechnet (Zeile 480, _value ist 1466786010075). Die Absicht ist es, den Wert des eingezahlten WBTC in USD zu berechnen. Anschließend überträgt der Vertrag die Anzahl der yCREDIT-Tokens (_value - fee) an denjenigen, der WBTC eingezahlt hat (den Angreifer). Das liegt daran, dass der Wert von yCREDIT einem USD entspricht (wie vom System vorgesehen). Alles ist in Ordnung, außer dass der Angreifer einen kleinen Betrag an fee verliert.
Darüber hinaus fügt der Vertrag den eingezahlten WBTC zum WBTC-yCREDIT-Paar-Pool hinzu. Das geschieht, weil der eingezahlte WBTC seine Liquidität verlieren würde, wenn er im Vertrag gesperrt wäre. Daher wurde zunächst der Wert des Token-Paares (WBTC zu yCREDIT), das in den Pool eingebracht wird, berechnet. Dieser Wert wird anhand der Funktion _addLiquidity berechnet. Im Grunde wird er basierend auf den vorhandenen Reserven im Pool berechnet. Da der Pool nur 1e-8 WBTC und 331,335 yCREDIT-Tokens enthält, beträgt der berechnete amountA 44 (amountB ist 1466786010075). Das bedeutet, der Angreifer gibt nur 44e-8 WBTC (Zeile 485) aus und erhält 14667,86010075 - fee = 14594,52080025 yCREDIT-Tokens (Zeile 493). Gleichzeitig verbleiben kleine Mengen an WBTC (1e-8 + 44e-8) und (331,335 + 14667,86010075) yCREDIT-Tokens im Pool.
Um Gewinne zu erzielen, kann der Angreifer die erhaltenen 14594,52080025 yCREDIT-Tokens einfach an Börsen handeln. Interessanterweise ist der Prozess zur Gewinnrealisierung 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 nur) die folgenden:
Aktualisierung
2020/01/03: Es gibt einen neuen Smart Contract, der die Schwachstelle behebt.
Zeitplan
- 2021/01/01 23:25 UTC, Angriffe wurden von unserem System erfasst
- 2021/01/02 16:20 UTC, dieser Blog wird veröffentlicht
