Las vulnerabilidades de código abierto afectaron a Equifax. ¿Cómo puedes protegerte?

Equifax, un gigante del monitoreo de crédito, reveló la semana pasada que sufrió una filtración que expuso datos sumamente personales de 143 millones de personas, y afirmó que la causa principal fue una vulnerabilidad en Apache Struts, una biblioteca de Java muy popular. La empresa manejó mal su respuesta al ataque, y mantener nuestros datos seguros es su responsabilidad. Sin embargo, no es ni mucho menos la única organización expuesta a vulnerabilidades de Struts u otras bibliotecas de código abierto.

Es probable que Equifax haya sido vulnerada mediante la vulnerabilidad trivial de explotar de ejecución remota de comandos (RCE) divulgada en marzo pasado o mediante la nueva vulnerabilidad RCE de la semana pasada, que es casi igual de grave. A pesar de la considerable atención que han recibido estos problemas, quienes usan estos paquetes tardan muchísimo en solucionarlos.

Analizamos alrededor de 1,000 proyectos de código abierto en GitHub que dependen directamente de Struts y descubrimos que el 64 % aún es vulnerable a la grave vulnerabilidad de marzo. Prácticamente todos son vulnerables a la falla divulgada la semana pasada. Por otra parte, al analizar los miles de proyectos de Java examinados por Snyk, vimos que el 78 % era vulnerable a la RCE de marzo al momento del primer análisis, y que el 100 % era vulnerable al problema de la semana pasada (posteriormente, alertamos a los usuarios y los ayudamos a solucionar estos problemas).

El riesgo que representan estas vulnerabilidades no es teórico: son una amenaza real e inmediata. Tras la divulgación de la RCE de Struts en marzo, vimos una cantidad considerable y creciente de ataques activos que aprovechaban esta falla de seguridad conocida y fácil de explotar. Del mismo modo, la vulnerabilidad divulgada la semana pasada está provocando grandes oleadas de ataques.

¿Quién tiene la responsabilidad?

Las filtraciones suelen dar lugar a una serie de acusaciones, en las que cada entidad involucrada intenta culpar a otra por el desastre. Por desgracia, la responsabilidad por la seguridad del código abierto es un tema complicado…

En este caso, es fácil culpar a Apache Struts.

Durante la última década, se divulgaron más de 40 vulnerabilidades en Apache Struts, incluidas algunas graves, como los problemas de RCE mencionados antes. Esto podría hacerte pensar que Struts es una biblioteca insegura, pero nada más lejos de la realidad. De hecho, su equipo respondió con rapidez y responsabilidad a los problemas detectados y, a diferencia de muchos proyectos de código abierto, se tomó el trabajo de adaptar correcciones importantes a versiones anteriores del software que recibían menos mantenimiento. Apache publicó una respuesta bien redactada sobre el incidente de Equifax.

Los siguientes a quienes culpar son los desarrolladores de Equifax que crearon el portal vulnerado.

Eligieron usar una biblioteca de código abierto de terceros sin verificar si tenía vulnerabilidades conocidas ni monitorearla con el tiempo, lo que terminó en un desastre. Sin duda, estos desarrolladores tienen responsabilidad, ya que crear software seguro forma parte de su trabajo. Sin embargo, es importante recordar que los desarrolladores no son expertos en seguridad y que muchos desconocen los riesgos de usar una biblioteca de código abierto. Además, en las grandes organizaciones como Equifax, a menudo los desarrolladores no tienen la autonomía necesaria para «pensar fuera de lo establecido» y asumir la responsabilidad de más de lo que se les pidió explícitamente.

Si nos atenemos a las responsabilidades formales, la culpa recae en el equipo de seguridad de Equifax.

A ellos se les asignó formalmente la tarea de proteger sus sistemas, y está claro que no lo lograron. Aunque no cabe duda de que fallaron, si el equipo de seguridad de Equifax es como cualquier otro que he visto, probablemente no cuenta con las condiciones necesarias para proteger las aplicaciones de la empresa. A menudo, los equipos de seguridad tienen 100 desarrolladores por cada integrante y, sencillamente, no pueden seguir el ritmo del desarrollo de software moderno, que estas mismas bibliotecas de código abierto aceleran aún más. Si el equipo de seguridad es el único responsable de gestionar la seguridad, una filtración grave es prácticamente inevitable.

Lo que nos lleva al último responsable de este fiasco: el equipo directivo de Equifax.

Sus integrantes son los custodios morales y legales de nuestros datos personales, y deciden cuánto invertir en protegerlos, incluso a costa de las ganancias y el crecimiento. También son responsables de lograr que toda la empresa se preocupe por la seguridad, en lugar de limitar esa responsabilidad a un equipo pequeño. Por último, deben entender que adoptar prácticas modernas de desarrollo, como el uso de bibliotecas de código abierto, también implica nuevos riesgos, y que es necesario gestionarlos bien. No tengo reservas sobre la responsabilidad del equipo directivo, salvo que ninguna organización es invulnerable y que una falla no implica necesariamente negligencia ni incompetencia.

Cómo evitar ser el próximo Equifax

En lugar de enfocarnos en buscar culpables, tomémonos un momento para hablar de cómo puedes evitar que tu empresa se sume a la lista de las peores filtraciones de seguridad. Aquí tienes algunas sugerencias para protegerte, ahora y de forma continua.

1. Haz pruebas. Analiza tus aplicaciones con una herramienta de seguridad de código abierto que detecte bibliotecas vulnerables, incluidas las que tienen las RCE de Struts, y asegúrate de probar todas tus aplicaciones.

2. Soluciona los problemas que encuentres. Dejar de mirar para otro lado y detectar las bibliotecas vulnerables es un primer paso necesario, pero si no solucionas los problemas que encuentras, sigues igual de expuesto. No te limites a registrar las vulnerabilidades como problemas: corrígelas.

3. Monitorea las vulnerabilidades de las bibliotecas que usas. Está muy bien analizar ahora tus bibliotecas en busca de vulnerabilidades, pero puedes tener la certeza de que mañana se encontrarán nuevas, como acabamos de ver con Struts. Configura alertas para recibir avisos sobre vulnerabilidades recién divulgadas y poder solucionarlas antes de que los atacantes las aprovechen.

4. Encuentra herramientas de seguridad que los desarrolladores puedan usar. Tu equipo de seguridad no puede escalar al mismo ritmo, y los desarrolladores necesitan herramientas distintas a las de los especialistas en seguridad. Encuentra herramientas de seguridad que les gusten a los desarrolladores y logra que tus equipos de desarrollo las usen. Al igual que hicimos con DevOps, necesitamos que más personas asuman la responsabilidad de la seguridad (lo que suele llamarse DevSecOps).

Si no sabes por dónde empezar con todo esto, empieza con un análisis usando la CLI de Snyk o su integración con GitHub. Está claro que no soy imparcial al recomendarlo, pero, como mínimo, el plan gratuito de Snyk detectará los problemas en tus aplicaciones y te ayudará a empezar a solucionarlos. Si no quieres usar Snyk, busca otra herramienta, pero haz algo al respecto antes de que el problema te explote en la cara.

Este no es un problema de Struts

Por último, cabe señalar que este problema no se limita a Struts ni al sistema Java Maven. Tan solo el mes pasado se divulgó una vulnerabilidad de ejecución arbitraria de código en el popular paquete de npm para Node.js pg, así como una vulnerabilidad de cross-site scripting en el framework de Python django.

El mes anterior se divulgaron vulnerabilidades como una XSS en Spark Core, una popular plataforma de macrodatos basada en Java, y se descubrieron decenas de paquetes maliciosos en el registro de npm. Estudios realizados a principios de este año muestran que el 77 % de los sitios web usan una biblioteca de JS vulnerable en su página de inicio.

Las estadísticas no dejan de acumularse. En resumen, hoy en día es imprescindible rastrear y corregir las vulnerabilidades de las bibliotecas de código abierto que usas, y la única forma de abordarlo de verdad es integrarlo en tu proceso de desarrollo. Si necesitas consejos para empezar, escríbenos y te ayudaremos. Pero, hagas lo que hagas, aprende del error de Equifax y no bajes la guardia.