Ir para o conteúdo
Financial Context Wiki

Ataque de governança

Um ataque de governança obtém poder de voto ou execução suficiente para aprovar mudanças prejudiciais pela via de governança autorizada.

Atualizado

Somente para fins educacionais; não constitui recomendação nem aconselhamento de investimento. Investir pode causar perdas.

Resposta direta

Um ataque de governança obtém poder suficiente para votar, propor, cancelar ou executar e faz o protocolo realizar uma ação prejudicial por sua via de governança autorizada. As chamadas podem passar por todas as verificações dos contratos inteligentes. A falha está em permitir que o controle seja adquirido de forma barata, rápida ou sem responsabilização em relação ao valor submetido a ele.

O poder de voto pode vir de tokens próprios, votos delegados, tokens emprestados, eleitores subornados, chaves comprometidas ou funções privilegiadas do governador e do timelock. Pontos de controle históricos impedem que o mesmo saldo vote outra vez após uma transferência e podem frustrar empréstimos feitos depois do snapshot. Eles não impedem votos obtidos antes dele, delegação concentrada, regras fracas de quórum ou um executor comprometido.

Nem toda proposta impopular é um ataque: a governança existe para mudar regras. A questão de segurança é saber se alguém obteve controle desproporcional ou temporário, ocultou ou deturpou o efeito executável ou ultrapassou um limite de autoridade declarado publicamente. Devem ser examinadas as chamadas reais, o caminho mais barato para o poder decisivo, o tempo de reação e o valor ou controle máximo alcançável após a execução.

Como funciona

  1. Mapeie a autoridade desde o ativo de votação, passando por delegações e checkpoints, até o governador, timelock, administrador de proxy, tesouraria, funções de emergência e contratos de destino. A interface de governança não é o grafo de permissões.
  2. Fixe a rede, os endereços, versões de implementação, modo do relógio, snapshot, limiar de proposta, cálculo do quórum, regra de contagem, atraso e período de votação, atraso de fila, validade, direitos de cancelamento e funções de execução.
  3. Reconstrua o poder de voto no snapshot exato com leituras históricas como getPastVotes. Agrupe endereços controlados ou coordenados pelo mesmo agente e separe o saldo de tokens do peso delegado.
  4. Decodifique cada ação: targets, values, calldatas e descriptionHash. Resolva proxies e seletores, inspecione chamadas em lote e compare a carga executável com a descrição legível.
  5. Reproduza em um fork a criação, votação, entrada na fila e execução. Compare antes e depois saldos, propriedade, funções, permissões, implementações, configurações de oráculo, parâmetros de garantia e qualquer função recém-acessível.
  6. Calcule o caminho de controle mais barato entre compras à vista, mercados de crédito, liquidez flash, empréstimos de balcão, delegação, incentivos de voto, hedge com derivativos, comprometimento de chaves e captura de funções privilegiadas. Inclua taxas, slippage, garantia, perdas no desfazimento e tempo de imobilização do capital.
  7. Teste a resposta. Confirme quem pode cancelar ou pausar, quais evidências são necessárias, se a ação cabe no atraso, onde os usuários obtêm avisos oficiais e como a governança recomeça sem deixar uma chave de emergência ilimitada.

Um governador de tokens típico passa por proposta, atraso, snapshot, votação, aprovação ou rejeição, fila, timelock e execução. As regras exatas dependem da implementação. Com checkpoints no estilo ERC-5805, é possível consultar o peso delegado em um momento passado; o relógio pode usar blocos ou timestamps. É preciso usar o relógio e a configuração implantados, sem presumir que a duração exibida ou o saldo de tokens sejam autoritativos.

O timelock cria um prazo mínimo de aviso, mas não avalia a intenção nem torna a carga segura. Suas funções de proponente, executor, cancelador e administrador também são críticas. Se um administrador externo puder contornar o atraso, o timelock não é a autoridade final. Se ninguém puder cancelar uma ação maliciosa na fila, detectá-la não impede sua execução.

Exemplos calculados

  • Captura com baixa participação. Um protocolo tem 100 million tokens totais e 40 million em circulação. Uma proposta exige 2 million votos participantes, mais votos favoráveis que contrários e timelock de 6-hour. Um agente compra 1.2 million votos e recebe 1 million delegados. Há 0.8 million votos contrários; assim, seus 2.2 million votos favoráveis aprovam uma chamada capaz de transferir 15 million USDC da tesouraria. Ele controla 2.2 / 100 = 2.2% da oferta total e 2.2 / 40 = 5.5% da oferta circulante, mas 2.2 / 3.0 = 73.3% dos votos lançados. Os parâmetros decisivos são participação, delegação, quórum, autoridade da carga e atraso, não o slogan 51%.
  • Limite do snapshot. Se o peso for lido do saldo atual e a execução for imediata, uma transação pode tomar tokens, votar, executar e devolver. Ler o peso histórico imutável de um momento anterior à votação bloqueia esse caminho na mesma transação. Ainda permite capital emprestado ou delegado antes do snapshot; por isso, o atraso da proposta e a janela observável de aquisição continuam fazendo parte da defesa.
  • Beanstalk em 17 de abril de 2022. A Beanstalk Farms informou que um atacante usou um flash loan para explorar a governança do protocolo e subtraiu aproximadamente $77 million em ativos de usuários que não eram Beanstalk. O caso mostra que a liquidez flash financia o ataque, enquanto a fraqueza decisiva é permitir que poder econômico temporário alcance permissões valiosas de execução.

Riscos e controles

  • Poder efetivo concentrado. Meça delegados e entidades coordenadas, não apenas endereços. Publique a fatia dos principais delegados, a distribuição da participação e a dependência de fundações, custodiantes, formadores de mercado e representantes.
  • Regras fracas de proposta e quórum. Compare limiares com poder ativo, oferta emprestável e exposição da tesouraria. Separe os requisitos de parâmetros rotineiros e atualizações ou transferências de alto impacto.
  • Snapshots inseguros. Use checkpoints históricos imutáveis e um relógio comum ao token e ao governador. Deixe atraso suficiente antes do snapshot para tornar visíveis acúmulos ou delegações anormais.
  • Voto tardio ou surpresa. Considere uma extensão mínima quando o quórum chegar perto do encerramento e monitore grandes mudanças de delegação durante todo o ciclo.
  • Cargas opacas. Publique chamadas decodificadas e simulações independentes. Separe ações arriscadas não relacionadas para que uma ação normal não esconda mudança de administrador ou transferência.
  • Atraso de execução insuficiente. Ajuste o timelock ao impacto e publique as operações na fila. O atraso deve comportar revisão, alertas, cancelamento ou pausa e uma saída confiável para o usuário.
  • Funções de emergência excessivas. Limite guardiões por função, valor, duração e padrão de revisão. Divulgue membros, limiares, rotação, evidências exigidas e processos de remoção e retomada.
  • Caminhos de atualização não revisados. Acompanhe administradores de proxy, beacons, inicializadores, implantações metamórficas e contratos atualizáveis depois de receber autoridade.
  • Risco de execução entre redes. Autentique governador e mensagem de origem, impeça replay, limite funções de destino, adicione atraso local a chamadas críticas e defina o comportamento durante falha ou suspensão da ponte.
  • Monitoramento insuficiente. Alerte sobre criação de propostas, concentração de votos, mudanças de quórum, fila e cancelamento, alterações de estado decodificadas, atualizações, concessões de funções, permissões e saídas da tesouraria.
  • Resposta a incidentes falha. Simule propostas maliciosas, perda de signatários, comprometimento do front-end, indisponibilidade da ponte e pausas indevidas. Registre quem decide, comunica, assina, verifica e restaura com segurança.
  • Valor em risco ilimitado. Limite transferências individuais e acumuladas, escopo de atualização, emissão, mudanças de garantia e permissões. Um voto aprovado não deve conceder automaticamente autoridade ilimitada.

O resultado deve ser um registro de controle reproduzível: cada ação privilegiada, seu controlador, votos ou chaves necessários, primeiro horário de execução, caminho de cancelamento, fonte de monitoramento e valor máximo alcançável. Recalcule após atualizações, distribuições de tokens, mudanças de delegação, migrações de pontes ou variações relevantes de liquidez e participação.

Equívocos comuns

  • “O atacante precisa de 51% da oferta total.” A maioria dos sistemas depende de votos delegados ou participantes, quórum e regra de aprovação. O controle decisivo pode custar muito menos que metade da oferta.
  • “Snapshots eliminam ataques de governança.” Eles impedem certos reusos de votos ou empréstimos de última hora, não empréstimos prévios, compras, concentração de delegação, suborno ou chaves privilegiadas comprometidas.
  • “Um voto aprovado on-chain prova legitimidade.” Ele só prova que as condições do código foram atendidas. Não demonstra que descrição e carga coincidem nem que o resultado é seguro, justo ou compatível com compromissos públicos.
  • “Um timelock mais longo é sempre mais seguro.” Só é útil se houver tempo para monitorar, analisar, cancelar ou pausar, comunicar e sair. Atraso excessivo também pode prejudicar manutenção urgente.
  • “Adicionar um conselho de segurança resolve o risco.” O conselho pode acelerar a resposta, mas cria outro caminho de controle. Autoridade, responsabilização, remoção e falhas devem entrar no mesmo modelo de ameaças.

Tópicos relacionados

Fontes

Navegação

Pesquisar na wiki...