OWASP Top Ten 2017 (es)
A6:2017-Configuración de Seguridad incorrecta |
Languages: en de [es] |
Agente de amenaza / Vector de ataque | Debilidades de seguridad | Impacto | |||
---|---|---|---|---|---|
Específico de la Apl. |
Explotabilidad: 3 | Prevalencia: 3 | Detectabilidad: 3 | Técnico: 2 | ¿Negocio? |
Los atacantes a menudo intentarán explotar vulnerabilidades sin parchear
o acceder a cuentas por defecto, páginas no utilizadas, archivos y
directorios desprotegidos, etc. para obtener acceso o conocimiento del
sistema o del negocio. |
Las configuraciones incorrectas de seguridad pueden ocurrir en cualquier
nivel de la pila tecnológica, incluidos los servicios de red,
la plataforma, el servidor web, el servidor de aplicaciones,
la base de datos, marcos de trabajo, el código personalizado y máquinas
virtuales preinstaladas, contenedores, etc.
Los escáneres automatizados son útiles para detectar configuraciones
erróneas, el uso de cuentas o configuraciones predeterminadas,
servicios innecesarios, opciones heredadas, etc |
Los defectos frecuentemente dan a los atacantes acceso no autorizado a
algunos datos o funciones del sistema.
Ocasionalmente, estos errores resultan en un completo compromiso
del sistema.
El impacto al negocio depende de las necesidades de la aplicación y de los
datos. |
¿La aplicación es vulnerable?
La aplicación puede ser vulnerable si: * Falta protección adecuada en cualquier parte de la pila tecnológica, o si quedan permisos mal configurados en los servicios de la nube. * Se encuentran instaladas o habilitadas características innecesarias (ej. puertos, servicios, páginas, cuentas o permisos). * Las cuentas predeterminadas y sus contraseñas siguen activas y sin cambios. * El manejo de errores revela a los usuarios trazas de la aplicación u otros mensajes demasiado informativos. * Para los sistemas actualizados, las nuevas funciones de seguridad se encuentran desactivadas o no se encuentran configuradas de forma adecuada o segura. * Las configuraciones de seguridad en el servidor de aplicaciones, en el marco de trabajo de aplicación (ej., Struts, Spring, ASP.NET), bibliotecas o bases de datos no se encuentran especificados con valores seguros. * El servidor no envía directrices o cabeceras de seguridad a los clientes o se encuentran configurados con valores inseguros. * El software se encuentra desactualizado o posee vulnerabilidades (ver A9: 2017 Uso de componentes con vulnerabilidades conocidas). Sin un proceso de configuración de seguridad de aplicación concertado y repetible, los sistemas corren un mayor riesgo. |
Cómo se previene
Deben implementarse procesos seguros de instalación, incluyendo: * Un proceso de fortalecimiento reproducible que agilice y facilite la implementación de otro entorno asegurado. Los entornos de desarrollo, de control de calidad (QA) y de Producción deben configurarse de manera idéntica y con diferentes credenciales para cada entorno. Este proceso puede automatizarse para minimizar el esfuerzo requerido para configurar cada nuevo entorno seguro. * Use una plataforma minimalista sin funcionalidades innecesarias, componentes, documentación o ejemplos. Elimine o no instale marcos de trabajo y funcionalidades no utilizadas. * Siga un proceso para revisar y actualizar las configuraciones apropiadas de acuerdo a las advertencias de seguridad y siga un proceso de gestión de parches (Ver A9: 2017 Uso de componentes con vulnerabilidades conocidas). En particular, revise los permisos de almacenamiento en la nube (por ejemplo, los permisos de buckets S3). * La aplicación debe tener una arquitectura segmentada que proporcione una separación efectiva y segura entre componentes y acceso a terceros, contenedores o grupos de seguridad en la nube (ACLs). * Envíe directivas de seguridad a los clientes (por ej. cabeceras de seguridad). * Utilice un proceso automatizado para verificar la efectividad de los ajustes y configuraciones en todos los ambientes. |
Ejemplos de escenarios de ataque
Escenario #1: Proceso automatizado para verificar la efectividad de
los ajustes y configuraciones en todos los ambientes. | |
Ejemplos de escenarios de ataque
Escenario #1: el servidor de aplicaciones viene con ejemplos que
no se eliminan del ambiente de producción. Estas aplicaciones
poseen defectos de seguridad conocidos que los atacantes usan
para comprometer el servidor. Si una de estas aplicaciones es la
consola de administración, y las cuentas predeterminadas no se han
cambiado, el atacante puede iniciar una sesión Escenario #2: el listado de directorios se encuentra activado en el servidor y un atacante descubre que puede listar los archivos. El atacante encuentra y descarga las clases de Java compiladas, las descompila, realiza ingeniería inversa y encuentra un defecto en el control de acceso de la aplicación. Escenario #3: la configuración del servidor de aplicaciones permite retornar mensajes de error detallados a los usuarios, por ejemplo, las trazas de pila. Potencialmente esto expone información sensible o fallas subyacentes, tales como versiones de componentes que se sabe que son vulnerables. Escenario #4: un proveedor de servicios en la nube (PSN o CSP) por defecto permite a otros usuarios del PSN acceder a sus archivos desde Internet. Esto permite el acceso a datos sensibles almacenados en la nube. |
Referencias
OWASP
* OWASP Testing Guide: Configuration Management * OWASP Testing Guide: Testing for Error Codes For additional requirements in this area, see the Application Security Verification Standard V19 Configuration. Externos * NIST Guide to General Server Hardening * CWE-2: Environmental Security Flaws * CWE-16: Configuration * CWE-388: Error Handling * CIS Security Configuration Guides/Benchmarks * Amazon S3 Bucket Discovery and Enumeration |