Precauções Não Óbvias para Segurança de DAOs

O que aprendemos com o hack da governança do Tornado Cash

Conteúdo

📝 Introdução
🛠️ A natureza dos contratos metamórficos
💤 O problema da DAO inativa
🛡️ Estratégias de defesa: Prevenindo hacks em DAOs
📝 Conclusão: O caminho a seguir
🗃️ Referências

Introdução

O hack da governança do Tornado Cash: Uma análise detalhada

Durante a conferência ETHDam, onde os membros da nossa equipe discutiam ativamente sobre tópicos relacionados ao ZK (conhecimento zero), a comunidade blockchain foi surpreendida com uma revelação de emergência: o sistema de governança do Tornado Cash havia sido atacado.

Este incidente, repleto de incertezas, está atualmente sob escrutínio de muitos investigadores da comunidade. Nossa equipe fez uma pequena análise do recente ataque à governança do Tornado Cash. Neste artigo, pretendemos guiá-lo através de todo o incidente, explicando nossa perspectiva sobre o que aconteceu, suas implicações e potenciais soluções. Vamos nos aprofundar nos detalhes, entender a gravidade da situação e falar sobre as lições que temos a aprender com isso.

Em 20 de maio de 2023, exatamente às 07:25:11 UTC, o sistema de governança do Tornado Cash foi vítima de um ataque meticulosamente calculado. Um atacante não identificado, explorando uma brecha no sistema, conseguiu conceder a si mesmo um surpreendente total de 1.200.000 votos através de uma proposta maliciosa. Esse número ultrapassou em muito os aproximadamente 700.000 votos legítimos, entregando efetivamente as rédeas do sistema de governança ao atacante. O incidente foi detectado pela primeira vez quando uma transação incomum foi identificada na blockchain Ethereum.

O atacante explorou uma vulnerabilidade no sistema de governança relacionada a uma chamada selfdestruct(). Essa função, quando usada com CREATE2, permite que um código arbitrário seja executado na memória de governança. O atacante utilizou essa brecha para inflar artificialmente seu saldo de tokens TORN, concedendo a si mesmo a maioria dos votos. O ataque foi executado por meio de uma proposta maliciosa que, infelizmente, foi aceita. A proposta deu ao atacante um número avassalador de votos, efetivamente entregando a ele o controle do sistema de governança. Além disso, recomendamos a leitura da Descrição Completa do Ataque à Governança feita pelos participantes da comunidade Tornado.

Anomalias pré-ataque: Alguns sinais de alerta

1. Curiosamente, a própria comunidade detectou uma das etapas de preparação da exploração, mas não a reconheceu como uma ameaça de um ataque completo.
2. Após o ataque, ao analisar as transações do hacker, foram detectadas estranhas aprovações nulas no mapeamento accumulatedRewards através de uma chamada para lockWithApproval(). Além disso, você pode analisar todos os contratos (aproximados) do atacante no sandbox Learn-evm-attacks.

Resultados da investigação e consequências: A importância de uma auditoria abrangente

▪ Nossa análise nos levou a suspeitar que as aprovações nulas poderiam ter sido o plano inicial do hacker para tornar os preços do gás para transações subsequentes mais baixos. Dada a suspeita, parece ter sido uma tática de distração para confundir todos com transações irrelevantes.

▪ A atualização do contrato de governança contra ataques metamórficos parece boa o suficiente e funcionaria se todas as propostas fossem examinadas cuidadosamente. Em termos gerais, não havia proteção, seja no nível da interface de usuário UICS, no nível do contrato de Governança, ou na verificação das próprias propostas. É provável que auditorias de propostas pudessem ter evitado o ataque, mas essa questão raramente é levantada em qualquer DAO.

Além disso:

Estamos atualmente investigando mais a fundo as chamadas lockWithApproval() com quantidades zero.

Essa chamada essencialmente calcula a quantidade colocada em stake para o endereço e a armazena no mapeamento accumulatedRewards. Mais tarde, accumulatedRewards pode ser retirado usando a chamada getReward().

Nossas suposições sobre as intenções do hacker são as seguintes:

1. Inicialmente, eles podem ter desejado retirar tokens discretamente sem causar uma queda drástica no preço do TORN. Portanto, antes do ataque, eles "prepararam" seus 100 endereços chamando lockWithApproval() com um valor zero. Isso define o valor do mapa accumulatedRewardRateOnLastUpdate para cada endereço para a taxa atual, fazendo com que o stake pareça normal e não notável ao chamar lockWithApproval com uma quantidade zero. Isso define accumulatedRewardRateOnLastUpdate.

2. Talvez o plano original deles de retirar fundos discretamente tenha falhado, então eles rapidamente retiraram tudo do cofre da governança. Neste ponto, o método addBurnRewards() no contrato de staking inclinou a balança, e todos os stakers começaram a acumular apostas massivas. O hacker preparou seus 53 endereços restantes armazenando essa aposta massiva no mapeamento accumulatedRewards para cada endereço nesta transação.

🛠️ A natureza dos contratos metamórficos

O problema do opcode SELFDESTRUCT

Na Ethereum, o opcode (código de operação) SELFDESTRUCT é uma função que permite que um contrato se destrua e envie seu saldo para outro endereço. Embora essa função possa ser útil em certos casos, ela também pode ser explorada se não for tratada com cuidado.

A função SELFDESTRUCT faz parte de um grupo de funções conhecidas como "contratos metamórficos". São contratos que podem alterar seu próprio código. Embora isso possa ser útil para atualizar contratos, ao mesmo tempo introduz riscos de segurança se não for devidamente auditado e controlado.

Várias Propostas de Melhoria do Ethereum (EIPs) foram feitas para abordar os problemas relacionados ao opcode SELFDESTRUCT e contratos metamórficos. Estes incluem:

▪ EIP-2936: Proposta que visa mitigar os riscos associados ao opcode SELFDESTRUCT, introduzindo um novo opcode que impedirá contratos de serem destruídos.

▪ EIP-4758: EIP que propõe um método para melhorar a segurança dos contratos metamórficos, introduzindo um novo opcode que permitiria aos contratos alterar seu próprio código sem a necessidade de SELFDESTRUCT.

▪ EIP-4760: Proposta que busca tornar o opcode SELFDESTRUCT mais seguro, introduzindo um atraso antes que o contrato seja realmente destruído.

▪ EIP-6046: EIP que propõe um novo opcode que permitiria aos contratos alterar seu próprio código sem a necessidade de SELFDESTRUCT, tornando os contratos metamórficos mais seguros.

▪ EIP-6049: Proposta que visa tornar o opcode SELFDESTRUCT mais seguro, introduzindo um atraso antes que o contrato seja realmente destruído.

▪ EIP-6780: EIP que sugere remover completamente o opcode SELFDESTRUCT, argumentando que ele introduz mais riscos do que benefícios.

Estas propostas destacam os esforços contínuos na comunidade Ethereum para melhorar a segurança dos contratos inteligentes e DAOs. Eles também enfatizam a importância de uma auditoria abrangente não apenas do código dos contratos inteligentes, mas também das propostas que governam sua operação.

Em relação ao opcode SELFDESTRUCT, embora seja verdade que ele foi associado a riscos de segurança, também é uma parte da funcionalidade central da Ethereum, e removê-lo completamente poderia ter implicações para contratos existentes que dependem dele. Isso provavelmente faz parte da discussão contínua na comunidade Ethereum.

Como SELFDESTRUCT é usado em hacking

Em um exemplo do ataque à governança do Tornado Cash, o atacante usou o SELFDESTRUCT em conjunto com os opcodes CREATE e CREATE2 para executar código malicioso na memória da governança.

O esquema de implantação de contratos maliciosos parece realmente elegante:

O ponto chave é que o uso do contrato Deployer permite redefinir o Nonce e implantar novamente o código no mesmo endereço (Veja também Rekt.News TL;DR).

Quais são as possíveis soluções?

Para reduzir o risco de aprovar uma Proposta maliciosa, os desenvolvedores podem introduzir uma representação visual do hash do commit da Proposta que está sendo votada no nível de UX/UI. Isso daria aos eleitores mais informações sobre quais mudanças técnicas serão implementadas e em que ordem. Por sua vez, isso permitirá que mais participantes testem e verifiquem localmente a Proposta.

A comunidade pode ocasionalmente recorrer a equipes de auditoria profissional e pesquisadores terceirizados para revisar e validar a segurança das Propostas em questão, pelo menos nos casos em que houver dúvidas. Como uma melhor prática, cada Proposta deve ser validada com antecedência antes de ser submetida a uma votação.

💤O problema da DAO inativa

Geração e validação de algoritmo de Propostas

O mecanismo de tomada de decisão em uma DAO depende dos membros da comunidade apresentando uma proposta para discussão, que deve ser votada a favor ou contra pelos detentores de tokens de Governança. A primeira condição para a validade do voto é que um quórum - um número mínimo predeterminado de tokens que devem estar envolvidos no voto - seja alcançado.

As Propostas também são limitadas no tempo em que os membros da governança podem votar a favor ou contra. Assim, se os membros do conselho forem discretos, não participarem das votações e não verificarem adequadamente o que estão votando, isso abre uma janela de oportunidade para ataques habilidosos e não óbvios.

O caso da governança do Tornado Cash

No caso da governança do Tornado Cash, vários fatores se combinaram:

▪ Após as sanções ao protocolo, a equipe de desenvolvimento teve que lidar com uma série de questões legais e institucionais que caíram sobre seus ombros de repente, tornando impossível validar cada proposta tão ativamente.

▪ O atacante apresentou a proposta #20 como uma solução para problemas rotineiros do protocolo, semelhante à proposta #16 previamente adotada, tranquilizando assim os eleitores desatentos.

▪ O hacker manteve o código da proposta previamente aceita, #16, praticamente inalterado. A única pequena diferença era a presença da função emergencyStop(), que levava uma função selfdestruct(). Mas foi exatamente essa diferença que levou a consequências tão trágicas.

▪ Os membros votantes não se preocuparam em verificar minuciosamente a proposta quanto à segurança, confiando na palavra de alguns programadores que também não foram cuidadosos e sérios o suficiente sobre esse aspecto.

🛡️Estratégias de defesa: Prevenindo hacks a DAOs

Vetores de ataque a DAOs

Além disso, a votação por moedas é suscetível a vários ataques, incluindo compra de votos, empréstimo de votos e conluio de baleias, enquanto também está exposta a ataques complexos da Teoria dos Jogos, como, por exemplo, o ataque Beanstalk e o hack Dharma Proposal do Uniswap. E esses são apenas problemas não técnicos. Há também bugs puramente técnicos que um programador pode introduzir no código devido a distração ou conhecimento insuficiente de como a blockchain funciona.

Vamos explicar as vulnerabilidades de votação em DAOs mais comuns:

▪ Ataques a Empréstimos Relâmpago: Estes podem ocorrer quando um hacker pode votar e executar uma proposta no mesmo bloco. Para prevenir isso, DAOs podem usar mecanismos que calculam o saldo do usuário um bloco antes da proposta ser criada, tornando os ataques a empréstimos relâmpago impossíveis. Para mais detalhes, recomendamos analisar o hack ao empréstimo relâmpago da MakerDAO.

▪ Re-votação Incorreta: Esta vulnerabilidade surge se um contrato permite que um usuário vote novamente em uma proposta, mas subtrai o voto antigo do usuário incorretamente. Isso pode ser prevenido corretamente adicionando/subtraindo o poder de voto anterior durante uma re-votação.

▪ Falta de Validação da Proposta: Se as propriedades de uma proposta não são totalmente validadas, um hacker pode ter oportunidades de engenharia social para criar uma proposta destrutiva que pareça benigna. DAOs podem combater isso implementando mecanismos robustos de validação de propostas. Para mais detalhes, veja como o Compound aplicou uma proposta maliciosa e perdeu mais de $80.M link 1 — link 2.

▪ Falta de Validação de Transferência: Um mecanismo de bloqueio de token deve verificar o valor retornado de uma chamada transferFrom() aprovada e outros métodos semelhantes a transferência. Isso pode ser evitado garantindo que o mecanismo de bloqueio de token verifique os valores retornados dessas chamadas.

▪ Janela de Votação Pequena: Usuários e detentores de veto que são negativamente inclinados a algumas propostas podem não ter o tempo necessário para reagir. Para mitigar esse risco, DAOs podem estabelecer um período de votação razoável para permitir que todos os participantes votem.

▪ Voto Duplo: Isso ocorre quando um hacker vota em uma proposta duas vezes com os mesmos tokens. Por exemplo, esquemas de voto-transferência-voto ou voto-delegação-voto podem ser usados no ataque. Pode ser combatido implementando mecanismos que impeçam os usuários de votar duas vezes na mesma proposta com os mesmos tokens.

▪ Execução Dupla: Isso acontece quando o método execute() pode ser chamado duas vezes no mesmo bloco. Para evitá-lo, pode-se usar o padrão Checks-Effects-Interactions, que torna os métodos de execução invulneráveis à reentrância.

Práticas de defesa de DAOs

Diante das vulnerabilidades que as DAOs podem encontrar, é crucial ter estratégias de defesa robustas em vigor. Essas estratégias devem abordar não apenas desafios técnicos, mas também desafios relacionados à governança. Aqui estão algumas estratégias de proteção que podem ser empregadas para proteger DAOs de potenciais ataques:

▪ Carteiras Multiassinatura: Usar carteiras multiassinatura pode adicionar uma camada extra de segurança a uma DAO. Estas carteiras requerem várias assinaturas para aprovar uma ação, tornando mais difícil para um único atacante assumir o controle.

▪ Bloqueios de Tempo: Implementar bloqueios de tempo para propostas pode prevenir ataques a empréstimos relâmpago. Significa que haverá um atraso entre o momento em que uma proposta é feita e o momento em que pode ser executada, dando à comunidade tempo para reagir e potencialmente cancelar uma proposta maliciosa.

▪ Requisitos de Quórum: Definir um requisito de quórum para propostas pode impedir que um pequeno grupo de indivíduos avance com propostas. Para que um voto seja válido, uma certa porcentagem de todos os detentores de tokens deve participar deste voto.

▪ Delegação: A delegação permite que os detentores de tokens deleguem seu poder de voto a uma parte confiável. Isso pode ajudar a mitigar o problema de detentores de tokens inativos e garantir que mais votos sejam dados em cada decisão.

▪ Períodos de Votação: Ter períodos de votação mais longos pode garantir que todos os membros da DAO tenham a chance de participar do processo de tomada de decisão, independentemente de seu fuso horário ou agenda.

▪ Auditorias de Código: Auditar regularmente o código da DAO pode ajudar a identificar e corrigir potenciais vulnerabilidades. Isso inclui auditorias internas e auditorias de terceiros.

▪ Recompensas por Encontrar Bugs: Oferecer recompensas por encontrar bugs pode incentivar hackers éticos a encontrar e relatar vulnerabilidades no código da DAO.

▪ Governança Transparente: Manter transparência em todos os processos de governança pode ajudar a construir confiança dentro da comunidade e dissuadir atores maliciosos.

Auditoria de Propostas de Governança

Devido ao alto número de casos de hacking com propostas maliciosas envolvidas, nossa equipe achou interessante começar a conduzir auditorias em grande escala para elas. Acreditamos que uma auditoria de alta qualidade do código da proposta melhora significativamente a segurança do protocolo de Governança e poderá prevenir possíveis ataques a tempo.

📝 Conclusão: O Caminho a Seguir

Em conclusão, queremos enfatizar mais uma vez que até mesmo pequenas alterações na base de código, às vezes tão pequenas quanto uma única linha, podem levar à perda total de controle sobre o protocolo e o fluxo de dinheiro. Seja cuidadoso e não ignore auditorias de segurança.

Atualização da Governança do Tornado Cash

Há boas notícias! Após a execução da Proposta #22, todos os saldos EOA do atacante foram redefinidos para zero, e a Governança recuperou o controle do protocolo.

Sobre a Oxorio

Oxorio é uma empresa jovem, mas em rápido crescimento, de auditoria e consultoria no campo da indústria blockchain, fornecendo consultoria e auditorias de segurança para organizações de todo o mundo. A Oxorio participou de vários projetos blockchain nos quais sistemas de contratos inteligentes foram projetados e implantados pela empresa.

A Oxorio é a criadora, mantenedora e principal contribuinte de vários projetos blockchain e emprega mais de 5 especialistas em blockchain para analisar e desenvolver contratos inteligentes. Nossos contatos

⚡oxor.io

⚡Github

⚡Linkedin

⚡Twitter

Referências

[1] — Mixbytes _| artigo “DAO voting vulnerabilities”; \
[2]_ — Mixbytes | artigo “Metamorphic smart contracts: Is EVM Code Truly Immutable?”; \
[3] — “The Promise and the Peril of Metamorphic Contracts”; \
[4] — Tornado Governance forum | thread “Attacker transaction history”.

Artigo original publicado por Oxorio. Traduzido por Paulinho Giovannini.