Bug de transferencia en Super Sushi Samurai

El 21 de marzo de 2024, el token GameFi de Blast Super Sushi Samurai (SSS) perdió aproximadamente $4,8 millones por un bug en la lógica de transferencia de tokens: transferir tokens a uno mismo acreditaba el saldo sin debitarlo, duplicando las tenencias del remitente en cada auto-transferencia. Un atacante hizo un bucle de auto-transferencias para acuñar un saldo efectivamente infinito, y luego lo descargó en el pool de liquidez. Un white-hat había descubierto independientemente el mismo bug y estaba intentando rescatar los fondos cuando el actor malicioso atacó.

Qué ocurrió

La implementación ERC-20 transfer de SSS manejaba incorrectamente el caso from == to — añadía el monto al receptor antes de restarlo del remitente, por lo que una auto-transferencia aumentaba netamente el saldo. Auto-transferencias repetidas inflaron el SSS del atacante a un tamaño arbitrario; vender ese suministro drenó el pool SSS/WETH por ~$4,8M.

Consecuencias

• Un white-hat recuperó una porción (había estado compitiendo para asegurar fondos a través del mismo bug).
• El proyecto negoció devoluciones parciales; SSS colapsó.

Por qué importa

Super Sushi Samurai es el mismo bug contable de auto-transferencia / from == to que MonoX (intercambiar un token por sí mismo) — la clase de entradas degeneradas. Ningún usuario legítimo se hace auto-transferencias para duplicar su saldo; precisamente porque es degenerado, no se prueba. La regla recurrente del catálogo: prueba las entradas que ningún usuario honesto enviaría jamás, porque esas son exactamente las entradas que un atacante enviará. Las pruebas basadas en propiedades ("para todo a,b: el invariante balanceOf se mantiene tras transfer(a,b) incluyendo a==b") detectan esto trivialmente; las pruebas basadas en ejemplos escritas en torno al comportamiento esperado del usuario nunca lo harán.