Carreras profesionales
es
es
Ralph Moonen - Consultor principal
Se han encontrado vulnerabilidades en Apache Log4j, denominadas Log4Shell (formalmente conocidas como CVE-2021-44228). Muchas aplicaciones web y otros sistemas de todo el mundo utilizan este software, que podría causar graves daños en muy poco tiempo. La vulnerabilidad ya ha afectado a Twitter, Amazon, Apple, Tesla y otros.
¿Qué encontrará en esta página de actualización de Log4j?
Bureau Veritas Cybersecurity ha ayudado a numerosos clientes a identificar instancias vulnerables de Log4j o a realizar análisis forenses en servidores que estaban (potencialmente) comprometidos. Durante ese tiempo, también se descubrieron y publicitaron nuevas vulnerabilidades en Log4j. Afortunadamente, la situación actual parece ser que el exploit activo no es muy común. Decimos esto con cierta reserva, porque el modelo de amenaza para esta vulnerabilidad es tan diferente de otras vulnerabilidades que es muy plausible que se descubran nuevos e innovadores vectores de ataque en el futuro.
Por ahora, es importante señalar que la versión 2.17.1 se publicó para solucionar un problema de seguridad que resultó tener un impacto muy limitado. Por lo tanto, no es sumamente necesario salir corriendo a parchear de nuevo. Si ejecuta la versión 2.16.1 seguirá estando protegido contra Log4Shell y cualquier variante conocida. Bureau Veritas Cybersecurity continuará vigilando la situación y proporcionará actualizaciones aquí en caso de cualquier cambio.
Si aún no está seguro de qué hacer o desea obtener información sobre su seguridad, no dude en ponerse en contacto con nosotros.
Log4j es un componente muy utilizado en todo tipo de entornos. Recientemente se ha sabido que existe una grave vulnerabilidad que afecta a muchos otros productos, aplicaciones y sistemas porque está integrado en muchas soluciones de software. Bureau Veritas Cybersecurity está en estrecho contacto con otras organizaciones de seguridad como Cyberveilig Nederland y el NCSC para coordinarse y ayudar a nuestros clientes a hacer frente a las consecuencias de esta nueva vulnerabilidad. Nuestros probadores han incorporado pruebas para esta vulnerabilidad en su flujo de trabajo estándar. Pero es posible que aún tenga dudas sobre qué hacer y cómo reaccionar. Así que nos gustaría sugerirle algunos pasos que puede dar para disminuir el riesgo y mitigar este problema.
Pero primero, es importante entender el asunto. Funciona así: si un atacante puede conseguir que se registre una cadena de ataque específica a través de log4j, esta cadena hará que log4j establezca una conexión con un host controlado por el atacante, y descargue un fragmento de código proporcionado por el atacante y lo ejecute. Entonces, ¿qué tipo de cosas se registran? Bastantes, ¡resulta! Podría ser un nombre de usuario, un encabezado de correo electrónico, una cookie de un sitio web, realmente cualquier cosa podría quedar registrada en algún punto del camino. Y para complicar las cosas, a veces las cosas se registran en una fecha posterior, o sólo después de que hayan ocurrido un cierto número de eventos. Por ejemplo, algunos mecanismos de registro podrían registrar un intento fallido de inicio de sesión sólo después de diez o más intentos. Así que es difícil probar todos los vectores de inyección posibles. Es totalmente posible que todos sus servidores expuestos externamente a Internet no sean vulnerables, pero un servidor de aplicaciones interno backend sí lo sea. La cuestión es que un atacante puede esparcir las cadenas por ahí y esperar que en algún momento encuentre componentes vulnerables. En el momento de escribir esto, los productos vulnerables incluyen muchas soluciones de uso general: Jira, Confluence, Splunk, Elastic, VMWare Center, y muchos más. ¡Algunos son realmente productos de seguridad!
Por suerte, el NCSC holandés está rastreando el software vulnerable conocido. También están proporcionando IOCs y mitigaciones. Así que en lugar de proporcionar estos aquí, vamos a redirigir a todos a su repositorio.
Averigüe dónde está utilizando log4j o un producto vulnerable que utilice log4j. Compruebe con regularidad la lista en https://github.com/NCSC-NL/log4shell porque se actualiza continuamente.
Parchee su software o aplique una de las mitigaciones mencionadas en el enlace al repositorio GitHub del NCSC. No lo olvide: no sólo los sistemas orientados a Internet pueden ser atacados.
Si no puede parchear o mitigar, asegúrese de que un servidor vulnerable no pueda conectarse a Internet como solución temporal.
Configure su IDS y SIEM para bloquear los IOC e implemente reglas de detección, de nuevo nos remitimos a https://github.com/NCSC-NL/log4shell para esta información (y manténgala actualizada porque también hay muchas formas de eludir las reglas de detección).
Si tiene indicios de que un servidor está en peligro, tome las medidas estándar de incident response y forenses: aísle, contenga e investigue.
Está claro que la mayoría de las organizaciones se encuentran actualmente en riesgo, ya que el exploit es tan fácil y la vulnerabilidad está tan extendida. Saber lo que tiene (gestión de activos) es extremadamente importante y saber qué componentes de software utiliza (SBOM)
Además, esperamos que no sólo los sistemas de TI, sino también los sistemas OT se vean afectados por esta vulnerabilidad. Debido a la naturaleza a menudo incrustada de las aplicaciones en los entornos OT, esperamos que lleve mucho más tiempo conocer y averiguar qué productos OT son especialmente vulnerables. Pero es muy plausible que los historiadores y registradores de datos OT resulten ser vulnerables.
Actualizaremos esta página cuando se produzcan nuevos desarrollos o se disponga de información relevante. Para nuestros clientes, póngase en contacto con su gestor de cuenta si tiene alguna pregunta sobre esta vulnerabilidad.
El jueves 6 de enero, nuestro Director Técnico, Ralph Moonen, impartirá el seminario web en directo: "Log4j, Latest Insights and How to Stay Secure?", durante el cual podrá formular todas sus preguntas. ¿Desea asistir a este seminario web? Ya puede inscribirse aquí.
