Distorções do tempo, Exploração de Mineração, Negação de Serviço e Mais!
Os entusiastas de criptomoedas vivem dizendo às pessoas comuns o quão seguros e protegidos são os protocolos Blockchain que alimentam suas moedas preferidas. De fato, criptomoedas grandes como Bitcoin e Ethereum vêm mantendo sua segurança muito bem - melhor, sem dúvida, do que qualquer outro sistema de ativo/pagamento na história, o que é, bastante notável considerando que eles são dinheiro digital não endossado, livre de controle de qualquer parte com uma recompensa efetiva de vários milhões de dólares em suas proverbiais cabeças.
Muitos, entretanto, darão um passo mais adiante e declararão que as ditas criptomoedas são literalmente “não hackeáveis”. Isso é, no mínimo, um erro tático, já que a proliferação da meme “não hackeáveis” coloca o entusiasta em algumas posições inconvenientes quando ou se alguns eventos se revelam. Como, digamos, um hack.
Em tal evento, parece que, no mínimo, uma explicação é pedida.
No mês passado, um invasor ainda não identificado foi capaz de comprometer seriamente a Verge, uma criptomoeda relativamente pequena, com foco na privacidade. O hacker misterioso conseguiu dominar a rede em três ocasiões por intervalos de várias horas ao longo de 4 a 6 de abril, impedindo qualquer outro usuário de fazer pagamentos. Pior que nesse intervalo eles conseguiram gerar o que é uma Verge pirata a uma taxa de 1.560 moedas Verge (aproximadamente US$80) por segundo, cunhando o que equivalia a mais de um milhão de dólares em moeda.
Não há necessidade de rodeios — isso foi um desastre. A coisa foi hackeada para o céu.
Sumário
3 . Mineração Verge ou quando cinco algoritmos não são melhores do que um
Mas a quem culpar? Isso é um caso de erro humano da parte dos desenvolvedores da Verge, um enfraquecimento dos fundamentos da criptografia ou algo intermediário? Uma coisa assim poderia acontecer de novo, talvez com moedas maiores, e se sim, o que pode ser feito para prevenir isso?
Com esse tipo de violação, muitos detalhes inevitavelmente permanecem obscuros. Contudo, nesse caso, os exploits fundamentais podem ser compreendidos com bastante clareza. Adiante:
Falsificação de timestamp
A raiz do exploit é algo que pareceria, à primeira vista, ser um bug, mas na verdade é um recurso deliberado: a habilidade de criar timestamps “incorretos”. Nos protocolos das blockchains, transações individuais (comumente, pagamentos de uma parte para outra) são agrupadas num único bloco, que é então confirmado como um todo. Todo bloco vem com um timestamp da sua data de criação. Mesmo quando um protocolo blockchain está funcionando adequadamente, a ordenação desses timestamps pode algumas vezes estar fora de sequência, ou seja, bloco 100 pode ter um timestamp que, na verdade, vem depois do bloco 101. Isso porque nas redes descentralizadas que obstinadamente recusam a conceder qualquer autoridade especial a terceiros, impondo precisamente uma sincronização do tempo, não é uma questão simples. Dada a variância imprevisível do tempo que os dados levam para se propagarem pela rede peer-to-peer, é completamente possível que os tempos de bloco apareçam “fora de ordem”, mesmo que todas as partes estejam sendo perfeitamente honestas. Em outras palavras, é pelo menos justo, permitir um certo grau de flexibilidade; no caso da Verge (antes do hack, de qualquer forma), o protocolo permitiu que nós (nodes) “discordassem” sobre o tempo corrente por uma janela, de pelo menos duas horas.
O ponto de entrada para o hacker foi começar a falsificar os timestamps, enviando blocos que parecem ser do passado, mas estão ainda alocados na janela de duas horas e então, elegíveis para serem aceitos por outros nós.
O porquê disso, em última instância, ser importante para a segurança da rede, tem a ver com a natureza da mineração proof-of-work.
Dificuldade de Mineração
Manter a rede Verge descentralizada exige assegurar que dispositivos de pequena escala (macbooks, digamos) possam participar da execução do software na rede. Isso, por sua vez, significa limitar o volume de atividade de pagamento na rede, ou seja, estabelecer uma meta clara do tempo do bloco (e, por sua vez, um limite de transações da rede por segundo). Para a Verge, a meta é um bloco por 30 segundos. Agora, alguém pode perguntar, dado que a rede é descentralizada, como isso pode ser aplicado? O que está impedindo as partes de enviarem blocos num ritmo muito mais rápido? Isso não é um problema trivial. Dado que um bloco aceito ganha para o remetente uma recompensa de bloco, é um incentivo para o remetente, confirmar os blocos o mais rápido possível.
A resposta, em resumo, é a mineração proof of work. Para um bloco ser considerado válido pela rede, precisa conter uma solução para um problema computacional criptograficamente difícil derivado diretamente dos dados do próprio bloco. A natureza desse problema é tal que a dificuldade pode ser livremente ajustada. O tempo alvo do bloco para a Verge é de um bloco a cada 30 segundos e a dificuldade dos blocos de mineração é constantemente ajustada com base na taxa corrente de confirmações de blocos; se mais pessoas decidirem dedicar mais poder de mineração para gerar blocos da Verge e mais blocos forem minerados mais rapidamente, o protocolo aumenta a dificuldade de mineração e o envio de blocos é restringido. Por outro lado, à medida que o poder de mineração diminui e o tempo do bloco aumenta, a mineração fica mais fácil. Então, quando funcionando corretamente, mesmo como mudança confusa de fatores da vida real — flutuações da economia, preços de mercado de criptos, mercados de energia, impérios subindo e caindo, etc —a rede Verge está sempre reagindo e direcionando a rede para nossa meta de equilíbrio de taxa do bloco.
O algoritmo que a Verge usa para calcular dificuldade corrente é chamado Dark Gravity Wave; ele envolve obter uma média ponderada das confirmações da taxa de bloqueio numa janela móvel de 30 minutos. É um pouco complexo e os detalhes realmente não importam aqui — o que importa é o seguinte: a dificuldade de mineração é uma função da frequência do bloco e, executar cálculos da frequência de bloco naturalmente envolve olhar para os timestamps dos blocos.
E consequentemente, o problema: se um número suficiente de timestamps defeituosos está sendo criado, todas as disputas serão canceladas. E foi isso que o hacker fez — a análise dos dados da_ blockchain_ revela que durante o hack, todos os outros blocos foram enviados com um timestamp de aproximadamente uma hora antes do tempo atual, confundindo tragicamente o algoritmo de ajuste de mineração do protocolo. Se o protocolo fosse senciente e fluente em inglês, ele diria algo assim: “Ah não! Não foram enviados blocos suficientes recentemente! A mineração deve estar muito difícil - Vamos facilitar”! Como os timestamps estivessem sendo continuamente falsificados, o protocolo reduziria a dificuldade continuamente até que a mineração se tornasse ridiculamente fácil. Para dar uma ideia geral, a média de dificuldade em horas antes da invasão foi 1393093.39131, enquanto durante a invasão ela se tornou tão lenta quanto 0.00024414, uma redução da dificuldade de mais de 99.999999%. Dificuldade menor para enviar um bloco significa mais blocos a serem enviados — nesse caso, aproximadamente um bloco a cada segundo.
A engenhosidade dessa invasão está em como ela contorna a barreira de dificuldade de mineração ao invés de tentar rompê-la. Se a proteção fornecida pelo poder de mineração é um portão ao redor da rede —um portão que é muito forte para ser quebrado e muito alto para ser escalado — esse hack consegue passá-lo encontrando uma forma de baixá-lo tão perto do chão que permita caminhar por cima dele.
Se já não é óbvio, isso é por si só uma má notícia. Uma violação de um protocolo planejado, dessa forma tão gritante, simplesmente não é uma boa imagem. Além disso, o aumento drástico da taxa de envio do bloco significa muito mais Verge recém minerados do que o protocolo havia previsto, o que deve incomodá-lo caso você seja o tipo de economista que tem uma queda por dinheiro sólido com uma taxa stock-to-flow alta e previsível.
Contudo, reduzir a dificuldade é apenas a metade da história; isoladamente não daria nenhuma vantagem ao invasor. Com a dificuldade drasticamente menor, minerar os blocos se torna mais fácil para o invasor, mas também fica mais fácil para qualquer outra pessoa; mineradores estão sempre em competição entre eles, assim como o economista descrito acima. O que deveríamos esperar ver é que apesar de, sim, os blocos serem minerados mais rapidamente, as identidades dos mineradores bem sucedidos devem ser tão distribuídas e democráticas quanto antes. Ou, colocando de outra forma, independente da dificuldade, um único invasor deveria ainda precisar de 51% do poder de mineração para dominar a rede.
Entretanto, esse hacker de fato assumiu toda a rede e foi capaz disso com bem menos do que 51% da taxa de hash. O que permitiu que fizessem isso é o segundo componente do exploit, que tem a ver com o uso de múltiplos algoritmos de mineração.
Mineração Verge ou quando cinco algoritmos não são melhores do que um
Geralmente, os blocos de criptomoedas baseadas em proof-of-work são minerados por um único algoritmo, sendo o mais comum o SHA-256. A Verge, contudo, permite que mineradores usem qualquer dos cinco algoritmos diferentes (para os que estão morrendo de vontade de saber, os algoritmos que a Verge usa são Scrypt, X17, Lyra2rev2, myr-groestl e blake2s.) A justificativa para usar vários algoritmos é algo assim:
Alguns críticos do Bitcoin argumentam que ao longo do tempo, a indústria de mineração do Bitcoin se tornou muito especializada e centralizada; a maior parte da mineração da moeda, por exemplo, é executada pelos Bitcoin ASICs, dispositivos criados com o único propósito de mineração da moeda, e muito da mineração do Bitcoin é executado por alguns pools de mineração — grupos de mineradores que unem seus recursos e dividem as recompensas proporcionalmente. Essas tendências em direção a diferentes tipos de “centralização”, eles dizem, são antiéticas em relação à proposta de valor fundamental das criptomoedas não permissionadas. Fazer uma moeda usar vários algoritmos de mineração pretende ser um respaldo contra essas tendências. O argumento é que controlar cinco algoritmos diferentes em termos de hardware, indústria e gerenciamento de recursos deve ser mais difícil que controlar apenas um, levando a economia de mineração da Verge numa direção mais distribuída e descentralizada.
Então aqui está o negócio: a única maneira disso funcionar corretamente — e “funcionar corretamente” nesse caso inclui manter tempos de bloco de 30 segundos, manter todos os cinco algoritmos consistentes para os mineradores e evitar que um dos cinco algoritmos domine (o que tornaria todo o experimento inútil) — é fazer com que cada algoritmo tenha seu próprio parâmetro de dificuldade que fica ajustado independentemente dos outros quatro. Que é dizer que a dificuldade de minerar do Scrypt é ajustada para alcançar equilíbrio de bloco de 30 segundos, como é a do X17 e assim por diante.
O que isso significa é que nosso falsificador de timestamp, de fato, não reduziu a dificuldade de mineração para toda a rede; ele apenas a reduziu para as minerações com um dos cinco algoritmos — por fim, o Scrypt. Assim, enquanto todos os mineradores do Scrypt agora aproveitam o grau de dificuldade de mineração comicamente fácil, os mineradores que utilizam os outros quatro algoritmos estão presos tendo que trabalhar tão duro quanto antes, tornando todo seu poder de hash efetivamente inútil para proteger a rede. Categoricamente, isso significa que o invasor apenas teve que minerar com o algoritmo do Scrypt e apenas teve que competir com os outros fazendo o mesmo; então, o poder de hash exigido para nosso invasor dominar sai de mais de 50% (dominar a rede toda) para apenas mais de 10% (dominar os outros mineradores Scrypt).
Agora nesse ponto, as coisas se tornam um pouco especulativas, mas parece que a situação era muito pior do que isso. A estimativa de 10% origina-se do fato de que dada a natureza do ajuste da dificuldade de mineração, aproximadamente a mesma quantidade de recursos econômicos deve ser utilizada para cada um dos cinco algoritmos de mineração. A realidade, muitas vezes, tem uma maneira de recusar obstinadamente a se conformar com os axiomas da economia de livre mercado. De acordo com discussões na comunidade, vários fatores — a existência dos Scrypt ASICs que já tiveram que ser implementados, os recursos extras disponíveis para aluguel via Nicehash etc — sugerem que o Scrypt deveria, no momento da invasão, ter ficado muito mais barato para dominar do que qualquer dos outros quatro algoritmos. Pode-se assumir com segurança que a taxa de hash exigida, em última instância, chega a bem menos do que 10%; algumas estimativas de última hora no reddit colocam que a taxa chegou a 0.4%.
Assim, em resumo: a falsificação do timestamp possibilitou uma redução drástica da dificuldade de mineração; o uso da Verge de cinco algoritmos mostrou que se pode reduzir a dificuldade de apenas um deles, tornando, então, mais fácil cancelar a rede toda; o status econômico/industrial desse algoritmo de mineração específico ainda tornou mais fácil dominá-lo; e, finalmente, os tempos do bloco drasticamente reduzidos, resultantes da baixa dificuldade, tornaram as invasões aproximadamente 30 vezes mais lucrativas do que seria de outra forma.
Lições Aprendidas
O que pode ser absorvido disso tudo? As consequências de curto prazo do hack foram previsivelmente desorganizadas e confusas. Depois de alguns dias difíceis, os desenvolvedores principais implantaram algumas correções rápidas de bug, que podem ou não ter tido erros incorporados e a rede acabou passando por um hard fork, que pode ou não ter sido inicialmente um acidente. Quanto à resposta no mundo em geral, na semana após o hack o preço da Verge aumentou 30% e na semana seguinte, foi anunciado que a Verge seria aceita como pagamento de assinatura para o pornhub.com. Exatamente como o maior hack em nível de protocolo de uma criptomoeda, na memória recente, poderia preceder a referente criptomoeda, aumentando no preço e depois anunciando uma parceria com um site pornô mais traficado na internet, é uma pergunta que eu sou forçado a deixar em aberto; minha teoria especial predileta é que isso tem alguma coisa a ver com o fato de que o mundo não faz sentido e os seres humanos são todos completamente fora de suas mentes malditas.
Mas eu divago. No plano maior das coisas, pode realmente haver algum aprendizado aqui:
Primeiramente, o truque de usar timestamps para reduzir artificialmente a dificuldade é um que realmente tem sido conhecido há tempo suficiente para ter seu próprio nome — o exploit “time-warp” (distorção do tempo). Pode-se encontrar discussões sobre vetores de ataque em fóruns do Bitcoin de anos atrás. De certa forma, o que fez a invasão funcionar na Verge foi o uso do mais novo e sofisticado algoritmo de ajuste de dificuldade, Dark Gravity Well no qual a dificuldade é ajustada a cada novo bloco, oposto ao que acontece com o Bitcoin, cuja dificuldade é ajustada apenas a cada 2016 blocos. Ao ajustar dificuldades em incrementos tão espaçados e discretos pode parecer, à primeira vista, uma decisão de projeto estranha, esse hack deixa claro que é apenas uma precaução de segurança; se houvesse alguma forma de reduzir um pouco a dificuldade de mineração, no Bitcoin, o invasor só poderia fazer uma vez a cada duas semanas, tornando os resultados insignificantes, comparado com a Verge, onde eles podem fazer isso uma vez a cada 30 segundos.
Curiosamente, um dos supostos benefícios do Dark Gravity Wave é especificamente que ele deveria ser imune ao exploit de distorção do tempo. Dado o quão decisivamente tal afirmação foi agora refutada, outras moedas que a utilizam deveriam estar, no mínimo, um pouco nervosas.
Quanto ao uso de cinco algoritmos de mineração: embora, à distância isso pareça ser um experimento valioso para incentivar economicamente a descentralização, novamente introduz novas complexidades que inevitavelmente aumentam a probabilidade do surgimento de vulnerabilidades imprevisíveis.
Em ambos os casos esse hack apresenta argumento forte para a tendência de se ater a coisas que comprovadamente funcionam e de estar atento a coisas excessivamente complicadas e que consequentemente introduzem riscos desnecessários quando ativos financeiros das pessoas estão envolvidos. O que, eu suponho, significa dois pontos para o time do Bitcoin.
Há um ponto maior a ser feito aqui: desenvolvedores de software, por mais que detestemos admitir, são, em última análise, humanos. Mesmo quando os princípios de proteção subjacentes parecem perfeitamente sólidos, sempre vai haver espaço para erros. Vetores de ataque inesperados emergem; trade-offs são mal estimados e então, naturalmente, sempre vai haver os bons e velhos bugs. Esse software nem sempre funciona da forma que gostaríamos que funcionasse e o fato de que essas falhas podem levar a perda de fundos, não deve ser particularmente chocante para ninguém em 2018. Mas quando esse software é, de fato, dinheiro, vale a pena uma camada extra de proteção.
Dado que muitos de nós não tem tempo livre para conduzir uma revisão completa do código de cada projeto no qual investimos, as melhores proteções contra desastres são depositar mais confiança nas coisas que têm um histórico comprovado de funcionar corretamente e cujo caráter de desenvolvimento se inclina para o lado conservador. E se você quiser investir fundos em projetos mais experimentais, do tipo “mova rápido e quebre as coisas e levante dinheiro”, pelo menos esteja ciente dos riscos envolvidos. Mais importante, a pressão da comunidade para a devida diligência na tentativa de mitigar desastres futuros é, em última análise, a melhor defesa. Acredito que foi o George Santayana que disse “Aqueles que não aprendem com as falhas de segurança do passado estão condenados a reimplantá-las”, palavras a serem acatadas para que não nos encontremos inesperadamente à beira de fazer a distorção do tempo de novo.
Correção: A janela de redirecionamento da dificuldade foi originariamente relatada como sendo igual ao desvio de tempo permitido (2 horas). De fato, a janela de redirecionamento é atualmente 30 minutos, que, para aqueles que acompanham em casa, é de fato INFERIOR ao desvio de tempo permitido.
Atualização (22/5): Parece que estamos, realmente, fazendo de novo distorção do tempo; a mesma vulnerabilidade está sendo explorada de novo enquanto nós falamos, embora a palavra é que dessa vez o(os) hacker(s) usou(usaram) dois algoritmos de mineração ao invés de um. Fique ligado!
Atualização: Leia o artigo de acompanhamento do segundo hack aqui
Para perguntas: [email protected]
14 maio, 2018
Este artigo foi escrito por Daniel Goldman, traduzido por Fátima Lima e você pode acessar o original aqui.
Top comments (0)