USDs-Exploit-Bericht vom 3. Februar vom Engineering-Team

Feb 07 2023

Am 3. Februar manipulierte ein Angreifer den USD-Guthaben auf einem Multi-Sig-Wallet und änderte ihn auf 9,7 Milliarden, indem er einen internen Fehler im USD-Token-Vertrag ausnutzte.

Am 3. Februar manipulierte ein Angreifer den USD-Guthaben auf einem Multi-Sig-Wallet und änderte ihn auf 9,7 Milliarden, indem er einen internen Fehler im USD-Token-Vertrag ausnutzte. Bevor das Sperax-Team den Vertrag pausierte, tauschte der Angreifer etwa 309.000 USD in Vermögenswerte wie USDT, USDC und WETH um.

Timeline-Traceback

03.02.2023 23:25:59 Uhr +UTC

Der Angreifer hat die Adresse des nächsten zu erstellenden Gnosis Safe-Vertrags vorab berechnet (0x5c978df5f8af72298fe1c2c8c2c05476a10f253911) und 11 USD von der Adresse 0x4afcd19bb978eaf4f993814298504ed285df1181 an diese Adresse gesendet.https://arbiscan.io/tx/0xe74641b4b7e9c9eb7ab46082f322efbc510b8d39af609d934f41c41d7057fe49

Der Angreifer erstellte einen Gnosis Safe an der Adresse 0x5c..39 (mit einem Unterzeichner 0x4a..81) und verschickte die 11 USD von dieser Adresse in derselben Transaktion.https://arbiscan.io/tx/0xfaf84cabc3e1b0cf1ff1738dace1b2810f42d98baeea17b146ae032f0bdf82d5
(Der Angreifer nutzte diesen Vertrag, um die Adresse vorab zu berechnen und eine Mehrfachsignatur bereitzustellenhttps://arbiscan.io/address/0xfeedb6f87ab4b05dc6ab6ef75547c22235e7b642#code)
Diese Token-Transfer-Aktion löste einen Fehler im USD-Token-Vertrag aus und der Saldo der Adresse 0x5c..39 sprang auf 9797854205567803995021828646 (9,79 Milliarden).

Der Angreifer begann, USD auf Arbitrum zu verkaufen, meist 10.000 auf einmal (wobei 0x4a..81 bei den meisten Transaktionen der direkte Empfänger war).

Das Sperax-Team hat die Vertragsaktion des USD ausgesetzt. Insgesamt wurden 309.000 USD verkauft.

Kontext

USDs ist ein Rebasing-Token mit zwei Arten von Inhabern: Rebasing und Non-Rebasing.

Das USD-Guthaben eines Rebasing-USD-Inhabers erhöht sich bei einem Rebase (der wöchentlich ausgelöst wird) automatisch. wohingegen der USD-Saldo des Nicht-Rebasing-Inhabers nach einer Rebase unverändert bleibt.
Standardmäßig sind alle EOAs Rebasing-Inhaber und alle Smart Contracts sind Non-Rebasing-Inhaber.

Balance = Guthaben / CreditsPerToken

Jeder Inhaber hat sein eigenes Guthaben
Alle Rebasing-Inhaber teilen sich die gleichen CreditsPerToken
Jeder Nicht-Rebasing-Inhaber hat sein eigenes CreditsPerToken

Am 14. Dezember aktualisierte Sperax den USD-Token-Vertrag, um ein Präzisionsproblem bei der Berechnung des Kontostands zu beheben, das zu Inkompatibilitätsproblemen mit DEXs führte.

Dieses Upgrade vereinfachte auch die Art und Weise, wie der USD-Token-Vertrag den Saldo der Nicht-Rebasing-Inhaber verfolgt. Es wurde ein Prozess hinzugefügt, um alle nicht rebasierenden CreditsPerToken auf 1 zu aktualisieren (und die Credits entsprechend zu aktualisieren). Dadurch entfällt die Notwendigkeit, die CreditsPerToken jedes nicht rebasierenden Inhabers im Auge zu behalten und nur das Guthaben des Inhabers als dessen Saldo zu verfolgen, wodurch USDs für diese Inhaber wie ein üblicher ERC20-Vertrag behandelt werden.

Hier wird jedoch ein Fehler in der Funktion _ensureRebasingMigration () eingeführt .

Fehlerdetails

_ensureRebasingMigration () fungiert als Wächter, um sicherzustellen, dass die Rebasing-/Nicht-Rebasing-Buchhaltung in den folgenden Szenarien korrekt ist:

Der Vertragsadministrator ändert ein Konto von Rebasing zu Non-Rebasing (oder umgekehrt)
Wenn es eine USD-Aktion (Transfer, Mint oder Burn) für einen Smart-Vertrag gibt, der nicht explizit auf „Non-Rebasing“ eingestellt wurde, sollte der Smart-Vertrag auf „Non-Rebasing“ eingestellt werden
ein intelligenter Vertrag, der zum ersten Mal mit USDs interagiert
ein Smart-Vertrag, der als Rebasing-Inhaber ein USD-Guthaben hat (aber vom Administrator nicht auf Rebasing eingestellt wurde)

Die Transaktion des Angreifers konstruierte Szenario ( 2b ), indem er zuerst USDs an die Adresse schickte und sie dann zu einem Gnosis Safe (einem intelligenten Vertrag) machte. Anschließend löste er eine USD-Überweisung aus, die _ensureRebasingMigration() auslöste , wobei _balanceOf(_account) Credits anstelle von Credits /creditPerToken zurückgibt . Der Saldo der Adresse stieg auf 9,7b.

*Die Testfälle deckten alle Szenarien in 1 und 2a ab, konnten jedoch Randfall 2b nicht abdecken.

Nächste Schritte

Obwohl alle von uns entwickelten Verträge mehrere Überprüfungsrunden und gründliche Tests durchlaufen, haben wir diesen Grenzfall dennoch übersehen. Wir haben das Gefühl, dass der Angreifer nur mit dem Vertrag experimentiert hat, da der aktualisierte Code nicht veröffentlicht wurde. Allerdings hat er/sie einen neuartigen Fehler entdeckt, es hätte zu einer noch schlimmeren Situation kommen können (wenn es geplant gewesen wäre).

Wir bedauern das und die Unannehmlichkeiten, die wir verursacht haben, wirklich. Leider können wir dies nicht rückgängig machen, aber wir werden das Problem beheben und unseren Entwicklungsprozess noch einmal überprüfen, um sicherzustellen, dass er noch strenger und unsere Smart Contracts robuster sind. Wir wenden uns auch an unsere Partner für eine Peer-Review.

Aktualisieren Sie das Guthaben des Hacker-Kontos (Multisig) wieder auf 0.
Aktualisieren Sie die anderen durch den Exploit verursachten Abrechnungsfehler wieder auf den Normalwert.
Beheben Sie den Fehler
Überprüfen Sie den Vertrag, um sicherzustellen, dass die gesamte Buchhaltungslogik korrekt ist.
Testen Sie das Upgrade.
Füllen Sie den Tresor mit Sicherheiten auf, die dem überhöhten USD-Angebot entsprechen.
Nehmen Sie den USD-Kontrakt wieder auf.

Sperax USD ist ein Stablecoin- und Ertragsautomator auf Arbitrum. Halten Sie $USDs und verdienen Sie Auto-Yield. Setzen Sie $SPA ein, um die Anlagestrategie für Sicherheiten zu steuern.