¿Eres un administrador de sistemas que ha conseguido implementar las mitigaciones de Log4Shell a tiempo para la fecha límite impuesta por el Gobierno de los Estados Unidos, el 24 de diciembre de 2021?
Si es así, es posible que hayas disfrutado de unas minivacaciones navideñas junto con gran parte del resto del mundo, sólo para volver a la carga esta semana y encontrar que el equipo de Apache Log2j acaba de publicar el cuarto parche en lo que podríamos llamar la Saga de la Vulnerabilidad Log4Shell.
El fallo recién descubierto es CVE-2021-44832, parcheado en Log4j 2.17.1, anunciado el 28/12/2021.
Afortunadamente, a pesar de la comprensible publicidad que ha recibido este cuarto fallo, y que recomendamos parchearlo con prontitud de todos modos, actualmente sólo se califica como fallo moderado.
Este no parece ser directa y fácilmente explotable como la vulnerabilidad original CVE-2021-44228 que dio lugar al nombre Log4Shell en primer lugar.
La saga hasta ahora
Para resumir la saga hasta ahora, comenzamos aproximadamente el 9 de diciembre de 2021:
- Aparece la noticia de una “característica” fácil de usar en el código de registro de Apache Log4j. Lo que la mayoría de los programadores ignoraron como una simple sustitución de variables en los datos de registro (por ejemplo, convertir ${java:version} en una cadena de texto que describe la versión de Java) resultó que permitía a los atacantes ocultar comandos peligrosos en los datos desde el exterior, como inyectar instrucciones para filtrar datos secretos o descargar código malicioso.
- Organizaciones de todo el mundo se han dado cuenta de que el código defectuoso está muy extendido. Incluso las empresas que no se consideraban a sí mismas tiendas de Java encontraron aplicaciones Java dispersas en sus redes. Inesperadamente, Log4j resultó estar incluido en muchas de estas aplicaciones.
- El mensaje es que este fallo puede ser explotado incluso en lo más profundo de una red. Ejecutar servidores no-Java en el borde de la red no elimina el riesgo. Cualquier servidor interno al que se envíen datos no fiables (por ejemplo, un número de teléfono o un código postal) para su procesamiento podría estar en peligro si registras esos datos. Y muchas aplicaciones de lógica empresarial crean abundantes registros, a menudo con buenas razones, como por ejemplo para fines de auditoría o de cumplimiento.
- Apache publica rápidamente Log4j 2.15.0, que corrige el principal fallo de seguridad. Para aquellos servidores en los que el control de cambios se interpuso en la aplicación del parche (aparentemente sin ironía, dado que el mismo proceso de control de cambios presumiblemente pasó a través del código vulnerable hace muchos años), Apache proporcionó prácticas mitigaciones en tiempo de ejecución para suprimir el comportamiento peligroso.
- Los ataques aumentaron, incluyendo muchos de los autodenominados investigadores que “intentaban ayudar”. Como este fallo era originalmente una característica, podía ser explotado con facilidad, así que cualquiera que quisiera involucrarse podía intentarlo. Miles, quizás incluso millones, lo hicieron, a menudo sin una intención abiertamente maliciosa. Pero entre el humo de la “investigación” inútil de ciberseguridad había numerosos incendios auténticos provocados por ciberdelincuentes que robaban datos o implantaban malware como criptomineros y ransomware.
- Apache profundiza en el código y encuentra un nuevo fallo. Log4j recibe rápidamente una segunda actualización a la versión 2.16.0.
- Apache encuentra un tercer fallo que nos lleva a la versión 2.17.0. Aconsejamos a los administradores de sistemas que estuvieran a medio camino de la actualización a la 2.16.0 o a la 2.15.0 que simplemente siguieran parcheando, pero utilizando la 2.17.0 para sus sistemas aún no parcheados. Es mejor tener todos los sistemas en 2.15.0 o superior tan pronto como sea posible, y luego volver a “completar” los servidores 2.15.0 y 2.16.0 más tarde, que arriesgarse a dejar algunos servidores completamente sin parches durante más tiempo.
- El Gobierno de EEUU establece el 24 de diciembre de 2021 como fecha límite para la aplicación de parches. Dado que el día de Navidad y el día de San Esteban de 2021 caen en sábado y domingo respectivamente, creando un doble juego de fin de semana y vacaciones familiares en gran parte del mundo, CISA decide establecer la proverbial noche antes de Navidad como fecha límite para que el sector público estadounidense despliegue sus parches.
El cuarto fallo
Este nuevo y cuarto fallo fue reportado justo después del fin de semana de Navidad 2021, el 28/12/2021.
Afortunadamente, en palabras de Apache
Las versiones 2.0-beta7 hasta la 2.17.0 de Apache Log4j2 (excluyendo las versiones de corrección de seguridad 2.3.2 y 2.12.4) son vulnerables a un ataque de ejecución remota de código (RCE) en el que un atacante con permiso para modificar el archivo de configuración de registro puede construir una configuración maliciosa utilizando un JDBC Appender con una fuente de datos que haga referencia a un URI JNDI que pueda ejecutar código remoto. Este problema se soluciona limitando los nombres de fuentes de datos JNDI al protocolo java en las versiones 2.17.1, 2.12.4 y 2.3.2 de Log4j2.
El RCE, por supuesto, es el peor tipo de agujero de ciberseguridad que se puede sufrir, ya que normalmente significa que un extraño puede introducir un programa inesperado en su ordenador sin ni siquiera un permiso.
Un ataque RCE puede inyectar una aplicación que no es de confianza, introducir un fragmento binario de código de máquina en la memoria, u ofrecer sigilosamente un archivo de script no deseado y si el atacante tiene éxito, ejecutarás su código sin saberlo, sin ningún aviso oficial de ¿Está seguro (S/N)? o de Esto podría dañar su ordenador que te alerte.
Pero a pesar de que este fallo menciona RCE, no es realmente lo que la jerga llama una ejecución remota no autenticada, en la que cualquiera que pueda interactuar con tu red sin iniciar sesión primero (por ejemplo, visitando una web) podría activar el fallo.
Como menciona Apache, para activar la ejecución remota, un atacante necesitaría primero un acceso suficiente para trastear con los ajustes de configuración del servidor vulnerable o de la aplicación empresarial.
Sospechamos que cualquier atacante con suficiente acceso para alterar los ajustes de configuración del lado del servidor tendrá varias formas adicionales para comprometer tus aplicaciones internas, sistemas o red.
En otras palabras, si estás directamente en riesgo de CVE-2021-44832 en este momento, entonces la actualización de Log4j 2.17.0 a 2.17.1 probablemente no es la solución necesaria ni suficiente para tus problemas de seguridad.
En pocas palabras, no te limites a parchear a la versión 2.17.1 y pienses: “Genial. Ahora puedo relajarme hasta el Año Nuevo”.
¿Qué hacer?
- Parchea a Log4j 2.17.1 cuando puedas. No tiene sentido saltarse esta actualización simplemente porque sólo está calificada como Moderada.
- Si crees que CVE-2021-44832 supone un peligro claro y presente para tu red, no basta con aplicar el parche por sí solo. Un sistema que es realmente vulnerable a los intrusos malintencionados a causa de este error es casi seguro que también está en riesgo de sufrir otros ataques.
- Revisa los ajustes de configuración de Log4j. Busca configuraciones no autorizadas o no deseadas que no hayas considerado antes.
En un artículo anterior, propusimos revisar tu propio uso de Log4j en un futuro próximo, y averiguar si realmente lo necesitas en tu propio software.
Si has heredado Log4j sin darte cuenta, como parte de la “cadena de suministro” de Java, y puedes sustituirlo fácilmente por algo mucho más sencillo y con menos funciones, creemos que sería una decisión inteligente.
Algunos comentaristas han dicho que no somos realistas o que nos pasamos de la raya al decir esto, afirmando que subestimamos las complejas necesidades de registro de la aplicación empresarial media.
Pero vamos a sugerir, una vez más, que si has encontrado Log4j en tu ecosistema recientemente, especialmente en servidores donde ni siquiera sabías que estaba ahí, que te hagas la pregunta: “¿Realmente necesito un conjunto de herramientas de registro de varios megabytes que consiste en cerca de medio millón de líneas de código fuente, o algo mucho más modesto y más fácil de revisar lo haría al menos igual de bien?”
Esto no es una crítica a Apache; es simplemente un recordatorio de que los problemas de seguridad heredados, como Log4Shell, son a menudo el efecto secundario inesperado de una decisión de ciberseguridad tomada hace años por alguien de fuera de tu empresa a quien nunca has conocido, y nunca conocerás.
A pesar de que la decisión original puede no haber sido tomada por ti, ahora es tu responsabilidad, por lo que revisarla no puede considerarse controvertida o poco meditada.
Puedes conocer más sobre la vulnerabilidad visualizando este webinar.
