A05:2021 – Configuración de Seguridad Incorrecta

Factores

CWEs mapeadas	Tasa de incidencia máx	Tasa de incidencia prom	Explotabilidad ponderada prom	Impacto ponderado prom	Cobertura máx	Cobertura prom	Incidencias totales	Total CVEs
20	19.84%	4.51%	8.12	6.56	89.58%	44.84%	208,387	789

Resumen

Ascendiendo una posición desde el sexto puesto en la edición anterior, el 90% de las aplicaciones se probaron para detectar algún tipo de configuración incorrecta, con una tasa de incidencia promedio del 4,5% y más de 208.000 ocurrencias de CWEs en esta categoría de riesgo. Con mayor presencia de software altamente configurable, no es sorprendente ver que esta categoría ascendiera. Las CWE notables incluidas son CWE-16 Configuración y CWE-611 Restricción incorrecta entidades externas referenciadas de XML.

Descripción

La aplicación puede ser vulnerable si:

Le falta el hardening de seguridad adecuado en cualquier parte del stack tecnológico o permisos configurados incorrectamente en los servicios en la nube.
Tiene funciones innecesarias habilitadas o instaladas (puertos, servicios, páginas, cuentas o privilegios innecesarios, por ejemplo).
Las cuentas predeterminadas y sus contraseñas aún están habilitadas y sin cambios.
El manejo de errores revela a los usuarios rastros de pila u otros mensajes de error demasiado informativos.
Para sistemas actualizados, las últimas funciones de seguridad están deshabilitadas o no configuradas de forma segura.
Las configuraciones de seguridad en los servidores de aplicaciones, frameworks de aplicaciones (Struts, Spring o ASP.NET por ejemplo), bibliotecas, bases de datos, etc., no poseen configurados valores seguros.
El servidor no envía encabezados o directivas de seguridad, o no poseen configurados valores seguros.
El software está desactualizado o es vulnerable (consulte A06:2021-Componentes Vulnerables y Desactualizados).

Sin un proceso de configuración de seguridad de aplicaciones coordinado y repetible, los sistemas corren un mayor riesgo.

Cómo se previene

Deben implementarse procesos de instalación seguros, incluyendo:

Un proceso de hardening repetible agiliza y facilita la implementación de otro entorno que esté debidamente inaccesible. Los entornos de desarrollo, control de calidad y producción deben configurarse de forma idéntica, con diferentes credenciales utilizadas en cada uno. Este proceso debe automatizarse para minimizar el esfuerzo necesario para configurar un nuevo entorno seguro.
Una plataforma mínima sin funciones, componentes, documentación ni ejemplos innecesarios. Elimine o no instale características y frameworks no utilizados.
Una tarea para revisar y actualizar las configuraciones apropiadas para todas las notas de seguridad, actualizaciones y parches como parte del proceso de administración de parches (consulte A06: 2021-Componentes Vulnerables y Desactualizados). Revise los permisos de almacenamiento en la nube (por ejemplo, Permisos de bucket de S3).
Una arquitectura de aplicación segmentada proporciona una separación efectiva y segura entre componentes o instancias, con segmentación, organización en contenedores o grupos de seguridad en la nube (ACLs).
Envío de directivas de seguridad a los clientes, por ejemplo, encabezados de seguridad.
Un proceso automatizado para verificar la efectividad de las configuraciones y ajustes en todos los entornos.

Ejemplos de escenarios de ataque

Escenario #1: El servidor de aplicaciones contiene aplicaciones de ejemplo que no se eliminan del servidor de producción. Estas aplicaciones de ejemplo poseen fallas de seguridad conocidas que los atacantes utilizan para comprometer el servidor. Supongamos que una de estas aplicaciones es la consola de administración y no se modificaron las cuentas predeterminadas. En ese caso, el atacante inicia sesión con las contraseñas predeterminadas y toma el control.

Escenario #2: El listado de directorios no se encuentra deshabilitado en el servidor. Un atacante descubre que simplemente puede enumerar directorios. El atacante detecta y descarga las clases Java compiladas, que decompila y aplica ingeniería inversa para ver el código. El atacante luego encuentra una falla severa de control de acceso en la aplicación.

Escenario #3: La configuración del servidor de aplicaciones permite que se retornen a los usuarios mensajes de error detallados, por ejemplo, trazas de pila(stack traces). Esto potencialmente expone información confidencial o fallas subyacentes, como versiones de componentes que se sabe son vulnerables.

Escenario #4: Un proveedor de servicios en la nube (CSP) posee permisos de uso compartido predeterminados abiertos a Internet a otros usuarios. Esto permite acceder a los datos confidenciales almacenados en el almacenamiento en la nube.