Log4J, un fallo que podría haberse evitado con una simple comprobación pero que al no hacerlo se ha convertido en un grave problema

Tener un mes tranquilo es complicado en el sector de la ciberseguridad. Cuando no es un ransomware, es una campaña de phishing; cuando no es la aparición de una vulnerabilidad capaz de poner en jaque a medio mundo. La semana pasada os hablamos de Log4J o Log4Shell, concretamente de para qué servicios podría suponer una amenaza y la gravedad de la vulnerabilidad. Esta vulnerabilidad ha copado los titulares de todos los medios, y no es para menos. Sus efectos podrían ser catastróficos en caso de ser explotada, algo que ya se están dando en algunos países (Irán y China) según ha revelado Microsoft. Ahora bien, ¿Dónde se ha originado todo este embolado? El origen de Log4Shell, aunque parezca mentira, es el que menos cabría imaginar teniendo en cuenta el daño que puede causar. Log4J, un fallo que podría haberse evitado con una simple comprobación.

Antes de nada, comentar que Log4Shell es una librería de código abierto cuya función es realizar los registros automáticos de cualquier web o aplicación programada con lenguaje Java. Esta librería ha sido adoptada por muchas empresas gracias a su facilidad de uso; una adopción que no contó con las pruebas de calidad necesarias para comprobar si estaba libre de fallos. Y aquí llega el quid de la cuestión. La librería, creada por un programador voluntario de la plataforma Apache Software Foundation, contaba con una brecha de seguridad. Dicha brecha permite introducir ciertas modificaciones en el código. Una vez aplicadas, permiten hacerse con el control remoto de los servidores que usan esa librería. A la hora de guardar el archivo, Log4Shell lo interpreta erróneamente y permite la ejecución de comandos con servidor remoto. A veces, lo gratis sale caro, especialmente si no se revisa su código para comprobar si tiene fallos.

Ya hay parches, pero no solución a corto plazo

Evidentemente, nos encontramos ante una situación que podríamos tildar como rocambolesca. Es complicado repartir culpas en esta situación, pues algunos se decantarán por culpar al creador; otros lo harán contra las empresas por no revisar la librería. El foco, en estos momentos, debe centrarse en poner fin a esta vulnerabilidad, la cual ha sido tildada de máximo riesgo por los centros nacionales de ciberseguridad de todo el mundo. INCIBE y el Centro Criptográfico Nacional, dos referencias en ciberseguridad de España, han hecho lo propio. Ralph Goers, creador de la librería, ya ha puesto a disposición un par de parches para arreglar este desaguisado. Según hemos sabido, lo que hacen es deshabilitar por completo la posibilidad que se pueda enviar esa cadena de código. A pesar de ello, aún hay fallos que corregir en la librería, por lo que poner fin al problema va para largo.