Un año después: el Armagedón de Log4Shell que nunca fue

Si bien el mundo digital no se ha derrumbado, Log4Shell inició numerosas calamidades cibernéticas, lo que provocó la pérdida de ingresos para las empresas y agotó las horas extra de los equipos de TI. Sin embargo, los expertos creen que la falla también presentó a la comunidad mundial de ciberseguridad una gran oportunidad de aprendizaje.

Ha pasado un año desde que se reveló la vulnerabilidad de día cero en Log4j, una biblioteca de registro basada en Java desarrollada por Apache Software Foundation. Descubierta por Chen Zhaojun de Alibaba Cloud el 24 de noviembre de 2021, la falla llamó la atención del público el 9 de diciembre.

Pronto se hizo evidente que los servicios globales como Steam, Apple iCloud, Amazon Web Services, Cloudflare y muchos otros eran vulnerables a la nueva falla que los investigadores de LunaSec denominaron Log4Shell.

El error afectó a una herramienta informática ampliamente utilizada, lo que permitió el robo de credenciales y la ejecución remota de código, pero afectó los registros en lugar del software en sí. El torrente de problemas se ganó rápidamente los títulos de vulnerabilidad como “el momento de Fukushima para la ciberseguridad”.

Es difícil exagerar el impacto inicial que causó la divulgación de la vulnerabilidad, afirma Jordan Schroeder, director de CISO en Barrier Networks, una empresa de ciberseguridad.

“Cuando se anunció por primera vez el problema de Log4j, provocó un pánico generalizado. Los equipos de desarrollo y TI luchaban por localizar todas las instancias de esta biblioteca de código profundamente integrada en sus propios proyectos, así como en sus servidores y productos suministrados por sus socios proveedores”, dijo Schroeder a Cybernews.

Pánico en los CISO

Los temores no fueron exagerados. Los bots comenzaron a buscar la vulnerabilidad recién anunciada casi de inmediato, dijo Xavier Bellekens, director ejecutivo de Lupovis, una empresa que utiliza técnicas basadas en el engaño para mejorar la ciberseguridad.

“A los pocos minutos del lanzamiento, nuestros señuelos detectaron los primeros escáneres en busca de vulnerabilidades en Log4J, lo que demuestra la resistencia y la eficacia de los adversarios”, dijo Bellekens a Cybernews.

Mientras los bots buscaban dispositivos vulnerables, los actores malintencionados rápidamente comenzaron a generar varios exploits, y los primeros inundaron Internet apenas una hora después de que se revelara el error. Los investigadores de la firma de seguridad cibernética Check Point detectaron millones de intentos de explotar la falla en los días posteriores a su divulgación.

“Algo así va a volver a suceder, y con más frecuencia de lo que nos gustaría. No quiero que se atragante con sus pasteles de carne picada, pero ¿en qué mes fallaron tanto SolarWinds como Log4j? Ponte a practicar.dijo Lindahl-Wise.

“Los proveedores lanzaron actualizaciones rápidas, los proyectos y las canalizaciones de desarrollo se suspendieron, y todos los líderes empresariales querían saber ‘¿ya solucionamos esto?’ Pero debido a la naturaleza del problema, uno nunca podría estar seguro de haber encontrado todas las instancias de Log4j”, dijo Schroeder.

Los intentos de usar Log4Shell para implementar ransomware aumentaron rápidamente en número. Por ejemplo, el ransomware Khonsari se detectó menos de una semana después de que se conociera la noticia del error. Grupos de ransomware conocidos como Conti, BlackCat, LockBit y otros pronto integraron la vulnerabilidad en su arsenal.

Los investigadores de Arctic Wolf suponen que desde principios de este año, el 60% de todos los incidentes de seguridad relacionados con Log4Shell que su equipo ha investigado podrían atribuirse a grupos de ransomware . Como era de esperar, los prolíficos afiliados de LockBit explotaron la falla con mayor frecuencia.

Empezando a sangrar de nuevo

Reducir la vulnerabilidad de los sistemas de TI afectados requirió un esfuerzo gigantesco, ya que los equipos de seguridad tuvieron que revisar interminables líneas de código. Según la Junta de Revisión de Seguridad Cibernética (CSRB) de EE. UU., un departamento federal dedicó la increíble cantidad de 33 000 horas para proteger sus redes internas de las vulnerabilidades de Log4Shell.

Sin embargo, muchos siguen siendo vulnerables a Log4Shell hasta el día de hoy. Si bien Bellekens dice que hay hasta 50,000 dispositivos vulnerables con acceso a Internet, Schroeder eleva el número aún más, con cientos de miles de servicios estimados como potencialmente vulnerables.

Según los investigadores de Tenable, el verdadero alcance del problema es aún mayor, con el 72 % de las organizaciones aún susceptibles al error Log4j a partir de octubre de 2022. Los autores del informe afirman que una quinta parte de todas las empresas que solucionaron la falla tuvieron la vulnerabilidad reintroducida.

El asesor jefe de seguridad de Tiberium, Gareth Lindahl-Wise, cree que Log4Shell ha reaparecido desde que algunas organizaciones se apresuraron a cancelar sus medidas de mitigación.

“Un número desalentador de organizaciones sigue siendo vulnerable a los ataques de Log4j. Es probable que se trate de una mezcla de personas que no eliminaron o no pudieron eliminar la vulnerabilidad, pero también algunas que tenían controles de compensación que luego se cambiaron: se quitaron el yeso y comenzaron a sangrar nuevamente”, explicó Lindahl-Wise a Cybernews. .

Un momento de enseñanza

Los expertos en seguridad con los que hemos hablado están de acuerdo en que, si bien es poco probable que Log4Shell desaparezca, la terrible experiencia ha obligado a las empresas y los gobiernos a revisar las prácticas de gestión y desarrollo de software. Mark Lamb, director ejecutivo de HighGround, llamó la atención sobre el lado positivo de una mentalidad cambiante.

“Creo que el mayor impacto ha sido positivo en la forma en que todos pensamos y administramos los componentes del software. Esto ha llevado a los legisladores a despertar y abordar activamente esta área”, dijo Lamb.

Log4Shell, al igual que el infame truco de SolarWinds , destacó la importancia de saber de qué está hecho el software. La lista de materiales del software (SBOM) , un inventario de los componentes utilizados para construirlo, es una de las formas de reducir el tiempo de mitigación.

“Creo que el mayor impacto ha sido positivo en la forma en que todos pensamos y administramos los componentes del software. Esto ha llevado a los legisladores a despertar y abordar activamente esta área”.Cordero dijo.

Según Schroeder, las empresas con SBOM completos dedicaron mucho menos tiempo a corregir el error, lo que redujo los meses de trabajo a horas. Las ganancias, dijo, demuestran la importancia de comprender la cadena de suministro de software en general.

“Los reguladores están proponiendo un requisito en el que estos SBOM se puedan pasar a cada desarrollador en la cadena de suministro hasta el usuario final. De esa manera, la existencia de algo como Log4j tendrá la visibilidad requerida de forma predeterminada para que la próxima vez no tengamos que buscar a ciegas componentes repentinamente vulnerables”, dijo Schroeder.

Sin embargo, hasta que los SBOM se vuelvan mundanos, los equipos de seguridad deben analizar la respuesta global a Log4Shell y practicar su respuesta. Lindahl-Wise señaló que las organizaciones no solo deben tener herramientas para comprender y escanear su software, sino que también deben tener un libro de jugadas genuino y practicado para una vulnerabilidad omnipresente de día cero.

“Algo así va a volver a suceder, y con más frecuencia de lo que nos gustaría. No quiero que se atragante con sus pasteles de carne picada, pero ¿en qué mes fallaron tanto SolarWinds como Log4j? Ponte a practicar”, dijo Lindahl-Wise.

Fuente: cybernews