Cos'è l'Attacco di Read-Only Reentrancy

L'attacco di Read-Only Reentrancy si riferisce a una situazione in cui una view viene “rientrata”, di solito non equipaggiata dallo sviluppatore con nessuna misura di protezione, poiché essendo una view non modifica lo stato del contratto. Tuttavia, se lo stato del contratto è incoerente, ciò potrebbe portare a valori errati riportati. Inoltre, questa vulnerabilità può essere sfruttata dagli aggressori per ingannare altri protocolli che si basano sui valori restituiti, inducendoli a leggere stati errati ed eseguire potenziali azioni indesiderate.

Nel contesto dei protocolli DeFi, vengono stabilite varie integrazioni con altre piattaforme DeFi per ottenere prezzi dei token o leggere i prezzi dei token incapsulati emessi da protocolli specifici. Questa integrazione è possibile quando un protocollo di prestito supporta token di pool da altri protocolli come garanzia o consente lo staking. Tali integrazioni richiedono frequentemente il recupero dei prezzi dei token di pool o dei prezzi dei token incapsulati.

Gli aggressori approfittano di queste situazioni per eseguire attacchi di Reentrancy in sola lettura manipolando i prezzi dei token a loro vantaggio.

Il possibile impatto della Read-only Reentrancy

La rilevanza dell'attacco di reentrancy in sola lettura risiede nella sua novità, spesso trascurata dagli sviluppatori e dagli auditor. Man mano che le interazioni tra diversi protocolli nello spazio DeFi aumentano, il rischio rappresentato da questo tipo di attacco diventa più evidente. Particolarmente preoccupante è il suo impatto sui protocolli DeFi che si integrano con piattaforme come Curve.fi.

Questi protocolli spesso dipendono dalla lettura dei prezzi dei token e dei prezzi dei token incapsulati da altri sistemi, rendendoli suscettibili all'exploit attraverso la manipolazione dei prezzi. Per garantire la sicurezza e l'integrità dell'ecosistema finanziario decentralizzato, è cruciale che sviluppatori, auditor e l'intera comunità siano vigili su questa minaccia e implementino opportune salvaguardie per mitigare i rischi.

Cos'è l'Attacco di Reentrancy (classico)

Un attacco di Reentrancy si verifica quando una funzione all'interno di un contratto intelligente invoca un contratto esterno non del tutto affidabile e questo contratto esterno effettua successivamente una chiamata ricorsiva alla funzione originale. Di conseguenza, l'attacco di Reentrancy può portare all'esaurimento dei fondi o all'avvio di attività dannose all'interno del contratto.

Questo tipo di attacco può manifestarsi in varie forme, tra cui Reentrancy in Singola Funzione, Reentrancy tra Diverse Funzioni, Reentrancy tra Diversi Contratti e Reentrancy crosschain.

In questo articolo, ci concentreremo nell'esplorare la Reentrancy in Sola Lettura, approfondendone le specifiche caratteristiche e implicazioni, ma prima diamo un esempio di Attacco di Reentrancy classica.

Scenario di Attacco di Reentrancy

1. Un utente chiama la funzione withdrawAll() del contratto "Reentrant", con l'intenzione di prelevare il proprio saldo.

2. Il contratto verifica prima il saldo dell'utente nella mappatura userBalances. Se il saldo è maggiore di 0, la funzione procede; in caso contrario, viene generato un messaggio di errore che dice "Saldo insufficiente".

3. Il contratto quindi deduce il saldo dell'utente dalla variabile totalSupply senza aggiornare il saldo dell'utente nella mappatura userBalances.

4. Il contratto esegue una dichiarazione msg.sender.call{value: balance}("") per trasferire il saldo dell'utente (in Ether) all'indirizzo dell'utente. Qui risiede la vulnerabilità. La funzione call consente di chiamare contratti esterni e poiché viene eseguita prima dell'aggiornamento del saldo dell'utente, il contratto esterno può chiamare nuovamente la funzione withdrawAll() prima che il saldo sia impostato su zero.

5. Durante la chiamata a msg.sender, il contratto esterno può richiamare nuovamente la funzione withdrawAll(), rientrando efficacemente nella funzione withdrawAll() mentre la chiamata iniziale è ancora in corso.

6. Nella chiamata rientrante, la funzione verifica nuovamente il saldo dell'utente, che è ancora il valore originale. Poiché il contratto consente la Reentrancy senza alcuna protezione, si ripete lo stesso processo e il contratto esterno può eseguire la funzione withdrawAll() ripetutamente, ogni volta deducendo il saldo dell'utente dalla totalSupply ed eseguendo il trasferimento di Ether.

7. Questo ciclo di Reentrancy continua fino a quando totalSupply raggiunge zero, risultando in uno scenario in cui il contratto non ha abbastanza Ether per soddisfare il trasferimento di saldo al chiamante originale.

8. Di conseguenza, il contratto non riuscirà a inviare Ether (richiede(success, "Impossibile inviare Ether")) quando il saldo Ether sarà esaurito, lasciando il contratto in uno stato incoerente e azzerando il saldo dell'utente nella mappatura userBalances.

Qual è il metodo di operazione o la strategia di attacco impiegata nello scenario di Reentrancy in Sola Lettura?

1. In questo scenario, un aggressore implementa un contratto in grado di eseguire rientranze e lo designa come "contratto rientrante". Diversi protocolli, inclusi il protocollo DeFi target, si basano sulla lettura di determinati valori da questo contratto, rendendolo una parte cruciale dell'attacco.

2. Quando gli altri protocolli interagiscono con il contratto rientrante, scatta un metodo di fallback, causando l'esecuzione di una logica specifica definita all'interno del contratto dell'aggressore.

3. Approfittando dell'opportunità, il contratto dell'aggressore procede quindi a chiamare il contratto del protocollo DeFi target senza alcun ostacolo, sfruttando la sua vulnerabilità.

4. Come previsto, il protocollo target interagisce con il contratto rientrante compromesso e recupera involontariamente valori errati o manipolati.

5. Mentre il contratto target rimane all'oscuro dell'attacco, l'aggressore lo ha sfruttato con successo, completando l'intero processo poiché i Passaggi 1 e 2 si concludono infine senza interferenze.

Casi di Attacchi del Mondo Reale

Numerosi protocolli sono caduti vittima di attacchi in sola lettura, con conseguente appropriazione illecita di ingenti liquidità legate a questi protocolli, per un ammontare di milioni di dollari.

1- Attacco alla Piattaforma Sentiment:

Analisi dell'Attacco

In un notevole incidente avvenuto il 4 aprile 2023, la piattaforma Sentiment, operante sulla soluzione ampiamente adottata Layer 2, Arbitrum, è stata vittima di un attacco. L'atto malevolo ha coinvolto la manipolazione dei prezzi degli asset utilizzando una Reentrancy in sola lettura, con conseguente perdita significativa di circa un milione di dollari per la piattaforma.

Protocolli Coinvolti

Piattaforma Sentiment:

L'obiettivo principale della piattaforma Sentiment è affrontare le inefficienze di capitale offrendo una soluzione basata su primitive che consente il credito on-chain senza garanzie. Affronta la sfida del rischio di controparte diffuso attraverso l'ipoteca on-chain. Fondamentale per il protocollo Sentiment è il concetto di "Conto Sentiment", che concede agli utenti un accesso a leve più elevate rispetto ai tradizionali mercati finanziari. Gli asset presi in prestito da questi conti possono essere impiegati nell'ecosistema DeFi.

Protocollo Balancer:

Balancer è un protocollo di market maker automatizzato decentralizzato (AMM) costruito su Ethereum, che fornisce un blocco flessibile per la liquidità programmabile. Il componente centrale di Balancer è la Vault, un contratto intelligente responsabile della gestione e del possesso di tutti i token in ciascun pool di Balancer. Inoltre, il Vault funge da principale gateway per varie operazioni di Balancer, tra cui scambi, partecipazioni ed uscite.

Aave v3:

Il protocollo Aave è un protocollo di liquidità decentralizzato che consente agli utenti di partecipare come fornitori, mutuatari o liquidatori. Gli utenti che forniscono liquidità a un mercato possono guadagnare interesse sui loro asset crittografici forniti, mentre i mutuatari possono sovra-collateralizzarsi e prendere in prestito asset. Aave supporta anche "flash loan", che sono transazioni di prestito in un blocco che non richiedono sovra-collateralizzazione tradizionale.

Impatto dell'Attacco:

La piattaforma Sentiment si integra con i pool di Balancer, consentendo agli utenti di aprire conti con gli asset di Balancer. Per agevolare questa integrazione, la piattaforma Sentiment utilizza il contratto Vault di Balancer e il suo metodo getPrice(token). Tuttavia, ciò introduce una vulnerabilità agli attacchi di Reentrancy in sola lettura, che potrebbero portare alla manipolazione dei prezzi degli asset. Questo vettore di attacco potrebbe avere conseguenze gravi per la piattaforma Sentiment, potenzialmente comportando ingenti perdite finanziarie e minando la fiducia dei suoi utenti.

Risultato Positivo Dopo l'Attacco

Fortunatamente, il team di Sentiment è riuscito a invertire la situazione dopo l'attacco. Sono riusciti a recuperare con successo il 90% dei fondi rubati dall'aggressore e hanno lavorato diligentemente per recuperare la parte restante. Questa risoluzione positiva dimostra la prontezza di risposta del team e gli sforzi di recupero efficaci, portando a un esito favorevole a seguito dell'incidente.

2- Leggi il Nostro Ultimo Articolo sull'Attacco a Eraland

https://www.smartcontract.tips/articoli/zksync-based-lending-protocol-eralend-under-attack-34m-loss-uncovered

Mitigazione

L'approccio alla mitigazione degli attacchi di Reentrancy in sola lettura varia a seconda che si stia scrivendo un nuovo contratto o si stia leggendo un contratto già implementato.

Per i nuovi contratti, un metodo efficace di mitigazione prevede l'aggiunta di una protezione di Reentrancy in sola lettura. Questa protezione funziona verificando se il blocco di Reentrancy è attivo. Se il blocco è attivato, viene generato un errore, impedendo l'esecuzione ulteriore. Per garantire la trasparenza, il blocco può essere reso pubblico, consentendo ai contratti chiamanti di verificare se il contratto target è in modalità bloccata prima di procedere.

Per quanto riguarda i contratti esistenti, un modificatore di Reentrancy può essere implementato e chiamato come primo passo in qualsiasi esecuzione di funzione. Se il modificatore fallisce, indicando un potenziale attacco di Reentrancy, il contratto sarà posto in modalità bloccata e qualsiasi operazione di lettura successiva dovrebbe essere evitata per prevenire ulteriori vulnerabilità. Utilizzando questi metodi di mitigazione, gli sviluppatori possono migliorare la sicurezza e la robustezza dei loro smart contract contro gli attacchi di Reentrancy in sola lettura.