DevSecOps: los viejos fallos de seguridad siguen realizando nuevos trucos

Publicado originalmente en DevOps.com.

En ciberseguridad, a menudo actuamos como cazadores. Mantenemos la vista fija en el horizonte, buscando la próxima vulnerabilidad emergente (junto con las herramientas, técnicas y tácticas de diseño adecuadas para detenerla). Sin embargo, este enfoque prospectivo puede tener el efecto sorprendente de reducir nuestra conciencia de seguridad general, cegándonos ante peligros profundamente arraigados que existen a nuestro alrededor y que los atacantes aprovechan con gusto.

A menudo comparo la ciberseguridad moderna con un chaleco de Kevlar. Las propiedades aparentemente etéreas del Kevlar pueden bloquear proyectiles de alta velocidad y todo tipo de armamento moderno y potente. Incluso puede hacer que quien lo lleva se sienta invencible. Sin embargo, un sistema de armas comparativamente antiguo, como el arco y la flecha, creado 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 después de las piedras, puede cortar el Kevlar tan fácilmente como si fuera una sudadera de algodón. Y luego está el pequeño detalle de que el Kevlar no puede proteger cada milímetro del cuerpo humano. Si un atacante encuentra cualquier brecha para lanzar un golpe dañino, lo hará, al igual que ocurre con las pequeñas áreas explotables en el software.

En ciberseguridad, muchas organizaciones son igualmente vulnerables a fallos en sistemas de ocho o diez años de antigüedad, los cuales, en términos de informática moderna, casi merecen una jubilación. Pero si cree que los fallos en estos sistemas antiguos son inofensivos, probablemente le espere algún que otro pantallazo azul de la muerte.

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 en todo, desde el manejo de eventos hasta el recorrido y manipulación del árbol DOM y la generación de animaciones. Es un caballo de batalla muy fiable que se ha utilizado durante muchos años. La gente asume que, al ser una biblioteca tan consolidada, debe haber sido completamente examinada y cualquier vulnerabilidad eliminada.

Lamentablemente, este no es el caso. Por defecto, la mayoría de las aplicaciones que dependen de jQuery utilizan las instrucciones de la biblioteca interna para la autenticación. Por ejemplo, en servidores Apache, esto significa comprobar los archivos .htaccess. Pocos desarrolladores que diseñan programas que utilizan Apache pensaron probablemente en asegurarse de que las actualizaciones del servidor Apache incluyeran .htaccess. Después de todo, ¿por qué Apache eliminaría ese componente crítico, que ha sido un pilar 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. Al parecer, tener que comprobar los archivos de configuración .htaccess cada vez que un programa necesitaba ejecutarse ralentizaba demasiado el proceso. 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 molestaban en comprobar si sus aplicaciones aún podían acceder a los archivos .htaccess, la mayoría de las solicitudes se aceptaban simplemente sin escrutinio.

Recientemente, los expertos descubrieron ese fallo y señalaron que utilizarlo 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 designada como CVE-2018-9206 en octubre. Pero la facilidad con la que un investigador de seguridad descubrió el fallo implica que los hackers profesionales, cuyo único objetivo es buscar vulnerabilidades como esta, probablemente ya lo hayan descubierto. Después de todo, a pesar de la publicidad, los parches y las correcciones posteriores, un ataque de alto impacto similar ocurrió solo unas semanas después, en el que se liberó un malware para robar Bitcoin en una popular biblioteca 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 nombre servicial, tiene sentido que Jenkins sea utilizado como servidor de automatización por equipos de desarrollo en muchas industrias. Cuando Jenkins funciona correctamente, es una herramienta extremadamente útil. Sin embargo, los fallos recién descubiertos y una operación de criptominería recientemente detectada que es verdaderamente masiva en escala, sugieren que Jenkins también estaba haciendo mucho trabajo 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 enviar dos solicitudes. La primera inicia un canal bidireccional para la descarga que es rechazado inicialmente por el servidor. Sin embargo, la segunda solicitud añade un canal de carga que contiene una carga útil con los comandos que el atacante desee y utiliza el script payload.jar. Una vez enviada la segunda solicitud, la comunicación se permite en servidores Jenkins sin parches.

Incluso en servidores parcheados, existen exploits. Por ejemplo, al ejecutar Jenkins en un entorno Windows, por defecto utiliza la cuenta NT AUTHORITY\SYSTEM para autorizar a los usuarios. Esto es peligroso porque SYSTEM tiene permisos totales en los servidores Windows. Los desarrolladores pueden cambiar la cuenta de autoridad, pero a menudo 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 cualquier vulnerabilidad ha sido parcheada hace mucho tiempo.

Más recientemente, un hacker utilizó estas vulnerabilidades antiguas de Jenkins para comprometer varios servidores. El objetivo era añadir un programa de criptominería en cada instancia vulnerable de Jenkins que pudieran encontrar. Los mineros consumían valiosos recursos informáticos en su búsqueda constante de criptomonedas. Hasta ahora, han encontrado aproximadamente 10 800 criptomonedas Monero, con un valor de casi 3,5 millones de dólares.

Lo viejo vuelve a ser nuevo

En ambos ejemplos, las vulnerabilidades están siendo explotadas por atacantes oportunistas en plataformas que muchas personas consideran seguras. En el lado defensivo, la falta de desarrollo consciente de la seguridad está permitiendo a estos hackers dar nueva vida a viejos trucos. Y a pesar de una nueva ronda de éxitos utilizando vulnerabilidades antiguas, muchas organizaciones no tienen un plan para detener este círculo vicioso.

Que algo sea antiguo no significa que sea inofensivo. Y que las bibliotecas y recursos comunes existan desde hace años no significa que sean completamente seguros (por ejemplo, la entrada n.º 9 en el top 10 actual de OWASP está dedicada a tratar el uso de componentes con vulnerabilidades conocidas). Solo mediante la diligencia y la formación constante en seguridad podemos protegernos no solo de las amenazas peligrosas que acechan en el horizonte, sino también de aquellas que ya se han instalado insidiosamente en nuestro propio patio trasero.