DevSecOps: los viejos errores de seguridad siguen haciendo nuevos trucos

Publicado originalmente el DevOps.com.

En ciberseguridad, a menudo somos como cazadores. Tenemos la vista fija en el horizonte, buscando la próxima vulnerabilidad emergente (junto con las herramientas de diseño, las técnicas y las tácticas adecuadas para detenerla). Sin embargo, este enfoque orientado hacia el futuro puede tener el sorprendente efecto de reducir nuestra conciencia general de seguridad, cegarnos ante los peligros profundamente arraigados que existen por todas partes y que los atacantes están encantados de aprovechar.

A menudo comparo la ciberseguridad moderna con una armadura de Kevlar. Las propiedades aparentemente etéreas del Kevlar pueden bloquear proyectiles de alta velocidad y todo tipo de armamento moderno y poderoso. Incluso puede hacer que quien lo lleve se sienta algo invencible. Sin embargo, un sistema de armas de arco y flecha relativamente antiguo, creado por primera vez alrededor del año 1000 a.C., a menudo puede penetrar esa protección. Un cuchillo afilado, probablemente la segunda arma más antigua del mundo detrás de las rocas, puede cortar el Kevlar con la misma facilidad que si se tratara de triturar una sudadera de algodón. Y además está el pequeño problema de que el Kevlar no es capaz de proteger cada milímetro del cuerpo humano. Si un atacante encuentra algún hueco para asestar un golpe dañino, «le gustarán mucho las áreas pequeñas y explotables del software».

En cuanto a la ciberseguridad, muchas organizaciones son igualmente vulnerables a las fallas en los sistemas que tienen ocho o diez años de antigüedad, lo que, en términos de informática moderna, casi las califica para recibir un reloj de oro y una pensión. Pero si cree que las fallas en estos sistemas antiguos son inofensivas, es probable que tenga una o dos pantallas azules de muerte en el futuro.

Una vulnerabilidad para un veterano

Una de las bibliotecas de JavaScript más antiguas y utilizadas es jQuery, un recurso de código abierto que ayuda con todo, desde la gestión de eventos hasta el recorrido y la manipulación del árbol DOM y la generación de animaciones. Es toda una herramienta y se ha utilizado durante muchos años. La gente asume que, dado que la biblioteca está tan establecida en este momento, debe haber sido examinada por completo y haber eliminado cualquier vulnerabilidad.

Lamentablemente, este no es el caso. De forma predeterminada, la mayoría de las aplicaciones que dependen de jQuery utilizan las instrucciones de la biblioteca interna para la autenticación. Por ejemplo, con los servidores Apache, esto significa revisar los archivos.htaccess. Es probable que pocos desarrolladores que diseñen programas que usen Apache hayan pensado en comprobar que las actualizaciones del servidor Apache incluyeran el archivo.htaccess. Después de todo, ¿por qué eliminaría Apache ese componente crítico, que ha sido la base de la seguridad durante años?

Por extraño que parezca, eso es exactamente lo que hizo Apache en la versión 2.3.9. Aparentemente, tener que revisar los archivos de configuración.htaccess cada vez que era necesario ejecutar un programa estaba ralentizando demasiado las cosas. Eliminarlo mejoró el rendimiento general de Apache, pero también creó una vulnerabilidad que la mayoría de la gente desconocía. Si los desarrolladores no se tomaran la molestia de comprobar si sus aplicaciones aún podían acceder a los archivos.htaccess, la mayoría de las solicitudes simplemente se aceptarían sin ningún tipo de control.

Recientemente, los expertos descubrieron esa falla y señalaron que su uso permitiría a usuarios no autorizados cargar y ejecutar shells o casi cualquier tipo de código en sistemas supuestamente seguros. Esto llevó a la creación de una alerta de vulnerabilidad denominada CVE-2018-9206 en octubre. Sin embargo, la facilidad con la que un investigador de seguridad descubrió la falla implica que los piratas informáticos profesionales, cuyo único objetivo es buscar vulnerabilidades como esta, probablemente ya la hayan descubierto. Al fin y al cabo, a pesar de la publicidad, los parches y las correcciones que generaron las secuelas, tan solo unas semanas después se produjo un ataque similar de gran impacto, en el que Malware que roba bitcoins se lanzó en una popular biblioteca de NPM descargada por millones de personas cada semana.

El mayordomo lo hizo

Al igual que jQuery, Jenkins es una oferta de código abierto y una de las más populares de su tipo. Con su útil nombre similar al de un servidor, tiene sentido que los equipos de desarrollo de muchos sectores utilicen Jenkins como servidor de automatización. Cuando Jenkins funciona correctamente, es una herramienta extremadamente útil. Sin embargo, hay fallas recientemente descubiertas y una operación de criptominería descubierta recientemente eso es realmente enorme en escala, sugiere que Jenkins también estaba trabajando mucho para los malos.

Una de las vulnerabilidades más peligrosas de Jenkins se llama deserialización de Java, que se designa como CVE-2017-1000353. Es un ataque complejo, pero que existe desde hace tiempo. Un atacante debe presentar dos solicitudes. La primera inicia un canal bidireccional de descarga que inicialmente es rechazado por el servidor. Sin embargo, la segunda solicitud añade un canal de carga que contiene una carga útil con los comandos que desee el atacante y utiliza el script payload.jar. Una vez que se envía la segunda solicitud, se permite la comunicación en los servidores Jenkins sin parches.

Incluso en servidores parcheados, existen exploits. Por ejemplo, cuando se ejecuta Jenkins en un entorno Windows, utiliza de forma predeterminada la cuenta NT AUTHORITY\ SYSTEM para autorizar a los usuarios. Esto es peligroso porque SYSTEM tiene todos los permisos en los servidores Windows. Los desarrolladores pueden cambiar la cuenta de autoridad, pero con frecuencia no lo hacen. Su lógica para no hacerlo se basa en el hecho de que Jenkins existe desde siempre, por lo que la gente piensa que las vulnerabilidades se corrigieron hace mucho tiempo.

Más recientemente, un pirata informático utilizó estas antiguas vulnerabilidades de Jenkins para comprometer varios servidores. El objetivo era agregar un programa de minería de criptomonedas en cada instancia vulnerable de Jenkins que pudieran encontrar. Los mineros utilizaron valiosos recursos informáticos en su búsqueda constante de criptomonedas. Hasta ahora, ellos han encontrado aproximadamente 10.800 criptomonedas Monero, con un valor de casi 3,5 millones de dólares.

Lo viejo es nuevo otra vez

En ambos ejemplos, atacantes oportunistas están explotando las vulnerabilidades en plataformas que muchas personas consideran seguras. Desde el punto de vista defensivo, la falta de un desarrollo que tenga en cuenta la seguridad está permitiendo a estos piratas informáticos dar nueva vida a viejos trucos. Y a pesar de una nueva ronda de éxitos que utiliza vulnerabilidades antiguas, muchas organizaciones no tienen ningún plan para detener este círculo vicioso.

El hecho de que algo sea viejo no significa que sea inofensivo. Y el hecho de que las bibliotecas y los recursos comunes hayan existido durante años no significa que sean completamente seguros (por ejemplo, la entrada número 9 en el top 10 actual de OWASP está dedicada a tratar Uso de componentes con vulnerabilidades conocidas). Solo a través de la diligencia y formación de seguridad constante podemos protegernos no solo de las peligrosas amenazas que se vislumbran en el horizonte, sino también de las que ya se han instalado insidiosamente en nuestros propios patios traseros.