Prova de Conceito: Protocolos IPFS e IPNS como meio para o controle de botnet

Prova de Conceito: Protocolos IPFS e IPNS como meio para o controle de botnet

Essa postagem originalmente era um short paper escrito para a edição de 2017 da SBSeg (Congresso de Segurança), porém, como o artigo foi recusado, o assunto começou a envelhecer de lá para cá (outras pessoas passaram a escrever assuntos bem semelhantes, como essa) e não estava mais com vontade de continuar a pesquisa, decidi publicar aqui no meu blog, para ao menos o texto não se perder.
A versão em inglês do artigo pode ser encontrada aqui, com o título de IPFS​ ​and​ ​IPNS​ ​protocols​ ​as​ ​way​ ​for​ ​controller​ ​of​ ​botnet:​ ​a​ ​proof of​ ​concept. E aqui está o repositório com o código fonte do projeto desenvolvido no artigo.

Abstract. To make internet safer, a fundamental step is to avoid the usage of a remotely-controlled infected computer network (Botnet) by a malicious user (Botmaster) who may use it to, among other ends, DDoS attacks. To fight against this problem, a challenge is the evolution of command and control services (C&C) used by the Botmaster for Botnet management, as they are, every time more sophisticated and hard to detect. A natural evolution of C&C is the usage of new distributed computing protocols. This paper outlines a new proof of concept for a C&C using both protocols, IPFS and IPNS, that allowed the Botmaster to acquire safer and more anonymous communication. Inhere, also, is presented a brief study of detection of executables using such protocols and techniques.

Resumo. Para tornar a internet mais segura, um passo fundamental é combater o uso de uma rede de computadores infectados e remotamente controlados (Botnet) por um usuário malicioso (Botmaster), que pode usá-la para, dentre outros fins, ataques DDoS. Para combater esse problema, um desafio é a evolução do serviço de comando e controle (C&C) usado pelo Botmaster para gerenciar a sua Botnet, pois estão cada vez mais sofisticados e difíceis de se detectar. Uma evolução natural no C&C seria o uso de novos protocolos de computação distribuída. Esse artigo apresenta uma prova de conceito do C&C com dois desses protocolos, o IPFS e IPNS, que assim possibilitou o Botmaster em obter uma comunicação mais segura e anônima. Onde, também, é apresentado um breve estudo de como detectar um executável usando tais protocolos e técnicas.

Introdução

Existem malwares cujo propósito é tornar os computadores das vítimas remotamente controláveis pelo atacante. Uma rede de computadores controlada dessa forma é comumente conhecida como botnet, sendo cada máquina infectada chamada de bot, e o controlador dessa rede é denominado botmaster. A rede é acessível para o botmaster por meio de um serviço de comunicação conhecido como Command-and-Control (C&C). Desse modo, o botmaster adquire um grande poder computacional, do qual pode usufruir para, por exemplo, realizar um ataque do tipo Distributed Denial-of-Service (DDoS) [1].

O C&C é a parte fundamental de uma botnet. Ele precisa garantir o anonimato do botmaster e ser um meio seguro de comunicação, para evitar que o malware seja facilmente detectado, assim como evitar ataques sybil [2]. Diversos protocolos, como IRC, HTTP e DNS [3], assim como diferentes topologias, como centralizada e distribuída, são usadas para desenvolver diferentes C&C [4].

Nesta pesquisa, foi desenvolvida uma botnet como prova de conceito cujo C&C usa dois novos protocolos: InterPlanetary File System (IPFS) e InterPlanetary NameSpace (IPNS). Então foi verificada a viabilidade deles para esse propósito, e se eles oferecem maior anonimato ao botmaster e segurança na comunicação. Em seguida, foram realizadas análises em como detectar uma botnet que use tais protocolos.

Este artigo está organizado da seguinte maneira. A seção 2.1 trata de uma discussão técnica sobre C&C. A seção 2.2 apresenta os protocolos IPFS e IPNS. As seções 3, 3.1 e 3.2 discutem a implementação de um bot usando esses protocolos em seu C&C, a fim de provar o conceito, e também é descrito os resultados obtidos nesse experimento. Por fim, a seção 4 conclui e descreve trabalhos futuros.

Fundamentação Teórica

Nesta seção são explicados os conceitos relacionados a Command-and-Control (C&C) e os protocolos InterPlanetary File System (IPFS) e InterPlanetary NameSpace (IPNS).

Command-and-Control

Diversos modelos de C&C foram propostos e são usados em bots, sendo o modelo de topologia centralizado o mais antigo, em que um único ponto é responsável pela troca de mensagens entre os bots e o botmaster. Dentre os protocolos mais comuns para usar no servidor do C&C estão o IRC e HTTP. As maiores vantagens do modelo centralizado é a baixa latência na comunicação e simplicidade no design para o desenvolvimento [5] [4].

Porém, como desvantagem, o servidor do C&C é um ponto crítico, uma vez que toda a comunicação é realizada por ele e, uma vez descoberto, pode comprometer todo o seu sistema, além de facilitar o monitoramento por terceiros, como pesquisadores e agentes de segurança. Para reduzir o risco do botmaster perder a comunicação de sua botnet em caso de problemas no servidor do C&C, o botmaster pode instanciar múltiplos servidores de C&C e configurar o bot para se comunicar com eles [5] [4].

Devido à fragilidade do modelo centralizado, começaram a ser desenvolvidos botnets com topologia distribuída, também chamado de Peer-to-Peer (P2P) [5]. Com esse modelo, é possível fornecer um maior grau de anonimato ao botmaster [1] e prover resiliência para a botnet, uma vez que não há apenas um único ponto de falha [5]. Algumas desvantagens do modelo P2P em relação ao centralizado é uma maior latência na comunicação e também a complexidade no desenvolvimento [1] [4].

Uma das formas de se detectar um bot é através da análise do tráfego de seu C&C. Por conta disso, os atacantes sempre buscam novos protocolos e formas de se comunicar no C&C para se esquivar dos agentes de segurança [4]. Desse modo, é relevante o estudo de novas técnicas para desenvolvimento do C&C, para compreender e mensurar os riscos futuros.

Protocolos InterPlanetary File System (IPFS) e InterPlanetary NameSpace (IPNS)

O IPFS é um protocolo peer-to-peer para sistemas de arquivos distribuídos [6]. A forma mais simples de acessar o conteúdo do IPFS é por meio do gateway público [7]. Também é possível executar um daemon localmente ou hospedar seu próprio gateway para obter acesso ao IPFS.

Pode-se adicionar dados, tais como arquivos, para o IPFS, os quais passam a ser chamados de object. Cada object adicionado tem uma hash dependendo de seu conteúdo, e será acessível por meio dele. Por exemplo, se um arquivo de texto com o conteúdo "ipfs" for adicionado no IPFS, ele se encontrará acessível com a hash "QmbXBAKDgbhE8HkGuEF4FuQQJej2mxqXtYSMsBPuJDqgjq". Todo object contido no IPFS é imutável, então se for necessário adicionar uma nova versão de um determinado arquivo, na verdade um novo object é criado, totalmente independente do anterior. Desse modo, uma nova hash é obtida e a anterior continua acessível. Por exemplo, se mudar o conteúdo do arquivo para "sbseg", é obtida a hash "QmXXhmvSrjYALb8KZwsfXhyz3ugavbaySNHcp6zAbWQ5yj".

O mecanismo descrito no parágrafo anterior se dá devido ao conceito de content-addressing do IPFS. Ou seja, os dados no IPFS são endereçáveis por meio de uma hash a partir de seu conteúdo, o que garante maior integridade, independente de onde ou quem esteja oferecendo tal conteúdo. Além disso, os links são permanentes, sempre apontando para o mesmo object [7].

Apesar do conceito de content-addressing trazer diversos benefícios, ele torna-se inconveniente caso sempre precise acessar a última versão, pois teria que obter num outro canal a hash da nova versão do object. Para resolver esse problema, foi desenvolvido o protocolo IPNS. Com o peerID, a hash da chave pública do usuário, é possível fornecer um redirecionamento para um determinado object [6].

Ambos os protocolos ainda estão em desenvolvimento, porém diversos experimentos são efetuados e tiveram sucesso, tais como um chat similar ao Slack [8] e um gerenciador de pacotes [9].

Prova de Conceito

Para provar o conceito do uso dos protocolos IPFS e IPNS no C&C, foi desenvolvido um bot que os utiliza. Para poder acessar os arquivos contido no IPFS, foi optado o uso do gateway público, de forma a não precisarmos instanciar no próprio malware um daemon para obter acesso ao IPFS, ou executar em outro servidor um gateway próprio. Porém, o gateway público traz algumas limitações, tais como a impossibilidade de adicionar conteúdo. Apesar dessa limitação, o gateway público é suficiente para a prova de conceito, pois com ele é possível receber dados, neste caso, os comandos emitidos pelo botmaster para a sua botnet.

Figura 1. Diagrama do fluxo de execução da prova de conceito.

Para validar a hipótese, foi desenvolvido um bot que efetua long polling em uma determina hash do IPNS, cujo fluxo de execução é exibido na Figura 1. O bot periodicamente requisita ao gateway público o endereço da hash apontada pelo IPNS, e então o gateway envia a hash do object apontado. O bot então verifica se a hash recebida é diferente da obtida anteriormente para, se for diferente, requisitar o conteúdo do object associado à essa hash, da qual é o comando a ser executado. Por fim, o gateway envia o conteúdo dessa hash. O conteúdo apontado por essa hash contém um texto descrevendo o comando a ser executado, com o padrão "índice comando parâmetros". O campo "índice" é necessário para o caso do botmaster precisar que sua botnet execute duas vezes seguidas o mesmo comando.

Desse modo, foi decidido desenvolver um comando simple que o botmaster poderia executar em sua botnet: efetuar download do arquivo de uma URL, armazená-lo na pasta temp e executá-lo.

Análise dos Resultados da Implementação

Figura 2: Demonstração da execução da aplicação.

Nos experimentos efetuados, foi possível enviar comandos para a botnet através do IPFS e IPNS, tal como exibido na Figura 2. Ao lado direito temos os logs de execução do bot, enquanto no lado esquerdo temos a imagem que o bot automaticamente fez download e abriu, com base no comando emitido pelo botmaster.

Uma das características analisadas foi o tempo da propagação do comando emitido do botmaster para o bot. Há dois fatores principais que atuam no tempo da propagação do comando: o intervalo de checagem do long polling, e a resolução do nome do IPNS. Enquanto o primeiro fator pode ser configurável pelo botmaster, o segundo foge do controle dele. Algo percebido é que a resolução do nome do IPNS costuma demandar alguns segundos. Conforme os testes efetuados, a resolução levou no mínimo 1 segundo e, em média, foi cerca de 10 segundos. Nos casos que demandava mais que 30 segundos, abandonamos a requisição e fazíamos outra no lugar. Atualmente, os desenvolvedores desses protocolos buscam fazer melhorias, visando tornar a resolução do nome do IPNS mais rápido, consequentemente facilitando o uso deste meio em ataques similares [10].

Uma característica no uso do protocolo IPNS é o tempo que o nome fica acessível. Quando o botmaster adicionar um novo object no IPFS e efetuar o redirecionamento de sua hash IPNS para o object adicionado, ele pode desligar o daemon em seu computador. Os nós do IPFS, inclusive do gateway público, continuarão mantendo o seu endereço IPNS, através do sistema de cache, porém, ele será mantido apenas por no máximo até 36 horas [11]. Isso é útil para a manutenção do anonimato do botmaster, porém, pode ser necessário que o mesmo republique o seu endereço IPNS de tempos em tempos, para o comando emitido continue acessível para a sua botnet.

Análise da Botnet

Uma das vantagens que foram observadas ao botmaster foi a possibilidade do uso do IPNS em opção ao registro de domínios para o C&C, da qual os botmasters costumam usar para facilitar a mudança do endereço IP real ou migrá-lo de servidor. Porém, correm o risco de serem descredenciado pela registradora de domínios, e assim perder o controle de sua botnet [4]. Já com o IPNS não existe descredenciamento. Além disso, o botmaster pode criar várias chaves peerID, assim tendo vários nomes diferentes para usar como canal. No lugar do descredenciamento do domínio, algo próximo que pode acontecer é o mantenedor de um gateway adicionar a hash IPNS do botmaster numa blacklist, entretanto, ela continuará sendo acessível em outro gateway, ou através de um daemon local, dando tempo para que o botmaster atualize para um novo endereço IPNS.

A garantia de que a botnet executará somente os comandos legítimos emitidos pelo botmaster é o peerID. Para que uma outra pessoa consiga redirecionar o endereço do IPNS do botmaster para uma outra hash no IPFS, ela precisaria copiar sua chave peerID.

Os protocolos IPFS e IPNS não fornecerem, por si só, um maior ganho de anonimato, uma vez que é possível obter o IP de quem esteja distribuindo/recebendo determinado object. Porém, como esses protocolos são agnóstico à camada de transporte, é possível usá-los juntos de outros protocolos que visam maior ganho de anonimato, como I2P e Tor [12]. Além disso, o botmaster pode usar alguns artifícios para emitir comandos com o IPFS e se manter oculto, como usar diversas chaves peerID, assim como copiar seu peerID em diferentes computadores de diferentes localidades, para então usá-los para adicionar novos object e redirecionar seu endereço IPNS para ele. Desse modo, o IPFS se responsabilizaria em manter e distribuir o arquivo durante um período, sem precisar da participação do botmaster nesse processo, assim ele poderá obter um maior grau de anonimato na propagação dos comandos.

As principais abordagens usadas para a detecção de botnets consistem em utilização de honeypots e monitoramento e análise de tráfego de redes [13]. Neste trabalho foi usada a abordagem baseada em monitoramento e análise de tráfego com o objetivo de identificar informações sobre a estrutura de controle da botnet e estimar possíveis contramedidas para botnets que adotasse esses protocolos.

Com o auxílio de ferramentas de captura e análise de tráfego, foi possível a detecção das requisições da botnet adotada neste trabalho e assim identificar o formato dos comandos enviados pelo C&C se baseando em análise de tráfego anômalo. Tal solução foi obtida por não ser adotados medidas para ocultar o comando como o uso de polimorfismos ou encriptação das mensagens.

Conclusão

Foi possível desenvolver uma prova de conceito de uma botnet cujo C&C seja por meio dos protocolos IPFS e IPNS. Com isso, pode ser observado um maior grau de anonimato e segurança ao botmaster. Para combater botnets que usem esses protocolos, foi apresentada uma solução usando análise no tráfego da rede.

Ainda é possível explorar mais o uso dos protocolos IPFS e IPNS para o C&C de botnet, como não usar o gateway público, mas sim executar ele em um dos bot da botnet, ou executar o daemon nos próprios bot, assim possibilitando que eles compartilhem dados pelo IPFS. Dessa forma, é importante mais estudos e análises, para assim compreender melhor os riscos e saber como detectar uma botnet com outras abordagens no uso dos protocolos IPFS e IPNS.

Tal como apresentado, o tempo de propagação do comando é o tempo do próximo long polling a ser executado somado ao tempo de resolução do IPNS. Um trabalho futuro seria comparar o tempo de programação dos comandos com outras topologias e estratégias de C&C. Isso é útil para a identificação de possíveis assinaturas na análise de tráfego dessa metodologia de botnet.

Referencias

[1] A. Upadhyaya, D. Jayaswal, and S. Yadav, “Botnet: A new network terminology,” in 2011 International Conference on Emerging Trends in Networks and Computer Communications (ETNCC), 2011 [Online]. Available: http://dx.doi.org/10.1109/etncc.2011.6255936
[2] P. Wang, L. Wu, B. Aslam, and C. C. Zou, “A Systematic Study on Peer-to-Peer Botnets,” in 2009 Proceedings of 18th International Conference on Computer Communications and Networks, 2009 [Online]. Available: http://dx.doi.org/10.1109/icccn.2009.5235360
[3] C. J. Dietrich, C. Rossow, F. C. Freiling, H. Bos, M. van Steen, and N. Pohlmann, “On Botnets That Use DNS for Command and Control,” in 2011 Seventh European Conference on Computer Network Defense, 2011 [Online]. Available: http://dx.doi.org/10.1109/ec2nd.2011.16
[4] M. Bailey, E. Cooke, F. Jahanian, Y. Xu, and M. Karir, “A Survey of Botnet Technology and Defenses,” in 2009 Cybersecurity Applications & Technology Conference for Homeland Security, 2009 [Online]. Available: http://dx.doi.org/10.1109/catch.2009.40
[5] H. R. Zeidanloo and A. A. Manaf, “Botnet Command and Control Mechanisms,” in 2009 Second International Conference on Computer and Electrical Engineering, 2009 [Online]. Available: http://dx.doi.org/10.1109/iccee.2009.151
[6] J. Benet, “IPFS - Content Addressed, Versioned, P2P File System.” 2015 [Online]. Available: https://github.com/ipfs/papers/blob/master/ipfs-cap2pfs/ipfs-p2p-file-system.pdf. [Accessed: 06-Aug-2017]
[7] M. Zumwalt, J. Johnson, J. Benet, L. Gierth, and L. Fisher, The Decentralized Web Primer. 2017.
[8] orbitdb, “orbitdb/orbit,” GitHub, 2017. [Online]. Available: https://github.com/orbitdb/orbit. [Accessed: 10-Sep-2017]
[9] J. Johnson, “whyrusleeping/gx,” GitHub, 2017. [Online]. Available: https://github.com/whyrusleeping/gx. [Accessed: 10-Sep-2017]
[10] ipfs, “namesys/pubsub: pubsub Publisher and Resolver by vyzo · Pull Request #4047 · ipfs/go-ipfs,” GitHub, 07-Jul-2017. [Online]. Available: https://github.com/ipfs/go-ipfs/pull/4047. [Accessed: 04-Sep-2017]
[11] ipfs, “Questions after first learning about IPFS. · Issue #154 · ipfs/faq,” GitHub, 2016. [Online]. Available: https://github.com/ipfs/faq/issues/154. [Accessed: 05-Sep-2017]
[12] J. Reed, “Privacy and anonymity in IPFS/IPNS,” discuss.ipfs.io, 09-Sep-2017. [Online]. Available: https://discuss.ipfs.io/t/privacy-and-anonymity-in-ipfs-ipns/1068/4. [Accessed: 10-Sep-2017]
[13] Feily, M., Shahrestani, A., and Ramadass, S. (2009). A survey of botnet and botnet detection. In Emerging Security Information, Systems and Technologies, 2009. SECURWARE ’09. Third International Conference on, pages 268 –273.