Log4jShell ha sido considerada como una de las peores vulnerabilidades de los últimos tiempos
Si una semana es mucho tiempo en política, un mes puede parecer toda una vida en ciberseguridad. Pocos de los que trabajamos en el ámbito de la ciberseguridad a principios de diciembre podíamos predecir lo que se nos venía encima antes de Navidad. Al final, Log4Shell y las subsiguientes vulnerabilidades encontradas en Log4j nos trajeron noches de insomnio. Lo cierto es que la utilidad de registro es tan omnipresente, que las amenazas relacionadas estarán con nosotros durante meses o incluso años.
Pero ese no es el final de la historia. Por desgracia, para los profesionales de la seguridad, sus empleadores y clientes, hay una preocupación mucho más amplia. Hemos sido una de las varias voces autorizadas que han advertido del impacto de los bugs de código abierto en la seguridad del mundo digital. A menos que tomemos medidas pronto, Log4Shell podría ser el comienzo de una tendencia muy poco deseada: una ciberpandemia alimentada por exploits de código abierto.
¿La primera de muchas?
Log4jShell ha sido considerada como una de las peores vulnerabilidades de los últimos tiempos. Su puntuación CVSS de 10,0 refleja un fallo relativamente fácil de explotar, que se encuentra en una herramienta de registro basada en Java casi omnipresente que también puede ser difícil de localizar debido a las dependencias, y que permite la ejecución remota de código. Le siguió en rápida sucesión el descubrimiento de otras cuatro vulnerabilidades en el mismo paquete, de distinto grado de criticidad.
La pregunta es, ¿qué días cero podrían estar al acecho en otras herramientas de código abierto? Tomemos el ejemplo del gigante del código abierto Apache, el administrador de Log4j. Un rápido examen de los proyectos vivos de la Fundación Apache, de los que hay más de 200, revela programas populares como Hadoop y OpenOffice. Recientemente se descubrió un fallo crítico «similar al de Log4Shell» en una popular base de datos SQL de Java conocida como H2.
Log4jShell ha sido considerada como una de las peores vulnerabilidades de los últimos tiempos
El número de vulnerabilidades descubiertas en estas ofertas, y en el software en general, se está disparando. De hecho, 2021 fue un año récord en CVEs, el quinto consecutivo en que esto ocurre. Es más, si utilizamos el análisis del NIST sobre la distribución de la gravedad de CVSS a lo largo del tiempo, vemos un salto significativo a partir de 2016:
El reto de DevOps
El reto del código abierto en particular es la forma en que se utiliza. El software se comió el mundo hace muchos años, y hoy todas las organizaciones funcionan con código. Sin él, la economía global se colapsaría, y la sociedad con ella. Pero eso significa una presión cada vez mayor sobre los desarrolladores para que se apresuren a comercializar los productos, a menudo sin la debida atención a los fallos de seguridad. El impulso post-pandémico de la transformación digital no ha hecho más que acelerar estas tendencias.
Una forma habitual de hacerlo es a través de paquetes de código abierto prediseñados, disponibles en cualquier número de repositorios. Se afirma que, en 2021, los desarrolladores solicitaron más de 2,2 billones de paquetes de código abierto de los cuatro principales ecosistemas: Java, JavaScript, Python y .NET.
El problema es que lo que descargan a veces contiene código defectuoso, introduciendo involuntariamente ciberriesgos por la puerta trasera. También hay razones para decir que la mayoría de las herramientas de código abierto se parchean y actualizan con menos frecuencia que el software comercial, lo que da a los hackers más tiempo para encontrar vulnerabilidades en el código.
Un proveedor ha llegado a afirmar incluso que los hackers introducen proactivamente errores en el código de los repositorios upstream y los explotan antes de que sean descubiertos. Se dice que estos ataques se dispararon un 650% interanual en 2021.
Lo que debe ocurrir en 2022
Las organizaciones no tienen que comprometer el tiempo de obtención de rentabilidad frente a la seguridad. Con el enfoque adecuado, pueden tener código y productos seguros entregados a tiempo.
Aquí algunas sugerencias para conseguirlo:
- Conozca su registro de activos de software, incluidas todas las dependencias: ¿qué software de base de datos se ejecuta detrás de la aplicación X/Y?
- Comprende el riesgo de datos asociado a cada aplicación: ¿sabe realmente cuál podría ser su exposición de datos por aplicación y las posibles consecuencias para el negocio?
- ¿Cuál es la amenaza lateral basada en la brecha de una aplicación? ¿Puede segmentar más su red para reducir el riesgo? ¿Tiene sentido una estrategia de zero trust para reducir las medidas provisionales como la remodelación reactiva de la red?
- Empiece por la izquierda: evalúe proactivamente los repositorios de código al inicio de su proceso de creación para asegurarse de que no está añadiendo vulnerabilidades conocidas a sus aplicaciones. Y asegúrese de que sus herramientas de evaluación pueden comprobar retrospectivamente si se anuncian las vulnerabilidades recién descubiertas.
- Al mover la seguridad hacia la izquierda (anticipar su implementación), incorpore la seguridad automatizada a los canales de DevOps a través de las API para conseguir la mínima fricción y el máximo impacto
- Los equipos de seguridad ya están sobrecargados de trabajo, y la enorme escasez de talento a nivel mundial no augura nada bueno, dado el aumento de las revelaciones de vulnerabilidades, el ciberriesgo y la sobrecarga de herramientas. Existen herramientas gratuitas de evaluación de vulnerabilidades para ayudar a las empresas.
Es probable que este año sea aún más ajetreados que 2021, si es que eso es posible. El panorama de amenazas en torno al código abierto sigue evolucionando, por tanto, abróchense los cinturones y prepárense para el viaje.
Por José de la Cruz, director técnico de Trend Micro Iberia
