Como julgar se um chamado “HACK” que aconteceu com um projeto de criptografia ou blockchain é legítimo ou se é apenas um mecanismo para esconder um tapete?

Republicado por Platão

seguidores: 0

Obviamente, depois do que aconteceu com MtGox ou QuadrigaCX ou casos semelhantes em que os fundadores alegaram que perderam as chaves privadas que detinham a maioria dos ativos digitais de suas exchanges enquanto desapareciam ou eram encontrados mortos posteriormente, as pessoas na esfera criptográfica ficam cada vez mais desconfiadas quando ouvem sobre um hack em um projeto, e o primeiro pensamento que vem à mente é que os fundadores basicamente esvaziaram o fundo e fugiram com ele, isso é o que comumente chamamos de RUG.

Este provavelmente foi o caso em muitos projetos, mas não necessariamente em todos eles, então hoje estamos analisando um caso que acreditamos ser um hack real devido à natureza da situação.

Achamos que é um caso interessante para analisar porque ajudará a entender melhor a importância da segurança e das auditorias em contratos inteligentes ou projetos relacionados a blockchain em geral.

Analisaremos objetivamente o drama ocorrido com o projeto RING Financial, token lançado no BSC (Binance Blockchain).

Antes de chegar ao hack, vamos primeiro resumir o projeto e sua situação diante dele:

RING Financial antes do hack

RING Financial foi um projeto DeFi com o objetivo de tornar o DeFi mais acessível para a comunidade DeFi e cripto. Um projeto ambicioso que queria criar um protocolo de rendimento de nó que seria governado por Node Holders e alocaria liquidez em mais de 300 protocolos de uma só vez. O objetivo era obter acesso a todos os protocolos através de um RING Node e através do RING Dapp.

Esses protocolos eram verificados pela equipe e, em seguida, a comunidade votava neles para onde alocar. O mesmo conceito de votação que você teria em um DAO, o que tornou o RING bastante atraente.

A RING Financial também simplificou bastante o processo de pesquisa e implantação para um único Node Holder. Um Dapp para acessar todos os outros Dapps, então você só precisaria de uma interface em vez de 300 diferentes com seus próprios acessos e próprios nós.

Finalmente, o objetivo da RING Financial era reduzir as taxas de implantação em diferentes protocolos, com o volume vem taxas de transação mais baixas para titulares individuais, que foi um dos principais pontos de venda do projeto. Um projeto com talento e ambição para tornar as coisas mais fáceis para a comunidade e ainda mais mainstream para aqueles que não conhecem o Defi.

No entanto, talento e ambição nem sempre são suficientes e você precisa de experiência e conhecimento que em mercados novos e imaturos é um achado raro e é por isso que a RING Financial não conseguiu cumprir sua promessa inteiramente.

Então, o que realmente aconteceu com a RING Financial? E por que foi hackeado? Graças ao blockchain, temos todas as evidências forenses necessárias para investigar isso e ver onde estavam as vulnerabilidades e por quê RING Financial não era uma farsa.

O RING Financial HACK aconteceu em 5 de dezembro de 2021 entre 2h01 e 2h06 UTC.

Sim, tudo aconteceu literalmente em apenas 5 minutos! A propósito, graças ao scanner blockchain por esses detalhes, fornecemos logo abaixo os links das transações relacionadas ao HACK, bem como o endereço do contrato para quem quiser pesquisar mais detalhadamente.

Aqui está o resumo explicando a falha que o invasor explorou:

Você tem que entender que o contrato inteligente da RING Financial era composto de várias partes, uma para o token e todos os dados relacionados a ele e outra para tudo relacionado à contabilização de nós e recompensas. A parte do token tinha uma segurança para que apenas o administrador do contrato pudesse modificar os dados importantes deste, para mostrar algum código, aqui está um cabeçalho de uma função do contrato que é protegida através do atributo "onlyOwner' que estipula que a função pode ser executada apenas pelo administrador:

Uma função que não possui apenasProprietário atributo (ou atributo equivalente para proteger o acesso da função) pode ser executado por literalmente qualquer um.

Agora, adivinhem? As funções da parte Nodes e Rewards não tinham esse atributo, como você pode ver olhando os nomes das funções abaixo (o apenasProprietário falta o atributo):

E como você pode imaginar, um hacker explorou e enganou essa falha para obter um número exponencial de recompensas no RING e, em seguida, despejou-as no pool de liquidez e quase o esvaziou violentamente em alguns minutos. Assim, ele cometeu seus golpes.

Agora você provavelmente está se fazendo duas perguntas:

Como os desenvolvedores puderam deixar essa brecha?

Depois de conversar com os desenvolvedores do Solidity (linguagem usada para codificar contratos inteligentes no Ethereum), este é um erro relacionado à herança de papéis entre dois contratos inteligentes, a herança é uma noção de linguagem de programação e para não causar dor de cabeça, nós vai ficar em palavras simples: Basicamente, é muito provável que a pessoa que codificou o contrato pensou que as funções da parte Node herdaram as funções de segurança das funções da parte Token, mas infelizmente não é o caso no Solidity, e é necessário redefinir os papéis de cada função de cada contrato, seja qual for o seu vínculo. Portanto, nossa conclusão sobre esse ponto é que o desenvolvedor não era um especialista e que provavelmente publicou o contrato SEM perder tempo para lê-lo novamente, provavelmente com pressa.

Como você sabe que não é o próprio desenvolvedor que deixou essa falha de propósito e não foi uma farsa?

Muito boa objeção e é fácil assumir um golpe quando você não tem certeza sobre como smart contracts trabalho, mas na verdade é muito fácil assumir a inocência do desenvolvedor, porque ele publicou e verificou todo o código do contrato inteligente publicamente no BSCSCAN.COM (o scanner mais popular da Binance Blockchain), em 19 de novembro de 2021, que ou seja, mais de duas semanas antes do RING Financial HACK acontecer. E como explicado antes, a falha estava escrita em PRETO NO BRANCO no contrato, e qualquer desenvolvedor experiente teria percebido e reagido, mas infelizmente, o primeiro a não teve piedade alguma. Portanto, é óbvio que o desenvolvedor não estava ciente dessa falha porque ele não teria corrido o risco de deixar alguém matar o projeto RING Financial a qualquer momento.

Voltando à continuação do RING Financial HACK, o desenvolvedor percebeu seu erro e simplesmente congelou o contrato para impedir qualquer distribuição de recompensas para que o invasor não esvazie completamente o pool. Ele então reimplantou um contrato Node, desta vez com o atributo de segurança “onlyOwner”. Este novo contrato Node foi capaz de lidar com a nova distribuição de recompensas corretamente, exceto que era tarde demais, porque como resultado do HACK toda a confiança foi perdida no projeto e na equipe, e a pressão de venda matou e acabou com o token e o projeto.

Para concluir, escolhemos esta história porque mostra duas coisas importantes sobre contratos inteligentes e projetos de criptografia, nunca codifique um contrato com pressa e sempre entre em contato com as empresas de auditoria, porque uma vez que o hack acontece, é tarde demais para salvar o barco e O projeto RING Financial é um bom exemplo, além disso, de acordo com sua comunicação, eles contataram empresas de auditoria para este segundo contrato de Node e não o publicaram publicamente no BSCSCAN até que tivessem certeza de sua segurança. Mas, como dito antes, era tarde demais para a RING Financial e os danos eram irreversíveis.