Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo los desarrolladores trabajaron para asegurar la vulnerabilidad Log4j

[19/12/2021] El fin de semana del pasado 11, Internet se incendió y todavía no está claro cuántos desarrolladores con extintores se necesitarán para controlarlo. Sin embargo, había un grupo de socorristas en la escena: mantenedores o desarrolladores en gran parte no remunerados que trabajan en su tiempo libre parchando vulnerabilidades, dando orientaciones y proporcionando la claridad que tanto se necesitaba en medio del caos.

El 9 de diciembre, la Fundación Apache publicó una actualización de emergencia para una vulnerabilidad crítica de día cero llamada Log4Shell que se había identificado en Log4j, un marco de trabajo para registro, de código abierto, utilizado en todo tipo de aplicaciones Java. El error, identificado como CVE-2021-44228, permite a un atacante ejecutar código arbitrario en cualquier sistema que use la biblioteca Log4j para escribir mensajes de registro. Inmediatamente se le calificó con la gravedad máxima de 10 en la escala CVSS.

Como el CTO de Cloudflare, John Graham-Cumming, escribió: "Esta es probablemente una de las vulnerabilidades más graves en Internet desde Heartbleed y ShellShock. Incluso Minecraft no estaba seguro.

[Cómo mitigar adecuadamente las vulnerabilidades de Log4j]
[La vulnerabilidad de Apache Log4j se explota activamente]
[Consejos de mitigación de Log4j]
[La segunda vulnerabilidad de Log4j conlleva una amenaza de denegación de servicio]

Los socorristas

Desarrolladores y mantenedores se apresuraron inmediatamente durante el fin de semana a parchar tantas aplicaciones Java como fuera posible. La primera línea de defensa fue el propio Log4j, que es mantenido por el equipo de Logging Services de la Apache Software Foundation, una organización sin fines de lucro.

El equipo de Logging Services de Apache está conformado por 16 voluntarios no remunerados, distribuidos en casi todas las zonas horarias del mundo. "Hacemos esto porque nos encanta escribir software y resolver acertijos en nuestro tiempo libre, sostiene Gary Gregory, ingeniero de software y miembro del Comité de Gestión de Proyectos (PMC) de Apache Logging Services.

El canal de comunicación principal del PMC es el correo electrónico, y el miércoles 24 de noviembre a las 7:51 a.m. GMT, el grupo recibió un mensaje explosivo. Chen Zhaojun, miembro del equipo de seguridad de nube de Alibaba, les alertaba de que se había descubierto un error de seguridad de día cero en su software.

"Estaba claro de inmediato que esto sería un gran problema, anota Gregory, que operaba con unas cuatro horas de sueño durante el fin de semana.

El equipo rápidamente se puso a trabajar para solucionar el problema en privado, pero su cronograma se aceleró rápidamente cuando el exploit se hizo público el jueves 9 de diciembre. "Por favor, dense prisa, instó Chen de Alibaba.

Gregory y sus compañeros de mantenimiento dejaron todo y comenzaron a trabajar para solucionar el problema, preparando una actualización de la versión 2.15 que rápidamente decidieron que "no era lo suficientemente buena antes de publicarla a las 10:00 a.m. GMT del viernes 10 de diciembre. Siguieron con una versión 2.16 a las 10:28 p.m. GMT del 13 de diciembre.

"Conozco a estas personas, todas tienen familias y cosas que tienen que hacer. Pero dejaron todo a un lado y simplemente se sentaron durante todo el fin de semana y trabajaron en esto, sostuvo el exdesarrollador de Log4j, Christian Grobmeier, a Bloomberg.

En este punto del fin de semana, los miembros activos del PMC habían cambiado su forma de comunicarse, ahora lo hacían a través de un canal privado de Slack, donde continuaron combatiendo el problema y trabajando juntos para producir actualizaciones para los usuarios que operan con versiones anteriores de Java. Rápidamente produjeron la versión 2.12.2 para solucionar el problema para los usuarios de Java 7. La solución para Java 6 está resultando ser más complicada, pero es la siguiente en sus pendientes.

"En general, creo que, a pesar de las horribles consecuencias de este tipo de vulnerabilidad, las cosas salieron tan bien como podría esperar un desarrollador experimentado, indicó Gregory. "Fuimos notificados, proporcionamos un parche rápidamente e iteramos esa versión. Eso es algo que he visto en ambientes profesionales una y otra vez.

Hotpatches y orientación urgente

Otro grupo que se movió rápidamente durante el fin de semana, fue el equipo de Amazon Corretto dentro de Amazon Web Services. Corretto es una distribución del Open Java Development Kit (OpenJDK), que coloca a este equipo en la primera línea del problema de Log4Shell.

Dirigido por el ingeniero de software principal Volker Simonis, el equipo de Corretto rápidamente creó y estableció como código abierto un hotpatch para cualquier organización donde la actualización no sea posible de inmediato.

Como se describe en su página de GitHub: Esta es una herramienta que inyecta un agente Java en un proceso JVM en ejecución. El agente intentará parchar el método lookup () de todas las instancias org.apache.logging.log4j.core.lookup.JndiLookup cargadas para devolver incondicionalmente la cadena "Patched JndiLookup::lookup().

El hotpatch está diseñado para abordar la vulnerabilidad de ejecución remota de código CVE-2021-44228 en Log4j sin reiniciar el proceso de Java. Se sabe que los agentes dinámicos y estáticos se ejecutan en JDK 8 y JDK 11 en Linux, mientras que en JDK 17 solo funciona el agente estático.

"Un gran agradecimiento al equipo de Amazon Corretto por pasar días, noches y el fin de semana para escribir, reforzar y enviar este código, escribió el CISO de AWS Steve Schmidt en una entrada de blog. AWS también ha publicado una detallada lista de las actualizaciones de seguridad específicas del servicio para los productos afectados.

Por otra parte, los miembros del equipo de Java en Microsoft, dirigido por el gerente principal del grupo de ingeniería para Java, Martijn Verburg, ayudaron a evaluar ese parche y también emitieron más consejos generales para que los clientes se protejan, incluyendo varias soluciones alternativas recomendadas hasta que se pueda aplicar una actualización de seguridad completa.

Google Cloud respondió con una actualización de su producto de seguridad Cloud Armor, que lanzó una regla urgente para firewalls de aplicaciones web (WAF) el 11 de diciembre para ayudar a detectar y bloquear los intentos de explotación de CVE-2021-44228.

"En un intento por ayudar a nuestros clientes a enfrentar la vulnerabilidad Log4j, hemos introducido una nueva regla WAF preconfigurada llamada 'cve-canary' que puede ayudar a detectar y bloquear intentos de explotación de CVE-2021-44228, escribieron Emil Kiner, gerente de producto de Cloud Armor, y Dave Reisfeld,  administrador especialista en redes de Google, en una entrada de blog el sábado.

Lo que usted puede hacer

Si bien estos desarrolladores internos se apresuraron a proteger el software para sus clientes, muchos usuarios finales y desarrolladores empresariales se esfuerzan por evaluar sus vulnerabilidades y proteger sus propias aplicaciones Java.

Lo primero que debe hacer es detectar si Log4j está presente en sus aplicaciones. También es importante tener en cuenta que no todas las aplicaciones serán vulnerables a este exploit. Cualquiera que utilice una versión de Java superior a 6u212, 7u202, 8u192 o 11.0.2 debería estar seguro, gracias a la protección adicional para la carga de clases remotas JNDI (Java Naming and Directory Interface) en esas versiones.

De manera similar, los usuarios de versiones de Log4j superiores a 2.10 podrían mitigar el problema configurando la propiedad del sistema formatMsgNoLookups en 'true', configurando el parámetro JVM-Dlog4j2.formatMsgNoLookups=true, o eliminando la clase JndiLookup del classpath.

Esto aún no termina

Debido a que la vulnerabilidad Log4j no solo afecta a las aplicaciones Java, sino también a cualquier servicio que use la biblioteca, es probable que la superficie de ataque de Log4Shell sea muy grande.

Como escribió Lucian Constantin para CSO, "la comunidad sigue trabajando para evaluar la superficie de ataque, pero es probable que sea enorme debido al complejo ecosistema de dependencias. Algunos de los componentes afectados son extremadamente populares y millones de aplicaciones y servicios empresariales los utilizan.

Por su parte, el equipo de Apache Logging Services "continuará evaluando las características de Log4j que podrían tener riesgos de seguridad potenciales y hará los cambios necesarios para eliminarlos. Si bien haremos todo lo posible para mantener la compatibilidad con las versiones anteriores, esto puede significar que tengamos que deshabilitar las funciones que pueden estar usando, señaló Ralph Goers, miembro del equipo Logging Services de Apache.

Incluso cuando innumerables desarrolladores trabajaron incansablemente durante el fin de semana para parchar la vulnerabilidad Log4j, habrá muchos que sean más lentos en responder. Por lo tanto, el impacto de Log4Shell probablemente será a largo plazo y de amplio alcance.

Como el analista de seguridad Tony Robinson tuiteó: "si bien los buenos están solucionando el problema rápidamente al parcharlo, habrá muchos lugares que no parcharán, o no puedan parchar por un tiempo. Luego, uno comienza a ingresar al software que está al final de su vida útil o que puede que no se esté siendo reparado.

Crédito foto: Little Visuals / License: CC0