A PolyNetwork foi hackeada e mais de 300 milhões de dólares foram roubados. O atacante realizou o ataque em múltiplas redes. Neste blog, usamos a transação do ataque na Ethereum (0xd8c1f7424593ddba11a0e072b61082bf3d931583cb75f7843fc2a8685d20033a) para analisar a possível razão do hack. Nossa análise inicial mostra que uma possível razão pode ser tanto o vazamento da chave privada usada para assinar a mensagem cross-chain, quanto a existência de um bug no processo de assinatura da PolyNetwork que foi explorado para assinar uma mensagem forjada.
Aviso: Este blog contém apenas o resultado de nossa análise inicial com base nos dados onchain na Ethereum. Não podemos verificar nossas descobertas sem informações adicionais da Poly Network.
Atualização 2021/08/12: As informações adicionais mostram que a causa do ataque ocorreu porque o keeper foi modificado pelo atacante (e não por causa do vazamento da chave privada). Temos uma análise mais aprofundada para responder à pergunta de por que a transação para alterar o keeper pôde ser executada em primeiro lugar.
Transação e rastreamento de chamadas
Usamos nosso sistema de análise de transações para recuperar o rastreamento.
Atacante -> EthCrossChainManager -> EthCrossChainData -> LockProxy -> managerProxyContractforLockProxy
- 0xc8a65fadf0e0ddaf421f28feab69bf6e2e589963: Atacante
- 0x838bf9e95cb12dd76a54c9f9d2e3082eaf928270: EthCrossChainManager
- 0xcf2afe102057ba5c16f899271045a0a37fcb10f2: EthCrossChainData
- 0x250e76987d838a75310c34bf422ea9f1ac4cc906: LockProxy
- 0x5a51e2ebf8d136926b9ca7b59b60464e7c44d2eb: managerProxyContract para LockProxy
Assinaturas de Funções:
- d450e04c (verifyHeaderAndExecuteTx)
- 69d48074 (getCurEpochConPubKeyBytes)
- 5ac40790 (getCurEpochStartHeight)
- 0586763c (checkIfFromChainTxExist)
- e90bfdcf (markFromChainTxExist(uint64,bytes32))
O processo principal do ataque
O processo principal do ataque consiste no atacante passando os dados assinados para a função verifyHeaderAndExecuteTx(). Essa função decodificará os dados e verificará as assinaturas usadas para assinar os dados. Se esse processo for bem-sucedido, o método (e o endereço do contrato) especificado na mensagem será executado. Durante esse ataque, a função unlock do contrato inteligente 0x250e76987d838a75310c34bf422ea9f1ac4cc906 é invocada para transferir o Fei para o atacante.
Em resumo, o ataque ocorre devido aos parâmetros válidos passados para a função verifyHeaderAndExecuteTx. E os parâmetros conseguem passar pelo processo de verificação de assinatura. Após isso, a transação especificada na mensagem será executada (semelhante à execução arbitrária de comandos em segurança de software).
Para melhor compreender esse processo, recuperamos os valores críticos do rastreamento de chamadas.
Função: verifyHeaderAndExecuteTx:
verifySig
unlock
A variável managerProxyContract no LockProxy. Ela corresponde ao valor do endereço do chamador da função unlock.
Conclusão
A partir dos valores recuperados, descobrimos que:
- O atacante fornece uma mensagem assinada válida para a função verifyHeaderAndExecuteTx
- O modificador
onlyManagerContractno contrato inteligente LockProxy NÃO foi contornado.
Com base nessas duas observações, suspeitamos que:
- O atacante pode ter as chaves legítimas para assinar as mensagens, o que indica que as chaves de assinatura podem ter sido vazadas.
Ou
- Existe um bug no processo de assinatura da PolyNetwork que foi explorado para assinar uma mensagem forjada.
No entanto, não temos dados adicionais offchain para verificar nossas descobertas. Esperamos que nossa análise possa ser útil para investigações futuras.
Créditos: Yufeng Hu, Siwei Wu, Lei Wu, Yajin Zhou @BlockSec
Twitter: https://twitter.com/BlockSecTeam
