Am Morgen des 3. Februar (Zeitzone +8) meldete unser System eine Angriffstransaktion 0xfa97c3476aa8aeac662dae0cc3f0d3da48472ff4e7c55d0e305901ec37a2f704 auf den HypeBears NFT-Vertrag. Nach der Untersuchung stellten wir fest, dass es sich um einen Reentrancy-Angriff handelte, der durch die Funktion _safeMint von ERC721 verursacht wurde.
Die Grundursache
Das Projekt hat eine Beschränkung für die Anzahl von NFTs, die ein Konto prägen kann. Im Wesentlichen gibt es eine Map addressMinted, die protokolliert, ob ein Konto NFTs geprägt hat.
Beim Prägen von NFTs verwendet der Code die _safeMint-Funktion der OZ-Referenzimplementierung. Diese Funktion ist "sicher", da sie prüft, ob der Empfänger ERC721-Token empfangen kann. Dies kann verhindern, dass ein NFT an einen Vertrag geprägt wird, der keine ERC721-Token verarbeiten kann. Laut der Dokumentation:
Wenn an an einen Smart Contract verwiesen wird, muss dieser IERC721Receiver.onERC721Received implementieren, die bei einer sicheren Übertragung aufgerufen wird. Der folgende Code zeigt die OZ-Implementierung der Funktion
_safeMint:
Diese externe Funktionsaufruf schafft jedoch eine Sicherheitslücke. Insbesondere kann der Angreifer einen Reentrant-Aufruf innerhalb des onERC721Received-Callbacks durchführen. Zum Beispiel kann der Angreifer in dem verwundbaren HypeBears-Vertrag die Funktion mintNFT im onERC721Received-Callback erneut aufrufen (da addressMinted noch nicht aktualisiert wurde).
Der Angriff
Der folgende Screenshot zeigt die Angriffstransaktion.
Lektionen
Das von SafeMint ausgehende Risiko wurde von Sicherheitsexperten diskutiert Link1 Link2. Dennoch sehen wir immer noch verwundbaren Code und Angriffe in der Praxis. Wie bei safeTransfer im QBridge-Sicherheitsvorfall gezeigt, garantiert die Verwendung einer sicheren Funktion keinen sicheren Vertrag 😃.
