Como verifico se o Log4j está instalado no meu servidor?

Tente este script para obter uma dica:

echo "checking for log4j vulnerability..."
OUTPUT="$(locate log4j|grep -v log4js)"
if [ "$OUTPUT" ]; then
  echo "[WARNING] maybe vulnerable, those files contain the name:"
  echo "$OUTPUT"
fi
OUTPUT="$(dpkg -l|grep log4j|grep -v log4js)"
if [ "$OUTPUT" ]; then
  echo "[WARNING] maybe vulnerable, dpkg installed packages:"
  echo "$OUTPUT"
fi
if [ "$(command -v java)" ]; then
  echo "java is installed, so note that Java applications often bundle their libraries inside jar/war/ear files, so there still could be log4j in such applications."
fi
echo "If you see no output above this line, you are safe. Otherwise check the listed files and packages."

Certifique-se de que seu banco de dados de localização esteja atualizado com o updatedb.

Ou melhor verificar e executar o script aprimorado do GitHub , que também pesquisa dentro de arquivos Java compactados . Corra em uma linha com

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | bash   

Não tenho certeza se pode haver programas Java compilados em execução no servidor sem que o java esteja instalado?

Ou até mesmo versões compiladas onde os arquivos de origem não são mais encontrados dentro de arquivos compactados?

Também há muito desenvolvimento no GitHub , onde você encontra ataques e contramedidas.

Isso leva muito tempo para mim. Estou procurando alguém que possa transferir a propriedade do repositório no GitHub

Não há comando que certamente lhe dirá isso. Alguns aplicativos enviam as bibliotecas que usam diretamente como um arquivo jar, alguns os contêm em um arquivo.

E mesmo assim você não sabe qual versão é enviada e como é usada. A única maneira de ter certeza de mitigar o CVE é ler os anúncios de segurança e as notas de lançamento de seus aplicativos e seguir seus avisos.

Tente este Comandos:

• dpkg -l | grep liblog4j

• dpkg -l | grep log4

• find / -name log4j-core-*.jar

• locate log4j | grep -v log4js

Eu escrevi este script Python para encontrar versões vulneráveis ​​do Log4j2 em seu sistema: https://github.com/fox-it/log4j-finder

Ele funciona varrendo o disco e dentro dos arquivos Java Archive recursivamente e procurando por arquivos ruins conhecidos.

log4jscanner

Publicado pelo Google sob a licença Apache-2.0, o log4jscanner é um scanner de sistema de arquivos de vulnerabilidade log4j e um pacote Go para analisar arquivos JAR.

Pedindo desculpas pela referência de material externo, espero que isso seja tolerável nas circunstâncias atuais.

As informações que o Lunasec.io divulgou sobre hashes de arquivos .class binários Java vulneráveis:

https://github.com/lunasec-io/lunasec/blob/master/tools/log4shell/constants/vulnerablehashes.go

Veja também o blog deles: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/

Se você tiver ordenado hashes (um por linha) de classes suspeitas em um arquivo hashese tiver um arquivo jar subject.jare tiver os comandos unzip, finde sha256sum, poderá fazer uma comparação com os hashes conhecidos com:

JARFILE=subject.jar; DIROUT=$(mktemp -d); unzip -qq -DD "$JARFILE" '*.class' -d "$DIROUT" && find "$DIROUT" -type f -not -name "*"$'\n'"*" -name '*.class' -exec sha256sum "{}" \; | cut -d" " -f1 | sort | uniq > "$JARFILE"-hashes; rm -rf -- "$DIROUT"

comm -12 hashes subject.jar-hashes

Se commtiver saída, haverá um hash correspondente.

Experimente o syft . Ele cria uma lista de materiais de software (SBOM), que você pode procurar por versões antigas do log4j (até funciona com imagens do docker).

Algo como syft dir:/opt/foo-application | grep log4jpesquisas em implantações convencionais. syft dir:/ | grep log4jdeve funcionar para todo o seu servidor.

Passar suas imagens docker também funciona:

# syft -q jacobalberty/unifi:5.13.29 | grep log4j
log4j-api                                 2.12.1                               java-archive
log4j-core                                2.12.1                               java-archive
log4j-slf4j-impl                          2.12.1                               java-archive
tomcat-embed-logging-log4j                8.5.2                                java-archive

Criar um script para passar todas as suas imagens docker para o syft não deve ser muito difícil, mas você pode encontrar alguma inspiração nesses meus scripts: https://github.com/debuglevel/syft-grype-utils

John Hammond publicou com alguns outros um serviço de redirecionamento LDAP hospedado para que você possa pular todas as travessuras. https://log4shell.huntress.com/

As instruções são simples - ele gera um ID de cliente para você (está na URL, bem como parte da string de injeção) que você pode postar em qualquer formulário/solicitação/ou derivado de solicitação da web.

Geralmente, se você estiver executando qualquer coisa que "não funcione com isso porque é acesso local", tudo bem, pois não há meios de encaminhar através de seu aplicativo baseado em Java.

De nota - acredito que a maior preocupação deve ser colocada no hardware de gerenciamento de rede L2/L3; Especialmente se você estiver lidando com um ISP ou seu conteúdo for veiculado por meio de um serviço de hospedagem.

A verificação de pacotes instalados não é suficiente, pois log4jpode ser instalado manualmente por alguns outros aplicativos.

Para servidores Linux, estou usando o seguinte:find / -iname "*log4j*.jar"

Para servidores Windows, pode-se usar algo semelhante a isso: dir C:\*log4j*.jar /s(mudando C:para D:e assim por diante para outros discos).

Os nomes dos arquivos geralmente mostrarão a versão da biblioteca, mas para verificar novamente, você pode abrir o arquivo de manifesto e ler os campos de versão/implementação.

Observe que o acima não é suficiente para capturar embutidos log4j(por exemplo: em outros arquivos jar). Para isso, é necessário grep a string relevante, mas isso consome bastante tempo e recursos, então sugiro usar a pesquisa de arquivos como um primeiro (mas incompleto) passo.

Todas as tentativas aqui para resolver as vulnerabilidades no log4j ficam aquém. Você não pode confiar no locatecomando, pois ele apenas procura em um conjunto de caminhos configurados ( /etc/updatedb.confno Debian).

O software pode se instalar em locais não configurados updatedb.confe ser completamente ignorado pelo cron job que atualiza o banco de dados de localização.

Além disso, está sendo descoberto que fornecedores de software (como Elastic ) reempacotaram o JndiLookup.class vulnerável (por exemplo: elasticsearch-sql-cli-7.16.1.jar) em locais que não eram conhecidos anteriormente, o que deixa soluções incompletas que são construídas em torno de hashes, nomes ou caminhos de arquivos conhecidos.

@shodanshok está no caminho certo aqui, mas ao invés de procurar por log4j explicitamente, uma olhada em cada '.jar' no sistema é o que é necessário.

Este é mais completo, requer o pacote zip. e uma extensão da resposta de shodanshok. Isso apenas mostrará os locais onde o JndiLookup.classcódigo é encontrado. Outra linha pode ser adicionada para remover essas vulnerabilidades, mas prefiro deixar isso a critério do administrador. O link elástico acima mostra como:

for jar in $(find / -name '*.jar'); do
   unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Found vulnerability in $jar"
done

Exemplo:

# for jar in $(find / -name '*.jar'); do
>    unzip -l "$jar" | grep 'JndiLookup.class' &>/dev/null && echo "Found vulnerability in $jar"
> done
Found vulnerability in /usr/lib/unifi/lib/log4j-core-2.13.3.jar
Found vulnerability in /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.2-SNAPSHOT/minecraft-server-1.15.2-SNAPSHOT.jar
Found vulnerability in /home/minecraft/.m2/repository/org/spigotmc/minecraft-server/1.15.1-SNAPSHOT/minecraft-server-1.15.1-SNAPSHOT.jar
...

Tenha cuidado ao executar isso em um sistema com sistemas de arquivos de rede montados, pois o desempenho pode ser afetado. Nesses casos, você precisa executar os comandos no próprio servidor de arquivos.