Eine Sicherheitsanalyse von SlowMist offenbart einen kritischen Fehler in einem Ethereum-Smart-Contract, der zu einem massiven Diebstahl führt. Angreifer gelingt es, etwa 14,4 ETH abzuschöpfen, indem sie eine Storage-Slot-Kollision zwischen zwei Codekomponenten ausnutzen. Dies geschah zu einem Zeitpunkt, als Ethereum bei rund 1.610 US-Dollar gehandelt wurde.
Ethereum ist bei Bitvavo und Bybit erhältlich.
Storage-Slot-Kollision verursacht Millionendiebstahl
Das Problem entsteht durch eine Kollision zwischen zwei verschiedenen Funktionen im ATOHook-Contract. Das Rewards-Mapping und der Reentrancy-Guard von Solady (einer weit verbreiteten Sicherheitsbibliothek) nutzen denselben Storage-Slot. Dies führt dazu, dass der Sentinel-Wert des Reentrancy-Guards (0xffffffffffffff) gleichzeitig als Belohnungsbetrag gelesen wird.
Durch diese Storage-Slot-Kollision kann ein Angreifer künstlich hohe Belohnungen einfordern. Die getReward-Funktion wird durch einen nonReentrant-Modifier geschützt, aber der Modifier schreibt den Verteidigungsmechanismus an dieselbe Stelle, an der die Belohnungen gespeichert werden. Dadurch entsteht eine doppelte Nutzung derselben Speicherposition.
Angreifer holt 200 Mal hintereinander Geld ab
Der Angreifer (identifiziert als 0x2d2aafc193c24e59bd16139056ac9b4df4d37ad0) kann dank dieses Fehlers 200 Mal hintereinander Belohnungen einfordern. Jedes Mal wird der eingebaute Betrag als ETH ausgezahlt, was zu einem Gesamtverlust von 14,4 ETH für das Opfer führt.
SlowMist zeigt, dass dies auf unzureichende Tests und Architekturfehler im Contract zurückzuführen ist. Die Kollision zwischen Rewards-Accounting und dem Reentrancy-Guard-Speicher ermöglicht es, den Sicherheitsmechanismus vollständig zu umgehen und unbegrenzt Mittel abzuziehen.
Wie solche Fehler vermieden werden können
Dieser Vorfall unterstreicht die Bedeutung gründlicher Code-Audits und des richtigen Verständnisses der zugrunde liegenden Blockchain-Architektur. Bei der Arbeit mit bekannten Bibliotheken wie Solady ist es entscheidend zu wissen, wie diese intern Storage-Slots nutzen. Eine einfache Konfigurationsänderung oder das Verschieben eines einzigen Mappings kann eine solche katastrophale Kollision verhindern.
Entwickler müssen sich bewusst sein, dass Storage-Kollisionen nicht nur eine theoretische Gefahr darstellen. Sie können direkt ausgenutzt werden und Millionenbeträge kosten. Das Opfer in diesem Fall erleidet die Folgen eines vermeidbaren Fehlers, der durch ordnungsgemäße Audits hätte erkannt werden müssen.