#8: Incidente SushiSwap: Uma Tentativa de Resgate Desajeitada Leva a uma Série de Ataques Imitadores

Em 9 de abril de 2023, a SushiSwap se tornou alvo de um exploit devido a um Parâmetro Externo Não Verificado. A perda total foi de aproximadamente $3,3 milhões.

Como um protocolo líder no Ethereum com uma base de usuários substancial, mesmo os principais protocolos ainda são suscetíveis a introduzir novos problemas graves durante atualizações de contratos. É um lembrete para a comunidade DeFi de que a segurança deve sempre ser a prioridade máxima. Além disso, este incidente de segurança foi desencadeado pela tentativa de resgate de um pesquisador de segurança whitehat, gerando um debate considerável dentro da comunidade, e fornecemos uma introdução sucinta a este incidente, destacando-o como um dos dez principais incidentes de segurança de 2023.

Contexto

SushiSwap

A SushiSwap, uma DEX renomada, lançou um ataque vampiro contra a Uniswap, obtendo um sucesso tremendo. Em seu auge, seu TVL atingiu $8 bilhões, e ainda mantém cerca de $400 milhões.

Aprovação

Em resumo: permissão para um contrato acessar e transferir um token específico da sua carteira.

Por conveniência, muitos contratos solicitam aprovação ilimitada por padrão. Muitos usuários, preocupados com riscos de segurança, depositam apenas pequenas quantias em vários protocolos. No entanto, esses usuários concedem aprovação ilimitada de fundos aos protocolos. Se um protocolo for comprometido, todos os tokens aprovados na conta poderão ser perdidos.

A Vulnerabilidade

Parâmetro Externo Não Verificado

A função processRoute() do contrato RouteProcessor2 permite que os usuários tenham controle total sobre o fluxo de chamadas (parâmetro route). E em uniswapV3SwapCallback(), o parâmetro from do safeTransferFrom() é decodificado a partir do route fornecido pelo usuário. Como resultado, usuários que aprovaram o contrato RouteProcessor2 perderam seus ativos.

O Processo do Ataque

Este incidente envolveu múltiplas transações de ataque, mas usaremos a primeira transação de ataque como exemplo. Transação: 0x43ff7e01423044cfb501b4fe9ef1386725c0ddc117dadd6e6620cb68bdeaf4f9

O atacante chamou a função processRoute() do contrato vulnerável RouteProcessor2 com um argumento longo route cuidadosamente construído.
processRouteInternal() cria um InputStream baseado no route fornecido pelo usuário.
A transação seguiu o route do atacante até chegar em swapUniV3(). Observe que o pool é decodificado do stream, o que significa que o atacante controlou em qual pool fazer o swap(), definindo-o como o lastCalledPool.
Isso chamou o contrato malicioso implantado pelo atacante, que então simplesmente passou calldata malicioso para fazer uma chamada de volta ao uniswapV3SwapCallback() do RouteProcessor2.
O uniswapV3SwapCallback() exige a verificação do msg.sender, mas como o lastCalledPool já havia sido definido como o contrato malicioso, o hacker contornou a verificação. Importante destacar que o parâmetro from do safeTransferFrom() foi decodificado a partir do calldata construído pelo atacante.
Os ativos da vítima são transferidos para o contrato malicioso implantado pelo atacante.

Resgate Whitehat Controverso

Vale mencionar que um whitehat com o nome de usuário @trust__90 identificou este problema e tentou resgatar os fundos, mas essa tentativa de resgate causou um desastre.

Usando o mempool para transmitir transações em vez de um RPC privado.
Tentando resgatar apenas 100 Ether em vez de todos os valores em risco.

Isso abriu caminho para MEV Bots e outros atacantes executarem múltiplas transações copiadas, drenando efetivamente a maior parte dos fundos. Após esses eventos, @trust__90 enfrentou críticas e tentou defender suas ações.

People are saying all kinds of terrible things while being uninformed so allow me to share more details.
I've initiated coordination privately with Immunefi officials 3 hours before the white-hack. 90 minutes later, I realized the asset is currently used by the frontend and…
— Trust (@trust__90) April 10, 2023

Resgate BlockSec

Neste ataque, também resgatamos 100 Ether e devolvemos os fundos à vítima, 0xsifu.

Hey, @0xsifu We have successfully blocked an attack transaction and rescued 100 Ether. Please get in touch with us.
— BlockSec (@BlockSecTeam) April 9, 2023

Até o momento, impedimos com sucesso mais de 20 ataques reais e resgatamos mais de $14.000.000 em ativos.

Recomendações de Segurança

Atualizações Devem Sempre Ser Auditadas

É um lembrete para a comunidade DeFi de que a segurança deve sempre ser a prioridade máxima. Auditorias não são uma garantia de segurança, mas a ausência de uma auditoria certamente não garante segurança.

Mitigações para o Problema de Aprovação

O ano de 2023 foi marcado por numerosos incidentes envolvendo ataques de aprovação, e aproveitamos esta oportunidade para reenfatizar a importância de gerenciar aprovações. Uma prática de segurança é aprovar apenas os valores necessários, ou, se a conveniência for uma prioridade, aprovar um valor ligeiramente maior do que o necessário.

O MetaSuites da BlockSec oferece um conveniente recurso de Diagnóstico de Aprovação. Além disso, ferramentas como o Revoke Cash podem ser usadas para verificar regularmente os status de aprovação.

Adote Mecanismos de Monitoramento e Resposta Automática

O Ethereum é uma floresta sombria, e todos na comunidade DeFi enfrentam diversos riscos e desafios, até mesmo especialistas em segurança. Em 2023, lançamos o Phalcon Security, o primeiro sistema de resposta automatizada do setor, projetado não apenas para monitorar ataques, mas para bloquear ativamente ameaças em tempo real. As capacidades testadas em batalha do Phalcon provaram sua eficácia ao impedir com sucesso mais de 20 ataques reais e resgatar mais de $14.000.000 em ativos. Essa inovação garante que todas as partes interessadas possam dormir mais tranquilamente à noite, sabendo que medidas proativas estão em vigor para proteger seus investimentos.