Dieser Artikel wurde von BlockWeeks zusammengestellt und bearbeitet
Die Ostium-Plattform wurde von Angreifern ausgenutzt, wobei etwa 24 Millionen USDC gestohlen wurden, was acht Transaktionen umfasste. Der Angreifer hielt gleichzeitig die Signaturschlüssel autorisierter Oracles und die Rolle des PriceUpKeep-Vorreiters, reichte korrekt signierte Preisberichte mit zukünftigen Daten ein und öffnete und schloss wiederholt Handelspaare, wodurch falsche Gewinne erzeugt wurden, ohne tatsächliches Marktengagement.
Der Angriff erfolgte in acht Transaktionen, wobei jede Überweisung an dieselbe Wallet 0x321Df1…8bfD9 ging, wobei die größte Einzelüberweisung eine zyklische Eröffnungs-Schließungs-Operation in einem atomaren Batch war. Ostium läuft auf Arbitrum und ermöglicht es Benutzern, Derivate in Form von Terminkontrakten zu handeln, die den Preis des Basiswerts verfolgen, ohne dass eine Lieferung des Basiswerts oder ein festes Fälligkeitsdatum existiert.
Das Problem liegt darin, wie das Oracle-System von Ostium Preisdaten autorisiert. Der Validator empfängt Preisberichte, leitet die Identität des Unterzeichners aus der Signatur ab und prüft, ob der Unterzeichner in der autorisierten Liste steht. Es validiert nur die Identität des Unterzeichners, nicht die Genauigkeit des Preises selbst. Der Angreifer hielt gleichzeitig die Signaturschlüssel autorisierter Oracles und die registrierte Rolle des PriceUpKeep-Vorreiters (verantwortlich für die Ausführung ausstehender Aufträge) und nutzte diese Kombination, um korrekt signierte Preisberichte mit zukünftigen Daten einzureichen und dann wiederholt Handelspaare zu eröffnen und zu schließen, die gegenläufig waren. Dies ermöglichte es ihnen, aus Systemsicht Handelsgewinne zu erzielen, ohne tatsächliches Marktengagement.
Das Ostium-Ereignis ist eines von mehreren bedeutenden Schwachstellen auf Anwendungsebene in diesem Jahr, einschließlich der Fälle von Drift und KelpDAO's rsETH. Ein gemeinsames Thema ist, dass Smart Contracts und ihre Logik weiterhin robust sind; die Angreifer zielten hauptsächlich auf die Manipulation von Infrastruktur und menschlichem Vertrauen – im Fall von Ostium kompromittierte Signatur-Anmeldeinformationen, im Fall von Drift eine sozial konstruierte Übernahme durch vorab signierte Administratoren und im Fall von KelpDAO vergiftete RPC-Infrastruktur.
Nach diesen hochkarätigen Schwachstellen fordern einige Schutzmaßnahmen für Benutzergelder auf Anwendungsebene, wie z.B. die Begrenzung von Abhebungen, um böswilliges Verhalten abzuschrecken und Verluste bei Schwachstellen zu begrenzen. Solchen Vorschlägen sollte widerstanden werden.
Die Begrenzung von Abhebungen würde ein direktes Zensurrisiko auf Anwendungsebene einführen. Sobald ein Protokoll einseitig Ein- oder Auszahlungen von Benutzern verzögern oder einschränken kann, ist das Konzept der Selbstverwahrung auf dieser Anwendungsebene nicht mehr absolut, sondern bedingt. In diesem Fall bestimmt die Anwendung, nicht der Benutzer, die Verfügbarkeit und Verwendung von Geldern. Diese Praxis verwischt auch die Grenze zwischen Angreifern und normalen Benutzern, da Schutzmaßnahmen, die zur Abwehr von Angriffen entwickelt wurden, zwangsläufig für alle Benutzer der Anwendung gelten.
Das Risiko des "Rutschbahneffekts" verschärft dieses Problem weiter. Sobald ein Protokoll technisch in der Lage ist, Ein-/Auszahlungen zu begrenzen oder einzufrieren, wird diese Fähigkeit zum Präzedenzfall. Regulierungsbehörden können dies als Beweis anführen, dass diese Anwendungen bereits über die Werkzeuge verfügen, um Einfrierbefehle, KYC-Gates oder andere Anforderungen zu erfüllen, und daher auch dazu verpflichtet werden sollten. Schutzmaßnahmen, die zur Abwehr von Angriffen gebaut wurden, könnten zu einem Haken werden, der Protokolle in Richtung Verpflichtungen zieht, die sie sonst nicht übernehmen könnten.
Darüber hinaus werden unschuldige Marktteilnehmer dazu angeregt, die durch solche Maßnahmen verursachte Reibung zu umgehen. Zum Beispiel bedeutet die Suche nach Möglichkeiten, wirtschaftliche Exposition zu verlassen, für eingeschränkte Benutzer oft das Auftauchen eines handelbaren Anspruchsobjekts, um die Lücke zu füllen (wie Empfangs-Token, IOUs, verpackte Alternativen von Kryptowährungen). Dieser Anspruch selbst wird zu einer neuen Abhängigkeit mit eigenem Risikoprofil – auf Marktebene (möglicherweise brechende Anker, wachsende Abschläge während Paniken) und auf technischer Ebene (neue Verträge, neue Oracles, neue ausnutzbare Einheiten unabhängig von der Anwendung). Schutzmaßnahmen, die darauf abzielen, einen einzelnen Fehlerpunkt einzudämmen, verschärfen letztendlich die Verletzlichkeit, die sie zu verhindern versuchen.
Solche Inhalte bedeuten nicht, dass Protokolle nicht die Bereiche stärken sollten, die tatsächlich versagen (z.B. Signaturschlüsselverwaltung, Validator-Redundanz). Aber der Weg, Schwächen in Betriebsinfrastruktur und menschlichem Vertrauen zu beheben, besteht darin, diese Aspekte zu stärken, nicht willkürliche Kontrolle über Benutzergelder hinzuzufügen, die das Kernwertversprechen des Geschützten untergräbt.
