La complejidad intrínseca de la infraestructura de red interconectada y heterogénea, lo cual incluye cientos de aplicaciones web, genera la administración y revisión de la configuración sea un paso fundamental en cada prueba y despliegue de las aplicaciones. Puede ser una vulnerabilidad la cul mine la seguridad completa de la infraestructura, e incluso pequeños problemas y aparentemente sin importancia, pueden evolucionar en severos riesgos para otra aplicación en el mismo servidor. Para abordar estos problemas, es de suma importancia realizar una revisión profunda de la configuración y problemas conocidos de seguridad, después de haber mapeado toda la arquitectura.

La gestión adecuada de la configuración de la infraestructura del servidor web es muy importante para preservar la seguridad de la aplicación. Si elementos tales como el software del servidor web, los servidores de datos backend, o los servidores de autenticación no son adecuadamente revisados y asegurados, podría introducir riesgos indeseables o introducir nuevas vulnerabilidades los cuales podrían comprometer la aplicación.

Por ejemplo una vulnerabilidad del servidor web podría permitir a un atacante remoto exponer el código fuente de la aplicación por si misma (una vulnerabilidad la cual ha surgido varias veces en los servidores web o servidores de aplicaciones), lo cual podría comprometer la aplicación, como usuarios anónimos podrían utilizar la información expuesta en el código fuente para aprovechar los ataques contra la aplicación o usuarios.

Se deben seguir los siguientes pasos para probar la configuración de la gestión de infraestructura.

• Los diferentes elementos constituyendo la infraestructura necesitan ser determinados para entender como interactúan con una aplicación web, y como afectan su seguridad.
• Todos los elementos de la infraestructura necesitan ser revisados para asegurarse no contienen vulnerabilidades conocidas.
• Una revisión necesita ser hecha de las herramientas administrativas utilizadas para mantener todos los diferentes elementos.
• Los sistemas de autenticación necesitan ser revisados para asegurar sirven a las necesidades de la aplicación, y no pueden ser manipulados por los usuarios externos para aprovechar el acceso.
• Una lista de puertos definidos requeridos por la aplicación deben ser mantenidos bajo control de cambios.

Después de haber mapeado los diferentes elementos componiendo la infraestructura, es posible revisar la configuración de cada elemento encontrado, para luego evaluarlo por vulnerabilidades conocidas.

Objetivos de la Prueba

Mapear la infraestructura soportando la aplicación y comprender como afecta la seguridad de la aplicación

Como Evaluar

Vulnerabilidades Conocidas del Servidor

Las vulnerabilidades encontradas en las diferentes áreas de la arquitectura de la aplicación, ya sea en el servidor web o en la base de datos backend, pueden severamente comprometer la aplicación. Por ejemplo considerar una vulnerabilidad la cual permite a un usuario remoto no autenticado subir archivos hacia el servidor o incluso reemplazar archivos. Esta vulnerabilidad podría comprometer la aplicación, pues un usuario maliciosos puede ser capaz de reemplazar la aplicación o introducir código el cual afectaría a los servidores backend, pues el código de aplicación se ejecutaría como cualquier otra aplicación.

Revisar las vulnerabilidades del servidor web puede ser difícil de hacer si la prueba necesita ser hecha a través de una prueba de penetración ciega. En estos casos las vulnerabilidades necesitan ser probadas desde un sitio remoto, típicamente utilizando una herramienta automática. Sin embargo, probar por vulnerabilidades puede tener resultados impredecibles en el servidor web, y probar por otras (como aquellas directamente involucradas en ataques de negación de servicio), podrían no ser posibles, debido al tiempo de inactividad involucrados si la prueba no es exitosa.

Algunas herramientas automáticas marcarán vulnerabilidades basadas en la versión obtenida del servidor web. Esto conduce a falsos positivos o falsos negativos. De otro lado si el proveedor del software no actualiza la versión del servidor cuando se arreglan las vulnerabilidades, la herramienta de escaneo marcará las vulnerabilidades no existentes. Un caso muy común es algunos proveedores de sistemas operativos respaldan parches de vulnerabilidades de seguridad al software proporcionado con el sistema operativo, pero no realizan una carga completo a la versión más reciente del software. Esto ocurre en muchas distribuciones GNU/Linux como Debian, Red Hat o SuSE. En muchos casos, los escaneadores de vulnerabilidades de una arquitectura de una aplicación, solo encontrarán vulnerabilidades asociadas con los elementos “expuestos” de la arquitectura (como el servidor web), y usualmente serán incapaces de encontrar vulnerabilidades asociadas con elementos los cuales no están expuestas directamente, como con backends de autenticación, el backend de base de datos, o proxys reversos utilizados.

Finalmente no todos los proveedores de software exponen las vulnerabilidades de una manera pública, y por lo tanto estas debilidades no se registran dentro de las bases de datos públicas de vulnerabilidades. Esta información es únicamente divulgada hacia los clientes o publicadas a través de arreglos, los cuales no tienen anuncios acompañándolos. Esto reduce la utilidad de las herramientas para el escaneo de vulnerabilidades. Típicamente la cobertura de vulnerabilidades de estas herramientas sería muy buena en productos comunes (como un servidor web Apache, Microsoft IIS, o Lotus Domino de IBM), pero será escaso para productos menos conocidos.

Esto es porque revisar las vulnerabilidades es mejor hecho cuando al profesional se le proporciona información interna del software utilizado, incluyendo versiones y publicaciones utilizados, además de los parches aplicados en el software. Con esta información, el profesional puede obtener información del proveedor, para luego analizar cuales vulnerabilidades podrían estar presenten en la arquitectura, y como estas pueden afectar la aplicación. Cuando es posible estas vulnerabilidades pueden ser evaluadas para determinar sus efectos reales, y para detectar si podrían existir algunos elementos externos (como sistemas para la detección o prevención de intrusiones), los cuales podrían reducir o negar la posibilidad de una explotación exitosa. Los profesionales podrían incluso determinar, a través de una revisión de configuración, la vulnerabilidad no está presente, pues afecta un componente de software no siendo utilizado.

También es importante considerar, los proveedores algunas veces arreglan silenciosamente las vulnerabilidades, y hacen los arreglos disponibles con nuevas publicaciones del software. Diferentes proveedores podrían tener diferentes ciclos de publicación, lo cual determina el soporte brindado para publicaciones anteriores. Un profesional con información detallada sobre versiones de software utilizado por la arquitectura, puede analizar el riesgo asociado por el uso de publicaciones anteriores de software, lo cual podría no ser soportado a corto plazo, o ya no ser soportado. Esto es crítico pues si una vulnerabilidad aparece en una versión antigua de software ya no soportada, el personal de los sistemas podría no ser directamente consciente de esto. Ningún parche podría incluso estar disponible para esto, y los anuncios podrían no listar las versiones vulnerables, pues ya no son soportadas. Incluso en un evento en el cual se sea consciente de la vulnerabilidad está presente y el sistema es vulnerable, se necesita hacer un actualización completa hacia la nueva publicación del software, lo cual podría introducir tiempo de inactividad significativo, o podría forzar la aplicación se vuelva a activar debido a incompatibilidades con la más reciente versión del software.

Herramientas Administrativas

Cualquier infraestructura de servidor web requiere la existencia de herramientas administrativas para mantener y actualizar la información utilizada por la aplicación. Esta información incluye contenido estático (páginas web, archivos gráficos), código fuente de la aplicación, bases de datos para autenticación del usuarios, etc. Las herramientas administrativas podrían diferir dependiendo del sitio, la tecnología, o software utilizado. Por ejemplo algunos servidores web podrían ser gestionados utilizando interfaces administrativas los cuales en son si mismos los servidores web (como el servidor web iPlanet), o se podría administrar mediante la configuración de archivos en texto plano (en el caso de Apache), o utilizar herramientas gráficas del sistema operativo (cuando se usa el servidor Microsoft IIS o ASP.Net).

En muchos casos la configuración del servidor web podrían ser manejada utilizando diferentes herramientas para el mantenimiento de archivos utilizados por el servidor web, los cuales son gestionados a través de FTP, WebDAV, sistemas de archivos en red (NS, CIFS), u otros mecanismos. Obviamente el sistema operativo de los elementos constituyendo la arquitectura de la aplicación también se gestionará utilizando otras herramientas. Las aplicaciones también pueden tener interfaces administrativas incorporadas en estas, las cuales son utilizadas para gestionar los datos de la aplicación (usuarios, contenidos, etc.).

Después de haber mapeado las interfaces administrativas utilizadas para gestionar las diferentes partes de la arquitectura, es importante revisarlas, pues si un atacante gana acceso hacia cualquiera de estas, pueden comprometer o dañar la arquitectura de la aplicación. Para hacer esto es importante:

• Determinar loa mecanismos controlando el acceso hacia estas interfaces y sus susceptibilidades asociadas. Esta información puede estar en línea.
• Cambiar el nombre de usuario y contraseña por defecto.

Algunas compañías seleccionan no gestionar todos los aspectos de sus aplicaciones de servidor web, pero hacen a otras partes gestionen el contenido entregado por la aplicación web. Esta compañía externa podría ya sea proporcionar únicamente partes del contenido (noticias o promociones), o podría gestionar completamente el servidor web (incluyendo contenido y código). Es común encontrar interfaces administrativas disponibles desde Internet en estas situaciones, pues utilizar Internet es barato en lugar de proporcionar una línea dedicada la cual conectará la compañía externa hacia la infraestructura de la aplicación, a través de una interfaz de gestión. En esta situación es muy importante evaluar si las interfaces administrativas pueden ser vulnerables a ataques.

Fuentes:

https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Appli...
https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Appli...