Meu sistema está vulnerável à vulnerabilidade do Log4Shell?

Se você não executa nenhum software que esteja usando Java, tudo bem (pelo menos para este exploit).

No entanto, tenha em mente que há muitas coisas que usam Java sob o capô enquanto têm um aplicativo compilado nativo para iniciar as coisas e ter uma JVM incorporada. Esses são potencialmente afetados. Exemplos disso são, por exemplo, Jetbrains CLion e PyCharm, ambos são aplicativos Java.

É claro que os únicos aplicativos que são vulneráveis ​​a ataques reais são aqueles que podem ser acessados ​​pela Internet (ou por um intruso ativo em sua rede, caso em que você tem um problema muito maior.

Os produtos Jetbrains mencionados acima não estão entre esses, eles são apenas exemplos de coisas que executam Java debaixo d'água quando o usuário final pode nem estar ciente disso. Eles também não contam com o Log4J2, eles usam outra solução de log internamente.

Você estava executando, digamos, Jira ou Confluence, ou outros produtos como esse, você pode estar vulnerável e deve verificar com seus fornecedores.

Acontece que isso não é tão fácil de determinar. Existem muitos sistemas e aplicativos que incluem o serviço Log4j2. A lista atual de sistemas conhecidos como afetados, não afetados ou atualmente sob investigação está em https://github.com/cisagov/log4j-affected-db#software-list

ATUALIZAÇÃO: 2021-12-18...

Lembre-se de sempre verificar as informações mais recentes dos recursos listados abaixo

CVE-2021-45105 ... 2.16.0 e 2.12.2 não são mais correções válidas! As versões de correção atuais são 2.17.0 (Java 8) e 2.12.3 (Java 7). Todas as outras versões do Java precisam adotar a abordagem de interrupção (remover/excluir o arquivo JndiLookup.class do JAR log4j-core.
Atualizei minha mensagem abaixo de acordo.

Respondendo à pergunta diretamente:
Vá para o tópico do Reddit: log4j_0day_being_exploited e cntl+ fpara Vendor Advisoriese pesquise essas listas para ver se você usa algum desses softwares. Se você fizer isso e uma atualização estiver disponível, atualize-a.

Em seguida, vá para o mesmo site e cntl+ fpara .class and .jar recursive hunters Executar o programa do repositório listado lá. Se encontrar algo, corrija-o.

• Mais recursos
  • https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/
    • Este tem TONELADAS de informações úteis, incluindo detectores, ainda mais links de recursos, etapas de correção muito fáceis de entender e muito mais
  • https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
  • https://github.com/cisagov/log4j-affected-db
  • https://logging.apache.org/log4j/2.x/security.html

Correção:
CVE-2021-45046 ... CVE-2021-44228 ... CVE-2021-45105
Enquanto a maioria das pessoas que precisam saber provavelmente já sabem o suficiente para fazer o que precisam fazer, pensei em colocar isso apenas em caso...

• Siga as orientações nesses recursos... isso pode mudar, mas

A partir de 18/12/2021

É basicamente

• Remova os arquivos JAR log4j-core, se possível
  • De ambas as máquinas em execução para correção imediata E
  • em seu código-fonte/arquivos de gerenciamento de código-fonte para evitar que futuras compilações/lançamentos/implantações substituam a alteração
• Se isso não for possível (devido a uma dependência), atualize-os
  • Se você estiver executando o Java8, poderá atualizar para o log4j 2.17.0+
  • Se você estiver executando uma versão anterior do Java, poderá atualizar para o log4j 2.12.3
  • Se você estiver executando uma versão mais antiga do Java, precisará atualizar para a versão mais recente do Java e usar a versão mais recente do Log4J
  • Novamente, essas mudanças precisam acontecer tanto na máquina em execução quanto no código
• Se nenhum dos dois for possível por algum motivo... então existe a lacuna de parada NÃO-remediação de remover o arquivo JndiLookup.class dos JARs log4j-core.
  • Há uma linha para a opção de interrupção no Linux usando o zipcomando que vem empacotado com a maioria das distribuições do Linux por padrão.
    • zip -q -d "$LOG4J_JAR_PATH" org/apache/logging/log4j/core/lookup/JndiLookup.class
  • No momento da redação deste artigo, a maioria dos guias online para a opção stop gap no Windows diz para fazer o seguinte (novamente... supondo que você não possa fazer uma das opções de remoção de JAR ou atualização acima):
    • Instale algo como 7-zip
    • Localize todos os seus arquivos JAR log4j-core e para cada um faça o seguinte...
    • Renomeie o JAR para alterar a extensão para.zip
    • Use 7-zip para descompactar o JAR (que agora tem uma .zipextensão)
    • Localize e remova o arquivo JndiLookup.class da pasta descompactada
      • O caminho é\\path\\to\\unzippedFolder\\org\\apache\\logging\\log4j\\core\\lookup\\JndiLookup.class
    • Exclua o arquivo JAR antigo (que agora tem uma extensão .zip)
    • Use 7-zip para RE-zipar a pasta
    • Renomeie a nova pasta .zip para alterar a extensão para.jar
  • Existem também algumas opções para usar o Power Shell
    • Tópico do Reddit: log4j_0day_being_exploited
    • ctrl+ fpara "PowerShell"

Isso é bom se você tiver apenas 1 ou 2 arquivos JAR para lidar e não se importar em instalar o 7-zip ou tiver o PowerShell disponível para fazer isso. No entanto, se você tiver muitos arquivos JAR ou se não quiser instalar o 7-zip e não tiver acesso ao Power Shell, criei um script VBS de código aberto que fará isso por você sem precisar instalar qualquer software adicional. https://github.com/CrazyKidJack/Windowslog4jClassRemover

Leia o README e as notas de lançamento https://github.com/CrazyKidJack/Windowslog4jClassRemover/releases/latest

Boa explicação do exploit da Computerphile. https://www.youtube.com/watch?v=Opqgwn8TdlM