Di BlockSec
L'8 novembre 2022, abbiamo rilevato che alcuni attacchi hanno drenato con successo risorse dai pool creati sulla base del contratto ufficiale KashiPairMediumRiskV1 di Sushi (o di alcuni contratti che ne derivano). Dopo un'indagine, abbiamo scoperto che la causa principale è dovuta a un bug logico che causa un errore di calcolo dei prezzi dei token.
Abbiamo immediatamente contattato il team di sicurezza di Sushi e hanno confermato le nostre scoperte. La cosa positiva era che stavano agendo per proteggere alcuni pool preziosi ma vulnerabili dagli attacchi. Inoltre, hanno anche previsto procedure per risarcire coloro che hanno perso fondi a causa dell’exploit. Pertanto, ora riteniamo che sia sicuro rivelare i dettagli sulla vulnerabilità e sugli attacchi. In questo rapporto, vorremmo fornire un’analisi dettagliata.
Analisi della vulnerabilità
Dopo aver analizzato il codice sorgente del contratto KashiPairMediumRiskV1, concludiamo che questo bug risiede nella funzione di prestito, che utilizza l'obsoleto exchangeRate per verificare la quota presa in prestito nel modificatore solvente. Nello specifico, la verifica verrà eseguita in base al valore corrente di exchangeRate nella funzione _isSolvent.
Mentre nella funzione liquidate, la funzione updateExchangeRate viene richiamata all'inizio. Quindi la verifica e il calcolo verranno eseguiti in base al valore aggiornato.
Ovviamente, questo bug potrebbe essere sfruttato per ottenere una (enorme) differenza di prezzo.
Analisi dell'attacco
Abbiamo osservato due attacchi:
https://etherscan.io/tx/0xcf8f242ea83100b6d43e659f7f53a698d304fc6ac2ca6fe79e3e07ee05fefe58: la vittima utilizza il contratto KashiPairMediumRiskV1 e la perdita ammonta a circa 9.466 USDC.
https://etherscan.io/tx/0x3d163bfbec5686d428a6d43e45e2626a220cc4fcfac7620c620b82c1f2537c78: la vittima è un contratto strategico che utilizza CauldronMediumRiskV1 (il fork di KashiPairMediumRiskV1) e la perdita è di circa 110.911 MIM.
Si noti che la prima transazione di attacco è stata avviata da un bot che anticipa la transazione di attacco originale: https://etherscan.io/tx/0x7a845d8d2af7919f5b9e22dd5571305cb5347d17986a8402715c1463d515fc18, e l'indirizzo dell'attaccante originale è 0xb7ea0f0f8c6df7a61bf024db21bbe85ac5688005.
Qui prendiamo come esempio la prima transazione di attacco, che consiste nei seguenti passaggi:
Richiedere un prestito flash di 40.900 BADGER e 121.904 USDC da Balancer.
Deposito di 40.900 BADGER e 113.599 USDC su BentoBox.
Richiamo della funzione addCollateral di kmBADGER/USDC-LINK per depositare 40.900.000.000.000.000.000.000 azioni BADGER.
Richiamo della funzione addAsset di kmBADGER/USDC-LINK per depositare 112.529.000.000 di azioni USDC.
Richiamo della funzione di prestito per prendere in prestito 120.755.095.093 azioni USDC.
Richiamo della funzione UpdateExchangeRate.
Invocando la funzione liquidate per liquidare se stessa.
Preleva 40.899 BADGER e 123.006 USDC da BentoBox.
Rimborsando il prestito flash e ottenendo un profitto di circa 9466 USDC.
Si noti che il passaggio 6 non è necessario, perché la funzione borrow invocherà la funzione UpdateExchangeRate.
I passaggi chiave sono i seguenti:
Non è difficile capire che il valore di exchangeRate utilizzato nella funzione borow si discosta dal valore utilizzato nella funzione liquidate:
Nella funzione di prestito: 250.997.938.545.109.237.740.214.705.193
Nella funzione di liquidazione: 328.266.883.541.864.569.505.752.156.794
L'impatto
Ci sono decine di pool (sia su Ethereum che su BSC) che potrebbero essere interessati da questo bug. Un metodo temporaneo per mitigare questo problema è quello di ridurre o eliminare la deviazione invocando la funzione UpdateExchangeRate occasionalmente (o periodicamente). Questo metodo è già stato adottato da molti progetti interessati e le transazioni corrispondenti possono essere osservate in natura.