Resumo
Platypus Finance é um protocolo AMM na blockchain Avalanche. Ele já foi atacado três vezes, conforme descrito a seguir:
- Em 17 de fevereiro de 2023, sofreu um ataque devido a uma verificação de solvência incorreta, resultando em uma perda total de cerca de US$ 9,05 milhões. Desse total, US$ 2,4 milhões foram resgatados com a ajuda da BlockSec. Aproximadamente 380 mil tokens ficaram presos no contrato da Aave e foram posteriormente devolvidos.
- Em 12 de julho de 2023, foi hackeado, com cerca de US$ 50 mil perdidos devido à ignorância da diferença de preço entre stablecoins.
- Em 12 de outubro de 2023, sofreu ataques de manipulação de preço, com cerca de US$ 2,2 milhões perdidos. Após negociações com o explorador, 90% dos fundos roubados foram devolvidos.
O projeto tem sorte de ter sobrevivido a todos esses ataques. Nossa análise dessas três explorações mostra que as falhas lógicas poderiam ter sido evitadas se uma auditoria cuidadosa ou medidas de segurança mais ativas fossem utilizadas.
Ataque Um
Para entender esse incidente de segurança, é preciso compreender o fluxo de trabalho de vários contratos inteligentes. O processo, de forma resumida, é o seguinte:
- Um usuário pode depositar um token em um pool para se tornar um LP e receber um token LP.
- O token LP pode ser colocado em staking no MasterPlatypus para receber recompensas. O token LP será transferido para o contrato MasterPlatypus durante esse processo.
- O token LP pode ser usado como garantia para emprestar outros ativos e melhorar a eficiência dos ativos.
A figura a seguir mostra as interações.
Análise da Vulnerabilidade
A vulnerabilidade existe em uma função chamada emergencyWithdraw dentro do contrato MasterPlatypus. Em emergências, essa função deveria ser usada para retirar os tokens LP em staking no contrato MasterPlatypus. Nessa função, o contrato verifica se o usuário está Solvent (solvente) para permitir a retirada. A lógica verifica se os usuários têm alguma dívida ruim (ou seja, se a garantia pode ser usada para pagar a dívida). Se não, os usuários podem retirar os tokens LP em staking.
No entanto, essa lógica é falha. O fato de o usuário estar Solvent significa apenas que a garantia do usuário pode pagar sua dívida. No entanto, isso NÃO verifica se o usuário permanece Solvent após retirar emergencialmente os tokens em staking. Um atacante pode aproveitar essa falha para pedir emprestado os ativos e, em seguida, retirar emergencialmente os tokens LP em staking também (sem pagar as dívidas). Veja a análise detalhada no Blog da Immunefi.
Análise do Ataque
Usamos uma transação de ataque como exemplo para mostrar todo o processo de ataque.
Passo 1: Pedir emprestado 44 milhões de USDC via Flashloan da AAVE
Passo 2: Depositar 44 milhões de USDC no pool para obter LP-USDC
Passo 3: Depositar LP-USDC no MasterPlatypus
Passo 4: Usar LP-USDC como garantia para pedir USP emprestado
Passo 5: Executar a função emergencyWithdraw para lançar o ataque
O atacante obtém o LP-USDC sem pagar a dívida de USP.
Passo 6: Retirar LP-USDC do pool para obter USDC
Passo 7: Vender USP para obter lucro
No entanto, os lucros ficam retidos dentro do contrato de ataque. Na verdade, o atacante pode configurar um novo endereço de recebimento para o swap para obter os lucros.
Resgate da BlockSec
Descobrimos que o atacante deixou os lucros dentro do contrato de ataque. Além disso, não há lógica dentro do contrato de ataque para retirar os ativos. No entanto, encontramos uma vulnerabilidade no contrato de ataque, que pôde ser aproveitada para "hackear de volta" e retirar parte dos ativos dentro do contrato.
Especificamente, há um controle de acesso na função de callback do flashloan, o que significa que qualquer pessoa pode invocar essa função de callback. Essa também é a causa raiz de muitos bots de MEV sendo atacados.
Além disso, dentro da função de callback, o contrato do atacante aprova o token USDC para o contrato do pool da Platypus Finance. E esse contrato do pool é atualizável (upgradable)!
Combinando os dois pontos anteriores, pudemos resgatar o USDC dentro do contrato de ataque ao
- Atualizar o contrato do pool da Platypus Finance para incluir uma lógica de retirada do USDC dentro do contrato
- Invocar o callback do contrato de ataque para aprovar o USDC ao contrato do pool
- O contrato do pool pode substituir qualquer função (que será executada pelo contrato de ataque) para transferir o USDC do contrato de ataque (já que o contrato de ataque aprova o USDC para o contrato do pool).
Aqui está a transação para resgatar 2,4 milhões de USDC.
Outros Dois Ataques
Consulte os links a seguir para mais detalhes sobre os outros dois ataques.
-
Ataque-II: 11 de julho de 2023, o protocolo presume que a proporção entre USDC e USDT é 1:1, o que se desvia das flutuações de mercado, resultando em uma lógica de retirada falha. O link para uma transação de ataque. Há várias delas.
-
Ataque-III: 12 de outubro de 2023, devido à manipulação de
casheliability, o que afetou o preço de swap. [A primeira transação de ataque | A segunda transação de ataque]
Resumo
Os três ataques exploraram vulnerabilidades diferentes no protocolo. Mesmo que outros fornecedores tenham auditado o protocolo, o atacante ainda encontrou a brecha e explorou o protocolo com sucesso. Felizmente, alguns ativos foram resgatados, mas não podemos esperar ter sorte sempre. Mais medidas de segurança incluindo monitoramento de ataques e resposta automática devem ser adotadas para proteger o protocolo e os ativos dos usuários.
Leia outros artigos desta série:
- Introdução: As Dez "Incríveis" Incidentes de Segurança de 2023
- #1: Colhendo Bots de MEV ao Explorar Vulnerabilidades no Relay do Flashbots
- #2: Incidente da Euler Finance: O Maior Hack de 2023
- #3: Incidente da KyberSwap: Exploração Magistral de Erros de Arredondamento com Cálculos Extremamente Sutis
- #4: Incidente da Curve: Erro do Compilador Produz Bytecode Defeituoso a Partir de Código-Fonte Inocente
- #6: Incidente da Hundred Finance: Catalisando a Onda de Explorações Relacionadas à Precisão em Protocolos Bifurcados Vulneráveis
- #7: Incidente da ParaSpace: Uma Corrida Contra o Tempo para Frustrar o Ataque Mais Crítico da Indústria até Agora
- #8: Incidente da SushiSwap: Uma Tentativa de Resgate Desajeitada Leva a uma Série de Ataques Imitadores
- #9: Bot de MEV 0xd61492: De Predador a Presa em uma Exploração Engenhosa
- #10: Incidente da ThirdWeb: Incompatibilidade Entre Módulos Confiáveis Expõe Vulnerabilidade
