De acordo com o relatório de tesouraria da THORChain para o primeiro trimestre de 2022, divulgado em 1º de abril, a rede registrou um crescimento na receita, apesar do duplo impacto da persistente lentidão do mercado e de fatores geopolíticos altamente instáveis. Dados públicos mostram que a THORChain registrou receita de US$ 2,17 bilhões no primeiro trimestre de 2022. A THORChain, aclamada como a “versão cross-chain do UniSwap”, ganhou uma posição segura no mercado de negociação cross-chain com base em suas vantagens exclusivas e ganhou amplo reconhecimento entre os investidores.
Por trás de todo esse glamour, THORChain também está profundamente preocupado com hackers. A rede sofreu frequentes violações de segurança desde que foi lançada no Ethereum, fato que coloca em dúvida sua segurança. Em 11 de abril, THORChain tuitou sobre ataques de phishing, alertando os usuários para não interagirem com [DeTHOR] ou outros tokens desconhecidos em suas carteiras, o que mais uma vez levantou preocupações sobre seus problemas de segurança.
Ao construir um sistema de segurança sólido para produtos CoinEx, a equipe de segurança da CoinEx também acompanha incidentes de segurança no espaço blockchain para ajudar os usuários a entender melhor a segurança de diferentes projetos do ponto de vista da segurança técnica e mitigar o risco de investimento. Com o objetivo de melhorar os critérios de segurança para o setor blockchain, a equipe de segurança da CoinEx analisou os riscos de segurança do THORChain (RUNE). A equipe espera que o THORChain possa observar e mitigar os seguintes riscos, otimizando os códigos de contrato inteligentes relevantes. Além disso, este artigo também é um alerta aos usuários, lembrando-os de estarem mais atentos à segurança patrimonial e evitar perdas patrimoniais.
Quão seguro é o THORChain (RUNE)?
Através da análise do código do contrato e da lógica do THORChain (RUNE), a equipe de segurança da CoinEx encontrou os seguintes riscos.
Para começar, vamos verificar o código do contrato do THORChain (RUNE): https://etherscan.io/address/0x3155ba85d5f96b2d030a4966af206230e46849cb#code
Podemos dizer que RUNE é um token ERC-20 bastante padrão. Deve-se notar que além da interface ERC-20, THORChain (RUNE) oferece uma interface adicional:
De acordo com transferTo (conforme mostrado na imagem acima), THORChain (RUNE) usa tx.origin, que é uma das causas por trás de seus riscos de segurança. Aqui, devemos explicar a diferença entre tx.origin e msg.sender:
A imagem abaixo descreve o que acontece quando um endereço normal chama o contrato inteligente:
Nesses casos, msg.sender = account.address e tx.origin = account.address, o que significa que msg.sender é igual a tx.origin.
Veja a seguir o que acontece quando uma conta chama o contrato A e o contrato A chama o contrato B:
Quando o contrato A chama o contrato B (conforme mostrado acima), podemos dizer que msg.sender é igual a tx.origin no contrato A.
Porém, no contrato B, msg.sender = contractA.address, enquanto tx.origin = account.address. Portanto, tx.origin é como uma variável global que percorre toda a pilha de chamadas e retorna o endereço da conta que originalmente enviou a transação. Esta é a questão principal: até o momento, quase todos os ataques conhecidos contra THORChain (RUNE) estão relacionados ao tx.origin.
Vamos agora descobrir como os invasores roubam os tokens RUNE dos usuários por meio do tx.origin.
Ataque 1: Roubar uma cabra de um rebanho
Os endereços no Ethereum são divididos em endereços externos e endereços de contrato. A transferência de ETH para esses dois tipos de endereços por meio de endereços externos é fundamentalmente diferente. A Documentação Oficial de Solidez afirma que um endereço de contrato deve implementar uma função de recebimento de Ether antes de fazer transferências.
À luz dos recursos do tx.origin, os hackers podem construir um contrato de ataque:
Quando o contrato de Ataque recebe uma transferência de ETH de um usuário, ele “roubará uma cabra de um rebanho” – o contrato roubará os tokens RUNE do usuário no processo.
Ataque 2: Ataque Interno
Um Ataque Interno é um tipo especial de ataque. Ao tentar roubar a RUNE de um usuário através de um Ataque Interno, o hacker precisa ter um token médio. Além disso, o token também deve chamar contratos de terceiros. De acordo com os registros de transferência de RUNE no Ethereum, alguns invasores hackearam RUNE por meio de transferências de token AMP.
O AMP Token usa o padrão ERC-1820 para gerenciar o registro do Hook e examinar se o Hook está registrado em cada transferência. Se o Hook tiver sido registrado, o Hook será chamado.
O código do contrato do AMP Token mostra que a implementação final da transferência é: _transferByPartition. Enquanto isso, existem duas chamadas envolvendo transferHook: _callPreTransferHooks (antes da transferência) e _callPostTransferHooks (após a transferência). Em particular, _callPreTransferHooks é para o endereço de origem, enquanto _callPostTransferHooks é para o endereço de destino (ou seja, o endereço de recebimento).
Para usuários regulares, roubar tokens de si mesmos é inútil. Portanto, os invasores podem explorar _callPostTransferHooks. Vamos agora verificar os códigos de _callPostTransferHooks.
Podemos dizer que o único retorno de chamada que os invasores podem explorar é AmpTokensRecipient(recipientImplementation).tokensReceived()
A seguir, ilustraremos como esta chamada pode ser usada para transferir o RUNE de um usuário ao fazer uma transferência de token AMP.
Passo 1: É necessário um contrato de chamada (conforme mostrado abaixo):
Etapa 2: Implante o contrato para obter o endereço de ataque.
Etapa 3: Chame a interface do contrato ERC-1820 (setInterfaceImplementer) para registrar a interface.
Endereço ERC-1820: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24
Interface de contrato: setInterfaceImplementer(endereço toAddr, bytes32 interfaceHash, implementador de endereço)
Em particular, toAddr é o endereço de recebimento da transferência AMP, interfaceHash é o hash de AmpTokensRecipient: 0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a
Implementador é o endereço de ataque obtido na Etapa 2.
Etapa 4: atrair um usuário para transferir AMP para toAddr para acionar um retorno de chamada e roubar seu RUNE ao mesmo tempo.
Ataque 3: Ataque de Phishing
Como o próprio nome sugere, em um ataque de phishing, o invasor promete oferecer benefícios incríveis para atrair os usuários a realizar determinadas operações contratuais. Aqui, apresentaremos um ataque de phishing comum.
Passo 1: O invasor emite um token ERC-20 e pode gravá-lo em qualquer interface de contrato que envolva assinaturas.
Passo 2: Crie um par de negociação no Uniswap ou qualquer outro swap;
Etapa 3: Ofereça airdrops a todos os usuários/endereços que possuam tokens RUNE;
O trabalho inicial do ataque de phishing é basicamente concluído através das etapas acima. Em seguida, o invasor só precisa esperar que os usuários negociem em uma troca, e os usuários correm o risco de perder seu RUNE ao realizar operações como aprovação, transferência, etc.
Além disso, a fim de verificar ainda mais o risco de segurança do código do contrato THORChain, a CoinEx discutiu com a equipe de segurança da SlowMist e da PeckShield, duas agências de segurança bem conhecidas no setor. Confirmado pelo SlowMist e PeckShield, o risco de segurança mencionado acima existe.
Até agora, cobrimos vários tipos de ataques, bem como os riscos de segurança aos quais os usuários estão expostos.
Como a equipe do projeto deve otimizar o código do contrato para torná-lo mais seguro e proteger os ativos dos usuários?
A única resposta é ter cuidado ao usar tx.origin.
Como podem os utilizadores regulares mitigar riscos e proteger os seus ativos face a ataques que parecem inevitáveis? A equipe de segurança da CoinEx oferece as seguintes sugestões:
- Para o Ataque 1: Ao fazer uma transferência, acompanhe o consumo estimado de Gás. Para uma transferência normal de ETH, uma taxa de gás de 21.000 é mais que suficiente. Tenha cuidado se o consumo de gás exceder em muito esse valor.
- Para o Ataque 2: Isole seus tokens adotando carteiras diferentes. Você pode armazenar tokens diferentes em endereços diferentes. É necessário cuidado extra quando se trata do endereço de carteira quente oferecido pelas bolsas.
- Para o Ataque 3: A ganância é a fonte de todo o mal. Não participe cegamente de nenhum evento de lançamento aéreo.
A segurança sempre foi uma das principais preocupações no setor blockchain. Todos os participantes, incluindo equipes de projeto e bolsas, devem priorizar a segurança durante a operação do projeto, manter os ativos dos usuários seguros e protegidos e promover conjuntamente o crescimento sólido da indústria blockchain.
Isenção de responsabilidade: As opiniões, bem como todas as informações compartilhadas nesta análise de preços ou artigos mensionando projetos, são publicadas de boa fé. Os leitores devem fazer sua própria pesquisa e devida diligência. Qualquer ação tomada pelo leitor é estritamente por sua conta e risco. O Bitcoin Block não será responsabilizado por qualquer perda ou dano direto ou indireto.
Leia também:
Último progresso do ataque de hackers
FTX obtém permissão judicial para vender criptoativos
CoinEx Hack: Lições aprendidas e o caminho para a recuperação
