L’hacker che ha attaccato preventivamente SushiSwap spiega come ha fatto

Baldassare Poma
| 2 min read

Recentemente l’exchange decentralizzato di criptovalute SushiSwap ha subito un attacco hacker dove sono stati rubati circa $3,3 milioni. Alcuni “white hat” sono intervenuti a sostegno del’exchange riuscendo a mettere al sicuro parte dei fondi detenuti nella piattaforma.

Certik e PeckShield avevan rivelato un’attività sospetta in quello smart contract, e chiesto gli utenti di rimuovere l’approvazione.

Gli hacker guidati da Trust hanno sfruttato una vulnerabilità presente in RouteProcessor2, per fare un attacco preventivo e salvare circa 1.000 ETH, mentre altri malintenzionati hanno imitato l’attacco e rubato dei fondi. L’hacker “buono” Trust ha spiegato cosa è successo.

SushiSwap colpito da un attacco hacker avanzato


Trust ha spiegato che il contratto RouteProcessor2, distribuito solo quattro giorni fa, è progettato per supervisionare vari tipi di scambi di token SUSHI, l’utility token di SushiSwap. Gli utenti pre-approvano il contratto per spendere i propri token ERC20, quindi chiamano la funzione swap() per eseguire lo scambio.

Tuttavia, il contratto interagisce con i pool UniswapV3 in modo non sicuro, poiché si fida completamente dell’indirizzo “pool” fornito dall’utente.

La supervisione consente a un pool errato di fornire informazioni false al contratto sulla fonte e sull’importo di un trasferimento, consentendo a qualsiasi utente di falsificare uno scambio e ottenere l’accesso all’intero importo approvato di un altro utente.

I dubbi si Trust

L’hacker che si fa chiamare Trust ha affermato che questa vulnerabilità avrebbe dovuto essere rilevata da qualsiasi società di revisione, sollevando preoccupazioni sull’affidabilità di chi ha prodotto il codice di base.

L’hacker ha anche menzionato la presenza di bot altamente sofisticati che hanno replicato la loro transazione di fondi per rubare risorse, sottolineando le ampie risorse e capacità di questi bot, noti come bot “miner exctractable value“(MEV).

L’hackeraggio preventivo di Trust


Trust ha scelto di eseguire l’hack preventivo per diversi motivi.

  • Un’ora e mezza prima dell’hack aveva presentato un rapporto completo sulla vulnerabilità, ma non aveva ricevuto risposta.
  • Temeva che il team di sviluppo potesse non essere disponibile durante il fine settimana.
  • Sapeva che il contratto non poteva essere risolto e poteva solo essere violato o revocare le approvazioni degli utenti.

Infine, hanno dato la priorità al salvataggio di un unico indirizzo che deteneva la maggior parte dei fondi a rischio, l’indirizzo di Sifu. Trust inoltre non ha previsto la complessità dei robot MEV nella situazione.

Alla luce di queste rivelazioni, è fondamentale per la comunità crypto rivalutare le pratiche di sicurezza e dare la priorità a controlli approfonditi sugli smart contract per evitare che tali vulnerabilità vengano sfruttate.

Inoltre, le azioni di Trust dimostrano l’importanza degli hacker white hat nell’ecosistema, che lavorano per proteggere i fondi degli utenti e migliorare la sicurezza generale.

 

Leggi anche:

Segui Cryptonews Italia sui canali social