DevSecOps: Los viejos errores de seguridad siguen haciendo nuevos trucos

Publicado originalmente en DevOps.com.

En ciberseguridad, a menudo somos como cazadores. Nuestros ojos están firmemente pegados al horizonte, buscando la próxima vulnerabilidad (junto con las herramientas de diseño, técnicas y tácticas adecuadas para detenerla). Sin embargo, este enfoque orientado al futuro puede tener el sorprendente efecto de amortiguar nuestra conciencia de seguridad en general, cegándonos a los peligros más profundos que existen a nuestro alrededor, y que los atacantes están muy contentos de explotar.

A menudo comparo la ciberseguridad moderna con una armadura de Kevlar. Las propiedades aparentemente etéreas del kevlar pueden bloquear balas de alta velocidad y todo tipo de armamento moderno y potente. Incluso puede hacer que el usuario se sienta algo invencible. Sin embargo, un sistema de armas relativamente antiguo, fabricado por primera vez en torno al año 1000 a.C., a menudo puede atravesar esa protección. Un cuchillo afilado, probablemente el segundo arma más antigua del mundo después de las piedras, puede atravesar el Kevlar con la misma facilidad que si se tratara de una sudadera de algodón. Y luego está la pequeña cuestión de que el Kevlar no puede proteger cada milímetro del cuerpo humano. Si un atacante puede encontrar cualquier hueco para asestar un golpe dañino, lo hará "como las pequeñas áreas explotables en el software".

En el ámbito de la ciberseguridad, muchas organizaciones son igualmente vulnerables a los fallos de los sistemas que tienen ocho o diez años de antigüedad, lo que en términos informáticos modernos les da derecho a un reloj de oro y a una pensión. Pero si crees que los fallos en estos sistemas antiguos son inofensivos, entonces probablemente tengas una pantalla azul de la muerte o dos en tu futuro.

Una vulnerabilidad para un veterano

Una de las bibliotecas de JavaScript más antiguas y más utilizadas es jQuery, un recurso de código abierto que ayuda con todo, desde el manejo de eventos, hasta el recorrido y la manipulación del árbol DOM, y la generación de animaciones. Es un caballo de batalla, y se ha utilizado durante muchos años. La gente asume que porque la biblioteca está tan establecida en este punto, que debe haber sido completamente vetada, con 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, con los servidores Apache, esto significa comprobar los archivos .htaccess. Pocos desarrolladores que diseñan programas que usan Apache probablemente pensaron en comprobar que las actualizaciones del servidor Apache incluían el .htaccess. Después de todo, ¿por qué iba Apache a eliminar ese componente crítico, que ha sido un cimiento 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 comprobar los archivos de configuración .htaccess cada vez que un programa necesitaba ejecutarse estaba ralentizando demasiado las cosas. Al eliminarlo, se mejoró el rendimiento general de Apache, pero también se creó una vulnerabilidad que la mayoría de la gente desconocía. Si los desarrolladores no se molestaban en comprobar si sus aplicaciones podían seguir accediendo a los archivos .htaccess, la mayoría de las peticiones se aceptaban sin más.

Recientemente, los expertos descubrieron ese fallo y observaron 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. Pero, la facilidad con la que el fallo fue descubierto por un investigador de seguridad implica que los hackers 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 se produjeron a raíz de este fallo, unas semanas más tarde se produjo un ataque similar de gran impacto, en el que se desató un malware que se dedicaba a robar Bitcoin en una popular librería NPM que descargan millones de personas cada semana.

El mayordomo lo hizo

Al igual que jQuery, Jenkins es una oferta de código abierto, y uno de los más populares de su tipo. Con su útil nombre de servidor, tiene sentido que Jenkins sea utilizado como servidor de automatización por los equipos de desarrollo de muchas industrias. Cuando Jenkins funciona correctamente, es una herramienta extremadamente útil. Sin embargo, las fallas recientemente descubiertas, y una operación de minería de criptomonedas recientemente descubierta que es realmente masiva en escala, sugiere que Jenkins también estaba haciendo mucho trabajo para los malos.

Una de las vulnerabilidades más peligrosas de Jenkins es la llamada deserialización de Java, designada como CVE-2017-1000353. Es un ataque complejo, pero que ha existido durante un tiempo. Un atacante debe enviar dos peticiones. La primera inicia un canal bidireccional de descarga que inicialmente es rechazado por el servidor. Sin embargo, la segunda petición añade un canal de subida que contiene una carga útil con los comandos que el atacante quiera, y utiliza el script payload.jar. Una vez enviada la segunda petición, la comunicación está permitida en los servidores Jenkins no parcheados.

Incluso en servidores parcheados, existen exploits. Por ejemplo, cuando se ejecuta Jenkins en un entorno Windows, por defecto utiliza la cuenta NT AUTHORITY\SYSTEM para autorizar a los usuarios. Esto es peligroso porque a SYSTEM se le conceden todos los permisos 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 ha existido siempre, por lo que la gente piensa que cualquier vulnerabilidad ha sido parcheada hace mucho tiempo.

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

Lo que es viejo es nuevo otra vez

En ambos ejemplos, los atacantes oportunistas explotan las vulnerabilidades de plataformas que muchos 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 ningún plan para detener este círculo vicioso.

El hecho de que algo sea antiguo no significa que sea inofensivo. Y sólo porque las bibliotecas y recursos comunes hayan existido durante años no significa que sean completamente seguros (por ejemplo, la entrada número 9 del actual top 10 de OWASP está dedicada a tratar el tema del Uso de Componentes con Vulnerabilidades Conocidas). Sólo mediante la diligencia y la formación constante en materia de seguridad podremos protegernos no sólo de las peligrosas amenazas que se avecinan, sino también de las que ya se han instalado insidiosamente en nuestros propios patios.