Buenas prácticas de desarrollo seguro: A9 – Uso de componentes con vulnerabilidades conocidas

Al momento de desarrollar, el uso de componentes con vulnerabilidades conocidas llega a convertirse en un problema tan recurrente, que es considerado en la lista top 10 de OWASP. En el noveno artículo repasamos en qué consiste y cómo evitar esta vulnerabilidad. La firma de abogados panameña, Mossack Fonseca (MF), cerró sus puertas en marzo […]

Al momento de desarrollar, el uso de componentes con vulnerabilidades conocidas llega a convertirse en un problema tan recurrente, que es considerado en la lista top 10 de OWASP. En el noveno artículo repasamos en qué consiste y cómo evitar esta vulnerabilidad.

La firma de abogados panameña, Mossack Fonseca (MF), cerró sus puertas en marzo de 2018. El motivo se remonta a 2015, cuando la cadena de seguridad de la información de esta firma fue rota. Se filtraron los documentos confidenciales entre MF y sus clientes. Esta fuga de datos fue mundialmente conocida como “Los Panama Papers”. Mientras los principales medios de comunicación se centraron en un escándalo internacional de evasión de impuestos a empresas y celebridades, el foco de la seguridad de la información estaba en uno de los data breaches más grandes y dramáticos de la historia.

Desde Mossack Fonseca se filtraron 2.6 TB de datos que comprenden 11.5 millones de documentos sobre información de clientes / abogados para más de 214,000 entidades offshore. ¿Cómo fue posible, para los hacktivistas (o más bien, leaktivistas), acceder y exfiltrar toda esa información? Si bien las barreras de seguridad de MF tenían más agujeros que un queso suizo, la puerta de entrada la proveyó el uso de aplicaciones que tenían vulnerabilidades conocidas, que ya habían sido solucionados por los desarrolladores, pero MF nunca aplicó las actualizaciones de seguridad necesarias.

MF tenía dos websites: El principal, que corría en WordPress, y un portal para intercambiar información con clientes, que corría en Drupal. Ambas versiones estaban desactualizadas.

En el caso del sitio en WordPress, había un plugin para simplificar el diseño web, Revolution Slider, que habría permitido al atacante obtener una shell en el servidor web.

En el caso del sitio en Drupal, la versión que ocupaban tenía más de 23 vulnerabilidades conocidas! En ambos casos, incorporar componentes con vulnerabilidades ya conocidas permitió acceder, escalar privilegios y los posteriores movimientos laterales dentro de la infraestructura de resguardo de documentación extremadamente confidencial.

Lo cierto es que este tipo de fallas no son aisladas. Si consideramos, por ejemplo, dos componentes de software bastante conocidos y ampliamente ocupados por mucho tiempo, y que resultaron tener fallas:

Biblioteca de OpenSSL: es un componente de software que se usa a menudo para ayudar a proteger los datos utilizados por las aplicaciones web. En 2014, el error Heartbleed fue descubierto en OpenSSL. Este error permitió que los datos cifrados con las rutinas SSL / TLS en OpenSSL se vieran comprometidos. Ya ha sido arreglado. ¡Actualiza tu OpenSSL si aún no lo has hecho!

BASH shell de Unix: se descubrió en 2014 que el venerable shell BASH, que ha estado en uso durante dos décadas, tenía vulnerabilidades que permitían que las inyecciones de línea de comandos ejecutaran comandos. Estos fueron apodados Shellshock. La cáscara de BASH desde entonces ha sido parcheada para abordar los problemas. Actualiza BASH si no lo has hecho recientemente.

Estos ejemplos se proporcionan para ilustrar que incluso el software que ha estado en uso durante mucho tiempo puede contener vulnerabilidades. Todo el software tiene el potencial de albergar fallas. Pues bien, al incorporar al desarrollo software de terceros, componentes externos, incrementamos la posibilidad de que nuestro propio desarrollo contenga vulnerabilidades, y hay una fuerte tendencia a utilizan componentes preexistentes en lugar de codificar las aplicaciones web completamente desde cero. Aun más así, si consideramos los ritmos de producción muy sobrecargados, donde, bajo presión para entregar a la velocidad, estos componentes no se revisan lo suficiente antes de su uso. El resultado puede ser nuevos sitios web y aplicaciones con vulnerabilidades profundamente incrustadas desconocidas para el operador de la aplicación.

Dado que las bibliotecas existen, los scripts a menudo se usan sin ser revisados y se tratan sin ninguna conciencia de que pueden introducir una vulnerabilidad en la aplicación. Por supuesto, no hay garantía de que ningún componente de una aplicación (de código abierto, propietario o licencia) sea completamente seguro. Los desarrolladores y / o investigadores de seguridad a menudo descubren nuevas vulnerabilidades después de la publicación y emiten parches de seguridad para corregirlas. No todos los componentes recibirán los parches necesarios, pero incluso cuando lo hacen, si el usuario no los aplica, la vulnerabilidad permanece.

Las vulnerabilidades conocidas sin parchear son un riesgo grave. Tan pronto como el desarrollador arregla una vulnerabilidad, su existencia se convierte en conocimiento público. Los cibercriminales se apresuran a desarrollar y utilizar exploits antes de que los usuarios tengan tiempo para parchear las aplicaciones. Este es un problema creciente: Gartner predijo que para 2020, el 99% de las fallas de seguridad explotadas se conocerán desde hace al menos un año. Las bases de datos de seguridad como el Mitre CVE y el NIST NVD recopilan vulnerabilidades de seguridad conocidas públicamente. Proporcionan una manera fácil de ver de un vistazo si una aplicación, API, CMS u otra aplicación o componente tiene vulnerabilidades de seguridad asociadas. Sin embargo, cuando una vulnerabilidad llega a una base de datos pública, la aplicación se debe considerar en riesgo hasta que se actualice.

El uso de componentes con vulnerabilidades conocidas se convierte en una vulnerabilidad en sí cuando proporcionamos privilegios completos a los componentes de la aplicación, como bibliotecas, marcos y otros módulos de software. Si se explota un componente vulnerable, tal ataque puede facilitar la pérdida grave de datos o la toma de control del servidor. Las aplicaciones que utilizan componentes con vulnerabilidades conocidas pueden socavar las defensas de la aplicación y permitir una variedad de posibles ataques e impactos.

Un análisis realizado por Snyk colocó el riesgo como el más desastroso de los 10 principales de OWASP. El uso de componentes con vulnerabilidades conocidas representa el 24% de las infracciones reales conocidas asociadas con el OWASP. Según Veracode, en 2017, el 77% de todas las aplicaciones contenían al menos una vulnerabilidad de seguridad. Esto se aplica especialmente a Java, con más de la mitad de todas las aplicaciones Java que utilizan componentes con vulnerabilidades conocidas. Según el informe de Ponemon de junio de 2018, el 48% de las empresas ha sufrido una violación en los últimos dos años, y el 58% de las involucradas tiene una vulnerabilidad conocida y sin parches. Según Ponemon, el 58% de las violaciones en los últimos dos años involucraron una vulnerabilidad conocida y no parcheada.

¿Cuando está más expuesta una aplicación a ser vulnerable?

Si no conoces las versiones de todos los componentes que usas (tanto del lado del cliente como del lado del servidor). Esto incluye los componentes que usas directamente, así como las dependencias anidadas.

Si el software es vulnerable, no es compatible o está desactualizado. Esto incluye el sistema operativo, el servidor web / de aplicaciones, el sistema de administración de bases de datos (DBMS), las aplicaciones, las API y todos los componentes, los entornos de ejecución y las bibliotecas.

Si no buscas vulnerabilidades con regularidad y ni suscribe a boletines de seguridad relacionados con los componentes que utilizas.

Si no arreglas o actualizas la plataforma, los marcos y las dependencias subyacentes de manera oportuna y basada en el riesgo. Esto ocurre comúnmente en entornos en los que la aplicación de parches es una tarea mensual o trimestral bajo control de cambios, lo que deja a las organizaciones abiertas a muchos días o meses de exposición innecesaria a vulnerabilidades fijas.

Si los desarrolladores de software no prueban la compatibilidad de las bibliotecas actualizadas o parcheadas.

Si no proteges las configuraciones de los componentes

Cómo protegerse contra esta vulnerabilidad.

Debe existir un proceso de administración de parches para:

Elimine las dependencias no utilizadas, las características innecesarias, los componentes, los archivos y la documentación.

Se recomienda hacer un inventario continuo de las versiones de los componentes del lado del cliente y del servidor (por ejemplo, marcos, bibliotecas) y sus dependencias utilizando herramientas como las versiones, DependencyCheck, retire.js, etc.

Es importante revisar continuamente las fuentes como CVE y NVD para detectar vulnerabilidades en los componentes y utilizar herramientas de análisis de composición de software para automatizar el proceso. Es recomendado suscribirse a alertas de correo electrónico para detectar vulnerabilidades de seguridad relacionadas con los componentes que se utilizan.

Los componentes de fuentes oficiales se deben obtener sólo a través de enlaces seguros. PSe deben preferir los paquetes firmados para reducir la posibilidad de incluir un componente modificado y malicioso.

Se deben supervisar las bibliotecas y los componentes que no se mantienen o que no crean parches de seguridad para versiones anteriores.

Cada organización debe asegurarse de que haya un plan en curso para monitorear, realizar triages y aplicar actualizaciones o cambios de configuración durante la vida útil de la aplicación.