A rede da Nano sofreu um ataque DDoS no sábado que envolveu atraso na confirmação de algumas transações e uma tentativa de extorsão mal sucedida contra a comunidade e a Nano Foundation, para interromper o ataque.
Ataque DDoS contra a rede da Nano
Há alguns dias a rede da Nano começou a observar o envio de blocos inválidos para alguns representantes principais (nodes que possuem pelo menos 0,1% do total de votos delegados online) por parte de um suposto node anônimo.
Estes blocos, denominados como unchecked (não-checados) não são válidos por não possuírem origem da conta gênesis e foram rotulados pela comunidade como uma tentativa de sobrecarregar os nodes – uma espécie de ataque de negação de serviço (DDoS) direcionada – com uso de recursos computacionais extras para verificar e limpar os blocos.
Não se sabia ao certo se a intenção do atacante era realmente essa, ou uma tentativa mal sucedida de gasto duplo, mas devido ao ataque constituir no envio de um alto volume de blocos facilmente identificados como inválidos, apenas para nodes direcionados e não transmitidos para toda a rede, leva a crer que a intenção realmente era de sobrecarga de serviço e não de causar um fork.
O protocolo da nano também elimina automaticamente blocos não verificados em algumas horas, então este excesso de informação era resolvido em pouco tempo, sem afetar a rede como um todo (apesar de prejudicar o node, que precisava destinar banda e CPU para lidar com a sobrecarga).
No dia 21 de abril, o criador da nano – Colin LeMahieu – fez uma postagem no fórum de desenvolvedores, explicando que devido aos ataques que estavam sendo realizados contra os nodes, os esforços da equipe de desenvolvimento estaria em corrigir a vulnerabilidade explorada pelo atacante.
“Atualmente estamos trabalhando em algumas mudanças relacionadas ao gerenciamento de blocos não-verificados e outros alvos desta atividade recente. Embora o impacto até agora tenha sido mínimo, trabalhar para mitigar impactos futuros é importante e terá precedência sobre outras atualizações.”
Ataque spam mais robusto no sábado
No sábado, dia 23 de abril, dois dias após publicação de Colin referente ao ataque, a rede enfim foi afetada pelos esforços do atacante, que realizou a mesma operação, mas focando em diversos representantes principais ao mesmo tempo, com uma quantidade de blocos falsos realmente muito alta, o que fez com que alguns nodes mais fracos não resistissem e ficassem offline.
Isso fez com que as transações da nano demorassem entre 30 e até mesmo 60 minutos para algumas pessoas. Este atraso nas confirmações é muito prejudicial ao protocolo, conhecido por confirmar transações em menos de um segundo.
A duração pelo qual os usuários se viram afetados foi entre 3 a 5 horas, que é o mesmo tempo necessário para que o próprio protocolo elimine blocos não-válidos automaticamente. Após a limpeza do armazenamento e fim da sobrecarga de CPU, os nodes puderam ligar novamente e a rede voltou a funcionar normalmente.
O que garantiu o sucesso deste ataque, foi o fato de que mais de 33% de todos os votos da rede ficaram offline ao mesmo tempo, fazendo com que não houvesse a quantidade mínima de votos necessária para atingir o consenso sobre as transações.
Esta é uma medida defensiva e um desenho intencional para evitar gastos duplos.
Caso esta quantidade mínima de votos online não existisse, um ataque parecido poderia ter a capacidade de controlar a maioria do consenso e fazer o “ataque de 51%”, causando gastos duplos, após derrubar os nodes mais fracos.
Como evitar que algo assim ocorra?
Em uma rede descentralizada pública e não-permissionada como a Nano (XNO), qualquer pessoa pode se tornar um node e conseguir poder de voto – delegado ou próprio – para se tornar um representante principal.
Desta forma, mesmo computadores mais fracos, podem assumir protagonismo na rede e serem mais facilmente atingidos por ataques direcionados, como foi o caso neste sábado.
Ao escolher um node como representante é importante levar em conta também fatores como capacidade computacional e de banda.
No sistema ORV (Open Representative Voting) da nano, todos os endereços podem alterar seu representante a qualquer momento, sem limitações de tempo e sem a necessidade de travar fundos através de staking.
Cada endereço vota (ou delega) de acordo com o balanço atual online da conta.
Além do cuidado de toda a comunidade em delegar para nodes mais fortes, os desenvolvedores estão trabalhando em corrigir a vulnerabilidade que foi explorada pelo hacker, ainda não está claro como isso será resolvido, mas o processo pode ser acompanhado no repositório do GitHub: nano-node.
Chantagem contra a Nano Foundation
Até o momento, apresentei fatos conclusivos, mas agora entramos na área da especulação, teorias e rumores, que vou compartilhar com você, leitor do Cointimes.
Há algumas semanas, o usuário DaRealJesus assumiu responsabilidade pelos ataques em um servidor de discord da comunidade.
Ele disse que “ainda não conseguia fazer o ataque spam”, quando foi questionado por outro membro, mas que estava realizando “testes de otimização”, com os ataques individuais.
O que se provou verdade no sábado, quando os testes foram colocados em prática e conseguiu afetar a rede.
Rumores nos grupos dizem que DaRealJesus – um membro conhecido e antigo na comunidade, que já contribuiu muito com o ecossistema da Nano – perdeu mais de $5 mil dólares com trades com a XNO e sentiu uma necessidade de vingança. Por isso estava realizando estes ataques.
Mais rumores dizem que o “hacker” fez uma tentativa de extorsão contra a Nano Foundation, exigindo o pagamento de $10.000 USD para que ele encerrasse os ataques.
A comunidade, em sua maioria, se mostrou contrária ao pagamento do valor e é fato conhecido que a Nano Foundation não tem intenção nenhuma de fazê-lo, tendo ignorado publicamente a tentativa de chantagem pelo atacante.
Mais sobre esse tipo de ataque
Os nodes continuam recebendo uma alta quantidade de blocos inválidos, mas até o momento nenhum novo atraso foi registrado.
Um desenvolvedor experiente – @trashman – disse que o ataque no sábado foi robusto e exigiu uma estrutura relevante para conseguir o resultado alcançado.
Ele [trashman] tentou reproduzir o que foi feito e, mesmo com 2 computadores potentes e boa conexão com a internet, atingiu menos de 10% do que foi realizado pelo atacante ou, segundo ele, pelo, mais provável, grupo de atacantes.
Ataques de negação de serviço, ou ataques spam, são as maiores ameaças atualmente ao protocolo da nano, que não possui taxas para transacionar e, portanto, é mais vulnerável à isso.
Atrasos, mesmo que mínimos, nas transações, prejudicam muito as operações de negócios e usuários que utilizam nano em seu dia-a-dia e é por isso que a equipe está tão empenhada em resolver estes problemas nas atualizações futuras. Encontrando alternativas à cobrança de taxas que é eficiente contra ataques spam, mas acaba punindo usuários honestos que precisam pagar o custo da prevenção.
Entre março e maio de 2021, a rede da nano foi vítima de um massivo (e muito caro) ataque spam que dobrou o número de blocos na ledger e gerou atrasos até mesmo de vários dias para alguns usuários, que tiveram seu dinheiro travado em blocos não confirmados.
Este ataque foi mitigado com a atualização v22 do software que alterou a forma como a rede prioriza os blocos a serem confirmados, punindo automaticamente um suposto atacante e dando prioridade para usuários legítimos, através de um sistema de filas que coloca transações realizadas por endereços menos utilizados na frente de endereços que estão realizando muitas transações em sequência.
Até o momento outros ataques semelhantes haviam sido realizados sem sucesso, demonstrando a eficiência do método que ainda está longe do ideal e continua em melhoria constante.
Leia mais:
