Detecção de exploração do Log4J (CVE-2021-44228)

Se você está lendo este artigo, presumo que já tenha ouvido falar sobre a CVE-2021-44228, a vulnerabilidade de Execução Remota de Código (RCE) que afeta o Apache Log4j, a biblioteca de registro Java que grande parte da Internet usa em seus servidores Web. Embora muitos blogs e comentários tenham publicado métodos para determinar se seus servidores Web/sites estão vulneráveis, há poucas informações sobre como detectar facilmente se o seu servidor Web foi de fato explorado e infectado. Mas, primeiro, uma breve sinopse:

CVE-2021-44228 RCE do Apache Log4J

• Primeiro, como a maioria dos especialistas em segurança e no Twitter está dizendo: essa vulnerabilidade é ruim. Muito ruim. Muitos sites importantes executam esse registrador.

• RCE = Execução Remota de Código. O invasor pode executar qualquer código (por exemplo, malware) que desejar em seu servidor da Web enviando uma solicitação da Web ao seu site com nada mais do que uma string "mágica" + um link para o código que deseja executar.

• Afeta o servidor da Web Apache que usa versões vulneráveis do logger log4j (o módulo de registro java mais popular para sites que executam java).

• Versões vulneráveis: 2.0 - 2.14.1 (Recomenda-se atualizar para a versão 2.17.0)

Alguém tentou explorar meu servidor da Web?

O comportamento típico a ser esperado se o seu servidor for explorado por um invasor é a instalação de um novo webshell (malware de site que dá acesso de administrador ao servidor por meio de uma interface de administrador oculta). O Apache executaria comandos curl ou wget para baixar o webshell ou outro malware que eles quisessem instalar.

Felizmente, há algumas maneiras de detectar tentativas de exploração enquanto se monitora o servidor para descobrir tentativas de exploração anteriores:

1. Analise os logs do Apache para jndi:ldap, jndi:rmi ou jndi:dnsEssas são as sequências mágicas que fazem o logger enlouquecer e seguir/executar a URL que as segue.
2. Digitalizar /var/log com assinaturas Yara que correspondem a alguns desses indicadores.
3. Examine o servidor da Web em busca de webshells genéricos.
4. Se você tiver EDR no servidor Web, monitore se há comandos suspeitos curl, wget ou relacionados. Provavelmente, o código que eles tentam executar primeiro após a exploração faz com que o sistema entre em contato com o servidor de comando e controle usando utilitários incorporados como esse.

OBSERVAÇÃO: se o servidor for explorado por scanners automatizados (os bons estão executando esses scanners), é possível que você obtenha um indicador de exploração sem malware ou webshells subsequentes. Alguns scanners de pesquisa exploram a vulnerabilidade e fazem com que o sistema envie uma única solicitação de ping ou dns para informar ao pesquisador quem estava vulnerável.

Parceiros da Datto: Componente RMM

A Datto lançou ambos os modelos. Datto RMM Um componente para seus parceiros e um script comunitário para todos os MSPs que os ajudará a usar o poder e o alcance do seu RMM, independentemente do fornecedor, para enumerar sistemas potencialmente vulneráveis ​​e que já sofreram ataques. A ferramenta também pode tentar proteger contra ataques subsequentes aplicando uma solução alternativa conhecida.

Não hesite em entrar em contato com a nossa equipe de especialistas para obter ajuda.

ATUALIZAÇÃO 22/12:

Na última semana, vimos muitas atividades de varredura de scanners de segurança, atividades de exploração em larga escala do espaço IP russo e ucraniano e muitas explorações de sistemas que variam de servidores Elastic a serviços da Web personalizados.

Atualizamos nosso scanner log4shells para incluir uma melhor cobertura dos métodos de ofuscação e também depreciamos as opções de atenuação, agora extintas, que o apache recomendava anteriormente. A variável de ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS ou o argumento cli log4j2.formatMsgNoLookups=True não impedirá muitos vetores de ataque.

Além disso, expandimos o scanner para examinar todas as unidades (não apenas as unidades do sistema ou onde o log4j está instalado) e recomendamos executá-lo novamente caso não o tenha feito recentemente.

1. Encontra quaisquer arquivos .jar com a classe JndiLookup.class problemática.
2. Analisa o sistema em busca de arquivos .log compactados e não compactados com indicadores de exploração relacionados à vulnerabilidade log4shells.
— O caminho principal no Linux e no MacOS é: /var/log
— Os caminhos principais no Windows incluem $env:SystemDrive\logs\, $env:SystemDrive\inetpub\, bem como quaisquer pastas que incluam o termo java, log4j ou apache.
3. Também utiliza assinaturas Yara de código aberto nos arquivos de log.

Devido ao número de implementações do log4j incorporadas em vários produtos, nem sempre é trivial encontrar a versão da extensão log4j. A maneira mais fácil é examinar o nome do arquivo ou da pasta do arquivo .jar encontrado com o JndiLookup.class, mas isso nem sempre está presente. Alguns produtos exigem instruções específicas do fornecedor.

ATUALIZAÇÃO 14/12:

Os ataques continuam a ser lançados contra servidores Apache vulneráveis, mas desta vez com mais e mais ofuscação. Os invasores parecem estar analisando as recomendações de informações publicadas e testando seus ataques contra elas. Atualizamos significativamente nossa extensão de detecção de exploits log4shells/log4j para nos anteciparmos.

A correspondência de regex em registros pode ser difícil de acertar quando os atores ofuscam, mas ainda é um dos métodos mais eficientes baseados em host para encontrar atividades de exploração como essa. A imagem acima mostra várias ofuscações que já vimos e nossa lógica de correspondência abrange todas elas. Nossa abordagem com regras como essa é ter uma regra altamente ajustada e específica com baixos falsos positivos e outra regra mais genérica que se esforça para minimizar os falsos negativos à custa de falsos positivos. Nossos caçadores geralmente lidam com a triagem dos resultados genéricos em nome de nossos clientes.

Além disso, o monitoramento comportamental genérico continua a ser um recurso principal que não requer atualizações. Se o apache começar a executar novos comandos curl ou wget (atividade padrão do segundo estágio), ele será analisado.

Continuaremos monitorando à medida que a situação evolui e recomendamos adicionar a extensão log4j às suas varreduras programadas.

ATUALIZAÇÃO 12/12:

Trabalhamos com alguns de nossos parceiros na noite passada e atualizamos nossa extensão para servidores apache baseados em Windows também:

Um problema com a análise de logs em servidores Apache no Windows é que a pasta de logs não é padrão. Portanto, nossa extensão irá procurar em <em>[DriveLetter]</em>:\logs\ (também conhecido como C:\logs\) primeiro, pois é uma pasta comum, mas se o Apache/httpd estiverem em execução e ela não estiver lá, ele pesquisará no restante do disco.

Também é feita a verificação da existência de arquivos .jar que importam o código vulnerável. Sugestões de parceiros da área que buscam informações sobre uma variável de ambiente chamada log4j2.formatMsgNoLookups Isso também pode ajudar, mas entenda que existem muitas implementações em que esse valor pode estar codificado diretamente no código e não em uma variável de ambiente.

IMPORTANTE: Muitas das atividades que observamos provêm de scanners automatizados (sejam eles de pesquisadores ou não) que não investigam a distribuição ou os impactos do webshell/malware. A facilidade de exploração dessa vulnerabilidade pode tornar esse processo muito ruidoso, por isso recomendamos que todos que buscam explorá-la procurem outros indicadores de comprometimento antes de declarar um incidente com base em uma correspondência positiva nos registros. Entre em contato conosco se tiver dificuldades nesta etapa.

Ainda não é parceiro da Datto? Entre em contato para solicitar uma demonstração hoje mesmo.