CREATE2 und vorausberechnete Adressen als Angriffsvektor

Definition

Der CREATE2-Opcode, der mit dem Ethereum Constantinople Hard Fork eingeführt wurde, ist ein grundlegender Mechanismus, der die Bereitstellung von Smart Contracts an vorausberechneten Adressen ermöglicht. Im Gegensatz zum älteren CREATE-Opcode, der die Adresse eines Vertrags basierend auf der Adresse des Senders und einer Transaktions-Nonce bestimmt, erlaubt CREATE2, dass die Adresse bereits bekannt ist, bevor der Bytecode des Vertrags tatsächlich auf der Blockchain bereitgestellt wird. Diese deterministische Adressgenerierung wird erreicht, indem die Adresse des Deployers, ein vom Benutzer festgelegter Salt-Wert und der Hash des Initialisierungscodes des Vertrags in die Adressberechnung einbezogen werden. Diese Fähigkeit bedeutet, dass ein Vertrag an einer Adresse bereitgestellt werden kann, die viel früher vorhergesagt und vereinbart wurde, unabhängig von der Reihenfolge der Transaktionen oder der Nonce des Deployers.

Eine vorausberechnete Adresse ist eine Smart-Contract-Adresse, deren Wert im Voraus, vor der tatsächlichen Bereitstellung des Vertrags, typischerweise unter Verwendung des Ethereum CREATE2-Opcodes, bestimmt werden kann.

Kernaussage

Die zentrale Implikation der deterministischen Adressgenerierung von CREATE2 ist ihre Doppelnatur: Während sie leistungsstarke Funktionen für legitime Anwendungen wie universelle Factories und State Channels bietet, führt sie gleichzeitig einen neuartigen und ausgeklügelten Angriffsvektor ein. Böswillige Akteure können die Fähigkeit ausnutzen, einen Vertrag an einer bekannten zukünftigen Adresse bereitzustellen, indem sie Benutzer dazu verleiten, mit einem Vertrag zu interagieren oder Transaktionen für einen Vertrag zu genehmigen, der noch nicht auf der Blockchain existiert. Dies ermöglicht es Angreifern, später einen bösartigen Vertrag an genau dieser vorab genehmigten Adresse bereitzustellen und so unbefugten Zugriff auf Gelder zu erhalten oder unbeabsichtigte Operationen auszuführen, wodurch traditionelle Sicherheitsannahmen umgangen werden.

Mechanik

Das Verständnis der Mechanik von CREATE2 ist entscheidend, um seine Sicherheitsimplikationen zu erfassen. Traditionell wird bei der Bereitstellung eines Vertrags mittels des CREATE-Opcodes dessen Adresse aus dem Keccak-256-Hash der RLP-kodierten Senderadresse und deren Transaktions-Nonce abgeleitet. Dies bedeutet, dass die Adresse von der Transaktionshistorie des Senders abhängt und erst zum Zeitpunkt der Bereitstellung bestimmt werden kann. Wenn ein Sender mehrere Verträge bereitstellt, erhöhen sich seine Nonces, was zu unterschiedlichen Adressen für jede Bereitstellung führt, selbst bei identischem Bytecode.

Im Gegensatz dazu bietet CREATE2 einen anderen Ansatz. Die Adresse eines über CREATE2 bereitgestellten Vertrags wird mit der folgenden Formel berechnet: new_address = keccak256(0xff ++ deployer_address ++ salt ++ keccak256(init_code))[12:]. Hierbei ist 0xff ein festes Präfix, deployer_address ist die Adresse des Kontos, das die CREATE2-Operation ausführt, salt ist ein beliebiger 32-Byte-Wert, der vom Deployer gewählt wird, und keccak256(init_code) ist der Hash des Erstellungs-Bytecodes des Vertrags. Da das 0xff-Präfix, die deployer_address und der keccak256(init_code) für einen bestimmten Vertrag und Deployer fest sind, wird der salt-Parameter zur primären Variablen, die es dem Deployer ermöglicht, die resultierende Vertragsadresse vollständig zu kontrollieren. Dies bedeutet, dass, wenn die deployer_address, salt und init_code bekannt sind, die endgültige Vertragsadresse mit absoluter Sicherheit off-chain berechnet werden kann, lange bevor der Vertrag überhaupt bereitgestellt wird. Diese Deterministik ist leistungsstark für Anwendungsfälle wie die Bereitstellung eines universellen Factory-Vertrags an derselben Adresse über mehrere EVM-Ketten hinweg oder für die kontrafaktische Instanziierung, bei der die Existenz eines Vertrags angenommen wird, bevor er tatsächlich bereitgestellt wird.

Trading-Relevanz

Die Existenz von CREATE2 und die damit verbundenen Angriffsvektoren haben eine erhebliche Trading-Relevanz für Teilnehmer in den Kryptowährungs- und DeFi-Ökosystemen. Trader, Liquiditätsanbieter und jeder, der mit Smart Contracts interagiert, sind ständig potenziellen Schwachstellen ausgesetzt. Ein Angriff, der vorausberechnete Adressen nutzt, kann zu direkten finanziellen Verlusten führen, da Benutzer unwissentlich Token-Transfers an eine Adresse genehmigen könnten, die später von einem bösartigen Vertrag kontrolliert wird. Ein Benutzer könnte beispielsweise die Genehmigung erteilen, dass der Vertrag eines DeFi-Protokolls seine Token für eine zukünftige Staking-Möglichkeit ausgibt, nur damit ein Angreifer einen bösartigen Vertrag an genau dieser Adresse bereitstellt und anschließend die genehmigten Gelder abzieht. Dieses Szenario untergräbt das Vertrauen der Benutzer in Smart-Contract-Interaktionen und kann unmittelbare, irreversible Folgen für ihre Portfolios haben.

Über den direkten finanziellen Verlust hinaus ist der breitere Einfluss auf die Marktstimmung und das Vertrauen nicht zu unterschätzen. Wenn Exploits auftreten, insbesondere solche, die ausgeklügelte Techniken wie CREATE2 nutzen, können sie Panikverkäufe auslösen, die Liquidität reduzieren und das Vertrauen in bestimmte Protokolle oder sogar den gesamten DeFi-Bereich untergraben. Trader, die sich dieser Angriffsvektoren nicht bewusst sind, könnten Marktbewegungen falsch interpretieren oder Opfern von Betrügereien werden, die darauf abzielen, diesen Mechanismus auszunutzen. Das Verständnis der Funktionsweise von CREATE2 und seines Missbrauchspotenzials ist daher nicht nur eine technische Kuriosität, sondern ein kritischer Bestandteil des Risikomanagements für jeden, der aktiv am Krypto-Handel und an dezentralen Finanzen beteiligt ist. Es erfordert ein erhöhtes Maß an Sorgfalt bei der Interaktion mit neuen oder komplexen Protokollen, insbesondere solchen, die Genehmigungen oder zukünftige Vertragsinteraktionen beinhalten.

Risiken

Das Hauptrisiko im Zusammenhang mit CREATE2 und vorausberechneten Adressen ist der Approval-Exploit. Benutzer werden oft aufgefordert, Smart Contracts zu genehmigen, um ihre Token in ihrem Namen auszugeben. In einem CREATE2-Angriffsszenario kann ein böswilliger Akteur einem Benutzer eine scheinbar harmlose Vertragsadresse zur Genehmigung vorlegen. Diese Adresse wird unter Verwendung von CREATE2-Parametern vorausberechnet, aber der Vertrag selbst wurde noch nicht bereitgestellt. Der Benutzer, der eine legitim aussehende Adresse sieht oder von einer vielversprechenden dApp angelockt wird, erteilt die Genehmigung. Später stellt der Angreifer einen bösartigen Vertrag an genau dieser vorausberechneten Adresse unter Verwendung von CREATE2 bereit. Da der Benutzer diese spezifische Adresse bereits genehmigt hatte, kann der neu bereitgestellte bösartige Vertrag nun ohne weitere Interaktion auf die genehmigten Token des Benutzers zugreifen und diese übertragen, was zu einem sofortigen und oft irreversiblen Verlust von Geldern führt. Dies umgeht traditionelle Sicherheitsprüfungen, die einen neu bereitgestellten, unbekannten Vertrag möglicherweise kennzeichnen würden, da die Adresse selbst im Voraus "bekannt" und genehmigt war.

Ein weiteres erhebliches Risiko ist Front-Running und Adress-Squatting. Angreifer können den Mempool auf Transaktionen überwachen, die beabsichtigen, einen legitimen Vertrag an einer bestimmten CREATE2-Adresse bereitzustellen. Wenn sie die Zieladresse berechnen und ihren eigenen bösartigen Vertrag an dieser Adresse vor der Bestätigung der legitimen Transaktion bereitstellen können, "besetzen" sie effektiv die beabsichtigte Adresse. Dies kann legitime Protokollbereitstellungen stören, Gelder umleiten oder sogar offizielle Verträge imitieren. Darüber hinaus kann die deterministische Natur von CREATE2 bei Phishing- und Social-Engineering-Angriffen ausgenutzt werden. Angreifer können ausgeklügelte Schemata entwickeln, die Benutzer dazu überreden, unter falschen Vorwänden mit zukünftigen Vertragsadressen zu interagieren oder diese zu genehmigen. Die wahrgenommene Legitimität einer vorab bestimmten Adresse, insbesondere wenn sie Teil eines bekannten Musters ist (z. B. eine universelle Factory-Adresse), kann die Wachsamkeit eines Benutzers herabsetzen und ihn anfälliger für ausgeklügelte Betrügereien machen. Die sich entwickelnden Taktiken von Cyberkriminellen erfordern kontinuierliche Wachsamkeit und die Anpassung von Sicherheitsmaßnahmen, um diesen innovativen Exploits entgegenzuwirken.

Geschichte und Beispiele

Der CREATE2-Opcode wurde im Februar 2019 im Rahmen des Constantinople Hard Forks in die Ethereum-Blockchain eingeführt. Seine primäre Motivation war es, erweiterte Funktionalitäten wie State Channels und kontrafaktische Instanziierung zu ermöglichen, bei denen die Existenz eines Vertrags angenommen und mit ihm interagiert werden kann, noch bevor er physisch auf der Kette bereitgestellt wird. Dies ermöglicht effizientere und flexiblere Protokolldesigns, insbesondere für Skalierungslösungen und komplexe Mehrparteien-Interaktionen. Beispielsweise ermöglicht eine universelle CREATE2-Factory, die an einer festen Adresse über alle EVM-Ketten hinweg bereitgestellt wird, konsistente Vertragsbereitstellungsmuster und vereinfacht die kettenübergreifende Entwicklung. Das ursprüngliche Design konzentrierte sich auf die Vorteile der Deterministik, ohne die ausgeklügelten Angriffsvektoren vollständig zu antizipieren, die aus ihrem Missbrauch entstehen könnten.

Obwohl spezifische, hochkarätige Exploits, die ausschließlich dem CREATE2-Angriffsvektor zugeschrieben werden, seltener veröffentlicht werden als andere Schwachstellen (wie Reentrancy- oder Flash-Loan-Angriffe), haben Sicherheitsforscher die theoretischen und praktischen Risiken umfassend dokumentiert. Check Point Research hob beispielsweise hervor, wie die Fähigkeit von CREATE2, Verträge an bekannten Adressen bereitzustellen, ausgenutzt werden kann, um digitale Wallets zu kompromittieren und traditionelle Sicherheitsmaßnahmen zu umgehen. Sie betonten, dass diese Schwachstelle die Notwendigkeit verbesserter Sicherheitsmaßnahmen bei Wallet-Produkten unterstreicht, um sich an die sich entwickelnden Taktiken von Cyberkriminellen anzupassen. Hypothetisch könnte ein Angreifer eine gefälschte dApp erstellen, die Benutzer dazu auffordert, einen zukünftigen Liquiditätspool-Vertrag an einer bestimmten CREATE2-Adresse "vorab zu genehmigen". Sobald genügend Benutzer zugestimmt haben, stellt der Angreifer einen bösartigen Vertrag an genau dieser Adresse bereit, der dann die genehmigten Token abzieht. Diese Art von Angriff nutzt Social Engineering in Kombination mit den technischen Fähigkeiten von CREATE2 und stellt eine potente Bedrohung in der DeFi-Landschaft dar.

Häufige Missverständnisse

Ein häufiges Missverständnis ist, dass der CREATE2-Opcode selbst von Natur aus bösartig oder fehlerhaft ist. Dies ist falsch. CREATE2 ist ein leistungsstarkes und nützliches Primitiv, das innovative Blockchain-Architekturen wie universelle Vertrags-Factories, State Channels und Meta-Transaktionen ermöglicht, indem es deterministische Vertragsadressen zulässt. Sein Design erleichtert legitime Anwendungsfälle, bei denen die Adresse eines Vertrags vor seiner Bereitstellung bekannt sein muss. Die Schwachstelle entsteht nicht durch die Existenz von CREATE2, sondern durch sein Missbrauchspotenzial durch böswillige Akteure, die die Deterministik ausnutzen, um Benutzer zu täuschen, insbesondere im Kontext von Token-Genehmigungen für Verträge, die noch nicht existieren. Es ist ein Werkzeug, das zum Guten oder zum Schlechten verwendet werden kann, ähnlich wie jede andere leistungsstarke technologische Fähigkeit.

Ein weiteres Missverständnis ist, dass alle vorausberechneten Adressen gefährlich sind und vermieden werden sollten. Obwohl immer Wachsamkeit geboten ist, stellt eine vorausberechnete Adresse nur dann ein Risiko dar, wenn sie Teil eines bösartigen Schemas ist. Viele legitime Protokolle nutzen CREATE2 aus gültigen Gründen, wie z. B. die Bereitstellung von Proxy-Verträgen oder die Sicherstellung konsistenter Adressen über verschiedene Netzwerke hinweg. Die Gefahr liegt im Kontext der Interaktion: Wenn ein Benutzer aufgefordert wird, eine Adresse für einen noch nicht bereitgestellten Vertrag zu genehmigen und die Quelle dieser Anfrage verdächtig oder unbestätigt ist, dann wird dies zu einem Hochrisikoszenario. Darüber hinaus könnten einige Benutzer fälschlicherweise glauben, dass die Sicherheitsfunktionen ihrer Wallet ausreichen, um sie vor allen Formen von Smart-Contract-Exploits zu schützen. Obwohl Wallets ständig verbessert werden, erfordert die einzigartige Natur von CREATE2-Angriffen, bei denen eine Adresse vor der Existenz des bösartigen Codes genehmigt wird, fortschrittliche Erkennungsmechanismen, die traditionelle Prüfungen möglicherweise übersehen. Benutzer müssen verstehen, dass die letztendliche Verantwortung für die Überprüfung von Interaktionen bei ihnen liegt, zusätzlich zur Nutzung robuster Sicherheitstools.

Zusammenfassung

Der CREATE2-Opcode stellt einen bedeutenden Fortschritt in den Bereitstellungsfähigkeiten von Ethereum-Smart-Contracts dar, indem er die Erstellung von Verträgen an vorausberechneten Adressen ermöglicht, basierend auf dem Deployer, einem gewählten Salt und dem Initialisierungscode des Vertrags. Während diese Deterministik erhebliche Vorteile für legitime Anwendungen wie universelle Factories und State Channels bietet, führt sie gleichzeitig einen ausgeklügelten Angriffsvektor ein. Böswillige Akteure können diese Funktion ausnutzen, indem sie Benutzer dazu verleiten, Transaktionen für eine zukünftige Vertragsadresse zu genehmigen, nur um später einen schädlichen Vertrag an genau diesem Ort bereitzustellen und so unbefugten Zugriff auf Gelder zu erhalten. Dieser Mechanismus umgeht traditionelle Sicherheitsannahmen und unterstreicht die sich entwickelnde Landschaft der Blockchain-Sicherheit. Das Verständnis der Mechanik von CREATE2, das Erkennen der Risiken im Zusammenhang mit Approval-Exploits und Adress-Squatting sowie ein hohes Maß an Wachsamkeit bei der Interaktion mit dezentralen Anwendungen sind von größter Bedeutung, um digitale Vermögenswerte in der komplexen und dynamischen Welt von Web3 zu schützen.