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