Der Cosmos Hub wurde nicht gehackt

Der Vorfall gefährdete weder den Cosmos Hub noch jede Blockchain im weiteren Cosmos-Ökosystem. Die Schwachstelle steckte in cosmos/evm, gemeinsamer Software, die unabhängigen Cosmos-basierten Netzwerken die Ausführung Ethereum-kompatibler Anwendungen ermöglicht.

Laut dem Cosmos-Labs-Post-Mortem wurden zwischen dem 20. und 25. August sechs Netzwerke genutzt, die diese Software einsetzen. MANTRA, TAC und KiiChain wurden in der detaillierten Zeitleiste namentlich genannt; die anderen drei wurden im Dokument nicht öffentlich identifiziert.

Diese Unterscheidung ist wichtig: Sie verhindert, dass ein Fehler in gemeinsam genutzter Software zur irreführenden Schlagzeile eines „Cosmos-Hacks“ wird. Dieselbe Abgrenzungsregel galt für den Sandbox-Bridge-Exploit – eine kompromittierte Integration bedeutete nicht, dass das gesamte zugrunde liegende Protokoll gehackt worden war.

Angreifer wandelten 5,72 Mio. USD auf zwei Wegen um

Cosmos Labs schätzte, dass Angreifer auf Basis der Preise vom 19. August rund 2,87 Millionen US-Dollar über dezentrale Plattformen tauschten. Das Unternehmen bezeichnete diesen Betrag als Schätzung, die nicht unabhängig geprüft wurde. Weitere 2,85 Millionen US-Dollar sollen über zentralisierte Börsen verkauft worden sein, womit der insgesamt umgewandelte oder verkaufte Betrag etwa 5,72 Millionen US-Dollar beträgt.

Cosmos Labs teilte mit, dass die betroffenen Chains berichteten, die Konten bei den zentralisierten Börsen seien eingefroren worden, während polizeiliche Ermittlungen laufen. Der Umwandlungsbetrag von 5,72 Millionen US-Dollar wird sich nicht ändern, doch die Rückgewinnung eingefrorener Guthaben auf den Börsen könnte den endgültigen Nettoverlust verringern.

Auch die Reaktion begrenzte den Schaden. Cosmos Labs arbeitete mit 13 weiteren potenziell exponierten Netzwerken zusammen, um diese zu patchen, anzuhalten oder anderweitig zu schützen, ohne dass weitere Vorfälle gemeldet wurden, und koordinierte sich insgesamt mit 40 Chains.

Wie ein Rechenfehler gültige Guthaben offenlegte

Die Schwachstelle entstand daraus, dass zwei Teile der Software Guthaben unterschiedlich berechneten. Cosmos EVMs StateDB erfasste nur den Betrag, den ein Konto sofort ausgeben konnte. Ein Cosmos-Vesting-Konto konnte jedoch sowohl verfügbare als auch gesperrte Token halten, und das Staking-System erlaubte es, gesperrte Token zu delegieren.

Als die Software den vollständigen delegierten Betrag vom kleineren verfügbaren Guthaben abzog, konnte ein ungeprüfter arithmetischer Unterlauf das Ergebnis in eine Zahl nahe 2^256 umschlagen lassen. Ein Angreifer konnte diesen Unterlauf dann mit einem Überlauf bei einer Übertragung kombinieren. Diese Klasse von Bugs – Integer-Unterlauf und -Überlauf bei vorzeichenloser Arithmetik – ist eine gut dokumentierte Kategorie von Smart-Contract- und Blockchain-Schwachstellen und einer der Gründe, warum moderne Smart-Contract-Sprachen standardmäßig geprüfte Arithmetik verwenden.

Die Sequenz erzeugte keine dauerhafte Erhöhung des Angebots. Stattdessen konnte sie ein Opferkonto mit hohem Guthaben auf null reduzieren und dem Angreifer das zuvor gehaltene Guthaben dieses Kontos verschaffen. Damit war die Schwachstelle ein direktes Risiko für den Diebstahl von Geldern, nicht bloß eine ungenaue Anzeige oder eine Buchhaltungsauffälligkeit.

Die Warnung kam fast vier Monate vor den Angriffen

Der Diebstahl war das Ende einer längeren Sequenz. Der entscheidende Fehler geschah bei der ersten Bewertung, Monate bevor jemand den Code ausnutzte.

Cosmos Labs behandelte eine Produktionsbedrohung als routinemäßige Wartung

Der ursprüngliche Proof of Concept verwendete eine mit sechs Dezimalstellen konfigurierte Chain. Cosmos Labs testete Konfigurationen mit 18 Dezimalstellen, konnte das Ergebnis nicht reproduzieren und schloss daraus, dass bekannte Produktionsnetzwerke sicher seien. Diese Schlussfolgerung war falsch: Die zugrunde liegende Guthaben-Diskrepanz konnte jede Cosmos-EVM-Chain betreffen, unabhängig von ihrer Dezimalkonfiguration.

Als spätere Berichte die größere Reichweite belegten, wusste Cosmos Labs, dass Produktionsgelder exponiert waren. Das Unternehmen wählte einen stillen Patch-Prozess, der den Ziel-Code in die Hände der Betreiber bringen sollte, ohne Details zu veröffentlichen, die Angreifern helfen könnten.

Die Releases standen etwa 20 Stunden vor dem ersten bekannten Angriff zur Verfügung, doch ihre Hinweise gaben weder den Schweregrad an noch teilten sie den Betreibern mit, dass eine verzögerte Aktualisierung Nutzer-Gelder gefährden könnte. Betreiber konnten sehen, dass neue Releases Sicherheitskorrekturen enthielten, doch die Hinweise erklärten nicht, dass ungepatchte Chains potenzielle Geldverluste riskierten.

Die Offenlegung wurde am nächsten Morgen öffentlich. Ein Pull Request in einem Downstream-Fork beschrieb den Exploit-Pfad und identifizierte betroffene Release-Tags etwa 12 Stunden vor dem ersten Angriff. Der öffentliche Pull Request gab Angreifern einen klareren Weg, und Cosmos Labs hatte die Betreiber bereits ohne eine Warnung gelassen, die die Dringlichkeit erklärte.

Das Dilemma, vor dem Cosmos Labs stand, ist in der Open-Source-Sicherheit bekannt: Die vollständige Offenlegung einer Schwachstelle kann Angreifer rüsten, bevor jeder Betreiber gepatcht hat, während Schweigen Betreibern die Einschätzung der Dringlichkeit erschwert. Koordinierte Offenlegungspraktiken in der Softwarebranche versuchen genau diesen Trade-off auszubalancieren, und dieser Vorfall zeigt, was geschieht, wenn die Balance nach beiden Seiten hin kippt.

Cosmos kannte nicht jede Chain, die gewarnt werden musste

Selbst ein privater Warnprozess funktioniert nur, wenn die Maintainer wissen, wen sie kontaktieren sollen. Cosmos Labs teilte mit, dass das Ökosystem mehr als 115 bekannte öffentliche Chains umfasst, aber kein vollständiges Verzeichnis besitzt. Während der Reaktion erfuhr das Unternehmen von 11 Cosmos-EVM-Bereitstellungen, die in seinen Sicherheitskanälen nicht registriert waren.

Cosmos Labs pflegte den gemeinsamen Code, ohne jedes Netzwerk zu kennen, das ihn eingesetzt hatte. Diese Lücke erschwerte es, eine vertrauliche Warnung zu übermitteln, bevor genug Informationen veröffentlicht wurden, damit Chain-Teams die Bedrohung selbst erkennen konnten.

Auch die Zeitleiste der Reaktion zeigt, warum die Botschaft explizit sein musste. Nachdem MANTRA den ersten Angriff gemeldet hatte, sandte Cosmos Labs rund zwei Stunden später seine erste kritische Sicherheits-E-Mail. TAC wurde trotz früherer Kommunikation etwa 45 Stunden nach MANTRA angegriffen, und die Anweisungen eskalierten später dahingehend, allen Cosmos-EVM-Chains zu raten, den Betrieb einzustellen.

Für unabhängige Cosmos-EVM-Chains reichte die Veröffentlichung des Codes nicht aus. Ihre Teams mussten zusätzlich erfahren, dass die Aktualisierung dringend war, und ein State-breaking Release koordinieren.

Gefährdete Chains müssen upgraden oder anhalten

Die kritische Sicherheitsempfehlung führt Versionen vor 0.6.2 sowie Versionen ab 0.7.0 bis ausschließlich 0.7.2 als betroffen auf. Betreiber sollten auf Cosmos EVM 0.6.2, 0.7.2 oder ein späteres Release wechseln.

Es gibt keine reine Konfigurationslösung. Das Deaktivieren des Staking-Precompile entfernt den in der Empfehlung beschriebenen primären Auslöser, doch Cosmos Labs betrachtet diesen Schritt nicht als Ersatz für ein Upgrade. Eine Chain, die ein gepatchtes Release nicht sofort installieren kann, sollte den Betrieb einstellen.

BTCPay hatte kürzlich nach der Bestätigung gestohlener Gelder ähnlich versionsspezifische Anweisungen herausgegeben: Betroffene Installationen aktualisieren oder offline nehmen. In beiden Fällen ist die nützliche Anleitung konkret, weil das Risiko von der eingesetzten Softwareversion abhängt.

Die nächste Korrektur betrifft den Offenlegungsprozess

Cosmos Labs teilte mit, dass es die Bewertung von Schwachstellen über den Proof of Concept des Melders hinaus ausweiten, sein Sicherheitskontaktnetzwerk erweitern und prüfen wird, ob diese Kontakte erreichbar bleiben. Außerdem plant das Unternehmen klarere Standards für private und stille Patches, einschließlich der Frage, wann Maintainer eine Betriebseinstellung statt eines koordinierten Upgrades empfehlen sollten. Eine externe Überprüfung seiner operativen Sicherheitspraktiken ist ebenfalls geplant.

Diese Änderungen adressieren den Teil des Vorfalls, den ein weiterer Code-Patch nicht lösen kann: wie eine dezentrale Gruppe unabhängiger Chains eine zeitkritische Warnung erhält, versteht und danach handelt. Die erste Bewertung grenzte den Bug zu schnell ein. Der spätere Release-Prozess verheimlichte einigen der Personen, die die Korrektur installieren sollten, die Dringlichkeit. Der Code war vor dem ersten Angriff verfügbar. Was mehreren Betreibern fehlte, war eine Warnung, dass Warten Nutzer-Gelder kosten könnte.

Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Finanz-, Investitions- oder Sicherheitsberatung dar. Netzwerkbetreiber sollten die offizielle Cosmos-EVM-Empfehlung konsultieren und ihre eingesetzte Version überprüfen.

Quelle: Coindoo