Super Sushi Samurai Transfer-Bug

Am 21. März 2024 verlor das Blast-GameFi-Token Super Sushi Samurai (SSS) rund 4,8 Millionen Dollar an einen Token-Transfer-Logik-Bug: Tokens an sich selbst zu transferieren schrieb das Guthaben gut, ohne es zu belasten, was das Halten des Senders bei jedem Self-Transfer verdoppelte. Ein Angreifer schleifte Self-Transfers, um einen praktisch unendlichen Saldo zu prägen, und warf ihn dann in den Liquiditätspool. Ein Whitehat hatte unabhängig denselben Bug entdeckt und versuchte, Mittel zu retten, als der bösartige Akteur zuschlug.

Was geschah

SSSs ERC-20-transfer-Implementierung behandelte den from == to-Fall falsch — sie addierte den Betrag zum Empfänger, bevor sie ihn vom Sender abzog, sodass ein Self-Transfer das Guthaben netto erhöhte. Wiederholte Self-Transfers blähten den SSS des Angreifers auf beliebige Größe auf; der Verkauf dieses Vorrats entzog dem SSS/WETH-Pool ~4,8 Mio. $.

Nachwirkungen

• Ein Whitehat rettete einen Teil (war im Wettlauf, Mittel über denselben Bug zu sichern).
• Das Projekt verhandelte Teilrückgaben; SSS kollabierte.

Warum es zählt

Super Sushi Samurai ist derselbe Self-Transfer-/from == to-Buchhaltungs-Bug wie MonoX (ein Token gegen sich selbst tauschen) — die degenerierte-Input-Klasse. Kein legitimer Nutzer transferiert an sich selbst, um sein Guthaben zu verdoppeln; gerade weil es degeneriert ist, wird es nicht getestet. Die wiederkehrende Regel des Katalogs: Teste die Inputs, die kein ehrlicher Nutzer jemals einreichen würde, denn das sind genau die Inputs, die ein Angreifer einreichen wird. Property-basierte Tests („für alle a,b: balanceOf-Invariante gilt nach transfer(a,b) einschließlich a==b") fangen das trivial; beispielbasierte Tests, die um erwartetes Nutzerverhalten geschrieben sind, niemals.