Visión general
Fue el número 2 de la encuesta de la comunidad Top 10, pero también tenía suficientes datos para llegar al Top 10 a través de datos. Los componentes vulnerables son un problema conocido que luchamos para probar y evaluar el riesgo y es la única categoría que no tiene vulnerabilidades y exposiciones comunes (CVE) asignadas a los CWE incluidos, por lo que se utiliza un peso de vulnerabilidad/impacto predeterminado de 5.0. Los CWE notables incluidos son CWE-1104: uso de componentes de terceros no mantenidos y los dos CWE de Top 10 2013 y 2017.
Descripción
Es probable que seas vulnerable:
-
Si no conoce las versiones de todos los componentes que utiliza (tanto del lado del cliente como del lado del servidor). Esto incluye los componentes que usa 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 tiempo de ejecución y las bibliotecas.
-
Si no busca vulnerabilidades con regularidad y se suscribe a los boletines de seguridad relacionados con los componentes que utiliza.
-
Si no corrige o actualiza la plataforma, los marcos y las dependencias subyacentes de manera oportuna y basada en el riesgo. Esto suele ocurrir 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 expuestas a días o meses de exposición innecesaria a vulnerabilidades reparadas.
-
Si los desarrolladores de software no prueban la compatibilidad de las bibliotecas actualizadas, mejoradas o parcheadas.
-
Si no protege las configuraciones de los componentes (consulte ).
Como prevenir
Debe existir un proceso de administración de parches para:
-
Elimine las dependencias no utilizadas, las funciones, los componentes, los archivos y la documentación innecesarios.
-
Haga un inventario continuo de las versiones de los componentes del lado del cliente y del lado del servidor (por ejemplo, marcos, bibliotecas) y sus dependencias utilizando herramientas como versiones, OWASP Dependency Check, retire.js, etc. Monitoree continuamente fuentes como Common Vulnerability and Exposures (CVE) y National Vulnerability Database (NVD) para vulnerabilidades en los componentes. Utilice herramientas de análisis de composición de software para automatizar el proceso. Suscríbase a alertas por correo electrónico sobre vulnerabilidades de seguridad relacionadas con los componentes que utiliza.
-
Solo obtenga componentes de fuentes oficiales a través de enlaces seguros. Prefiera los paquetes firmados para reducir la posibilidad de incluir un componente malicioso modificado (consulte A08:2021: fallas de integridad de datos y software).
-
Supervise las bibliotecas y los componentes que no reciben mantenimiento o que no crean parches de seguridad para versiones anteriores. Si no es posible aplicar parches, considere implementar un parche virtual para monitorear, detectar o proteger contra el problema descubierto.
Cada organización debe garantizar un plan continuo para monitorear, clasificar y aplicar actualizaciones o cambios de configuración durante la vida útil de la aplicación o cartera.
Ejemplos de escenarios de ataque
Escenario n.º 1: los componentes normalmente se ejecutan con los mismos privilegios que la propia aplicación, por lo que las fallas en cualquier componente pueden tener un impacto grave. Dichos defectos pueden ser accidentales (p. ej., un error de codificación) o intencionales (p. ej., una puerta trasera en un componente). Algunos ejemplos de vulnerabilidades de componentes explotables descubiertas son:
-
CVE-2017-5638, una vulnerabilidad de ejecución remota de código de Struts 2 que permite la ejecución de código arbitrario en el servidor, ha sido culpada por infracciones significativas.
-
Si bien el Internet de las cosas (IoT) suele ser difícil o imposible de parchear, la importancia de parchearlos puede ser grande (por ejemplo, dispositivos biomédicos).
Existen herramientas automatizadas para ayudar a los atacantes a encontrar sistemas sin parches o mal configurados. Por ejemplo, el motor de búsqueda de Shodan IoT puede ayudarlo a encontrar dispositivos que aún sufren la vulnerabilidad Heartbleed parcheada en abril de 2014.
Referencias
-
Estándar de verificación de seguridad de aplicaciones OWASP: V1 Arquitectura, diseño y modelado de amenazas
-
Comprobación de dependencias de OWASP (para bibliotecas Java y .NET)
-
Guía de prueba de OWASP: arquitectura de aplicaciones de mapas (OTG-INFO-010)
-
Mejores prácticas de parcheo virtual de OWASP
-
La desafortunada realidad de las bibliotecas inseguras
-
Búsqueda de vulnerabilidades y exposiciones comunes (CVE) de MITRE
-
Base de datos de vulnerabilidad nacional (NVD)
-
Retire.js para detectar bibliotecas JavaScript vulnerables conocidas
-
Avisos de seguridad de bibliotecas de nodos
-
-
https://safecode.org/publication/SAFECode_Software_Integrity_Controls0610.pdf
Lista de CWE mapeados
CWE-937 OWASP Top 10 2013: uso de componentes con vulnerabilidades conocidas
CWE-1035 2017 Top 10 A9: Uso de componentes con vulnerabilidades conocidas
CWE-1104 Uso de componentes de terceros sin mantenimiento
Más información: