Anatomia dos criptomineradores: Encerrando botnets de mineração
Índice
Introdução
Boas-vindas à última edição da nossa série de blogs sobre Anatomia dos criptomineradores:
Em nossa primeira publicação, discutimos criptomoedas em geral, os vários atributos delas e o que torna algumas mais atraentes do que outras para agentes de ameaças.
Na segunda parte, analisamos diversas amostras de mineração de criptomineração que encontramos abusando de diferentes topologias de mineração.
Nesta terceira e última publicação do blog da série, exploraremos duas novas técnicas proativas que podem ser usadas para derrotar os criptomineradores.
Além dessas publicações do blog, lançamos várias ferramentas de análise que podem ser encontradas em nosso repositório.
Todo mundo sabe que a melhor defesa é o ataque. Devido à natureza distribuída das campanhas de criptomineradores, interrompê-las pode ser muito desafiador.
Nesta publicação do blog, mostramos como superar esse problema explorando o design de topologias de mineração comuns para encerrar efetivamente o processo de mineração. Embora as técnicas que descrevemos tenham sido usadas para atingir os criptomineradores do Monero, os mesmos princípios também podem ser aplicados a outras criptomoedas.
Encerrando as operações de criptomineradores
Quando uma operação de criptominerador mal-intencionado é detectada, há atualmente duas maneiras de tentar desativá-la:
Podemos solicitar que a conta do invasor seja banida pelo o serviço de pool
Podemos tentar derrubar outros serviços na infraestrutura do invasor para interferir na campanha
O problema com essas opções é que elas podem se tornar bastante complexas e demorar muito tempo por causa da dependência de terceiros.
Encontramos uma opção melhor.
Desenvolvemos duas técnicas aproveitando as topologias de mineração e as políticas de pool que nos permitem reduzir a eficácia de um botnet criptominerador até o ponto de desligá-lo completamente, o que força o invasor a fazer alterações radicais em sua infraestrutura ou até mesmo abandonar toda a campanha.
Ambas as técnicas baseiam-se na exploração das comunicações da Stratum de modo a permitir a proibição de componentes críticos, como proxies ou carteiras, que estejam relacionados com as contas da operação de mineração.
3,3 milhões para zero
Visamos uma operação maliciosa de criptomineração que está ativa há seis anos. Ao banir o proxy de mineração do invasor, um ponto central de falha na topologia de mineração, conseguimos reduzir sua taxa de hash de 3,3 milhões de hashes por segundo até zero (Figura 1).
Tão facilmente quanto os invasores estavam fazendo dinheiro, conseguimos encerrar a receita anual potencial do invasor em questão de segundos. Ao usar um simples notebook, fizemos com que a operadora de criptominerador perdesse US$ 26.000 por ano de fluxo de caixa com a taxa de hashes agora despencada.
O vídeo na Figura 2 demonstra essa técnica, que nós apelidamos de "compartilhamentos ruins". Ele retrata uma vítima de criptominerador que está conetada a um proxy de mineração mal-intencionado. Ao executar "compartilhamentos ruins", foi possível banir o proxy de mineração da rede, desligando a operação de mineração e diminuindo o uso da CPU da vítima de 100% para 0%.
Fig. 2: Aplicando a técnica de compartilhamentos ruins na configuração do laboratório
Se não puder derrotá-los, bana-os
A criptomineração por um pool é baseada no envio de cálculos de hash válidos, chamados de compartilhamentos. Para gerar receita, uma criptominerador deve enviar ações para o pool de mineração. Ao receber um compartilhamento, o pool de mineração validará o resultado e a dificuldade do hash.
A validação de compartilhamentos é uma das tarefas mais pesadas que o servidor de pool precisa realizar, especialmente em casos de compartilhamentos inválidos. Assim como acontece com tudo na vida, erros são possíveis; por exemplo, um mau funcionamento de hardware pode levar a compartilhamentos incorretos sendo enviados ao pool.
O tratamento de compartilhamentos inválidos consome muitos recursos, portanto, os pools devem se proteger contra o colapso sob uma carga de envios massivos de compartilhamentos inválidos. Portanto, quando uma ação enviada não passar pela validação do servidor, a maioria dos pools aplicará uma penalidade ao minerador, geralmente na forma de uma proibição temporária.
Essa interação pode ser muito interessante quando se tenta encerrar uma operação de mineração maliciosa. Se pudermos fazer um nó de back-end ou um pool para banir os mineradores invasores (ou seja, as vítimas), poderemos parar a exploração de recursos do criptominerador e, essencialmente, liberar as vítimas.
Nas seções a seguir, demonstramos esse conceito direcionando duas campanhas de mineração que já exploramos anteriormente, cada uma representando uma topologia de mineração diferente: um proxy de mineração e uma conexão direta de pool público.
Usar compartilhamentos ruins para proibir um invasor que esteja usando proxy de mineração
Uma das topologias de mineração mais populares usadas por criptomineradores mal-intencionados é um proxy de mineração (Figura 3). Essa configuração aumenta a privacidade ocultando o endereço de back-end e o endereço da carteira dos invasores, protegendo assim suas identidades e reduzindo a rastreabilidade dentro da rede.
Os proxies de mineração representam desafios únicos para a detecção de rede, pois "ocultam" o pool de destino ao qual o minerador se conecta, o que geralmente é detectável pela inspeção de rede. Eles também ocultam o endereço da carteira, o que reduz ainda mais o rastro detectável do minerador. No entanto, descobrimos que os proxies de mineração podem servir como um calcanhar de Aquiles dos criptomineradores.
Durante a mineração usando um proxy, todas as vítimas são conectadas a um único servidor, o que significa que a interferência com o proxy pode reduzir toda a operação de mineração. Desenvolvemos uma técnica que nos permite fazer exatamente isso.
A ideia é simples: Ao conectar-se a um proxy mal-intencionado como um minerador, podemos enviar resultados de trabalho de mineração inválidos, compartilhamentos inválidos, que ignorarão a validação do proxy e serão enviados ao pool. Compartilhamentos ruins consecutivos acabarão sendo banidos pelo proxy, interrompendo efetivamente as operações de mineração para todo o botnet de criptomineração.
Comunicação com o proxy
O criptominerador deve primeiro se conectar ao proxy usando o método de login do Stratum. Se nenhuma outra configuração foi definida, o minerador se identifica como x por padrão no servidor proxy XMRig (Figura 4).
Se a conexão for bem-sucedida, isso significa que há um ouvinte na extremidade do proxy. Podemos garantir que seja realmente um proxy de mineração analisando a resposta, uma resposta válida será um documento JSON que está em conformidade com o protocolo Stratum e o resultado será um trabalho.
Embora o processo completo de mineração seja complexo (conforme descrito em Zero a Monero), criar um compartilhamento personalizado é relativamente simples. Ele só requer a extração de alguns valores da resposta de proxy: O id do npi de trabalho, o id do trabalho e o nicebash nonce. Os três são necessários para acompanhar um trabalho de mineração específico, portanto, se quisermos que o proxy aceite nossos compartilhamentos ruins, precisamos preencher esses campos corretamente (Figura 5).
Ao receber um compartilhamento de um minerador, o proxy o encaminhará para o pool quase como está, com uma diferença importante: ele é enviado sob o endereço de carteira do invasor. É por isso que nunca podíamos saber a carteira ou outras informações sobre a conta do invasor ou o pool da amostra do criptominerador.
XMRogue
Infiltrar-se na botnet de criptomineradores como uma das vítimas não é difícil. Geralmente, não há autorização especial e, em muitos casos, ele usa aplicações padrão como XMRig como minerador e XMRig-proxy como um proxy de mineração.
Isso nos levou a desenvolver o XMRogue. O XMRogue é uma ferramenta que nos permite representar um minerador, conectar-se a um proxy de mineração, enviar compartilhamentos ruins consecutivos e, por fim, proibir o proxy de mineração do pool (Figura 6).
Uma consideração importante é a validação de ações no nível do proxy. Como nossos compartilhamentos inválidos são encaminhados ao pool pelo proxy, ele tem a oportunidade de identificá-los e abandoná-los.
Por exemplo, o popular XMRig-proxy validará o nicehash nonce que ele fornece com o trabalho e a dificuldade do resultado. Se o nonce ou a dificuldade estiverem incorretos, o compartilhamento ruim não será encaminhado para o pool de back-end. Na Figura 7, vemos a validação dentro do código, na qual compartilhamentos com hashes de baixa dificuldade ou valores incorretos de nicehash são descartados.
Podemos superar essas validações analisando a solicitação de trabalho e elaborando cuidadosamente um resultado de trabalho "ruim" que é considerado válido pelo proxy, fazendo com que ele encaminhe nossos compartilhamentos para o pool.
Testando a teoria
Para testar nossa técnica, optamos por visar uma das campanhas de mineração identificadas na parte dois desta série. Conseguimos extrair os endereços de todos os proxies de mineração usados pela campanha escolhida, o que nos dá um pouco de informação para analisar. Por exemplo, podemos ver que o proxy do invasor central, criativamente chamado de "proxy", tem uma classificação máxima da Nanopool, que indica uso estendido (Figura 8).
Esse proxy gera 3 milhões de hashes por segundo, aproximadamente igual a uma receita de US$ 3 por hora ou US$ 26.000 por ano. Ao segmentar este proxy com o XMRogue, conseguimos rapidamente bani-lo do pool e parar a mineração de todas as vítimas que estavam conectadas a ele. Se inspecionarmos a taxa de hashes do proxy, poderemos ver que ela caiu até zero (Figura 9).
Se considerarmos o impacto do XMRogue em toda a campanha do atacante, poderemos ver uma redução substancial em sua lucratividade. Quando documentamos esta campanha pela primeira vez, ela gerou quase US$50.000 anualmente. Depois de o termos perturbado e desequilibrado, a receita anual da campanha diminuiu 76% para US$ 12.000. Com a segmentação de proxies adicionais, a receita pode ter caído para zero. Esse tipo de impacto poderia facilmente forçar os invasores a abandonar a campanha para obter um bom valor ou correr o risco de ser identificados ao fazer alterações que estão sendo monitoradas.
Aproveitar outras políticas de pool de mineração
Os invasores nem sempre usarão um proxy. Em muitos casos, as vítimas se conectarão diretamente ao pool, o que significa que a técnica anterior não será aplicável. O envio de compartilhamentos inválidos simplesmente proibirá nosso endereço IP do pool, sem afetar a operação de mineração.
Ao inspecionarmos o código-fonte do pool de mineração, outra opção veio à mente, segmentar o endereço da carteira. Embora a política anterior de ações inadequadas segmente endereços IP de mineradores, identificamos uma política adicional que é imposta no nível da carteira: o pool proibirá o endereço da carteira por uma hora se tiver mais de 1.000 nós de trabalho.
Ao usar a mineração de proxy, um invasor pode incorporar o endereço de carteira exclusivamente no servidor proxy, permitindo que ele se disfarce com eficiência. Mas em situações em que a mineração direta é realizada, o endereço da carteira deve estar presente na máquina da vítima, o que nos permite extraí-la.
É fácil banir o invasor nesse caso: basta enviar mais de 1.000 solicitações de login usando a carteira do invasor simultaneamente, o que forçará o pool a banir a carteira do invasor. Essa técnica foi adicionada como um modo de operação à ferramenta XMRogue.
Para ilustrar essa ideia, usamos outra campanha que descobrimos e que usa o pool público MoneroOcean. O estado inicial da campanha era uma taxa de hashes de 22 kH/s (Figura 11). Esta campanha é muito menor do que a que discutimos acima, mas a técnica em si deve abranger uma gama mais ampla de configurações de campanhas de criptomineração.
Após lançarmos nosso script, que instantaneamente inicia milhares de logins, vimos a taxa de mineração despencar, eventualmente parando completamente (Figura 12).
Rede mais larga, captura mais rasa
Essa tática poderia interromper mais operações de mineração, mas não é uma solução permanente. Assim que interrompemos as várias conexões de login, a taxa de hashes da campanha foi recuperada (Figura 13).
Resumo
As técnicas apresentadas acima mostram como os defensores podem efetivamente encerrar campanhas mal-intencionadas de criptomineradores sem interromper a operação legítima do pool, aproveitando as políticas do pool. Um minerador legítimo poderá se recuperar rapidamente desse tipo de ataque, pois pode modificar facilmente seu IP ou carteira localmente.
Essa tarefa seria muito mais difícil para um criptominerador mal-intencionado, pois exigiria a modificação de toda a botnet. No entanto, para mineradores menos sofisticados, essa defesa pode desativar completamente a botnet.
Conclusão da série
Esta publicação conclui nossa série Anatomia dos criptomineradores. Abordamos os fundamentos da mineração de criptomoedas e exploramos a mentalidade do invasor por meio da caça a campanhas ativas que implementam diferentes topologias de mineração.
Acreditamos que a ameaça dos criptomineradores continuará a crescer com o tempo. Mas agora podemos combater e interromper a operação dos invasores, tornando muito mais difícil monetizar os criptomineradores com eficiência.