Log4J-Mitigação-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

Por favor, fique de olho nesta página pois a equipe do Apache Log4j está divulgando muitos mais CVEs e corrigindo problemas de segurança muito rapidamente.

Atualização - 28-Dez-2021

CVE-2021-44832: Apache Log4j2 vulnerável a RCE via JDBC Appender quando o atacante controla a configuração.

Corrigido no Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) e 2.3.2 (Java 6)

Atualização - 17-Dez-2021

Durante a noite, foi divulgado pela Apache que a versão 2.16 do Log4j também é vulnerável a um ataque de Negação de Serviço com o impacto sendo uma falha completa da aplicação, a gravidade disso é classificada como Alta (7.5). O CVE-2021-45105 foi emitido, e uma nova versão corrigida (2.17) foi publicada pela Apache, recomendando a atualização.

Histórico:

As discussões na internet estavam agitadas sobre uma vulnerabilidade de dia zero (que pode resultar em execução remota de código) na popular biblioteca de logging Log4J da Apache para Java. Esta vulnerabilidade específica – rastreada como CVE-2021-44228 com a pontuação máxima “crítica” de CVSS de 10 – reside na capacidade de lookup do Log4J, combinada com o JNDI (Interface de Nomes e Diretórios Java). Este problema é generalizado porque muitos desenvolvedores não sabiam que o Log4J era perigoso de usar com entrada não filtrada. O impacto mais significativo é que um atacante pode fazer com que uma string chegue ao logger, que quando processada pelo Log4J, executa código arbitrário. Os primeiros exemplos disso usaram o caminho ${jndi:ldap}, o que poderia levar ao carregamento de código arbitrário de uma URL remota. Este caminho é parcialmente mitigado pelo uso de runtimes Java mais recentes que bloqueiam o carregador de classes baseado em URL por padrão. Infelizmente, uma versão moderna do Java pode não ser suficiente para evitar a exploração, pois a própria aplicação pode expor classes que podem ser usadas para executar código arbitrário.

A arquitetura JNDI:

jndiarch

Mitigações para diferentes ambientes:

Atualização - 17-Dez-2021

Vulnerabilidade de Segurança CVE-2021-45105

Detalhes:

As versões do Apache Log4j2 de 2.0-alpha1 até 2.16.0 não protegiam contra recursão descontrolada de lookups autorreferentes. Quando a configuração de logging usa um Pattern Layout não padrão com um Context Lookup (por exemplo, $${ctx:loginId}), atacantes com controle sobre os dados de entrada do Thread Context Map (MDC) podem criar dados de entrada maliciosos que contêm um lookup recursivo, resultando em um StackOverflowError que encerrará o processo. Isso também é conhecido como um ataque DOS (Negação de Serviço).

Mitigação:

A partir da versão 2.17.0 (para Java 8), apenas strings de lookup na configuração são expandidas recursivamente; em qualquer outro uso, apenas o lookup de nível superior é resolvido, e quaisquer lookups aninhados não são resolvidos. Em versões anteriores, este problema pode ser mitigado garantindo que sua configuração de logging faça o seguinte:

No PatternLayout da configuração de logging, substitua Context Lookups como ${ctx:loginId} ou $${ctx:loginId} por padrões de Thread Context Map (%X, %mdc ou %MDC). Caso contrário, na configuração, remova referências a Context Lookups como ${ctx:loginId} ou $${ctx:loginId} onde elas se originam de fontes externas à aplicação, como cabeçalhos HTTP ou entrada do usuário.

Atualização - 13-Dez-2021

** Log4j (Versão 2.16.0 – 2021-12-13) tem duas funcionalidades melhoradas:**

---------------!!Altamente recomendado atualizar para a versão mais recente disponível, pois os message lookups estão desabilitados por padrão.!!------------

https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

Desabilitar JNDI por padrão. Exige que log4j2.enableJndi seja definido como true para permitir JNDI.

Remover completamente o suporte para Message Lookups

Nova Atualização:

------------------CVE-2021-45046-----------------

Apache Log4j2 Thread Context Message Pattern e Context Lookup Pattern vulneráveis a um ataque de negação de serviço.

Mitigação:

Mitigação para Log4j 1.x: Log4j 1.x não é afetado por esta vulnerabilidade.

Mitigação para Log4j 2.x: Implemente uma das técnicas de mitigação abaixo.

Usuários de Java 8 (ou superior) devem atualizar para a versão 2.16.0. Usuários que necessitam de Java 7 devem atualizar para a versão 2.12.2 quando ela estiver disponível (trabalho em andamento, previsto para estar disponível em breve).

Caso contrário, remova a classe JndiLookup do classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Observe que apenas o arquivo JAR log4j-core é afetado por esta vulnerabilidade. Aplicações que usam apenas o arquivo JAR log4j-api sem o arquivo JAR log4j-core não são afetadas por esta vulnerabilidade.

------------------CVE-2021-44228-------------------

Mitigação

Mitigação para Log4j 1.x: Log4j 1.x não possui Lookups, então o risco é menor. Aplicações que usam Log4j 1.x são vulneráveis a este ataque apenas quando usam JNDI em sua configuração. Um CVE separado (CVE-2021-4104) foi registrado para esta vulnerabilidade. Para mitigar: audite sua configuração de logging para garantir que não tenha nenhum JMSAppender configurado.

Configurações do Log4j 1.x sem JMSAppender não são afetadas por esta vulnerabilidade.

Mitigação para Log4j 2.x: Implemente uma das técnicas de mitigação abaixo.

Usuários de Java 8 (ou superior) devem atualizar para a versão 2.16.0.

Usuários que necessitam de Java 7 devem atualizar para a versão 2.12.2 quando ela estiver disponível (trabalho em andamento, previsto para estar disponível em breve).

Caso contrário, remova a classe JndiLookup do classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

 1. Apache Log4j:
        Nas versões >=2.10** e
        Para versões >=2.0-beta9 e <=2.10.0

2. Correção do pom.xml:

3. Azure App Service (Windows e Linux):

4. Aplicações containerizadas:

5. Azure Functions:

6. Hotpatch para Apache Log4j

7. Como o Defender for Cloud encontra máquinas afetadas por vulnerabilidades do Log4j

8. Detecção em logs do Azure Sentinel e Azure WAF

9. Configuração do plug-in Maven para banir versões vulneráveis do log4j2 em builds futuros

1. Apache Log4j:

CVE-2021-44228: As funcionalidades JNDI do Apache Log4j2 não protegem contra LDAP controlado pelo atacante e outros endpoints relacionados ao JNDI.

Versões afetadas: todas as versões do log4j-core >=2.0-beta9 e <=2.14.1 Apache Log4j <=2.14.1: as funcionalidades JNDI usadas na configuração, mensagens de log e parâmetros não protegem contra LDAP controlado pelo atacante e outros endpoints relacionados ao JNDI. Um atacante que pode controlar mensagens de log ou parâmetros de mensagens de log pode executar código arbitrário carregado de servidores LDAP quando a substituição de message lookup está habilitada. A partir do log4j 2.15.0, este comportamento foi desabilitado por padrão.

Nas versões >=2.10**, este comportamento pode ser mitigado definindo a propriedade de sistema log4j2.formatMsgNoLookups ou a variável de ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS como true. Para versões >=2.7 e <=2.14.1, todos os padrões PatternLayout podem ser modificados para especificar o conversor de mensagens como %m{nolookups} em vez de apenas %m.

Para versões >=2.0-beta9 e <=2.10.0, a mitigação é remover a classe JndiLookup do classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.

2. Correção do pom.xml:

Atualize a dependência no pom.xml e troque pela versão mais recente disponível na seção de dependências: https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom

<dependencies>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->            
<!--         <version>2.17.0</version>-->
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->       
<!--         <version>2.17.0</version>-->
        </dependency>
    </dependencies>

Referência: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18

3. Azure App Service (Windows e Linux):

Se possível, os clientes devem atualizar o Log4j para a versão v2.15.0 e reimplantar as aplicações. Esta é a mitigação primária recomendada. Se não for possível reimplantar sua aplicação, então, nas versões do Log4j 2.10 e superiores, você pode mitigar este comportamento definindo a propriedade de sistema “-Dlog4j2.formatMsgNoLookups=true”. No App Service, você pode definir esta propriedade criando uma configuração de aplicativo chamada JAVA_OPTS com o valor “-Dlog4j2.formatMsgNoLookups=true”. A configuração de aplicativo JAVA_OPTS é passada para sua aplicação Java quando ela inicia. Se você já tiver a configuração de aplicativo JAVA_OPTS definida, apenas acrescente “-Dlog4j2.formatMsgNoLookups=true” ao valor existente. Se você estiver usando a versão Log4J 2.9 ou inferior, essa mitigação de propriedade de sistema não funcionará e você deve atualizar para v2.15.0.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"

4. Aplicações containerizadas

Para aplicações containerizadas, se a versão do Log4j 2 que você está usando for 2.10.0 ou superior, existe uma variável de ambiente ou opção de linha de comando Java que você pode usar para desabilitar o comportamento de substituição inseguro. Você pode adicionar a linha:
```
 ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
```
Referência do arquivo Docker: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
Para seu Dockerfile, ou você pode adicionar a flag equivalente "-Dlog4j.formatMsgNoLookups=true" ao comando que você executa em seu contêiner, por exemplo:
```
 CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
```
Você também pode configurar a variável de ambiente em tempo de execução, o que pode ser mais fácil, por exemplo, para Kubernetes você pode adicionar estas linhas em sua configuração.
```
 spec:
   containers:
   - name: ...
     image: ...
     env:
     - name: LOG4J_FORMAT_MSG_NO_LOOKUPS
       value: "true"
```

5. Azure Functions:

Configurar a propriedade de sistema dependerá de sua escolha de opção de hospedagem: dedicado, premium ou consumo. Como lembrete, a mitigação primária recomendada é atualizar o Log4J para 2.15.0 e reimplantar sua aplicação. Se você não puder fazer isso por qualquer motivo, então você pode aplicar a propriedade de sistema.

- Funções Dedicadas e Premium:

Crie uma configuração de aplicativo chamada JAVA_OPTS com o valor “-Dlog4j2.formatMsgNoLookups=true”. Se você já tiver a configuração de aplicativo JAVA_OPTS definida, apenas acrescente “-Dlog4j2.formatMsgNoLookups=true” ao valor existente.

- Funções de Consumo:

Linux: Crie uma configuração de aplicativo chamada “languageWorkers__java__arguments” com o valor “-Dlog4j2.formatMsgNoLookups=true”. Windows: Crie uma configuração de aplicativo chamada “languageWorkers:java:arguments” com o valor “-Dlog4j2.formatMsgNoLookups=true”. **Observe que atualizar a configuração do aplicativo reiniciará seus aplicativos Web e Function, o que pode afetar o desempenho de cold start. Se você estiver usando a versão Log4J 2.9 ou inferior, essa mitigação de propriedade de sistema não funcionará e você deve atualizar para v2.15.0.

6. Hotpatch para Apache Log4j

Como funciona? Esta ferramenta injeta um agente Java em um processo JVM em execução. O agente tenta corrigir o método lookup() de todas as instâncias carregadas de org.apache.logging.log4j.core.lookup.JndiLookup para retornar incondicionalmente a string “Patched JndiLookup::lookup()”. Isso foi projetado para lidar com a vulnerabilidade de execução remota de código CVE-2021-44228 no Log4j sem reiniciar o processo Java.

Se você tiver a possibilidade de reimplantar seus processos Java, você também pode usá-lo como um agente estático, o que significa que você pode incluir este patch em seu tempo de execução sem fazer login diretamente em seus servidores.

Github : https://github.com/corretto/hotpatch-for-apache-log4j2

7. Como o Defender for Cloud encontra máquinas afetadas por vulnerabilidades do Log4j

Usando o inventário, você tem duas maneiras poderosas de determinar sua exposição:

Inventário de software

Descobertas de avaliação de vulnerabilidade

https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/how-defender-for-cloud-finds-machines-affected-by-log4j/ba-p/3037271

8. Detecção em logs do Azure Sentinel e Azure WAF:

Azure WAF Log4j CVE-2021-44228 hunting

https://github.com/Azure/Azure-Sentinel/blob/master/Hunting%20Queries/AzureDiagnostics/WAF_log4j_vulnerability.yaml

Azure WAF matching for Log4j vuln(CVE-2021-44228)

https://github.com/Azure/Azure-Sentinel/blob/master/Detections/AzureDiagnostics/AzureWAFmatching_log4j_vuln.yaml

9. Configuração do plug-in Maven para banir versões vulneráveis do log4j2 em builds futuros:

Configuração do plug-in Maven para colocar em seu POM pai para evitar quaisquer usos de versões desatualizadas do log4j2, algumas das quais estão sujeitas ao RCE CVE-2021-44228 ("Log4Shell"), CVE-2021-45046 e CVE-2021-45105.

Referência: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d

 <!-- plug-in configuration to put into your parent POM for avoiding any usages of
     outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
     ("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
     latest version of log4j2 at
     https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.0.0</version>
  <executions>
    <execution>
      <id>ban-bad-log4j-versions</id>
      <phase>validate</phase>
      <goals>
        <goal>enforce</goal>
      </goals>
      <configuration>
        <rules>
          <bannedDependencies>
            <excludes>
              <exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
            </excludes>
          </bannedDependencies>
        </rules>
        <fail>true</fail>
      </configuration>
    </execution>
  </executions>
</plugin>
...

Contribuindo:

Feliz em receber contribuições da comunidade. Diretrizes de contribuição:

-->Por favor, faça um PR.

-->Por favor, inclua uma fonte de referência para mais contexto

Pode haver vários ambientes diferentes e outras formas de corrigir, sinta-se à vontade para abrir um pull request:

Referências:

https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

https://github.com/justincormack/log4jpoc

https://www.rumble.run/blog/finding-log4j/

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay