Przez BlockSec
8 listopada 2022 r. wykryliśmy, że niektóre ataki skutecznie wyczerpały zasoby z pul zbudowanych na oficjalnym kontrakcie KashiPairMediumRiskV1 firmy Sushi (lub niektórych kontraktach, które się z niego rozwidlają). Po zbadaniu sprawy odkryliśmy, że przyczyną jest błąd logiczny, który powoduje błędne obliczenie cen tokenów.
Natychmiast skontaktowaliśmy się z zespołem ds. bezpieczeństwa Sushi, a oni potwierdzili nasze ustalenia. Dobrą rzeczą było to, że podejmowali działania w celu ochrony niektórych cennych, ale podatnych na ataki puli. Ponadto udostępnili również procedury rekompensaty tym, którzy stracili fundusze z powodu exploita. W związku z tym uważamy, że teraz można bezpiecznie ujawnić szczegóły dotyczące podatności i ataków. W tym raporcie chcielibyśmy przedstawić szczegółową analizę.
Analiza podatności
Po przeanalizowaniu kodu źródłowego kontraktu KashiPairMediumRiskV1 doszliśmy do wniosku, że błąd ten leży w funkcji pożyczania, która używa przestarzałego exchangeRate do weryfikacji pożyczonego udziału w modyfikatorze rozpuszczalnika. Dokładniej rzecz biorąc, weryfikacja zostanie przeprowadzona na podstawie bieżącej wartości exchangeRate w funkcji _isSolvent.
Podczas gdy funkcja liquidate jest wywoływana na samym początku, funkcja updateExchangeRate jest wywoływana. W związku z tym weryfikacja i obliczenia zostaną wykonane na podstawie zaktualizowanej wartości.
Oczywiste jest, że błąd ten można wykorzystać do spowodowania (ogromnej) różnicy cen.
Analiza ataków
Zaobserwowaliśmy dwa ataki:
https://etherscan.io/tx/0xcf8f242ea83100b6d43e659f7f53a698d304fc6ac2ca6fe79e3e07ee05fefe58: ofiara korzysta z kontraktu KashiPairMediumRiskV1, a strata wynosi około 9466 USDC.
https://etherscan.io/tx/0x3d163bfbec5686d428a6d43e45e2626a220cc4fcfac7620c620b82c1f2537c78: ofiarą jest kontrakt strategiczny wykorzystujący CauldronMediumRiskV1 (fork KashiPairMediumRiskV1), a strata wynosi około 110 911 MIM.
Należy pamiętać, że pierwsza transakcja ataku została uruchomiona przez bota, który wyprzedza oryginalną transakcję ataku: https://etherscan.io/tx/0x7a845d8d2af7919f5b9e22dd5571305cb5347d17986a8402715c1463d515fc18, a oryginalny adres atakującego to 0xb7ea0f0f8c6df7a61bf024db21bbe85ac5688005.
Jako przykład weźmiemy pierwszą transakcję ataku, która składa się z następujących kroków:
Pożyczenie błyskawicznej pożyczki w wysokości 40 900 BADGER i 121 904 USDC od Balancer.
Wpłata 40 900 BADGER i 113 599 USDC na konto BentoBox.
Wywołanie funkcji addCollateral w kmBADGER/USDC-LINK w celu zdeponowania 40 900 000 000 000 000 000 000 akcji BADGER.
Wywołanie funkcji addAsset programu kmBADGER/USDC-LINK w celu zdeponowania 112 529 000 000 akcji USDC.
Wywołanie funkcji pożyczki w celu pożyczenia 120 755 095 093 akcji USDC.
Wywołanie funkcji UpdateExchangeRate.
Wywołanie funkcji likwidującej w celu likwidacji samego siebie.
Wypłać 40 899 BADGER i 123 006 USDC z BentoBox.
Spłata pożyczki błyskawicznej i uzyskanie zysku w wysokości około 9466 USDC.
Należy pamiętać, że krok 6 nie jest konieczny, ponieważ funkcja pożyczenia wywoła funkcję UpdateExchangeRate.
Kluczowe kroki są następujące:
Łatwo zauważyć, że wartość parametru exchangeRate używana w funkcji pożyczkowej różni się od wartości używanej w funkcji likwidacyjnej:
W funkcji pożyczania: 250 997 938 545 109 237 740 214 705 193
W funkcji likwidacyjnej: 328 266 883 541 864 569 505 752 156 794
Wpływ
Istnieją dziesiątki pul (zarówno na Ethereum, jak i BSC), których może dotyczyć ten błąd. Tymczasową metodą złagodzenia tego problemu jest zmniejszenie lub wyeliminowanie odchylenia poprzez okazjonalne (lub okresowe) wywoływanie funkcji UpdateExchangeRate. Tę metodę przyjęto już w wielu dotkniętych tym problemem projektach, a odpowiadające im transakcje można zaobserwować w praktyce.