La vulnerabilidad Log4Shell en Apache Log4j, que causó consternación en la industria de la tecnología cuando apareció a fines de 2021, estará con nosotros durante mucho tiempo, tal vez hasta una década, según un informe producido por Cyber de EE. UU. Junta de Revisión de Seguridad (CSRB, por sus siglas en inglés), un panel de expertos provenientes de varias agencias gubernamentales y del sector privado.
La CSRB, que fue establecida por el presidente Joe Biden a través de una orden ejecutiva en 2021, ha estado analizando exactamente lo que sucedió con Log4j, una biblioteca de registro omnipresente y omnipresente basada en Java que se ha incorporado a miles de sistemas a lo largo de los años.
Rastreada como CVE-2021-44228, la vulnerabilidad de ejecución remota de código (RCE) de Log4Shell se considera muy fácil de explotar y se ha descrito de diversas formas como una “falla de diseño de proporciones catastróficas” y el “peor de los casos”.
Ahora, más de seis meses después, ha quedado muy claro que, a pesar de la urgencia con la que la industria dio un paso adelante para abordarlo, Log4Shell no ha terminado de ninguna manera, como lo dejó claro el presidente de la CSRB, Robert Silver, subsecretario de política de la Departamento de Seguridad Nacional y la vicepresidenta Heather Adkins, directora sénior de ingeniería de seguridad de Google.
“Log4j permanece profundamente integrado en los sistemas, e incluso dentro del corto período disponible para nuestra revisión, las partes interesadas de la comunidad han identificado nuevos compromisos, nuevos actores de amenazas y nuevos aprendizajes”, escribieron Silver y Adkins. “Debemos permanecer atentos a los riesgos asociados con esta vulnerabilidad y aplicar las mejores prácticas descritas en esta revisión.
“La Junta evalúa que Log4j es una ‘vulnerabilidad endémica’ y que las instancias vulnerables de Log4j permanecerán en los sistemas durante muchos años, tal vez una década o más. Queda un riesgo significativo”.
En el momento de escribir este artículo, la CSRB dijo que no tenía conocimiento de ningún ataque significativo a la infraestructura nacional crítica (CNI) que haya explotado Log4Shell, y también señaló que la explotación general se produjo a niveles más bajos de lo que se predijo en un principio, dada su gravedad.
Sin embargo, señaló además que estas conclusiones no fueron fáciles de sacar porque gran parte de la evidencia es anecdótica y no hay fuentes reales para comprender las tendencias de explotación en geografías e industrias que no están vinculadas a intereses cibernéticos comerciales.
CSRB evaluó además que en la respuesta a Log4Shell, muchas cosas salieron bien, particularmente en la respuesta de Apache Software Foundation (ASF), que reconoció rápidamente la gravedad de la vulnerabilidad y pudo recurrir a procesos de desarrollo de software bien establecidos para remediar eso. La CSRB también elogió la respuesta de la industria cibernética en general, con proveedores que se apresuraron a producir orientación.
Sin embargo, agregó, las organizaciones claramente lucharon para responder al evento, con gran parte del arduo trabajo de actualizar los sistemas vulnerables aún lejos de completarse. Además, Log4Shell expuso riesgos de seguridad preocupantes inherentes a la comunidad de código abierto, que, según el informe, no contaba con los recursos adecuados para garantizar que el código se desarrolle de acuerdo con las mejores prácticas de seguridad.
El informe pasó a hacer 19 recomendaciones clave, que se dividen en cuatro categorías, que se detallan a continuación, mientras que el informe completo se puede descargar para su revisión aquí.
Terry Olaes, director de ingeniería de ventas de Skybox Security, un especialista en gestión de amenazas con sede en California, ha estado rastreando a Log4Shell desde que se reveló la vulnerabilidad por primera vez en diciembre de 2021. Describió los hallazgos del informe como desafortunados, pero no sorprendentes dado el uso generalizado de Log4j.
“Las amenazas Log4j exponen a las víctimas que carecen de modelos maduros de riesgo de seguridad cibernética a ataques que tienen vectores RCE como ransomware, y es probable que haya muchos ataques asociados con esta vulnerabilidad en los próximos años”, dijo Olaes.
“En los próximos años, los actores de amenazas innovarán formas nuevas y creativas de explotar herramientas comunes como Log4j. Como resultado, la prevención de infracciones requiere minimizar de inmediato su exposición a través de una mitigación inteligente y específica.
“Para una vulnerabilidad generalizada como Log4j, parchear todas las instancias no es práctico. No solo requiere mucho tiempo, sino que también es enormemente costoso. La historia muestra que la estrategia de ‘parchar todo’ es una pérdida monumental de esfuerzo debido al hecho de que, por lo general, es un subconjunto muy pequeño de dispositivos que en realidad están expuestos al ataque en sí. Por eso es crucial adoptar un enfoque más proactivo para la gestión de vulnerabilidades aprendiendo a identificar y priorizar las vulnerabilidades expuestas en todo el panorama de amenazas”.
Al comentar más sobre la revisión de CSRB, el estratega principal del Centro de Investigación de Seguridad Cibernética de Synopsys, Tim Mackey, dijo: “Rara vez recibimos una revisión exhaustiva del impacto y las causas raíz de un incidente cibernético tan rápido después de que ocurrió el incidente, pero eso es precisamente lo que tenemos de CSRB en su informe sobre Log4Shell y Log4j.
“El software de código abierto se gestiona fundamentalmente de manera diferente al software comercial, pero el software de código abierto juega un papel clave en el éxito del software comercial. El escenario de cola larga descrito en el informe es uno que hemos visto con innumerables vulnerabilidades pasadas y que favorece a los atacantes, ya que su éxito se basa en tener al menos una víctima que no haya reparado sus sistemas.
“Dado que la administración del software de fuente abierta es diferente al software comercial, y la fuente abierta impulsa el software comercial, depender de un proveedor comercial para alertar a los consumidores sobre un problema supone que el proveedor está administrando adecuadamente su uso de fuente abierta y que puede identifique y alerte a todos los usuarios de su software afectado, incluso si el soporte para ese software ha finalizado.
Mackey agregó: “Dado que la administración de parches es un desafío en el mejor de los casos, para mitigar el riesgo de una gobernanza de fuente abierta desconocida dentro de los proveedores, los consumidores de software deben implementar un modelo de confianza pero verificación para validar si el software que se les proporciona no No contiene vulnerabilidades sin parches”.
