Neste blog, queremos revisar todo o processo do Hack da Poly Network e discutir as lições aprendidas.
Soubemos que a Poly Network estava sendo hackeada em 10 de agosto de 2021 (usamos o fuso horário +8 neste blog). No entanto, não havia nenhuma pista de como o hack estava acontecendo e qual era a causa raiz do ataque. Como equipe de pesquisa em segurança, iniciamos nossa investigação.
Passo 1: Encontrar a transação do ataque
Reproduzimos a transação do ataque 0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a em nosso sistema de virtualização de transações (https://tx.blocksecteam.com).
O rastreamento é bastante simples, o que é diferente de outros ataques que manipulam o preço. Eles geralmente têm invocações de funções muito complicadas (Veja o hack do Popsicle.)
Passo 2: Analisar o código do contrato
Após obter o rastreamento do ataque, precisamos revisar o código-fonte do contrato. Surpreendentemente, a Poly Network NÃO possui código-fonte verificado no Etherscan. No entanto, conseguimos encontrar o código-fonte publicado no GitHub.
Após revisar o código-fonte, não encontramos nenhuma vulnerabilidade óbvia no código. Também comparamos o rastreamento do ataque com um rastreamento de transação legítima e descobrimos que eles são semelhantes.
Passo 3: Recuperar os estados críticos
Em seguida, recuperamos os estados críticos durante o ataque. Como o ataque é iniciado a partir da invocação de VerifyHeaderAndExecuteTxEvent, recuperamos vários valores de variáveis críticas, que compartilhamos em nossa primeira análise [1].
Durante esse processo, descobrimos que há apenas um keeper (veja a figura acima). Como o valor é obtido do rastreamento do ataque e a transação do ataque passou por toda a verificação de assinatura, pensamos que a razão potencial poderia ser o vazamento da chave privada ou um bug no processo de assinatura do servidor [1].
No entanto, cometemos um erro aqui. Analisar um ataque é como descascar uma cebola. Você descasca uma camada de cada vez, até localizar a "causa raiz raiz raiz" real. Naquele momento, não descascamos a cebola mais a fundo para verificar se o keeper havia sido alterado!
Passo 4: Nova pista
Algumas horas depois, Kelvin e o slow mist deram novas pistas no Twitter, mostrando que o keeper havia sido alterado. O processo de alteração abusa da colisão de hash para invocar uma função poderosa — um hack "inteligente".
Agora percebemos que nossa primeira análise não estava completa. Com base nas informações mais recentes, reproduzimos a transação que alterou o keeper. O rastreamento ainda é muito simples.
Mas lembre-se de que, durante essa transação, há quatro keepers (em vez de um). Todas essas chaves são as mesmas que as de outras transações legítimas — o que significa que as chaves são legítimas. Aqui surge a questão: por que a transação que altera o keeper pode ser incluída na cadeia e executada em primeiro lugar?
Passo 5: Localizar a transação de origem
Em seguida, tentamos localizar a transação de origem, pois a Poly Network é uma ponte cross-chain. Deve existir uma transação de origem em algum lugar. Fizemos isso decodificando a variável crítica (como mostrado na figura a seguir). Ela mostra o hash da transação da cadeia de origem e da poly chain.
Há um truque que não foi mencionado em nenhum outro lugar. O valor do hash da transação na variável tem uma representação diferente do valor oficial na poly chain. Por exemplo, o hash da transação da poly chain na figura é 0x80cc978479eb082e1e656993c63dee7a5d08a00dc2b2aab88bc0e465cfa0721a. Mas no explorador da poly chain, o valor do hash é 1a72a0cf65e4c08bb8aab2c20da0085d7aee3dc69369651e2e08eb798497cc80 (você percebe a diferença?). Compartilhamos nossas descobertas no grupo do EthereumSecurity no Telegram em 11 de agosto às 16:55.
Passo 6: Localizar a causa raiz
Mas ainda assim, não conseguíamos responder à pergunta "por que a transação para alterar o keeper" pode ser incluída na cadeia? Para responder a essa pergunta, começamos pela cadeia Ontology e encontramos o fluxo de transações:
Transação Ontology -> Relayer Ontology -> Poly chain -> Relayer Ethereum -> Ethereum
Em seguida, lemos o código-fonte da cadeia Ontology e dos relayers. Após algumas horas, descobrimos que o relayer da Ontology não possui validação suficiente para a transação cross-chain. Isso permite que a transação maliciosa seja incluída na poly chain. Após isso, o sistema foi comprometido.
Após discussão e desafios internos, publicamos nossas descobertas em 12 de agosto às 02:41 no Twitter e no Medium [3].
Lições
-
Segurança por design. A segurança deve estar em todo o processo do projeto DeFi. Os usuários confiam seu dinheiro ao projeto. Em contrapartida, o projeto deve merecer essa confiança. Infelizmente, vimos a negligência com a segurança por parte da Poly Network. Por exemplo, a falta de validação é uma vulnerabilidade de segurança antiga, que eu ensinei em aulas de graduação.
-
Não há código-fonte verificado para um projeto DeFi com mais de 600M em TVL. A base da infraestrutura descentralizada é a confiança, e o alicerce dessa confiança é a transparência. Infelizmente, os usuários estão dispostos a colocar seu dinheiro em um projeto de caixa preta, o que me surpreende e preocupa. Como melhorar o senso de segurança dos usuários provavelmente requer uma nova solução.
Referências
[1]https://blocksecteam.medium.com/the-initial-analysis-of-the-polynetwork-hack-270ac6072e2a
[2]https://twitter.com/kelvinfichter/status/1425290462076747777
[3]https://blocksecteam.medium.com/the-further-analysis-of-the-poly-network-attack-6c459199c057
Créditos: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @ BlockSecTeam
