Resumen
Fue el #2 en la encuesta de la comunidad de Top 10, pero también tuvo suficientes datos para ingresar al Top 10 a través de datos. Los Componentes Vulnerables son un problema conocido con el que luchamos para probar y evaluar riesgos, y es la única categoría que no tiene ninguna Exposición y Vulnerabilidad Común (CVE) mapeada a las CWEs incluidas, por lo que se utiliza un peso de explotación/impacto por defecto de 5.0. Las CWEs notables incluyen CWE-1104: Uso de Componentes de Terceros No Mantenidos y las dos CWEs de Top 10 2013 y 2017.
Descripción
Es probable que seas vulnerable si:
- No conoces las versiones de todos los componentes que usas (tanto del lado del cliente como del servidor). Esto incluye los componentes que utilizas directamente así como las dependencias anidadas.
- El software es vulnerable, no está soportado o está desactualizado. Esto incluye el sistema operativo, el servidor web/aplicación, el sistema de gestión de bases de datos (DBMS), aplicaciones, APIs y todos los componentes, entornos de ejecución y bibliotecas.
- No escaneas regularmente en busca de vulnerabilidades y no estás suscrito a boletines de seguridad relacionados con los componentes que usas.
- No arreglas ni actualizas la plataforma subyacente, los marcos de trabajo y las dependencias de manera oportuna y basada en el riesgo. Esto comúnmente sucede en entornos donde el parcheo es una tarea mensual o trimestral bajo control de cambios, dejando a las organizaciones expuestas innecesariamente a vulnerabilidades solucionadas durante días o meses.
- Los desarrolladores de software no prueban la compatibilidad de las bibliotecas actualizadas, actualizadas o parcheadas.
- No aseguras las configuraciones de los componentes (ver A05:2021 - Configuración de Seguridad).
Cómo prevenir
Debería haber un proceso de gestión de parches en su lugar para:
- Eliminar dependencias no utilizadas, características innecesarias, componentes, archivos y documentación.
- Inventariar continuamente las versiones de componentes tanto del lado del cliente como del servidor (por ejemplo, marcos de trabajo, bibliotecas) y sus dependencias usando herramientas como versiones, OWASP Dependency Check, retire.js, etc. Monitorear continuamente fuentes como Common Vulnerability and Exposures (CVE) y National Vulnerability Database (NVD) para detectar vulnerabilidades en los componentes. Usar herramientas de análisis de composición de software para automatizar el proceso. Suscribirse a alertas por correo electrónico para vulnerabilidades de seguridad relacionadas con los componentes que usa.
- Obtener componentes únicamente de fuentes oficiales a través de enlaces seguros. Preferir paquetes firmados para reducir la posibilidad de incluir un componente modificado o malicioso (ver A08:2021 - Fallos en la Integridad del Software y los Datos).
- Monitorear las bibliotecas y componentes que no se mantienen o que no crean parches de seguridad para versiones anteriores. Si el parcheo no es posible, considerar implementar un parche virtual para monitorear, detectar o proteger contra el problema descubierto.
Cada organización debe asegurar un plan continuo para monitorear, clasificar y aplicar actualizaciones o cambios de configuración durante toda la vida útil de la aplicación o el portafolio.
Ejemplos de ataques
Escenario #1: Los componentes suelen ejecutarse con los mismos privilegios que la propia aplicación, por lo que los fallos en cualquier componente pueden tener un impacto serio. Estos fallos pueden ser accidentales (por ejemplo, errores de codificación) o intencionales (por ejemplo, una puerta trasera en un componente). Algunos ejemplos de vulnerabilidades explotables en componentes descubiertas son:
- CVE-2017-5638, una vulnerabilidad de ejecución remota de código en Struts 2 que permite la ejecución de código arbitrario en el servidor, ha sido responsable de brechas significativas.
- Aunque el Internet de las Cosas (IoT) suele ser difícil o imposible de parchear, la importancia de parchearlos puede ser alta (por ejemplo, dispositivos biomédicos).
Existen herramientas automatizadas para ayudar a los atacantes a encontrar sistemas no parcheados o mal configurados. Por ejemplo, el motor de búsqueda IoT Shodan puede ayudarte a encontrar dispositivos que aún sufren de la vulnerabilidad Heartbleed, parcheada en abril de 2014.
Referencias
- OWASP Application Security Verification Standard: V1 - Arquitectura, diseño y modelado de amenazas.
- OWASP Dependency Check (para bibliotecas Java y .NET).
- OWASP Testing Guide - Mapeo de la Arquitectura de la Aplicación (OTG-INFO-010).
- OWASP Virtual Patching Best Practices.
- The Unfortunate Reality of Insecure Libraries.
- MITRE Common Vulnerabilities and Exposures (CVE) - búsqueda.
- National Vulnerability Database (NVD).
- Retire.js para detectar bibliotecas JavaScript vulnerables conocidas.
- GitHub Advisory Database.
- Ruby Libraries Security Advisory Database and Tools.
- SAFECode Software Integrity Controls [PDF].