Introdução
O setor de blockchain tem uma obsessão singular por descobrir vulnerabilidades no código dos contratos inteligentes. O investimento das equipas de desenvolvimento vai para auditorias, competições de bug bounty, ferramentas de fuzzing e técnicas de verificação formal, com a crença de que, ao encontrar todos esses bugs finais no código, a segurança seria alcançada.
Este método é importante, mas não leva em consideração um dos fatos mais assustadores que vieram à tona em 2024. A via de ataque mais catastrófica que atualmente assola os protocolos de criptomoedas não são cadeias de exploração complexas ou vulnerabilidades de código ocultas. Em vez disso, é uma ameaça significativamente mais profunda e ainda menos discutida que dominou o cenário de ameaças nos últimos anos.
O comprometimento de chaves privadas domina o cenário de ameaças
Um estudo de 2024 apresenta uma estatística alarmante que vai precisar redefinir a forma como abordamos a segurança da blockchain. A proporção de todos os fundos de criptomoedas roubados ao longo do ano que foram comprometidos através de uma chave privada é de 43,8%, sendo, portanto, de longe o tipo de ataque mais bem-sucedido.
As fraquezas do controlo de acesso arquitetónico não são normalmente relatadas pelas empresas tradicionais de auditoria de blockchain como conclusões formais, e as plataformas de auditoria competitivas desincentivam explicitamente os envios que se concentram nesses problemas sistémicos.
Esse pensamento focado contrasta fortemente com as melhores práticas de auditorias de segurança em outros setores, onde a escalação de privilégios e o design do controlo de acesso são questões centrais que devem ser consideradas mais cedo no ciclo de desenvolvimento, num momento em que muitas vezes é tarde demais para alterar a natureza geral dos problemas de controlo de acesso do sistema.
Para conceber os efeitos das decisões de design sobre a vulnerabilidade a ataques contra chaves privadas, considere o seguinte protocolo teórico de empréstimo com garantia excessiva. No entanto, é necessário acesso privilegiado a esses sistemas para realizar várias operações importantes:
- •Listagem e retirada da lista de ativos suportados
- •Configurar parâmetros de risco e taxas de juros
- •Cobrança de taxas de protocolo
- •Pausas de emergência e atualizações de desenvolvimento de contratos inteligentes
Isso define a resiliência geral desse protocolo em relação ao comprometimento da chave privada.
Nível 1: Exposição total com controlo de ponto único
O nível mais baixo é aquele em que o programador tem uma única conta controlada externamente com direitos administrativos totais para todas as funções do protocolo. Essa arquitetura é a configuração mais vulnerável, na qual a violação de uma chave privada dará aos invasores acesso instantâneo e total ao sistema, possivelmente na forma de carteiras de software conectadas à Internet.
A ameaça de traição é imensa e o efeito devastador e direto.
Nível 2: Gestão simples de riscos por chaves distribuídas
O próximo nível de maturidade é transferir os poderes administrativos para a carteira com várias assinaturas, que vai precisar da garantia de vários detentores de chaves para fazer a atualização. Isso só pode reduzir as chances de comprometimento e não restringir a extensão em que o protocolo pode ser danificado, mas ainda é uma melhoria.
Isso é muito melhor do que ter um controlo de chave única em termos de segurança, já que uma aquisição de protocolo não requer mais acesso suficiente com o comprometimento de uma chave de assinatura. No entanto, ainda existem riscos elevados na presença da melhoria:
- •A rapidez da execução é uma questão importante, uma vez que ações maliciosas podem ser implementadas antes da resposta de segurança
- •Embora os pontos de falha estejam distribuídos entre as chaves, a estrutura de controlo permanece centralizada
- •Mesmo sistemas de assinaturas múltiplas bem protegidos podem ser violados por meio de engenharia social avançada
Nível 3: Proteção melhorada por separação de tempo e função
As melhorias dramáticas na maturidade exigem que dois mecanismos de controlo críticos sejam aplicados: travas de tempo e o princípio do privilégio mínimo.
Os bloqueios temporais impõem um atraso entre a aprovação e a execução da transação, o que dá tempo para analisar a transação e responder a incidentes. O princípio do privilégio mínimo consiste em separar funções e responsabilidades para que cada função receba apenas o mínimo de permissões necessárias para cumprir uma função específica.
Este nível aborda falhas fundamentais de métodos mais simples:
- •Não permite execução imediata
- •Controlo partilhado entre várias especializações
- •Cria tempo para as equipas de segurança verificarem transações inesperadas
- •Permite uma intervenção proativa em vez de um controlo reativo dos danos
Nível 4: Nível de segurança máximo
O nível mais alto de maturidade é baseado na remoção total das ações administrativas e é a forma mais radical de compromisso com a ideia de descentralização e minimização da confiança. Essa estratégia exclui categoricamente o controlo de acesso como parte do modelo de ameaças do protocolo.
Para atingir este nível, são necessárias abordagens completamente diferentes de todos os outros níveis:
- •A atualizabilidade dos contratos deve ser abolida - os contratos inteligentes tornam-se totalmente imutáveis
- •A listagem de ativos passa a ser livre de permissões - mercados independentes são implementados de forma autónoma
- •Os parâmetros de risco são permanentemente consagrados - não é possível fazer gestão administrativa
- •Intervenção de emergência é impossível - os sistemas não são ajustáveis após a implementação
No caso de sistemas de empréstimos com garantia excessiva, vários elementos críticos devem ser abordados:
- •Novos recursos implementados em implementações totalmente diferentes com migração manual do utilizador
- •Mercados formados como instâncias de protocolo independentes para ativos específicos
- •Os parâmetros de risco seguem diretrizes algorítmicas ou configurações de implementação permanentes
Este número é cinco vezes maior do que qualquer outro tipo de ataque confirmado, mas o ecossistema de segurança da blockchain não está, em grande parte, preparado para lidar com tal ameaça.
Proteja o seu protocolo hoje mesmo
Não espere por um compromisso. Implemente controles de acesso adequados agora.
Estrutura de separação de funções
| Tipo de função | Responsabilidades | Requisitos de segurança | Duração do bloqueio temporal |
|---|---|---|---|
| Sistema central | Atualizações do contrato | Limites elevados de multisig | Atrasos longos |
| Operações | Configuração do protocolo do dia a dia | Necessidades moderadas de segurança | Atrasos médios |
| Pausa Guardião | Suspensão do protocolo de emergência | Capacidade de ação imediata | Sem atrasos |
| Cancelar Guardian | Revogar aprovações maliciosas | Autoridade de resposta rápida | Sem atrasos |
As equipas de segurança agora podem intervir positivamente nos casos, em vez de apenas responder aos danos depois que eles acontecem, mas isso traz novos riscos, como possíveis bugs nos sistemas de gestão de funções.
Embora esse paradigma de design não tenha nenhum risco de controlo de acesso, ele traz grandes desvantagens, incluindo a impossibilidade de intervenção de emergência e enormes custos iniciais de verificação.
Construindo sistemas resilientes desde o primeiro dia
A vulnerabilidade da chave privada em quase metade de todos os roubos de criptomoedas em 2024 é uma questão que não pode ser ignorada devido às escolhas de controlo de acesso arquitetónico feitas no início do processo de design. Embora a identificação convencional de vulnerabilidades ainda seja necessária, as decisões fundamentais de design terão de ser consideradas muito mais cedo no ciclo de desenvolvimento.
Medidas reais que podem ser tomadas para melhorar a segurança incluem:
- •Análise sincera do estado atual de maturidade do protocolo
- •Implementação de contratos com bloqueio temporal em funções administrativas
- •Sistemas de monitorização adequados para modos administrativos de alto risco
- •Mapeamento de funções privilegiadas e separação em funções lógicas
- •Aplicação dos princípios de privilégios mínimos
- •Identificação de elementos de design adequados para padrões imutáveis
A forma como os programadores podem criar protocolos que sejam inovadores e robustos é compreendendo as estruturas de maturidade e fazendo escolhas conscientes de padrões de design que evitem a dependência da confiança ou permitam que o compromisso se espalhe.
Isso requer investir em resiliência operacional nas primeiras fases do desenvolvimento, garantindo que os protocolos sejam resistentes não só a invasões técnicas, mas também a fatores humanos que tornam o comprometimento de chaves privadas uma fonte de ameaça tão bem-sucedida.
