Una serie de tres parches activos emitidos por Amazon Web Services (AWS) a fines de 2021 para abordar la vulnerabilidad de Log4Shell en Apache Log4j han surgido como problemas de seguridad graves que afectan a los servidores independientes de AWS, los clústeres de Kubernetes, el clúster de Elastic Container Service (ECS) y Fargate vulnerable a ataque.
Rastreado como CVE-2021-3100, CVE-2021-3101, CVE-2022-0070 y CVE-2022-0071, el cuarteto de vulnerabilidades fue descubierto por investigadores de la Unidad 42 de Palo Alto Networks, que han trabajado en estrecha colaboración con AWS desde diciembre para arreglarlos y ahora está en condiciones de anunciar públicamente su existencia.
«Dada la urgencia de Log4Shell, es posible que este parche caliente se implementara ampliamente y, sin darse cuenta, pusiera en riesgo 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 con imágenes que no son de confianza están particularmente en riesgo. Palo Alto Networks alienta a los usuarios a actualizar a la versión de parche caliente reparada lo antes posible”.
Sin embargo, Avrahai agregó que los equipos de TI que (por cualquier motivo) aún no han parcheado sus entornos de AWS deben priorizar los parches originales.
«Si bien los problemas presentados pueden conducir a ataques graves en entornos en 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 de manera eficiente esta vulnerabilidad. Cuando el uso de Log4Shell alcanzó su punto máximo, el hot patch de AWS ayudó a la comunidad a detener innumerables ataques. Con estas vulnerabilidades solucionadas, ahora es posible usar el parche activo para abordar Log4Shell mientras se mantienen seguros los entornos de contenedores”.
Unit 42 dijo que una vez que el servicio de parches se instaló en un servidor o clúster, cualquier contenedor en ese entorno podría 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 es posible ya sea que el usuario esté ejecutando aplicaciones Java o no, o si el host subyacente está ejecutando la distribución reforzada de AWS Linux para contenedores, Bottlerocket. Los contenedores que se ejecutan con espacios de nombre de usuario o como usuarios no root también se ven afectados.
Unit 42 y AWS descubrieron que el problema surgía porque los parches activos buscaban continuamente procesos de Java y los parcheaban contra Log4Shell sobre la marcha, considerando cualquier proceso que ejecutara un binario llamado «Java» como candidato, ya sea dentro o fuera de un contenedor.
Dentro de los contenedores, los hot patches llamaron al binario «Java» del contenedor dos veces, una vez para obtenerlo 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 restricciones que normalmente se les aplicarían, por lo que un contenedor malicioso podría contener un binario «Java» malicioso para engañar al parche activo para que lo ejecute con privilegios elevados para llamar. Fuera de los contenedores, el host parcheado procesa de manera similar, con el mismo resultado básico.
