Il nuovo exchange decentralizzato Merlin è stato privato di circa 1,82 milioni di dollari dal suo pool di liquidità mercoledì, e il revisore CertiK – che ha completato un audit del DEX poco prima del suo lancio – ha attribuito la responsabilità dell’hack a “sviluppatori disonesti”.
In un post su Twitter, il revisore ha dichiarato che “le indagini iniziali indicano che gli sviluppatori disonesti hanno sede in Europa e stiamo collaborando con le forze dell’ordine per rintracciarli” e li ha invitati ad accettare una taglia white hat del 20%. Merlin stessa ha accusato “diversi membri del team Back-End” di aver prosciugato i suoi contratti in un post su Twitter.
In una dichiarazione inviata a TCN, CertiK ha affermato che sta lavorando con “il restante team di Merlin” e con il team dietro la rete ZKSync su un piano di compensazione per gli utenti colpiti. Merlin non ha ancora risposto alle richieste di commento di TCN.
Costruita su zkSync, una soluzione di scalabilità di livello 2 di Ethereum, Merlin è stata lanciata solo pochi giorni fa con la vendita pubblica del suo token MAGE. Immediatamente prima del lancio, Merlin ha anche ricevuto una verifica del codice da parte della società di sicurezza dei contratti intelligenti CertiK, un passo che molte aziende di criptovalute considerano essenziale per garantire la sicurezza dei beni degli utenti e mantenere la fiducia dei clienti.
Secondo CertiK, che ha dichiarato di stare “indagando attivamente” sull’incidente di Merlin, “i risultati iniziali indicano come causa principale un potenziale problema di gestione della chiave privata piuttosto che un exploit”.
1/ CertiK sta valutando un piano di compensazione della comunità per coprire i circa 2 milioni di dollari di fondi degli utenti persi a causa dell’incidente Merlin DEX. Le prime indagini indicano che gli sviluppatori disonesti hanno sede in Europa e stiamo collaborando con le forze dell’ordine per rintracciarli.
⬇️⬇️⬇️
– CertiK (@CertiK) 26 aprile 2023
“Sebbene gli audit non possano prevenire i problemi relativi alle chiavi private, mettiamo sempre in evidenza le migliori pratiche per i progetti. Se dovessero essere scoperte delle irregolarità, collaboreremo con le autorità competenti e condivideremo le informazioni pertinenti”, ha dichiarato CertiK in un thread su Twitter, aggiungendo di aver evidenziato il rischio di centralizzazione di Merlin nel suo rapporto di audit.
Merlin ha risposto all’incidente poco dopo con un “annuncio agli sviluppatori”, chiedendo agli utenti di “revocare l’accesso al sito connesso sui loro portafogli” come precauzione.
Il DEX ha dichiarato che sta analizzando l’accaduto e che “verranno forniti ulteriori aggiornamenti”.
Annuncio dello sviluppatore
Potete tutti revocare l’accesso al sito connesso sui vostri portafogli/firmare l’autorizzazione https://t.co/YRxH7IUU4T
Stiamo analizzando l’exploit del nostro protocollo e sottolineiamo che tutti devono eseguire questa operazione per precauzione.
Verranno forniti ulteriori aggiornamenti
– Merlin (@TheMerlinDEX) 26 aprile 2023
Problemi di centralizzazione
Gli esperti di sicurezza della blockchain hanno evidenziato “gravi problemi di centralizzazione” negli smart contract di Merlin DEX.
“Anche se siamo ancora all’inizio di questa storia, ci sono indizi che indicano la presenza di gravi problemi di centralizzazione negli smart contract di Merlin DEX”, ha dichiarato a TCN Gonçalo Magalhães, smart contract engineer della piattaforma di bug bounty Immunefi. “In particolare, l’indirizzo che riceveva le commissioni per i pool era autorizzato a prosciugare tutti i fondi da ogni pool del protocollo”.
In un tweet, un altro DEX basato su zkSync, eZKalibur, ha affermato di aver identificato “il codice maligno responsabile del prosciugamento dei fondi” negli smart contract di Merlin.
Abbiamo fatto delle ricerche sugli smart contract Merlin e abbiamo identificato il codice maligno responsabile del prosciugamento dei fondi.
Queste due righe di codice nella funzione di inizializzazione stanno essenzialmente concedendo l’approvazione all’indirizzo feeTo per trasferire un numero illimitato (type(uint256).max)… pic.twitter.com/mIksh4HkhB
– eZKalibur ∎ (@zkaliburDEX) April 26, 2023
Secondo Magalhães di Immunefi, mentre CertiK ha evidenziato alcuni problemi di centralizzazione nella sua verifica, “non c’è alcuna menzione di questo punto specifico, in cui l’indirizzo del destinatario della tassa ha la piena approvazione per ritirare ogni token dai pool, il che è in realtà un cruciale punto singolare di fallimento”.
“Se questo fosse davvero il caso di una compromissione della chiave privata, non sarebbe certo il primo”, ha dichiarato Magalhães, definendo la corretta gestione delle chiavi degli indirizzi privilegiati di un protocollo una “questione critica”. Ha aggiunto che mitigazioni come i portafogli multisig sono vantaggiose, ma che “avere l’approvazione per il trasferimento completo di fondi su un singolo conto rende questa chiave privata un obiettivo succulento per gli hacker blackhat. “
Andy Zhou, CEO della piattaforma di audit BlockSec, ha fatto un ulteriore passo avanti, sostenendo che mentre gli audit dei contratti smart sono utili per individuare le vulnerabilità e proteggere i beni degli utenti nel protocollo, “un aspetto che di solito viene ignorato è cosa succede se il protocollo stesso è dannoso”, come ad esempio se ha l’intenzione di “rubare gli utenti”.
Su Twitter, Zhou ha paragonato Merlin a una banca che pre-autorizza il suo proprietario a prelevare arbitrariamente tutto il denaro dei clienti.
“Se sapete questo, depositerete comunque i vostri token in banca?” ha chiesto il CEO di BlockSec.
Dammi i tuoi soldi. sì, signore!
È come se una banca pre-autorizzasse il proprietario della banca a prelevare arbitrariamente il denaro di tutti i clienti.
Se lo sapete, depositerete comunque i vostri gettoni in banca?
Ecco come funziona Merlin DEX. pic.twitter.com/7NdyhRpjky
– Yajin (Andy) Zhou (@yajinzhou) 26 aprile 2023
Magalhães concorda sul fatto che l’approvazione dei destinatari di quote illimitate è “qualcosa che non è affatto necessario per la logica del protocollo”, affermando al TCN che “ci saremmo aspettati che un audit l’avrebbe segnalato come preoccupante”.
“Questo è un altro motivo per cui è importante che il codice venga controllato da più di una parte esterna. Ciò che non è stato notato da un’azienda, potrebbe essere segnalato da un’altra”, ha detto Magalhães.
Nella sua dichiarazione a TCN, CertiK ha osservato che “mentre le revisioni possono identificare potenziali rischi e vulnerabilità, non possono prevenire attività dannose da parte di sviluppatori disonesti, come i “rug pull””, e ha incoraggiato gli utenti a cercare progetti che hanno eseguito un processo di verifica KYC volontario. Il revisore ha inoltre sottolineato che “i privilegi delle chiavi private esulano dall’ambito di un audit sugli smart contract”, ma ha ribadito il proprio impegno ad assistere gli utenti colpiti e a dare la caccia ai responsabili di quella che ha descritto come una “truffa in uscita”.
