Auditoria de segurança da rede Nym mixnet e contratos de aquisição de direitos

Auditoria de segurança da rede mixnet e dos contratos de aquisição de direitos da Nym

9 mins Ler

Introdução

Em dezembro de 2022, a Nym passou por uma auditoria de segurança independente conduzida pela Oak Security, uma empresa de consultoria em segurança cibernética sediada na Alemanha, especializada em auditorias de blockchains de terceira geração e protocolos descentralizados. Com ampla experiência em ecossistemas como Cosmos, Terra, Polkadot e Flow, a Oak Security foi encarregada de avaliar dois componentes críticos do ecossistema Nym: (1) a rede mixnet Nym e os contratos de aquisição de direitos (ver relatório completo) e (2) a carteira Nym (ver relatório completo). A auditoria teve como objetivo avaliar a robustez desses componentes, identificar possíveis vulnerabilidades e garantir a adesão às melhores práticas no desenvolvimento de código. Para facilitar o acompanhamento, dividimos as conclusões para cada componente. Você pode conferir o resumo da auditoria da Nym Wallet aqui.

Resumo da auditoria da Nym Mixnet & Contratos Vesting pela Oak Security

Com duração de 2 semanas, a auditoria envolveu uma equipe de 4 especialistas. A equipe da Nym forneceu à Oak Security acesso total ao código-fonte do projeto, especificações detalhadas do projeto e documentação de apoio. O escopo da auditoria abrangeu os contratos/mixnet, contratos/repositórios de aquisição de direitos e importações relevantes por esses contratos para a mixnet Nym e contratos de aquisição de direitos.

A Oak Security revisou minuciosamente o código, combinando análise automatizada do código-fonte e das dependências com uma inspeção manual linha por linha para descobrir vulnerabilidades de segurança, avaliar a qualidade do código e avaliar a conformidade com os princípios de codificação segura. Essa abordagem abrangente incluiu uma análise aprofundada de áreas críticas, como vulnerabilidades de condições de corrida, problemas de subfluxo e estouro, práticas importantes de gerenciamento, robustez criptográfica, riscos de vazamento de dados, tratamento de senhas e controles de acesso e autorização.

O foco da auditoria foi garantir o funcionamento correto dos protocolos, identificar quaisquer vulnerabilidades exploráveis ou bugs nos contratos inteligentes e recomendar melhorias para a segurança e legibilidade do código.

Visão geral dos resultados

A rede mixnet e os contratos de aquisição de direitos da Nym caracterizavam-se por uma elevada legibilidade e clareza, com uma cobertura de testes robusta que comprovava a sua fiabilidade. Na sua avaliação, os auditores identificaram 19 conclusões, incluindo 9 vulnerabilidades de segurança – compreendendo questões críticas e de gravidade elevada – e 10 deficiências gerais classificadas como menores ou informativas.

A equipe Nym abordou rapidamente todas as questões críticas e de alta gravidade. A equipe da Oak Security verificou e aprovou nossas correções.

NYM-MIX-VEST-CONTRACT-1: Uma falha na execução de um evento de época ou intervalo bloqueia permanentemente o avanço da época (Crítico)

A auditoria identificou uma vulnerabilidade no tratamento das mensagens AdvanceCurrentEpoch em contracts/mixnet/src/interval/transactions.rs. Um loop sequencial processa todos os eventos pendentes diretamente dentro do contexto da transação, o que significa que um único evento com falha pode reverter toda a transação, interrompendo efetivamente o avanço da época e do intervalo e fazendo com que o protocolo fique travado.

Para resolver isso, os auditores recomendaram encapsular a execução de eventos em sub-mensagens com uma política de resposta. Essa abordagem permitiria que o sistema lidasse com falhas sem reverter a transação inteira. No entanto, optamos deliberadamente por não seguir essa recomendação. Uma falha durante a execução de eventos indica uma falha lógica significativa que poderia comprometer o mecanismo de recompensas, tornando preferível interromper o avanço de época para inspeção manual em vez de arriscar operar em um estado corrompido. Em vez disso, implementamos monitoramento aprimorado na API da Nym para detectar e nos alertar sobre falhas no avanço de época. Essa abordagem garante que tais falhas sejam sinalizadas prontamente, permitindo intervenção oportuna para resolver os problemas.

NYM-MIX-VEST-CONTRACT-2: Atacantes podem forçar mix nodes órfãos a entrar em uma família sem consentimento para agregar uma grande quantidade deles na mesma camada (Crítico)

Uma vulnerabilidade foi identificada na mensagem JoinFamilyOnBehalf, que poderia permitir que um atacante adicionasse um mix node a uma família sem o seu consentimento. Ao criar uma família maliciosa e usar a chave de identidade do mix node vítima assinada com sua chave privada como assinatura, o atacante poderia prender o mix node na família. Isso poderia potencialmente permitir que um atacante agrupasse mix nodes órfãos em uma única família, perturbando a rede ao concentrar nós na mesma camada e aumentando as chances do atacante de influenciar o roteamento.

Para resolver a vulnerabilidade na mensagem JoinFamilyOnBehalf, o mecanismo de assinatura do contrato foi redesenhado. Em vez de simplesmente assinar a identidade do mix node, as assinaturas foram atualizadas para incluir uma mensagem com intenção clara e um nonce único. Essa mudança garante que as assinaturas não possam ser reutilizadas ou reproduzidas.

NYM-MIX-VEST-CONTRACT-3: Iteração ilimitada no tratamento de mensagens TrackUndelegation poderia impedir o usuário de retirar delegação, inibindo permanentemente o avanço de época (Crítico)

A iteração ilimitada da mensagem TrackUndelegation poderia causar esgotamento de gas ao lidar com contas com muitas delegações, impedindo os usuários de retirar delegação. Essa falha também interromperia o avanço de época, deixando o protocolo travado em seu estado atual.

Para resolver o problema, implementamos um limite de 25 delegações de vesting por conta. Essa solução foi baseada no maior número de delegações de vesting observado na época.

Atualização: A partir de 2024, a opção de fazer delegações de vesting está completamente desativada.

NYM-MIX-VEST-CONTRACT-4: Um atacante pode realizar front-running nas mensagens BondMixnodeOnBehalf e CreateFamilyOnBehalf e modificar seu payload (Crítico)

Essa vulnerabilidade permitiria que um atacante realizasse front-running nas mensagens BondMixNodeOnBehalf e CreateFamilyOnBehalf, extraísse a assinatura e modificasse o payload. No caso de BondMixNodeOnBehalf, o atacante também poderia se definir como proxy, obtendo controle total sobre o bond registrado.

Para resolver a vulnerabilidade, implementamos uma solução dupla. Primeiro, aplicamos as mudanças de criação de assinatura descritas em NYM-MIX-VEST-CONTRACT-2, que adicionaram intenção clara e um nonce único. Segundo, restringimos o endereço de proxy legítimo à conta de vesting, garantindo que atacantes não possam se definir como proxy e obter controle não autorizado sobre bonds registrados.

Atualização: A partir de 2024, todas as operações de proxy estão desativadas, tornando o ataque inaplicável.

NYM-MIX-VEST-CONTRACT-5: Assinaturas podem ser reproduzidas em transações "em nome de" para se passar por usuários (Crítico)

Essa vulnerabilidade permite que assinaturas sejam reproduzidas em transações "em nome de", permitindo que atacantes se passem por usuários. Como as assinaturas incluem apenas dados brutos sem metadados adicionais como nonces ou identificadores de mensagem, um atacante poderia reutilizar uma assinatura de uma mensagem para outra a fim de remover membros da família à força. Além disso, atacantes podem reutilizar assinaturas para o mesmo tipo de mensagem, permitindo que um membro entre novamente em uma família múltiplas vezes usando a mesma assinatura.

A solução para esse problema espelha a implementada em NYM-MIX-VEST-CONTRACT-4.

NYM-MIX-VEST-CONTRACT-6: A geração de chaves para pares (proprietário, proxy) poderia levar a colisões (Crítico)

Essa vulnerabilidade permitiria que dois pares de endereços (proprietário, proxy) diferentes gerassem o mesmo resultado XOR na função generate_owner_storage_subkey, o que poderia levar a colisões de chaves e sobrescrita de dados.

A solução de restringir o proxy legítimo apenas ao endereço do contrato de vesting, aplicada no NYM-MIX-VEST-CONTRACT-4, também resolve essa vulnerabilidade. Ao garantir que a operação XOR seja sempre realizada contra uma string constante, essa mudança elimina efetivamente o risco de colisões.

NYM-MIX-VEST-CONTRACT-7: track_delegation pode sobrescrever uma delegação existente se mais de uma for processada no mesmo bloco (Crítico)

Esse problema permitiria que colisões de chaves ocorressem se múltiplas delegações fossem feitas no mesmo bloco, potencialmente fazendo com que a função save_delegation sobrescrevesse uma delegação existente, resultando na perda da delegação anterior.

Para resolver o problema, alteramos a lógica da função save_delegation para primeiro ler o valor de delegação existente antes de salvar o novo. Se já existir uma delegação para a mesma chave, recuperamos o valor atual, adicionamos a nova delegação e salvamos o total atualizado, garantindo que nenhuma delegação existente seja sobrescrita.

NYM-MIX-VEST-CONTRACT-8: O proprietário do bond não consegue realizar operações se o bond foi criado "em nome de" por um proxy (Grave)

Esse problema impediria o proprietário do bond de realizar qualquer operação sobre ele se o bond foi criado "em nome de" e a transação atual for iniciada pelo proprietário em vez do proxy. Como o proxy poderia ser comprometido ou perdido, e não há forma de o proprietário alterá-lo, isso poderia resultar na perda de controle do proprietário sobre seu bond.

Não consideramos isso um problema, pois é um comportamento intencional por design. Quando um mix node é vinculado (ou delegações são feitas) por meio do contrato de vesting, todas as interações subsequentes com o bond ou delegação devem ocorrer apenas pelo contrato de vesting.

Atualização: A partir de 2024, o contrato de vesting foi removido.

NYM-MIX-VEST-CONTRACT-9: A execução das mensagens LeaveFamily e LeaveFamilyOnBehalf poderia falhar se um número significativo de mix nodes forem membros de uma família (Grave)

Esse problema resultaria na falha das mensagens LeaveFamily e LeaveFamilyOnBehalf devido ao esgotamento de gas ao iterar sobre um grande número de membros da família no mapa MEMBERS. Isso impediria que mix nodes saíssem de uma família, efetivamente os prendendo em sua família atual.

Solução: A solução envolveu retrabalhar a lógica para acessar diretamente o mapa MEMBERS e verificar a associação de um mix node. Essa mudança eliminou a necessidade de iteração, que poderia resultar em erros de out-of-gas, e garantiu que os membros possam sair de uma família com sucesso, mesmo quando há muitos membros.

Atualização: A partir de 2024, as famílias de nós foram removidas.

Palavras finais

Gostaríamos de agradecer à equipe da Oak Security pela sua expertise e dedicação durante todo o processo de auditoria. Também apreciamos a colaboração e o profissionalismo demonstrados durante as etapas de planejamento e execução da auditoria. Nosso compromisso contínuo com a segurança permanece uma prioridade máxima, e aguardamos a continuidade das parcerias com especialistas em segurança para manter os mais altos padrões para o nosso ecossistema.

Compartilhar