A05:2021 – Configuración de Seguridad Incorrecta

Configuración de seguridad

Resumen

Pasando del puesto #6 en la edición anterior, el 90% de las aplicaciones fueron evaluadas por alguna forma de mala configuración, con una tasa de incidencia promedio del 4% y más de 208k ocurrencias de una Enumeración de Debilidades Comunes (CWE) en esta categoría de riesgo. Con el aumento del uso de software altamente configurable, no es sorprendente ver que esta categoría haya subido en el ranking. Las CWEs notables incluyen CWE-16 Configuración y CWE-611 Restricción Incorrecta de Referencia de Entidad Externa XML.

Descripción

La aplicación podría ser vulnerable si:

  • Falta endurecimiento de seguridad apropiado en cualquier parte de la pila de la aplicación o permisos configurados incorrectamente en servicios en la nube.
  • Se encuentran habilitadas o instaladas características innecesarias (por ejemplo, puertos, servicios, páginas, cuentas o privilegios innecesarios).
  • Las cuentas predeterminadas y sus contraseñas siguen habilitadas e inalteradas.
  • El manejo de errores revela trazas de pila u otros mensajes de error excesivamente informativos a los usuarios.
  • En los sistemas actualizados, las últimas características de seguridad están deshabilitadas o no configuradas de manera segura.
  • Las configuraciones de seguridad en los servidores de aplicaciones, marcos de aplicación (por ejemplo, Struts, Spring, ASP.NET), bibliotecas, bases de datos, etc., no están establecidas en valores seguros.
  • El servidor no envía encabezados o directivas de seguridad, o no están establecidos en valores seguros.
  • El software está desactualizado o vulnerable (ver A06:2021 – Componentes Vulnerables y Obsoletos).

Sin un proceso de configuración de seguridad de aplicaciones concertado y repetible, los sistemas están en mayor riesgo.

Cómo prevenir

Implementar procesos de instalación segura, incluyendo:

  • Un proceso de endurecimiento repetible que facilite y acelere el despliegue de otro entorno que esté adecuadamente asegurado. Los entornos de desarrollo, QA y producción deben configurarse de manera idéntica, utilizando credenciales diferentes en cada entorno. Este proceso debe ser automatizado para minimizar el esfuerzo requerido para configurar un nuevo entorno seguro.
  • Una plataforma mínima sin características, componentes, documentación y muestras innecesarias. Eliminar o no instalar características y marcos no utilizados.
  • Una tarea para revisar y actualizar las configuraciones de acuerdo con todas las notas de seguridad, actualizaciones y parches como parte del proceso de gestión de parches (ver A06:2021 – Componentes Vulnerables y Obsoletos). Revisar los permisos de almacenamiento en la nube (por ejemplo, permisos de cubos S3).
  • Una arquitectura de aplicación segmentada que proporcione una separación efectiva y segura entre componentes o inquilinos, utilizando segmentación, contenedorización o grupos de seguridad en la nube (ACLs).
  • Enviar 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 ataques

Escenario #1: El servidor de aplicaciones viene con aplicaciones de muestra que no se eliminaron del servidor de producción. Estas aplicaciones de muestra tienen fallos de seguridad conocidos que los atacantes utilizan para comprometer el servidor. Supongamos que una de estas aplicaciones es la consola de administración y las cuentas predeterminadas no se cambiaron. En este caso, el atacante inicia sesión con las contraseñas predeterminadas y toma el control.

Escenario #2: La lista de directorios no está desactivada en el servidor. Un atacante descubre que puede listar directorios fácilmente. El atacante encuentra y descarga las clases Java compiladas, que luego descompila e ingresa al código para visualizarlo. Posteriormente, el atacante encuentra un grave fallo de control de acceso en la aplicación.

Escenario #3: La configuración del servidor de aplicaciones permite que se devuelvan mensajes de error detallados, por ejemplo, trazas de pila, a los usuarios. Esto puede exponer información sensible o fallos subyacentes, como versiones de componentes que son conocidas por ser vulnerables.

Escenario #4: Un proveedor de servicios en la nube (CSP) tiene permisos de compartición predeterminados abiertos a Internet por otros usuarios del CSP. Esto permite que los datos sensibles almacenados en el almacenamiento en la nube sean accedidos.

Referencias