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 Re-entrancy-Angriff handelte, der durch die _safeMint-Funktion von ERC721 verursacht wurde.
Die Hauptursache
Das Projekt hat eine Begrenzung für die Anzahl der NFTs, die ein Konto prägen kann. Grundsätzlich 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 den Fall verhindern, dass ein NFT an einen Vertrag geprägt wird, der keine ERC721-Token verarbeiten kann. Laut der Dokumentation:
Wenn
tosich auf einen Smart Contract bezieht, muss dieser IERC721Receiver.onERC721Received implementieren, der bei einer sicheren Übertragung aufgerufen wird. Der folgende Code zeigt die OZ-Implementierung der_safeMint-Funktion.
Dieser externe Funktionsaufruf schafft jedoch eine Sicherheitslücke. Insbesondere kann der Angreifer innerhalb des onERC721Received-Callback einen Reentrant-Aufruf durchführen. Zum Beispiel kann der Angreifer im anfälligen HypeBears-Vertrag die mintNFT-Funktion 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 sind anfälliger Code und Angriffe in freier Wildbahn immer noch zu beobachten. Wie in der safeTransfer im QBridge-Sicherheitsvorfall gezeigt, garantiert die Verwendung einer sicheren Funktion keinen sicheren Vertrag 😃.
