blog

La limpieza (wiping) del espacio residual o de holgura, puede ser realizado con algunas de las más populares herramientas para limpieza. El espacio residual contiene datos de archivos los cuales previamente han sido sobrescritos. Recordar el espacio residual es simplemente un espacio no utilizado al final de un sector de tamaño fijo, así un dispositivo de almacenamiento puede ser limpiado en su espacio residual, sin modificar ningún dato el cual está siendo utilizado en el dispositivo de almacenamiento. Cuando el espacio residual es limpiado, los datos existentes son sobrescritos y no pueden ser recuperados.

Recuperar Remanentes de Archivos Almacenados en el Espacio Residual

Para recuperar cualquier archivo existente en el espacio residual, se debe buscar en diversos lugares para determinar si las copias o copias de seguridad (backups) de los datos existen. Conforme un archivo es accedido, porciones de este podrían permanecer en áreas del dispositivo de almacenamiento. Se puede buscar en las siguientes ubicaciones por datos los cuales estuvieron en el espacio residual.

• El archivo de paginación o espacio de intercambio (swap), si el archivo fue cargado en memoria
• MFT o FAT para determinar si el archivo existió
• El jornal NTFS si los datos existieron en una partición NTFS
• Cualquier copia de respaldo del sistema

Nuevamente ninguna de estas soluciones son totales. Si se conoce parte del contenido de un archivo, se sugiere buscar físicamente en todo el contenido del dispositivo de almacenamiento para tratar de ubicar los datos. Recordar los datos los cuales existieron en el espacio sin asignar ya fueron previamente borrados, por lo cual la probabilidad de recuperalos es muy baja.

Fuentes:

https://www.forensicswiki.org/wiki/Anti-forensic_techniques
https://forensicswiki.org/wiki/Slack

El Wiping o “Limpieza” es un real problema cuando se hace correctamente. Puede ser realizado de diferentes maneras, pero comparte algunos aspectos comunes. Por ejemplo, cualquier dato el cual ha sido verdaderamente limpiado desde un dispositivo de almacenamiento, ha sido sobrescrito al menos una vez. Utilizando las herramientas de software existentes, no se puede acceder hacia ningún dato el cual ha sido sobrescrito. Se puede determinar si herramientas de “wiping” o limpieza han sido instaladas, revisando los programas existentes o aquellos los cuales existieron en el dispositivo, pero no se pueden traer los datos limpiados de vuelta.

Limpiar (Wiping) Archivos

El limpiar archivos, también denominado como borrado seguro, es el método más popular, e involucra la eliminación de los datos de archivos desde un dispositivo de almacenamiento. El limpiar archivos de hecho sobrescribe el contenido del archivo, consecuentemente después de finalizado el proceso los datos se consideran irrecuperables.

Detectar Actividad de Limpieza (Wiping)

Aunque puede ser difícil o imposible recuperar datos los cuales han sido limpiados, es posible determinar si se ha suscitado. Un indicio de limpieza (wiping) es la existencia de caracteres repetidos sobre un archivo completo, el nombre del archivo, el espacio residual, y / o el espacio sin asignar. Los caracteres repetidos pueden ser ya sea el mismo carácter o una cadena repetida de caracteres una y otra vez (como 0123456789). Algunas herramientas de software forense pueden identificar potencialmente caracteres consecutivos.

Si es factible encontrar evidencia de caracteres repetidos, se debe asegurar el verificar cuando el sistema operativo fue instalado. Pues podría ser un nuevo sistema o un sistema operativo reinstalado.

Si se sospecha ha ocurrido una limpieza, se sugiere verificar el registro de Windows por cualquier programa inusual instalado o ejecutado. Incluso si un usuario ha desinstalado una utilidad para limpieza (wiping), se podría encontrar evidencia de esto. Buscar por programas con nombres atípicos. Algunas utilidades de limpieza se borran a si mismos, pero también generan archivos temporales o de texto. Otras utilidades de limpieza borran la Tabla Maestra de Archivos (MFT ), y generan muchos archivos pequeños pareciendo ser borrados. Verificar por nombres de archivos inusuales y extensiones de archivos. Los puntos de restauración del sistema también pueden contener entradas de los programas de limpieza.

Otra características de la limpieza (wiping) es la ausencia total de archivos borrados. Muchas utilidades de wiping limpian los archivos borrados. De hecho, solo porque el sistema no tiene archivos borrados, esto no necesariamente implica se ha suscitado una limpieza, pero cuando se combinan con otras características, podría apuntar hacia una actividad de limpieza. Si se encuentra un programa sospechoso de ser una utilidad de limpieza, se debe evaluarla, descargándola e instalándola en una máquina para análisis. Consecuentemente ejecutarla y examinar la máquina por algún artefacto forense.

Es importante mantener la mente abierta y considerar otras posibilidades antes de concluir el dispositivo ha sido limpiado. Un usuario podría haber comprado un dispositivo de almacenamiento de segunda mano, el cual no ha sido completamente limpiado antes de ser comprado. También anotar algunos proveedores de dispositivos de almacenamiento utilizan caracteres repetidos en el formateo de sus dispositivos de almacenamiento. Además algunos antivirus y programas de seguridad limpian archivos si no son factibles de poner en cuarentena o limpiarlos. Es responsabilidad como profesional forense eliminar todas estas posibilidades antes de concluir se ha suscitado una limpieza. Conforme se gana experiencia, se reconocerán patrones de actividad, y se estará en la capacidad de juntar todas las piezas.

Recuperar Remanentes de Archivos Limpiados

No existe una “receta” para traer de vuelta los datos. Para recuperar un archivo el cual ha sido limpiado, se puede observar en algunos lugares para determinar si al menos partes o copias de respaldo de versiones previas de los archivos aún existen. Cuando el archivo es accedido, porciones de este podrían ser almacenados en diversas áreas del dispositivo de almacenamiento. Se puede buscar en las siguientes ubicaciones por archivos limpiados.

• Archivo de paginación o espacio de intercambio (swap), si este fue cargado en memoria
• MFT o FAT para determinar si el archivo ha existido
• El jornal NTFS, si el dato existió sobre una partición NTFS
• El espacio residual o espacio sin asignar, si el archivo existió previamente en el dispositivo
• Copias de respaldo del sistema

Ninguna de estas soluciones total pero podrían funcionar. Si se conoce parte del contenido de un archivo, buscar en el dispositivo de almacenamiento por este contenido podría ubicar el archivo en algunas de estas ubicaciones.

Fuentes:

https://www.forensicswiki.org/wiki/Anti-forensic_techniques
https://www.defcon.org/images/defcon-20/dc-20-presentations/Perklin/DEF…
https://eraser.heidi.ie/

La esteganografía implica la capacidad de ocultar datos dentro de otro archivo. Utilizando las herramientas disponibles para esteganografía, se pueden ocultar datos en el interior de otros archivos de imágenes, audio o video. Consecuentemente cuando se está realizando una investigación forense, y existen remanentes relacionados con una herramienta para esteganografía, sería muy recomendable y prudente buscar por la existencia de datos ocultos en los archivos del sistema bajo investigación.

Detectar Esteganografía

Se pueden utilizar herramientas open source o de fuente abierta, como también herramientas comerciales para tratar de detectar esteganografía, con resultados fiables. Además de estas herramientas automáticas, se puede también buscar el sistema para determinar si han sido instaladas herramientas para esteganografía. Se hace necesario entonces conocer este tema y conocer como enfrentarlo, pues es un escenario forense relativamente común. Razón por la cual es necesario incluir una herramienta para la detección de esteganografía, entre el conjunto de herramientas forenses, lo cual permitirá realizar un análisis más exhaustivo.

Fuentes:

https://en.wikipedia.org/wiki/Anti-computer_forensics
https://en.wikipedia.org/wiki/Steganography
https://github.com/abeluck/stegdetect
https://stegosuite.org/
https://www.openstego.com/
https://0xrick.github.io/lists/stego/

La encriptación de clave asimétrica, en el termino más básico, significa claves asimétricas han sido utilizadas para encriptar datos, en otras palabras, una clave de encriptación ha sido utilizada para encriptar y otra es utilizada para desencriptar los datos. La encriptación de clave asimétrica es más fuerte comparada con la enciptación simétrica, porque no sólo la longitud de la clave lo protege, sino la clave privada utilizada para desencriptar los datos debe ser encontrada antes de los datos puedan ser accedidos. Teniendo la clave pública, la clave utilizada para encriptar los datos; no permitirá acceder hacia los datos originales. Si los datos están encriptados con una clave asimétrica, no se podría analizar o buscar el contenido de los datos; en lugar de esto se deberá encontrar algún otro método para identificar y acceder hacia los datos.

Identificar y Acceder a Encriptación de Clave Asimétrica

Se pueden identificar archivos encriptados con clave asimétrica de dos maneras; ya sea el nombre del archivo tiene una extensión como “.pgp”, “.gpg”, etc. el cual es utilizado por un programa de encriptación para identificar sus archivos, o se podría utilizar pruebas de entropía.

Identificar y Acceder a Encriptación de Clave Asimétrica con Autopsy 4

Cuando los datos son asimilados por Autopsy, se ejecutarán pruebas de entropía sobre los datos para determinar si podrían estar encriptados con un algoritmo conocido. Una vez Autopsy finaliza su indexación y análisis, los archivos serán identificados y categorizados como “Encriptados”.

Acceder a Encriptación con Clave Asimétrica

El acceder hacia datos encriptados con clave asimétrica requiere un herramienta la cual no solo soporte el algoritmo, sino también la capacidad de realizar fuerza bruta contra la clave. Aunque se podría utilizar la herramienta original y la automatización a través de un script para probar claves, existen herramientas específicamente disponibles para este propósito. Se debe entender sin embargo, la mayoría de algoritmos asimétricos podría requerir años de ejecución antes de poder determinar la clave. Con una clave fuerte, esto puede significar incluso cientos de años. Se puede intentar romper las contraseñas de la misma manera aplicada a la encriptación de clave simétrica, excepto las claves asimétricas demandarán una gran cantidad de tiempo.

Fuentes:

https://en.wikipedia.org/wiki/Anti-computer_forensics
https://www.forensicswiki.org/wiki/Anti-forensic_techniques
https://www.sleuthkit.org/autopsy/
https://www.openpgp.org/

La encriptación de clave simétrica, en el término más básico, significa una clave simétrica ha sido utilizada para encriptar los datos; en otras palabras, la misma clave de encriptación es utilizada para encriptar y desencriptar los datos. La encriptación de clave asimétrica es únicamente tan fuerte como la longitud de la clave, y la capacidad de mantener a otros lejos de la clave por si misma. Si los datos son encriptados con una clave simétrica, no se estará en la capacidad de analizar o buscar el contenido directamente, y se deberá encontrar algún otro método para identificar y acceder hacia los datos. De hecho, no se puede determinar si los datos fueron encriptados con un algoritmo simétrico a menos se haya identificado como tal.

Identificar y Acceder a Encriptación de Clave Simétrica

Se puede identificar archivos encriptados con clave simétrica de dos maneras, ya sea el archivo tenga una extensión la cual sea utilizada por un programa de encriptación para identificar sus archivos, o se puede utilizar un proceso conocido como “prueba de entropía”. Este es un proceso por el cual la aleatoriedad de la distribución de datos dentro de un archivo puede ser evaluado. La aleatoriedad específica puede luego ser comparado contra una tabla de aleatoriedad de algoritmos conocidos, para identificar si ha sido utilizado un algoritmo conocido. Esto funciona bien para los algoritmos de encriptación conocidos públicamente y documentados, porque es factible utilizarlos para documentar su escala de aleatoriedad. Por lo tanto, si se sospecha la utilización de un algoritmo nuevo y no público, una prueba de entropía no será capaz de identificar el tipo de encriptación utilizada.

Identificar Encriptación de Clave Simétrica con Autopsy 4

Autopsy 4 tiene la capacidad de detectar encriptación de clave simétrica. Categoriza los archivos en los cuales se ha detectado encriptación de dos maneras “Encriptación Detectada” y “Encriptación Sospechosa”.

La “Encriptación Detectada”, implica la plena identificación de un archivo con encriptación. Para este caso encriptación de clave simétrica.

La “Encriptación Sospechosa”, se basa en el resultado de una prueba de entropía realizada. Para este caso se detectó una alta entropía.

Si fuese factible conocer u obtener por algún mecanismo la contraseña para el archivo encriptado, es factible utilizar la interfaz de Autopsy 4 para ingresar la contraseña y acceder al archivo.

Mencionar Autopsy 4 no incluye una funcionalidad o característica para intentar romper las contraseñas de los archivos encriptados. Razón por lo cual se sugiere utilizar otro programa específicamente diseñado para este propósito. Otras herramientas forenses como EnCase Forensics o Forensics ToolKit si incluyen estas funcionalidades de manera inherente.

Fuentes:

https://autopsy.com/
https://en.wikipedia.org/wiki/Anti-computer_forensics
https://www.forensicswiki.org/wiki/Anti-forensic_techniques
https://en.wikipedia.org/wiki/Entropy_(computing)

Después de haber iniciado los módulos de asimilación para analizar las fuentes de datos, se visualizará la interfaz principal de análisis. Se puede seleccionar buscar elementos específicos, buscar carpetas específicas, o revisar los resultados de los módulos de asimilación.

Es factible iniciar con todas las técnicas de análisis utilizando la estructura de árbol ubicado en el lado izquierdo de Autopsy.

• El nodo de Fuentes de Datos raíz muestra todos los datos del caso.
  • Los nodos de imágenes individuales muestran la estructura del sistema de archivos de las imágenes de los discos, o discos locales en el caso
  • Los nodos de Conjuntos de Archivos Lógicos muestran los archivos lógicos en el caso.
• El nodo Vista muestra los mismos datos desde la perspectiva de un tipo de archivo o cronología
• El nodo Resultado muestra la salida desde los módulos de asimilación.

Cuando se selecciona un nodo desde la estructura de árbol ubicado en el lado izquierdo de Autopsy, será mostrado un listado de archivos en la parte superior derecha. Se puede utilizar la vista en Miniaturas de la parte superior derecha para visualizar las imágenes. Cuando se seleccione un archivo de la parte superior derecha, su contenido será mostrado en la parte inferior derecha. Se pueden utilizar las pestañas ubicadas en la parte inferior derecha para visualizar el texto del archivo, una imagen o datos en hexadecimal.

Si se está visualizando archivos desde los nodos Vistas o Resultados, se puede hacer clic derecho en un archivo para ir hacia su ubicación en el sistema de archivos. Esta funcionalidad es útil para visualizar aquello lo cual un usuario almacenó en la misma carpeta del archivo el cual se está visualizando. También se puede hacer clic derecho en un archivo para extraerlo hacia el sistema local.

Si se requiere buscar por palabras claves simples, entonces se puede utilizar la caja de búsqueda ubicado en la parte superior derecha de Autopsy. Los resultados serán mostrados en una tabla ubicada en la parte superior derecha.

La estructura de árbol de la izquierda y la tabla de la derecha tienen una funcionalidad de búsqueda rápida, la cual puede ser utilizada para encontrar rápidamente un nodo visible.

Se pueden etiquetar (marcar) archivos arbitrarios, de tal manera sea factible encontrarlos de manera rápida posteriormente, o para incluirlos específicamente en el reporte.

Bandeja de Entrada de Asimilación

Conforme se avanza a través de los resultados en la estructura de árbol, los módulos de asimilación son ejecutados en segundo plano. Los resultados son mostrados en la estructura de árbol tan pronto como los módulos de asimilación los encuentran y los reportan.

La bandeja de entrada de asimilación recibe los mensajes desde los módulos de asimilación conforme encuentran los resultados. Se puede abrir la bandeja de entrada para ver aquello encontrado recientemente. Este mantiene un rastro de los mensajes leídos.

La utilización prevista para esta bandeja de entrada, es enfocarse en algunos datos por un tiempo y luego volver a revisar la bandeja de entrada en el momento conveniente. Se puede ver aquello lo cual se encontró mientras se estaba enfocado en una tarea previa. Se puede conocer como se encontraron archivos dañinos conocidos o el archivo encontrado es relevante para una palabra clave, y luego decidir enfocarse en esto por un tiempo.

Cuando se selecciona un mensaje, se puede luego ir hacia el árbol de Resultados donde serán encontrados más detalles, o saltar hacia la ubicación del archivo en el sistema de archivos.

Otras Interfaces de Análisis

Cronología

Esta cronología o línea de tiempo mostrará el sistema de archivos y otros eventos organizados por tiempo, utilizando diversas técnicas de visualización. Demandará algunos minuto crear la cronología para el análisis.

Galería de Imágenes

La Galería de Imágenes se enfoca en mostrar las imágenes y videos desde las fuentes de datos organizadas por carpetas. Mostrará los archivos tan pronto hayan sido “hasheados” y sus datos EXIF extraídos.

Comunicaciones

La interfaz Comunicaciones se enfoca en mostrar cuales cuentas se han comunicado más y cuales mensajes enviaron. Esto permite enfocarse en ciertas relaciones o comunicaciones dentro de un cierto rango de fechas.

Fuentes:

http://sleuthkit.org/autopsy/docs/user-docs/4.12.0/quick_start_guide.ht…
https://www.autopsy.com/

Antes de comenzar las pruebas de seguridad, es fundamental entender la estructura de la aplicación. Sin una comprensión profunda sobre el diseño de la disposición de la aplicación, es improbable se puedan realizar pruebas profundas.

Objetivos de la Prueba

Mapear la aplicación web y entender los flujos de trabajo principales.

Como Evaluar

En las pruebas de caja negra es extremadamente difícil evaluar el código base completo. No solo porque el profesional no tiene una visión de las rutas de código a través de la aplicación, sino incluso si lo tuviera, probar todas las rutas de código consumiría bastante tiempo. Una manera de reconciliar esto es documentar las rutas de código descubiertas y evaluadas.

Existen muchas maneras de abordar la prueba y medir la cobertura del código:

• Ruta: Probar cada una de las rutas a través de la aplicación, lo cual incluya pruebas de análisis con valores combinatorios y limites para cada ruta de decisión. Mientras esta perspectiva ofrece minuciosidad, el número de rutas factibles de ser probadas crece exponencialmente con cada rama de decisión.
• Flujo de Datos (Análisis de Corrupción): Prueba la asignación de variables mediante una interacción externa (normalmente usuarios). Se enfoca en mapear el flujo, transformación y utilización de datos a través de la aplicación.
• Carrera: Evalúa múltiples instancias concurrentes de la aplicación manipulando los mismos datos.

El intercambio en cuanto a cual método utilizar y cual grado de cada método se utiliza, debe ser negociado con el propietario de la aplicación. También se podrían adoptar perspectivas simples, incluyendo consultar al propietario de la aplicación cuales funciones o secciones de código son particularmente preocupantes, y como estos segmentos de código pueden ser alcanzados.

Prueba de Caja Negra

Para demostrar la cobertura del código hacia el propietario de la aplicación, el profesional puede iniciar con una hoja de cálculo, y documentar todos los enlaces descubiertos mediante un proceso de “spidering” a la aplicación (ya sea hecha de manera manual o automática). Luego el profesional analizará de manera más cercana los puntos de decisión en la aplicación, para luego investigar cuantas rutas de código significativas son descubiertas. Estos luego son documentados en la una hoja de cálculo con URLs, prosa, y descripciones con capturas de pantalla de las rutas descubiertas.

Prueba de Caja Gris

Asegurar la cobertura de código suficiente para el propietario de la aplicación, es de lejos lo más fácil con la perspectiva de caja gris y caja blanca. La información solicitada y proporcionada al profesional, asegura los requerimientos mínimos para cumplir con la cobertura de código.

Ejemplo

Spidering automático

El spider automático es una herramienta utilizada para automáticamente descubrir nuevos recursos (URLs) en un sitio web particular. Inicia con una lista de URLs a visitar, llamadas las semillas, lo cual depende de como el Spider ha iniciado. Aunque existen muchas herramientas para “Spidering”, a continuación se utiliza Zed Attack Proxy (ZAP).

ZAP ofrece las siguientes características automáticas, los cuales pueden ser seleccionadas en base a requerimientos del profesional.

• Spider al Sitio: La lista semilla contiene todas las URIs existentes ya encontradas para el sitio seleccionado
• Spider a la Rama: La lista semilla contiene todas las URIs existentes ya encontradas y presentes en la rama de cada nodo seleccionado
• Spider a la URL: La lista semilla contiene únicamente la URI correspondiente hacia el nodo seleccionado (en el árbol del sitio)
• Spider a Todo el Alcance: La lista semilla contiene todas las URIs seleccionadas por el usuario “En Alcance”

Fuentes:

https://www.owasp.org/index.php/Map_execution_paths_through_application…
https://github.com/zaproxy/zaproxy

Enumerar las aplicación y su superficie de ataque es el precursor clave antes de cualquier prueba a ser realizada, esto permite al profesional identificar áreas probables de debilidad. Esta sección ayuda a identificar y mapear áreas dentro de la aplicación, las cuales deben ser investigadas una vez se ha completado la enumeración y el mapeo.

Objetivos de la Prueba

Entender como se realizan las peticiones y respuestas típicas desde la aplicación.

Como Evaluar

Antes de iniciar cualquier prueba, el profesional debe siempre tener un buen conocimiento de la aplicación, y de como el usuario y el navegador web se comunican. Conforme se camina a través de la aplicación, se debe poner especial atención hacia todas las peticiones HTTP (Métodos GET y POST, también conocidos como Verbos), como también cada parámetro y campo de formulario pasado hacia la aplicación. Además se debe poner atención cuando se utilizan las peticiones GET y cuando se utilizan las peticiones POST, para pasar parámetros hacia la aplicación. Es muy común sea utilizada una petición GET, pero cuando se pasa información sensible frecuentemente se hace dentro del cuerpo de una petición POST.

Anotar para la visualización de los parámetros enviados en una petición POST, el profesional necesitará utilizar una herramienta como un proxy de interceptación (Por ejemplo OWASP Zed Attack Proxy) o un plugin para el navegador. Dentro de la petición POST, el profesional debe también anotar especialmente los campos ocultos del formulario conteniendo información sensible, como información de estado, cantidad de artículos, precio de artículos, lo cual el desarrollador nunca destino a ser vistos y cambiados.

Por experiencia ha sido muy útil utilizar un proxy de interceptación y una hoja de cálculo para esta etapa de las pruebas. El proxy mantiene un rastro de cada petición y respuesta entre el profesional y la aplicación conforme es recorrida. Adicionalmente en este punto, el profesional usualmente atrapa cada petición y respuesta, de tal manera pueda visualizar exactamente cada cabecera, parámetro, etc. el cual es pasado hacia la aplicación, y aquello lo cual es retornado. Esto puede ser algo tedioso algunas veces, especialmente en grandes sitios interactivos (Pensar en aplicación de banca). Sin embargo, la experiencia mostrará aquello a buscar, y esta fase puede reducirse significativamente.

Conforme el profesional recorre a través de la aplicación, debe anotar cualquier parámetro interesante en la URL, cabecera personalizada, o cuerpo de la petición o respuestas, para luego guardarlas en una hoja de cálculo. Este documento debe incluir la página solicitada (podría ser bueno también añadir el número de petición desde el proxy para futuras referencias), los parámetros interesantes, el tipo de petición (POST/GET), si el acceso es autenticado o no autenticado, si se utiliza SSL/TLS, si es parte de un proceso de varios pasos, o cualquier otra anotación relevante. Una vez se tenga cada área de la aplicación mapeada, entonces se puede recorrer la aplicación y evaluar cada una de las áreas identificadas y anotar aquello lo cual funciona o no funciona. El resto es identificar como probar cada una de estas áreas de interés, pero esto debe realizarse antes de comenzar cualquier prueba.

A continuación se presentan algunos puntos de interés para todas las peticiones y respuestas. Dentro de la sección peticiones, enfocarse en los métodos GET y POST, pues estos aparecen en la mayoría de peticiones. Anotar otros métodos, como PUT o DELETE pueden ser utilizados. Frecuentemente, estas son peticiones más raras, si están permitidas, pueden exponer vulnerabilidades. Se tiene una especial consideración para probar estos métodos HTTP.

Peticiones:

• Identificar donde se utilizan las peticiones GET y donde se utilizan POST.
• Identificar todos los parámetros utilizados en una petición POST (Están en el cuerpo de la petición).
• Dentro de cada petición POST, poner especial atención en cualquier parámetro oculto. Cuando un POST es enviado, todos los campos del formulario (incluyendo los parámetros ocultos) serán enviados en el cuerpo del mensaje HTTP hacia la aplicación. Estos típicamente no son vistos a menos se utilice un Proxy o se visualice el código fuente. Además, la siguiente página mostrada, sus datos, y el nivel de acceso puede ser diferente dependiente del valor de los parámetros ocultos.
• Identificar todos los parámetros utilizados en una petición GET (la URL), en particular la cadena de consulta (usualmente después del signo “?”).
• Identificar todos los parámetros de la cadena de consulta. Estos usualmente están en un formato de pares, como “foo=bar”. También anotar muchos parámetros pueden estar en una cadena de consulta por separado por un “&“, “~”, “:”, o cualquier otro carácter especial o codificación.
• Una nota especial cuando se trata de identificar múltiples parámetros en una cadena o dentro de una petición POST, es algunos o todos los parámetros podrían ser necesarios para ejecutar los ataques. El profesional necesita identificar todos los parámetros (incluso si está codificada o encriptada), e identificar cuales son procesadas por la aplicación. Posteriormente se debe identificar como evaluar estos parámetros. En este punto solo se debe estar seguro cada uno ha sido identificado.
• También poner atención en cualquier tipo adicional de cabeceras o personalizada, la cual no es típicamente vista (como debug=false)

Respuestas:

• Identificar donde se definen nuevas Cookies (cabecera Set-Cookie), modifican o añaden.
• Identificar donde existe cualquier redirección (Código de estado HTTP 3xx), códigos de estado 400, en particular 403 Forbiden, y 500 Internal Server Error, durante las respuestas normales (ejemplo peticiones sin modificar)
• También notar donde se utiliza cualquier cabecera interesante. Por ejemplo “Server: BIG-IP” indica un balance de carga en el sitio. Por lo tanto, si el sitio usa balance de carga y un servidor está incorrectamente configurado, entonces el profesional podría hacer múltiples peticiones para acceder al servidor vulnerable, dependiendo del tipo de balance de carga utilizado.

Prueba de Caja Negra

Evaluar los puntos de entrada en la aplicación:

Ejemplo 1

Este ejemplo muestra una petición GET, la cual podría comprar un artículo en una aplicación de compras en linea.

Resultado Esperado:

Aquí el profesional debería anotar todos los parámetros de la petición; como “show.product_details”, “flypage”, “product_id”, como también la Cookie (La cual podría codificar parámetros o ser utilizada para el estado de la sesión).

Ejemplo 2

En este ejemplo se muestra una petición POST, la cual añade una artículo a ser comprado.

Resultado Esperado:

En este ejemplo el profesional debe anotar todos los parámetros como se hizo anteriormente, pero notará los parámetros son pasados en el cuerpo del mensaje y no en la URL. Adicionalmente notar la existencia de alguna Cookie personalizada.

Prueba de Caja Gris

Probar los puntos de entrada a la aplicación mediante una metodología de Caja Gris podría consistir de todo lo ya identificado anteriormente, con un añadido. En casos donde existen fuentes externas desde las cuales la aplicación recibe datos y las procesa (como capturas SNMP, mensajes syslog, SMTP, o mensajes SOAP desde otros servidores), una reunión con los desarrolladores de la aplicación, podría identificar cualquier función la cual acepte o espere entrada del usuario, y como esta es formateada. Por ejemplo, un desarrollador podría ayudar a entender como formular una petición SOAP correcta, la cual la aplicación podría aceptar, y donde reside el servicio web (si el servicio web o cualquier otra función no ha sido aún identificada durante la prueba de caja negra).

Fuentes:

https://www.owasp.org/index.php/Identify_application_entry_points_(OTG-…
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Es muy común e incluso recomendable, los programadores incluyan comentarios detallados y metadatos en su código fuente. Sin embargo, los comentarios y metadatos incluidos dentro del código HTML podría revelar información interna, lo cual no debería estar disponible para potenciales atacantes. La revisión de comentarios y metadatos debe ser hecho para determinar si se está fugando algún tipo de información.

Objetivos de la Prueba

Revisar los comentarios y metadatos para entender mejor la aplicación, y encontrar cualquier fuga de información.

Como Evaluar

Los comentarios HTML son frecuentemente utilizados por los desarrolladores para incluir información de depuración sobre la aplicación. Algunas veces ellos olvidan los comentarios dejándolos en producción. Los profesionales en pruebas de penetración deben buscar comentarios HTML.

Prueba de Caja Negra

Verificar el código fuente por comentarios conteniendo información sensible, lo cual puede ayudar a un atacante a ganar más indicios sobre la aplicación. Esto podría ser código SQL, nombres de usuarios y contraseñas, direcciones IP internas, o información sobre depuración.

Un profesional en pruebas de penetración podría encontrar algo como esto:

Verificar información sobre la versión HTML por números de versión validos y URLs de Definiciones de Tipos de Datos (DTD)

• "strict.dtd" - DTD estricto por defecto
• "loose.dtd" - DTD suelto
• “frameset.dtd" - DTD para documentos frameset

Algunas etiquetas Meta no proporcionan vectores activos de ataque, pero en su lugar permiten a un atacante perfilar una aplicación.

Algunas etiquetas Meta alteran las cabeceras, como “http-equiv” definida en una cabecera de respuesta HTTP sobre el atributo contenido del elemento meta.

También se debe revisar si esto puede ser utilizado para realizar ataques de inyección (por ejemplos ataques CRLF), Esto puede también ayudar a determinar el nivel de fuga de datos mediante el cache del navegador. Una etiqueta meta común es “refresh”.

Un uso común para las etiquetas Meta es especificar palabras clave o “keywords”, a ser utilizadas por el motor de búsqueda para mejorar la calidad de los resultados de búsqueda.

Aunque la mayoría de servidores web gestiones la indexación para motores de búsqueda mediante el archivo “robots.txt”, esto también puede ser manejado mediante etiquetas Meta. La etiqueta presentada a continuación advierte a los robots como realizar su trabajo.

PICS (Platform for Internet Content Selection) y PORDER (Protocol for Web Description Resources), proporcionan una infraestructura para asociar meta datos con contenido en Internet.

Prueba de Caja Gris

No aplica.

Fuentes:

https://www.owasp.org/index.php/Review_webpage_comments_and_metadata_fo…
https://www.robotstxt.org/
https://www.w3.org/PICS/
https://www.w3.org/TR/powder-dr/

Una etapa primordial en una prueba para encontrar vulnerabilidades en una aplicación web, es encontrar cuales aplicaciones web particulares están hospedadas sobre el servidor web. Muchas aplicaciones tienen vulnerabilidades conocidas, y estrategias de ataques conocidos pueden explotarse para ganar control remoto o explotar datos. Además muchas aplicaciones están frecuentemente mal configuradas o desactualizadas, debido a la percepción de únicamente se utilizan “internamente”,y por lo tanto no existen amenazas.

Con la profileración de servidores virtuales, la relación tradicional de tipo 1 a 1 entre una dirección IP y un servidor web, está perdiendo gran parte de su significado original. No es raro tener varios sitios webs o aplicaciones cuyos nombres simbólicos resuelven hacia la misma dirección IP. Este escenario no está limitado hacia entornos de hosting, sino también aplica hacia entornos corporativos ordinarios.

Los profesionales en seguridad algunas veces reciben un conjunto de direcciones IP como aquello lo cual evaluar. Se puede argumentar este escenario es el más parecido a un contrato de tipo prueba de penetración, pero en cualquier caso se espera tal asignación evalúe todas las aplicaciones web factibles de ser accedidas a través de aquello a evaluar. El problema es la dirección IP del host con un servicio HTTP en el puerto 80, es altamente probable devuelva un mensaje el cual verse sobre “Ningún servidor web ha sido configurado en esta dirección” o un mensaje similar. Pero el sistema podría “ocular” un número de aplicaciones web asociado hacia nombres (DNS) simbólicos sin relación. Obviamente la extensión del análisis afecta profundamente al profesional quien realiza las pruebas, pues deberá considerar evaluar todas las aplicaciones o únicamente aquellas conocidas.

Algunas veces la especificación de aquello a evaluar es amplia. Al profesional en pruebas de penetración se le proporciona 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 nombres simbólicos, y el cliente podría no ser consciente de esto (es más probable esto ocurra en grandes organizaciones).

Otros problemas afectando el alcance de la evaluación, está representada por las aplicaciones web publicadas en URLs no obvias (ejemplo: http://www.example.com /f3woj1), la cual no se referencia en ningún lugar. Esto puede ocurrir ya sea por error (debido a inadecuadas configuraciones), o intencionalmente (por ejemplo, interfaces administrativas sin anunciar).

Para solucionar estos inconvenientes es necesario realizar un descubrimiento de la aplicación web.

Objetivos de la Prueba

Enumerar las aplicaciones web dentro del alcance existente en el servidor web.

Como Evaluar

Prueba de Caja Negra

El descubrimiento de las aplicaciones web es un proceso dirigido a identificar aplicaciones web sobre una infraestructura definida. Esto último es usualmente especificado como un conjunto de direcciones IP (podría ser 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 la evaluación, ya sea un prueba de penetración al estilo clásico, o una evaluación enfocada a la aplicación. En ambos casos, a menos las reglas del contrato especifiquen lo contrario (por ejemplo probar únicamente la aplicación ubicada en http://www.example.com ), la evaluación debe abarcar el alcance más completo, es decir, debe identificar todas las aplicaciones factibles de ser accedidas a través de aquello a evaluar. Los siguientes ejemplos examinan algunas técnicas a emplearse para lograr este objetivo.

Nota: Algunas de las siguientes técnicas aplican a servidores web de cara hacia Internet, como servicios de búsqueda basados en web para nombres DNS e IP inversa, y el uso de motores de búsqueda. Ejemplo de utilizar una dirección IP privada (como 192.168. 1.100), la cual a menos se indique lo contrario representa direcciones IP genéricas, y son utilizadas únicamente para propósito de anonimato.

Existen tres factores influyendo en como muchas aplicaciones están relacionadas hacia un nombre DNS determinado (o una dirección IP):

1. URL base diferentes

El punto de entrada más obvio para una aplicación web es “www.example.com”, es decir con esta notación corta se piensa la aplicación web se origina en “www.example.com” (lo mismo se aplica para https). Sin embargo aunque esta es una situación común, no hay nada lo cual fuerce la aplicación inicie en “/”

Por ejemplo, el mismo nombre simbólico puede estar asociado hacia tres aplicaciones web, como http://www.example.com/url, http://www.example.com/url2, http://www.example.com/url3.

En este caso la URL http://www.example.com/ podría no estar asociada con una página significativa, y las tres aplicaciones podrían estar “ocultas” a menos el profesional en pruebas de penetración conozca como alcanzar cada una de estas, es decir conozca url1, url2, y url3. Usualmente no se necesita publicar las aplicaciones web de esta manera, a menos el propietario no requiera sean factibles de ser accedidas de manera estándar, y esté preparado para informar a los usuarios sobre su ubicación exacta. Esto no significa estas aplicaciones sean secretas, solo su existencia y ubicación no ha sido anunciada explícitamente.

2. Puertos no estándar

Mientras las aplicaciones web usualmente viven en el puerto 80 (http) o 443 (https), no existe ninguna magia en estos números de puerto. De hecho las aplicaciones web pueden estar asociadas con puertos TCP arbitrarios, y pueden ser referidos especificando el número de puerto como sigue: http://www.example.com:2000/

3. Hosts virtuales

DNS permite a una única dirección IP estar asociada con uno o más nombres simbólicos. Por ejemplo la dirección IP 192.168. 1.100 podría estar asociada hacia los nombres DNS www.example.com, helpdesk.example.com y webmail.example.com. No siendo necesario todos los nombres correspondan al mismo dominio DNS. Esta relación 1 a N puede relejarse para servir contenido diferente utilizando los así llamados hosts virtuales. La información especificando el host virtual referido esta incorporada en la cabecera “Host:” de HTTP 1.1

No se sospecharía la existencia de otras aplicaciones web además del obvio www.example.com, a menos se conozca helpdesk.example.com y webmail.example.com.

Perspectivas para abordar el inconveniente 1. URLs no estándar

No hay manera de determinar completamente la existencia de aplicaciones nombradas no estándar. Al ser no estándar, no hay un criterio fijo el cual gobierne la convención de nombramiento, sin embargo existen diferentes técnicas factibles de utilizar para ganar información adicional.

Primero, si el servidor web está inadecuadamente configurado y permite navegación de directorios, puede ser posible detectar estas aplicaciones. Los escáneres de vulnerabilidades pueden ayudar en este punto.

Segundo, estas aplicaciones pueden ser referidas por otras páginas webs, existiendo la probabilidad de haber sido rastreadas o indexadas por los motores de búsqueda web. Si el profesional en pruebas de penetración sospecha la existencia de tales aplicaciones “ocultas” sobre www.example.com, se podría buscar utilizando el operador “site:”, y examinando el resultado de la consulta “site:www.example.com”. Entre las URLs devueltas podría estar una apuntando hacia tal aplicación no obvia.

Otra opción es probar por URLs las cuales podrían ser probables candidatos para aplicaciones no publicadas. Por ejemplo un correo electrónico web podría ser factible de ser accedido desde URLs como https://www.example.com/webmail, https://webmail.example.com o https://mail.example.com. Lo mismo se aplica para interfaces administrador, las cuales podrían ser publicadas en URLs ocultas (por ejemplo, una interfaz administrativa Tomcat), y no estar referida en ninguna parte. Por lo tanto hacer una búsqueda al estilo diccionario (o “adivinación inteligente”) podría dar algunos resultados. Los escáneres de vulnerabilidades pueden ayudar en este punto.

Perspectivas para abordar el inconveniente 2. Puertos no estándar

Es fácil verificar la existencia de aplicaciones web en puertos no estándar. Un escáner de puertos como “nmap” es capaz de realizar un reconocimiento de servicios, lo cual se realiza utilizando la opción “-sV”, y podría identificar servicios http[s] en puertos arbitrarios. Lo requerido es un escaneo completo de los 65,535 puertos TCP.

Por ejemplo, el siguiente comando un escaneo de tipo “TCP Connect” contra todos los puertos abiertos en la dirección IP 192.168 .0.88, e intentará determinar cuales servicios están enlazados en estos (únicamente las opciones esenciales son mostradas, pues Nmap incluye una amplia diversidad de opciones).

# nmap -Pn -sT -sV -p- 192.168.0.88

Es suficiente examinar el resultados para buscar por http o servicios relacionados con SSL/TLS (lo cual debe ser probado para confirmar son https). Por ejemplo la salida del anterior comando se expone en la siguiente imagen.

Del ejemplo se puede ver:

• Existe un servidor Apache httpd ejecutándose en el puerto TCP 80
• Existe un servicio SSL/HTTPS ejecutándose en el puerto TCP 443, el cual Nmap no puede identificar.
• Existe un servicio Apache Tomcat/Coyote ejecutándose en el puerto TCP 8080
• Existe un servicio Jetty ejecutándose en el puerto TC 8081

La misma tarea puede ser realizada por los escáneres de vulnerabilidades, pero primero verificar el escáner elegido es capaz de identificar servicios http[s] ejecutándose en puertos no estándar. Por ejemplo Nessus es capaz de identificarlos en puertos arbitrarios (siempre se le instruya a escanear todos los puertos), y podría proporcionar con respecto a Nmap, un número de pruebas sobre vulnerabilidades conocidas para el servidor web, como también la configuración SSL de servicios https. Como se mencionó anteriormente Nessus es capaz de detectar aplicaciones populares o interfaces web, lo cuales de otra manera pasarían desapercibidas (por ejemplo una interfaz administrativa de Tomcat).

Perspectivas para abordar el inconveniente 3. Host virtuales

Existen diversas técnicas las cuales pueden ser utilizadas para identificar nombres DNS asociados hacia una dirección IP definida w.x.y.z.

Transferencia de Zona

Esta técnica tiene un uso limitado en la actualidad, de hecho las transferencia de zona son improbables de encontrar en servidores DNS. Sin embargo es necesario intentarlo. Primero, los profesionales en pruebas de penetración deben determinar los servidores de nombres sirviendo w.x.y.z. Si el nombre simbólico es conocido para w.x.y.z (digamos www.example.com), sus servidores de nombres pueden ser determinados mediante herramientas como “nslookup”, “host”, o “dig”, mediante peticiones a los registros NS del DNS.

Si no se conocen nombres simbólicos para w.x.y.z, pero la definición de aquello a evaluar contiene al menos un nombre simbólico, se debe intentar aplicar el mismo proceso y consultar el servidor de nombre (con la esperanza w.x.y.z de ese servidor también sirva para w.x.y.z). Por ejemplo, si aquello a evaluar consiste de una dirección IP w.x.y.z, y el nombre mail.example.com, determinar los servidores de nombre para el dominio example.com.

El siguiente ejemplo muestra como identificar los servidores de nombre para owasp.org, utilizando el comando host.

# host -t NS owasp.org

Una transferencia de zona podría ahora ser solicitada hacia los servidores de nombres para el dominio example.com. Si el profesional en pruebas de penetración es afortunado, podría obtener un listado de las entradas DNS para este dominio. Esto podría incluir el nombre obvio www.example.com, y host no tan obvios como helpdesk.example.com, y webmail.example.com (y posiblemente otros). Verificar todos los nombres devueltos por la transferencia de zona, y considerar todos aquellos los cuales se relacionan con los sistemas en evaluación.

Se intenta realizar una transferencia de zona contra www.owasp.org contra los dos servidores de nombres.

# host -l owasp.org dns1.stabletransit.com.
# host -l owasp.org dns2.stabletransit.com.

Consultas DNS inversas

Este proceso es similar a los anteriores, pero se basa en el registro (PTR) de los registros DNS. En lugar de solicitar una transferencia de zona, intentar configurar el tipo de registro PTR para realizar una consulta en una dirección IP definida. Si se es afortunado, se puede recuperar una entrada de nombre DNS. Esta técnica se basa en la existencia del mapeo de IP a nombre simbólico, lo cual no está garantizado.

Búsquedas DNS basadas en web

Este tipo de búsqueda es similar a la transferencia de zona DNS, pero se basa en servicios basados en web, lo cual permite búsquedas basadas en nombres sobre DNS. Uno de tales servicios es proporcionado por Netcraft. Pudiendo consultar por una lista de nombres correspondientes a un dominio elegido, como example.com. Luego se verifican si los nombres obtenidos son pertinentes a aquello lo cual se está examinando.

Servicios IP inverso

Servicios IP inversos son similares a las consultas inversas DNS, con la diferencia de se consulta una aplicación basada en web en lugar de un servidor de nombres. Existen diversos servicios disponibles. Dado el hecho tienden a retornar resultados parciales (y frecuentemente diferentes), es mejor utilizar múltiples servicios para obtener un análisis más completo.

El siguiente ejemplo muestra el resultado de consultar uno de los servicios reversos disponibles para la dirección IP correspondiente a www.owasp.org.

Buscar en Google

Siguiendo la captura de información desde las técnicas previas, se debe utilizar motores de búsqueda para posiblemente refinar o incrementar el análisis. Esto puede proporcionar evidencia de nombres simbólicos adicionales correspondientes a aquello en evaluación, o aplicaciones factibles de ser accedidas mediante URLs no obvias.

Por ejemplo considerar el ejemplo previo relacionado con www.owasp.org, pues se podría consultar a Google y otros motores de búsqueda, en busca de información (nombres DNS) relacionado a los dominios recién descubiertos.

Pruebas de Caja Gris

No aplica. La metodología permanece igual como en lo detallado en las pruebas de caja negra, no importando con cuanta información se inicie.

Fuentes:

https://www.owasp.org/index.php/Enumerate_Applications_on_Webserver_(OT…
https://nmap.org/
https://www.tenable.com/products/nessus/nessus-essentials
http://reverseip.domaintools.com/
https://www.dnsstuff.com/
https://www.net-square.com/mspawn.html
https://searchdns.netcraft.com/