OWASP Top Ten 2017 (es)
A9:2017-Uso de Componentes con vulnerabilidades conocidas |
Languages: en de [es] |
Agente de amenaza / Vector de ataque | Debilidades de seguridad | Impacto | |||
---|---|---|---|---|---|
Específico de la Apl. |
Explotabilidad: 2 | Prevalencia: 3 | Detectabilidad: 2 | Técnico: 2 | ¿Negocio? |
Es sencillo obtener exploits para vulnerabilidades ya conocidas pero la
explotación de otras requieren un esfuerzo considerable, para su
desarrollo y/o personalización. |
Este tipo de defecto está muy difundidos. El desarrollo
fuertemente basado en componentes de terceros, puede llevar a que los
desarrolladores no entiendan qué componentes se utilizan en la
aplicación o API y, mucho menos, mantenerlos actualizados. Algunos analizadores como retire.js ayudan en la detección, pero para determinar explotabilidad se requiere esfuerzo adicional. |
Mientras que ciertas vulnerabilidades conocidas conllevan impactos
menores, algunas de las mayores brechas registradas han sido
realizadas explotando vulnerabilidades conocidas en componentes comunes. Dependiendo del activo que esté protegiendo, este riesgo podría incluso estar de primero en la lista. |
¿La aplicación es vulnerable?
Es potencialmente vulnerable si: * No conoce las versiones de todos los componentes que utiliza (tanto del lado del cliente como del servidor). Esto incluye componentes utilizados directamente como sus dependencias anidadas. * El software es vulnerable, no posee soporte o se encuentra desactualizado. Esto incluye el sistema operativo, servidor web o de aplicaciones, DBMS, APIs y todos los componentes, ambientes de ejecución y bibliotecas. * No analizan los componentes periódicamente ni realiza seguimiento de los boletines de seguridad de los componentes utilizados. * No parchea o actualiza la plataforma subyacente, marcos de trabajo ni dependencias, con un enfoque basado en riesgos. Esto sucede comúnmente en ambientes en los cuales la aplicación de parches se realiza de forma mensual o trimestral bajo control de cambios, lo que deja a la organización abierta innecesariamente a varios días o meses de exposición a vulnerabilidades ya solucionadas. * Si los desarrolladores no prueban la compatibilidad de bibliotecas parchadas, renovadas o actualizadas. * No asegura la configuración de los componentes correctamente (vea A6:2017-Configuración de Seguridad Incorrecta). |
Cómo se previene
Debe haber un proceso para gestión de parches instalado para: * Remover dependencias, funcionalidades, componentes, archivos y documentación innecesaria y no utilizada. * Utilizar una herramienta para mantener un inventario de versiones de componentes (por ej. marcos de trabajo o bibliotecas) tanto del cliente como del servidor. Por ejemplo versions, DependencyCheck, retire.js, etc. Monitorear continuamente fuentes como CVE y NVD en busca de vulnerabilidades en los componentes. Usar herramientas de composición de software para automatizar el proceso. Suscribirse a alertas de correo sobre vulnerabilidades de seguridad relacionadas con los componentes que usa. * Obtener componentes únicamente de orígenes oficiales utilizando canales seguros. Utilizar preferentemente paquetes firmados con el fin de reducir las probabilidades de uso de versiones manipuladas maliciosamente. * Monitorear bibliotecas y componentes sin mantenimiento o que no liberan parches de seguridad para sus versiones antiguas. Si el parcheo no es posible, considere desplegar un virtual patch para monitorear, detectar o protegerse contra la debilidad detectada. Cada organización debe asegurar la existencia de un plan para monitorear, evaluar y aplicar actualizaciones o cambios de configuraciones durante el ciclo de vida de las aplicaciones o el portafolio. |
Ejemplos de escenarios de ataque
Escenario #1: típicamente, los componentes se ejecutan con
los mismos privilegios de la aplicación que los contienen y, como
consecuencia, las fallas en éstos pueden resultar en impactos
serios. Estas fallas pueden ser accidentales (por ejemplo,
errores de codificación) o intencionales (una puerta trasera en
un componente). Algunos ejemplos de vulnerabilidades en
componentes explotables son: * CVE-2017-5638, una ejecución remota de código en Struts 2 que ha sido culpada de grandes brechas de datos. * Aunque frecuentemente los dispositivos internet of things (IoT) son imposibles o muy difíciles de actualizar, la importancia de éstas actualizaciones puede ser enorme (por ejemplo en dispositivos biomédicos). Existen herramientas automatizadas que ayudan a los atacantes a descubrir sistemas mal configurados o desactualizados. A modo de ejemplo, el motor de búsqueda Shodan le ayuda a descubrir dispositivos que aún sufren la vulnerabilidad Heartbleed, la cual fue parcheada en abril del 2014. |
Referencias
OWASP
* OWASP Application Security Verification Standard: V1 Architecture, design and threat modelling * OWASP Dependency Check (for Java and .NET libraries) * OWASP Testing Guide - Map Application Architecture (OTG-INFO-010) * OWASP Virtual Patching Best Practices Externos * The Unfortunate Reality of Insecure Libraries * MITRE Common Vulnerabilities and Exposures (CVE) search * National Vulnerability Database (NVD) * Retire.js for detecting known vulnerable JavaScript libraries * Node Libraries Security Advisories * Ruby Libraries Security Advisory Database and Tools |