Back to Blog

Wie das Mirror Protocol ausgenutzt wurde

Code Auditing
May 31, 2022

Das Mirror Protocol wurde von @FatMan Berichten zufolge gehackt. Der Blog hat einen guten Bericht darüber. In diesem kurzen Artikel werden wir die Angriffstransaktion nutzen, um zu erläutern, wie dies geschah.

Haftungsausschluss: Dieser Artikel basiert auf der öffentlichen Transaktion und unserem Verständnis des Mirror-Protokolls und des Terra-Ökosystems. Bitte lassen Sie uns wissen, wenn etwas Ungenaues vorhanden ist. Kommentare zu diesem Blog sind willkommen.

1 Angriff

1.1 Vorbereitung

Die Transaktion wird zur Vorbereitung der Angriffe verwendet.

SCHRITT 1: In dieser Transaktion sendete der Angreifer zunächst 100.000 USTC an den Sperrvertrag. Dies ist nicht notwendig, um eine Position zu eröffnen, aber entscheidend für den Angriff.

SCHRITT 2: Danach eröffnete der Angreifer eine Position, indem er 10 USTC als Sicherheit hinterlegte und ein Sicherheitengewicht von 2,5 angab.

Die short_params sind so angegeben, dass der Prägevertrag die geprägten mAssets (d. h. mETH) verkauft und die erhaltenen USTC zum gesperrten Betrag der Position hinzufügt.

SCHRITT 2.1: Gehen wir die Transaktion Schritt für Schritt durch. Zuerst wird die Funktion open_position aufgerufen, um eine Short-Position mit der ID 43186 zu eröffnen.

SCHRITT 2.2: Da die optionalen short_params hinzugefügt wurden, prägt der Vertrag zunächst 0.001208 mETH (basierend auf dem aktuellen ETH-Preis) und tauscht ihn dann im mETH-UST Pair ein.

SCHRITT 2.3: Die 0.001208 mETH werden gegen 4.06582 USTC getauscht. Die getauschten USTC werden nach Abzug der entsprechenden Gebühren (z. B. Steuern) an den Sperrvertrag gesendet. Das liegt daran, dass die eröffnete Position erst nach einem bestimmten Zeitraum freigegeben werden kann.

SCHRITT 2.4: Dann wird lock_position_funds_hook aufgerufen. In dieser Funktion wird position_locked_amount durch Abfragen des current_balance und Vergleichen des current_balance mit den locked_funds berechnet.

Wie wir jedoch in Schritt 1 gesehen haben, wurden 100.000 USTC direkt in den Sperrvertrag übertragen, sodass der gesperrte Betrag etwa 100.004 USTC statt 4 USTC beträgt.

SCHRITT 2.5: Schließlich wird increase_short_token aufgerufen, um die sLP-Token aufzuzeichnen.

Bis hierher hat der Angreifer eine Position eröffnet, indem er 100.000 USTC direkt an den Sperrvertrag und 10 USTC als Sicherheit gesendet hat. Der gesperrte Betrag der Position beträgt etwa 100.004 USTC und kann nach einem bestimmten Zeitraum freigegeben werden. Der Angreifer hat viele solcher Positionen eröffnet, indem er 1.000 bis 100.000 USTC gesendet hat.

1.2. Angriff

Das Mirror Protocol prüft nicht die Duplizität der Positions-ID. In diesem Fall kann der Angreifer viele doppelte Positions-IDs einspeisen, um den gesperrten Betrag einer Position immer wieder freizugeben.

Die Transaktion ist die Angriffstransaktion. Für die Positions-ID 43186 hat der Angreifer beispielsweise 437 Mal dupliziert.

Da der ursprüngliche Vertragscode keine Prüfung auf Duplikate vornimmt, wurden etwa 43,7 Mio. (437 * 0,1 Mio.) USTC freigegeben (in diesem einzigen Funktionsaufruf).

Beachten Sie, dass auch andere Positionen mit demselben Mechanismus freigegeben wurden.

2. Bugfix

Die Schwachstelle wurde in diesem Commit behoben.

Insbesondere ist unlockable_positions ein Vektor, der die freizugebenden Positions-IDs enthält. Im ursprünglichen Code gibt es keine Prüfung, ob doppelte IDs in unlockable_positions vorhanden sind. Der gepatchte Code fügt eine Prüfung auf Duplikate der Positions-IDs hinzu.

3. Schlussfolgerung

Wie von @FatMan und anderen Community-Mitgliedern hervorgehoben, bestand dieser Fehler mehrere Monate lang und wurde bereits ausgenutzt. Wir sind der Meinung, dass das stille Beheben einer Schwachstelle, die bereits ausgenutzt wurde, keine gute Sicherheitspraxis ist. Darüber hinaus sind wir der Meinung, dass hochkarätige DeFi-Projekte einige "Gatekeeper" einsetzen sollten, um den Status ihrer Apps aktiv zu überwachen und bei ungewöhnlichen Vorkommnissen benachrichtigt zu werden.

Sign up for the latest updates
Building a Secure Stablecoin Payment Network: BlockSec Partners with Morph
Partnership

Building a Secure Stablecoin Payment Network: BlockSec Partners with Morph

BlockSec has partnered with Morph as an official audit partner for the $150M Morph Payment Accelerator. By offering exclusive discounts on smart contract audits and penetration testing, BlockSec provides institutional-grade security to payment builders, ensuring a safe and resilient foundation for the future of global stablecoin payments.

Weekly Web3 Security Incident Roundup | Mar 9 – Mar 15, 2026
Security Insights

Weekly Web3 Security Incident Roundup | Mar 9 – Mar 15, 2026

This BlockSec weekly security report covers eight DeFi attack incidents detected between March 9 and March 15, 2026, across Ethereum and BNB Chain, with total estimated losses of approximately $1.66M. Incidents include a $1.01M AAVE incorrect liquidation caused by oracle misconfiguration, a $242K exploit on the deflationary token MT due to flawed trading restrictions, a $149K exploit on the burn-to-earn protocol DBXen from `_msgSender()` and `msg.sender` inconsistency, and a $131K attack on AM Token exploiting a flawed delayed-burn mechanism. The report provides detailed vulnerability analysis and attack transaction breakdowns for each incident.

Venus Thena (THE) Incident: What Broke and What Was Missed

Venus Thena (THE) Incident: What Broke and What Was Missed

On March 15, 2026, an attacker bypassed the THE (Thena) supply cap on Venus Protocol (BNB Chain) through a donation attack, inflating a collateral position to 3.67x the intended limit and borrowing ~$14.9M in assets. Both sides lost money on-chain: Venus was left with ~$2.15M in bad debt after 254 liquidation bots competed across 8,048 transactions, while the attacker retained only ~$5.2M against a $9.92M investment. This deep dive examines what broke across three lines of defense (exposure limits, collateral valuation, and liquidation) and the monitoring gaps that left months of on-chain warning signals unacted upon.

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit