Einleitung
Angesichts des Wohlstands des NFT-Ökosystems auf Ethereum und der Zunahme damit verbundener Sicherheitsprobleme werden wir eine Reihe von Blogs veröffentlichen, um diese Sicherheitsprobleme vorzustellen und Entwicklern Vorschläge zur Sicherung von Verträgen zu geben. In diesem Blog werden wir das Reentrancy-Problem in NFT-Verträgen und wie die damit verbundene Schwachstelle gemindert werden kann, vorstellen.
Was ist Reentrancy
Laut Wikipedia
In der Informatik wird ein Computerprogramm oder eine Unterroutine als reentrant bezeichnet, wenn mehrere Aufrufe auf mehreren Prozessoren oder auf einem einzelnen Prozessor sicher gleichzeitig ausgeführt werden können, wobei eine reentrant-Prozedur mitten in ihrer Ausführung unterbrochen und dann sicher erneut aufgerufen („re-entered“) werden kann, bevor ihre vorherigen Aufrufe abgeschlossen sind.
In einem Smart Contract kann Reentrancy auftreten, wenn eine Funktion einen externen Aufruf eines anderen Vertrags ausführt, der die ursprüngliche Funktion (oder andere Funktionen) aufruft, bevor der ursprüngliche Aufruf zurückkehrt. Wenn der externe Aufruf von einer nicht vertrauenswürdigen Entität (z. B. einem bösartigen Vertrag) kontrolliert wird, kann dies zu unerwarteten Ergebnissen führen. Das liegt daran, dass in einigen Funktionen das Ergebnis vom Vertragsstatus abhängt. Der Vertragsstatus wird nach dem externen Aufruf aktualisiert. Der reentrant-Aufruf der Funktion verwendet jedoch den alten Zustand anstelle des aktualisierten.
Reentrancy ist ein weit verbreitetes Problem bei Smart Contracts, z. B. beim MakerDAO-Angriff, bei ERC777 auf Uniswap und anderen (suchen Sie nach Reentrancy in BlockSec Academy).
Reentrancy in NFT
Für NFT-Verträge gibt es einige implizite externe Funktionsaufrufe, die von Entwicklern übersehen werden könnten. Dazu gehören die Funktionen onERC721Received und onERC1155Received. Die Funktion onERC721Received wurde entwickelt, um zu prüfen, ob der Empfängervertrag NFTs verarbeiten kann (um zu verhindern, dass die NFTs für immer gesperrt werden). Diese Funktion wird in safeTransferFrom und _safeMint des ERC721-Vertrags aufgerufen. Eine ähnliche Funktion gibt es im ERC1155-Vertrag. Aufgrund dieser externen Funktionsaufrufe kann Reentrancy unbemerkt von den Vertragsentwicklern auftreten.
Single-Function Reentrancy
Single-Function Reentrancy ist die einfachere Form des Reentrancy-Angriffs. Bei dieser Art von Reentrancy-Angriff ist die neu aufgerufene Funktion dieselbe wie die ursprüngliche Funktion. Ein Angreifer kann die Funktion wiederholt aufrufen, bevor der erste Aufruf der Funktion abgeschlossen ist. In NFT-Verträgen tritt dies normalerweise in Funktionen im Zusammenhang mit der mint-Operation auf.
Beispielsweise können einige NFT-Projekte jedem Benutzer eine kostenlose Minting-Möglichkeit geben, die maximale Versorgung des gesamten Projekts festlegen oder die maximale Anzahl von NFTs begrenzen, die ein Benutzer halten kann. Normalerweise werden diese Einschränkungen vor der tatsächlichen Minting-Operation überprüft. Wenn die mit diesen Einschränkungen verbundenen Zustände jedoch nach der Funktion safeMint aktualisiert werden, kann der Angreifer diese Minting-Funktion erneut aufrufen und die Einschränkungen umgehen, da die verbundenen Zustände mit dem ersten Aufruf der Funktion übereinstimmen. Der HypeBears Reentrancy-Angriff, der in unserem früheren Blog beschrieben wurde, ist ein Beispiel dafür.
Eine kompliziertere Single-Function Reentrancy tritt auf, wenn die Funktion safeMint in einer Schleife verwendet wird und die Einschränkungen vor Beginn der Schleife überprüft werden. In diesem Szenario werden einige Zustände zwar automatisch vor dem externen Aufruf aktualisiert, die verbleibenden safeMint-Funktionsaufrufe in der Schleife können die Validierung jedoch weiterhin umgehen, da die Schleife bereits begonnen hat und die Validierung vor Beginn der Schleife erfolgt.
Wenn beispielsweise in dem in einem anderen Beitrag gezeigten Beispiel die Funktion mintNFT prüft, ob die Anzahl der vom Benutzer zu mintenden NFTs plus die aktuelle Versorgung die maximale Versorgung überschreiten kann. Die Funktion safeMint aktualisiert die Gesamtversorgung vor dem externen Aufruf von onERC721Received. Ein Angreifer kann dies immer noch ausnutzen, da die Funktion safeMint die Gesamtversorgung jedes Mal nur um 1 erhöht. Wenn der Angreifer also die Funktion mintNFT beim ersten Aufruf von safeMint in der Schleife erneut aufruft, wird die Gesamtversorgung zur alten Versorgung plus 1, anstatt zur alten Versorgung plus der Menge der NFTs, die beim ersten Aufruf von mintNFT gemintet werden.
Cross-Function Reentrancy
Anstatt dieselbe Funktion aufzurufen, kann der Angreifer eine andere Funktion aufrufen, die Zustände mit der Ursprungsfunktion teilt oder von diesen abhängt. Wir haben einige Fälle in unseren früheren Blogs für den Revest-Fall und den OMNI-Fall detailliert beschrieben.
Zusammenfassung und Vorschläge
Hier sind einige Vorschläge für Entwickler von NFT-Smart Contracts, um die Reentrancy-Bedrohung zu mindern.
- Verwenden Sie das Checks-Effects-Interactions Pattern in Ihrem Code.
- Seien Sie vorsichtig, wenn Sie Bibliotheken von Drittanbietern verwenden, die externe Aufrufe einführen. Seien Sie bei NFT-Verträgen vorsichtig mit dem impliziten Callback der Funktionen
onERC721ReceivedundonERC1155Received.
Lesen Sie den anderen Artikel in dieser Serie
Über BlockSec
BlockSec ist ein führendes Blockchain-Sicherheitsunternehmen, das 2021 von einer Gruppe weltweit renommierter Sicherheitsexperten gegründet wurde. Das Unternehmen engagiert sich für die Verbesserung der Sicherheit und Benutzerfreundlichkeit der aufkommenden Web3-Welt, um deren Massenadoption zu fördern. Zu diesem Zweck bietet BlockSec Dienstleistungen für die Überprüfung von Smart Contracts und EVM-Ketten Sicherheitsaudits, die Phalcon-Plattform für die Entwicklung sicherer Systeme und die proaktive Abwehr von Bedrohungen, die MetaSleuth-Plattform für die Nachverfolgung von Geldern und Ermittlungen sowie die MetaSuites-Erweiterung für Web3-Entwickler, um effizient in der Krypto-Welt zu navigieren.
Bis heute hat das Unternehmen über 300 namhafte Kunden wie MetaMask, Uniswap Foundation, Compound, Forta und PancakeSwap betreut und im Rahmen von zwei Finanzierungsrunden zweistellige Millionenbeträge von renommierten Investoren, darunter Matrix Partners, Vitalbridge Capital und Fenbushi Capital, erhalten.
Offizielle Website: https://blocksec.com/
Offizielles Twitter-Konto: https://twitter.com/BlockSecTeam
