Por Rodrigo Montoro e Ricardo Silva
O uso de serviços expostos na Internet é algo que atrai criminosos com múltiplos interesses. No entanto, temos observado uma predileção na busca por serviços projetados para lidar com grande volume de dados com o intuito de convertê-los em mineradores de criptomoedas, isso porque geralmente estes recursos são configurados para processar múltiplas e volumosas requisições. Em análises recentes, pudemos observar máquinas nestas condições, nas quais o produto Jupyter Notebook foi abusado com este objetivo.
Quem atua, ou tem colegas na área de data science, já deve ter ouvido sobre o Jupyter Notebook, uma aplicação web interativa que permite a criação e o compartilhamento de documentos com código dinâmico. O produto é amplamente usado nas áreas de mineração de dados, facilitando suas atividades de visualização, limpeza e exploração de dados, além de permitir a mesclagem de trechos de código e texto, otimizando a criação de apresentações e relatórios, permitindo a construção de tudo em um só local, como se fosse uma IDE (Integrated Development Environment) para o cientista de dados. A figura a seguir exibe uma arquitetura básica da ferramenta.
No início das análises, observamos que as máquinas estudadas possuíam um Docker sendo executado. Como esse produto tem sido comumente usado como vetor de ataque, imaginamos que ali estaria a fonte do comprometimento.
Entretanto, a única porta liberada no firewall dos ambientes avaliados era a 8888, que por sua vez levava a um servidor do Jupyter cujo processo de autenticação estava configurado de modo a não exigir token/senha.
Constatamos que havia pouca documentação sobre este tipo de comportamento, limitando-se principalmente a usuários do GitHub trocando informações sobre o caso. Desta forma, aprofundando o estudo das condições do ambiente, chegamos ao seguinte cenário:
1-) O endereço IP e a porta do servidor estavam indexados no Shodan.io
2-) Ferramentas que utilizam a API do Shodan podem detectar e se conectar ao servidor Jupyter de modo a validar o acesso via websocket
3-) Com o acesso validado, os atacantes estabelecem a conexão websocket e enviam o minerador o qual possui comandos bastante semelhantes aos de um PoC publicado pelo usuário do GitHub harshu4 em setembro de 2019, porém com algumas modificações nas versões e comandos.
4-) Após a execução dos comandos, o minerador XMRig é ativado.
Em buscas no Shodan pelo Tornado Server, Web Server que compõe a aplicação Jupyter Notebook, pudemos observar aproximadamente 15 mil servidores disponíveis. Muitos deles exigindo token em seu processo de autenticação, porém expostos.
Algumas lições aprendidas e sugestões
Manter estreito contato com o seu provedor de nuvem pode ser determinante na detecção de ataques como este, pois a empresa pode identificar flutuações incomuns no uso dos recursos e emitir alertas em um tempo bastante curto.
Também é importante checar periodicamente se ativos de seu ambiente estão sendo indexados por serviços como Censys e o Shodan. Esta é uma medida relevante para avaliar se tudo que está exposto à Internet realmente deveria estar nesta condição.
Também é importante monitorar o tráfego de rede de modo a identificar qualquer comunicação suspeita e periodicamente revisar permissões tanto no ambiente on premises quanto em nuvem de modo que eventos críticos como os de ativação de instâncias ou modificação permissões de firewall devem ser revisados com rigor.
MITRE ATT&CK Techniques
T1596.005 – Search Open Technical Databases: Scan Databases
T1190 – Exploit Public-Facing Application
T1059.004 – Command and Scripting Interpreter: Unix Shell
T1496 – Resource Hijacking
IOCs
Arquivos (sha256)
5db5646a8d3f5e980b28ccc69fa2b9a19d807698ca3fa6a33d8286783ac1b2df *config.json
88478b53af34395b7df22705f93161913294b3e17d00db1999a118bf28c1989a *xmrig
dd4285ba01e9a623c09c789ed483b1a131ccf88e0cf67aeb51476f01a97c5da9 mainscript.sh
Domínios
test586.000webhostapp[.]com
gulf.moneroocean[.]stream
