Resumo
Platypus Finance é um protocolo AMM na blockchain Avalanche. Ele foi atacado três vezes, conforme descrito a seguir:
- Em 17 de fevereiro de 2023, sofreu um hack devido a uma verificação de solvência incorreta, resultando em uma perda total de aproximadamente $9,05M. Desse valor, $2,4M foi resgatado com a ajuda da BlockSec. Aproximadamente 380K tokens ficaram presos no contrato Aave e foram posteriormente devolvidos.
- Em 12 de julho de 2023, foi hackeado, com cerca de $50K perdidos devido à desconsideração 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 $2,2M perdidos. Após negociação com o explorador, 90% dos fundos roubados foram devolvidos.
O projeto teve a sorte de sobreviver a todos esses ataques. Nossa análise desses três exploits mostra que as falhas lógicas poderiam ter sido evitadas caso uma auditoria cuidadosa ou medidas de segurança mais ativas tivessem sido utilizadas.
Ataque Um
Para entender este incidente de segurança, é necessário compreender o fluxo de trabalho de vários contratos inteligentes. O processo geral é 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 tomar emprestado 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 deve ser usada para retirar os tokens LP em staking no contrato MasterPlatypus. Nessa função, o contrato verifica se o usuário é Solvent (Solvente) para permitir a retirada. A lógica verifica se os usuários possuem alguma dívida inadimplente (ou seja, se a garantia pode ser usada para pagar a dívida). Caso contrário, os usuários podem retirar os tokens LP em staking.
No entanto, essa lógica é falha. O fato de o usuário ser Solvent significa apenas que a garantia do usuário pode pagar sua dívida. Porém, isso NÃO verifica se o usuário permanece Solvente após retirar emergencialmente os tokens em staking. Um atacante pode explorar essa falha para tomar emprestado os ativos e então 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
Utilizamos uma transação de ataque como exemplo para mostrar todo o processo do ataque.
Passo 1: Tomar 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 tomar emprestado USP
Passo 5: Executar a função emergencyWithdraw para lançar o ataque
O atacante obtém o LP-USDC sem pagar a dívida em USP.
Passo 6: Retirar LP-USDC do pool para obter USDC
Passo 7: Vender USP para obter lucros
No entanto, os lucros ficaram dentro do contrato do ataque. Na verdade, o atacante poderia ter configurado um novo endereço de recebimento para o swap a fim de obter os lucros.
Resgate da BlockSec
Descobrimos que o atacante deixou os lucros dentro do contrato do ataque. Além disso, não há lógica dentro do contrato do ataque para retirar os ativos. No entanto, encontramos uma vulnerabilidade no contrato do ataque, que pode ser explorada para realizar um contra-ataque e retirar parte dos ativos dentro do contrato.
Especificamente, há um controle de acesso da 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 MEV serem 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 de pool é atualizável!
Combinando os dois pontos anteriores, podemos resgatar o USDC dentro do contrato do ataque ao:
- Atualizar o contrato do pool da Platypus Finance para incluir uma lógica que retire o USDC de dentro do contrato
- Invocar o callback do contrato do ataque para aprovar o USDC para o contrato do pool
- O contrato do pool pode substituir qualquer função (que será executada pelo contrato do ataque) para transferir o USDC do contrato do ataque (já que o contrato do ataque aprovou o USDC para o contrato do pool).
Aqui está a transação para resgatar 2,4 milhões de USDC.
Os Outros Dois Ataques
Consulte os links a seguir para obter mais detalhes sobre os outros dois ataques.
-
Ataque-II: 11 de julho de 2023, o protocolo assume que a proporção entre USDC e USDT é 1:1, o que diverge das flutuações do mercado, resultando em uma lógica de retirada falha. O link para uma transação de ataque. Há algumas outras.
-
Ataque-III: 12 de outubro de 2023, devido à manipulação de
casheliabilityque afetou o preço do swap. [A primeira transação de ataque | A segunda transação de ataque]
Resumo
Os três ataques exploraram diferentes vulnerabilidades no protocolo. Mesmo que outros fornecedores tenham auditado o protocolo, o atacante ainda encontrou a brecha e o explorou com sucesso. Felizmente, alguns ativos foram resgatados, mas não podemos esperar ter sempre essa sorte. 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: Os Dez Principais Incidentes de Segurança "Incríveis" de 2023
- #1: Colhendo Bots MEV ao Explorar Vulnerabilidades no Flashbots Relay
- #2: Incidente Euler Finance: O Maior Hack de 2023
- #3: Incidente KyberSwap: Exploração Magistral de Erros de Arredondamento com Cálculos Extremamente Sutis
- #4: Incidente Curve: Erro de Compilador Produz Bytecode Defeituoso a partir de Código-Fonte Inocente
- #6: Incidente Hundred Finance: Catalisando a Onda de Exploits Relacionados à Precisão em Protocolos Bifurcados Vulneráveis
- #7: Incidente ParaSpace: Uma Corrida Contra o Tempo para Frustrar o Ataque Mais Crítico da Indústria até Agora
- #8: Incidente SushiSwap: Uma Tentativa de Resgate Desajeitada Leva a uma Série de Ataques Imitadores
- #9: Bot MEV 0xd61492: De Predador a Presa em um Exploit Engenhoso
- #10: Incidente ThirdWeb: Incompatibilidade Entre Módulos Confiáveis Expõe Vulnerabilidade
