Una serie de tres parches activos emitidos por Amazon Web Services (AWS) para abordar la vulnerabilidad de Log4Shell en Apache Log4j a finales de 2021 han resultado contener graves problemas de seguridad que dejan servidores independientes de AWS, clústeres de Kubernetes, Elastic Container Service (ECS ) clústeres y Fargate vulnerables a ataques.
El cuarteto de vulnerabilidades está siendo rastreado como CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 y CVE-2022-0071 y fue descubierto por investigadores de la Unidad 42 de Palo Alto Networks, que ha estado trabajando en estrecha colaboración con AWS desde diciembre para solucionarlos y ahora puede divulgar públicamente su existencia.
“Dada la urgencia que rodea a Log4Shell, es posible que este parche caliente se haya implementado a gran escala, poniendo en riesgo sin darse cuenta todo tipo de entornos de contenedores”, dijo el investigador de la Unidad 42, Yuval Avrahai.
“Los entornos de contenedores de múltiples inquilinos y los clústeres que ejecutan imágenes que no son de confianza están especialmente en riesgo. Palo Alto Networks alienta a los usuarios a actualizarse a la versión de revisión fija lo antes posible”.
Sin embargo, agregó Avrahai, los equipos de TI que (por alguna razón) aún no han parcheado sus entornos de AWS deben priorizar los parches originales.
“Si bien los problemas presentados pueden conducir a ataques severos contra entornos de contenedores, Log4Shell se ha ganado legítimamente su lugar como una de las peores vulnerabilidades de todos los tiempos y todavía se está explotando activamente”, dijo.
“Nos gustaría agradecer a AWS por su asociación y coordinación para remediar esta vulnerabilidad de manera eficiente. Cuando la explotación de Log4Shell alcanzó su punto máximo, el parche caliente de AWS ayudó a la comunidad a detener innumerables ataques. Con estas vulnerabilidades solucionadas, ahora es posible usar el parche activo para abordar Log4Shell y al mismo tiempo mantener seguros los entornos de contenedores”.
Unit 42 dijo que después de instalar el servicio de parches en un servidor o clúster, cada contenedor en ese entorno pudo explotarlo para hacerse cargo del host subyacente. Por ejemplo, si se instaló en un clúster de Kubernetes, todos los contenedores de ese clúster habrían podido escapar hasta que se revirtiera o actualizara el parche original. Los procesos sin privilegios también podrían haber explotado el parche para aumentar los privilegios y obtener la ejecución del código raíz.
Agregó que el escape del contenedor era posible independientemente de si el usuario está ejecutando o no alguna aplicación Java, o si su host subyacente está ejecutando la distribución reforzada de AWS Linux para contenedores, Bottlerocket. Los contenedores que se ejecutan con espacios de nombres de usuario o como usuario no root también se ven afectados.
Unit 42 y AWS descubrieron que el problema surgió porque los hot patches buscaban continuamente procesos de Java y los parcheaban contra Log4Shell sobre la marcha, y cualquier proceso que ejecutaba un binario llamado “java” se consideraba candidato, ya sea dentro o fuera de un contenedor.
Dentro de los contenedores, los hot patches invocaron el binario “java” del contenedor dos veces, una vez para recuperarlo y luego otra vez para inyectar el hot patch. Pero lo hicieron sin contener adecuadamente los archivos binarios. Esto significaba que los nuevos procesos de contenedores podrían ejecutarse sin las limitaciones que normalmente se les aplicarían, por lo que un contenedor malicioso podría incluir un binario “java” malicioso para engañar al parche activo para que lo invoque con privilegios elevados. Fuera de los contenedores, el host parcheado del servicio procesa de manera similar, con el mismo resultado básico.