Por BlockSec
Em 8 de novembro de 2022, detectamos que alguns ataques drenaram com sucesso ativos de pools construídos com base no contrato oficial KashiPairMediumRiskV1 do Sushi (ou em alguns contratos derivados dele). Após investigação, descobrimos que a causa raiz se deve a um bug lógico que causa o erro de cálculo dos preços dos tokens.
Entramos imediatamente em contato com a equipe de segurança do Sushi e eles confirmaram nossas descobertas. O bom é que eles estavam tomando medidas para proteger alguns grupos valiosos, mas vulneráveis, de serem atacados. Além disso, também forneceram procedimentos para compensar aqueles que perderam fundos com a exploração. Como tal, acreditamos agora que é seguro divulgar os detalhes sobre a vulnerabilidade e os ataques. Neste relatório, gostaríamos de fornecer uma análise detalhada.
Análise de Vulnerabilidade
Depois de analisar o código-fonte do contrato KashiPairMediumRiskV1, concluímos que esse bug está na função de empréstimo, que usa o exchangeRate desatualizado para verificar a parcela emprestada no modificador de solvente. Especificamente, a verificação será realizada com base no valor atual de exchangeRate na função _isSolvent .
Enquanto estiver na função liquidate, a função updateExchangeRate é invocada logo no início. Portanto a verificação e o cálculo serão realizados com base no valor atualizado.
Obviamente, este bug poderia ser explorado para levar a uma (enorme) diferença de preço.
Análise de Ataque
Observamos dois ataques:
https://etherscan.io/tx/0xcf8f242ea83100b6d43e659f7f53a698d304fc6ac2ca6fe79e3e07ee05fefe58: a vítima usa o contrato KashiPairMediumRiskV1 e a perda é de cerca de 9.466 USDC.
https://etherscan.io/tx/0x3d163bfbec5686d428a6d43e45e2626a220cc4fcfac7620c620b82c1f2537c78: a vítima é um contrato de estratégia que usa CauldronMediumRiskV1 (o fork de KashiPairMediumRiskV1) e a perda é de cerca de 110.911 MIM .
Observe que a primeira transação de ataque foi lançada por um bot que executa a transação de ataque original: https://etherscan.io/tx/0x7a845d8d2af7919f5b9e22dd5571305cb5347d17986a8402715c1463d515fc18, e o endereço original do invasor é 0xb7ea0f0f8c6df7 a61bf024db21bbe85ac5688005.
Aqui tomamos a primeira transação de ataque como exemplo, que consiste nas seguintes etapas:
Emprestando um flashloan de 40.900 BADGER e 121.904 USDC do Balancer.
Depositando 40.900 BADGER e 113.599 USDC na BentoBox.
Invocando a função addCollateral de kmBADGER/USDC-LINK para depositar 40.900.000.000.000.000.000.000 ações da BADGER.
Invocando a função addAsset de kmBADGER/USDC-LINK para depositar 112.529.000.000 ações de USDC.
Invocando a função de empréstimo para emprestar 120.755.095.093 ações do USDC.
Invocando a função UpdateExchangeRate .
Invocando a função liquidar para se liquidar.
Retire 40.899 BADGER e 123.006 USDC da BentoBox.
Reembolsando o flashloan e obtendo um lucro de cerca de 9.466 USDC.
Observe que a etapa 6 não é necessária, porque a função de empréstimo invocará a função UpdateExchangeRate.
As principais etapas são as seguintes:
Não é difícil descobrir que o valor de exchangeRate usado na função de emprestar se desvia do valor usado na função de liquidar :
Na função emprestar : 250.997.938.545.109.237.740.214.705.193
Na função liquidar : 328.266.883.541.864.569.505.752.156.794
O impacto
Existem dezenas de pools (tanto no Ethereum quanto no BSC) que podem ser afetados por esse bug. Um método temporário para atenuar esse problema é reduzir ou eliminar o desvio invocando a função UpdateExchangeRate ocasionalmente (ou periodicamente). Este método já foi adoptado por muitos projectos afectados e as transacções correspondentes podem ser observadas em estado selvagem.