Bolsas para Almacenar Evidencia Forense

Body

Los profesionales forenses utilizan una variedad de herramientas tanto en el laboratorio como en otros escenarios donde se requiere realizar identificación y recolección de evidencia digital. Cuando la evidencia es recolectada, el profesional forense necesita almacenar la evidencia para transportarla hacia un laboratorio forense, con el propósito de analizarlas. El profesional forense debe asegurarse la evidencia no se dañe ni se altere, por lo cual se han desarrollado diferentes tipos de bolsas para garantizar la evidencia se mantenga segura y protegida.

Las bolsas para almacenar evidencia, son a prueba de manipulaciones, contienen una cinta adhesiva la cual se sella automáticamente, formado un sello instantáneo y permanente, lo cual hace imposible reabrir las bolsas sin destruirlas. Un patrón de borde está impreso alrededor de los bordes para evitar la bolsa se abra por los lados. Son resistentes a perforaciones y desgarros, estando construidas con de un material de polietileno, lo cual proporciona resistencia y permite al profesional forense ver el contenido de la bolsa.

Las áreas de escritura incluyen espacio para nombres, contenidos, cadena de custodia, e información del laboratorio.

Bolsas para Almacenamiento de Dispositivos Inalámbricos

Este tipo de bolsas son utilizadas para almacenar dispositivos inalámbricos. Bloquea todas las señales inalámbricas y mantiene protegidos los dispositivos electrónicos de tamaño mediano para prevenir ataques, rastreo, espionaje, y corrupción de la cadena de custodia. Cuando un dispositivo está correctamente encerrado en la bolsa, no se pueden activar ni borrar de forma remota ninguna aplicación o código malicioso, ninguna comunicación puede penetrar, y nadie puede acceder hacia el micrófono, cámara, ubicación GPS, o la información. Los usos principales son para la aplicación de la ley y la recopilación de pruebas forenses militares, defensa contra el robo de datos, seguridad personal, protección EMP, reducción de radiación EMF, además de mejorar la privacidad digital.

Estas bolsas pueden albergar fácilmente varias computadoras portátiles, radios, teléfonos celulares, tabletas, y otros accesorios. También es factible garantizar los dispositivos electrónicos encerrados en el interior permanecerán secos y fuera de línea en cualquier lugar rodeado de agua.

Fuentes:

https://tritechforensics.com/evidence-bags/
https://tritechforensics.com/mission-darkness-dry-shield-faraday-15l-to…

Forensics Wiki (Wiki sobre Forense)

Body

Forensics Wiki es un sitio web de fuente abierta, el cual proporciona información relacionada con el forense digital. Los artículos del sitio web abarcan un amplio rango de información, desde herramientas utilizadas durante las investigaciones forenses, hasta artículos de personas y organizaciones contribuyendo al área forense

Descubrir contenido

Etiquetas

Para hacer el contenido factible de ser descubierto, los artículos están categorizados utilizando etiquetas. Cada página de este sitio web está etiquetado. La página podría tener una o varias etiquetas según el contenido del sitio. Las etiquetas se colocan en la parte superior del artículo.

Por ejemplo, el artículo Full Disk Encryption (Encriptación Completa del Disco) tiene tres etiquetas: Encryption (Encriptación), Disk Encryption (Encriptación del Disco) y Anti-Forensics (Anti Forense) . Al hacer clic en cualquiera de las etiquetas, se accederá hacia todo el contenido categorizado bajo esa etiqueta.

Tópicos

Etiqueta:

Operating Systems

Artículos:

  • Windows: windows_vista, windows 7, windows 8, windows 10
  • Unix: freebsd, netbsd, openbsd, solaris, aix
  • Mobile OS: android, ios, windows mobile

Etiqueta:

Tools

Artículos:

  • File Analysis: bless, ghidra, PST File Viewer, hachoir
  • Timeline Analysis: timesketch, Plaso
  • Disk Analysis: sleuthkit, bulk_extractor, fiwalk
  • Network Analysis: snort, tcpdump, nmap

Etiqueta:

File Formats

Artículos:

  • Archive: zip, tar, gfzip
  • Database: sqlite, olm, Thumbs.db
  • Disk Image: aff, raw image, qcow image format

Artículos necesitados de ser ampliados

Existen un número de artículo los cuales requieren “amor”. De ser factible su ayuda, se sugiere leer sobre como contribuir al proyecto.

Forensics Wiki ahora está en GitHub y acepta contribuciones de contenido desde la comunidad. Consulte la página de la comunidad para obtener instrucciones sobre como agregar o editar contenido.

Fuentes:

https://forensics.wiki/
https://osdfir.blogspot.com/2022/11/transitioning-forensics-wiki-to-git…
https://forensics.wiki/community/

Script http-aspnet-debug de Nmap

Body

Este script correspondiente al motor para scripts de Nmap, determina si una aplicación ASP.NET tiene habilitada la depuración, mediante una petición HTTP DEBUG.

El verbo HTTP DEBUG es utilizado en aplicaciones ASP.NET para iniciar/detener sesiones de depuración remota. El script envía un comando 'detener-depurar' para determinar el estado de configuración actual correspondiente a la aplicación, pero se requiere acceso a los servicios RPC para interactuar con la sesión de depuración. La petición no cambia la configuración de depuración de la aplicación.

Se procede a utilizar el script de nombre “http-asptnet-debug”

$ sudo nmap -n -Pn -sV -p80,443 --script http-aspnet-debug coxyz edu .pe

En este ejemplo se escanearon únicamente los puertos TCP 80 y TCP 443, en los cuales se identificó un servicio Apache httpd. En ambos puertos este script expone como estado, el verbo DEBUG está habilitado.

Fuentes:

https://nmap.org/nsedoc/scripts/http-aspnet-debug.html

Evaluar CSP - Política de Seguridad para Contenido

Body

Content Security Policy (CSP), es una política declarativa de listas permitidas las cuales se aplican a través de la cabecera de respuesta Content-Security-Policy, o un elemento equivalente. Permite a los desarrolladores restringir las fuentes desde las cuales se cargan recursos como JavaScript, CSS, imágenes, archivos, etc. CSP es una técnica eficaz para defensa en profundidad, y de esta manera mitigar el riesgo de vulnerabilidades como Cross Site Scripting (XSS) y Clickjacking.

La Política de Seguridad de Contenidos soporta directivas, las cuales permiten un control granular del flujo de las políticas.

Utilizando el comando curl, se procede a obtener y revisar la cabecera o el elemento meta, para identificar inadecuadas configuraciones.

$ curl -s --head https:// www. xyz .com

Para evaluar por inadecuadas configuraciones en CSP, se busca por configuraciones inseguras examinando la cabecera de respuesta “Content-Security-Policy”, o el elemento meta.

  • unsafe-inline Esta directiva permite scripts o estilos en linea, lo cual genera las aplicaciones sean susceptibles a ataques XSS.
  • unsafe-eval Esta directiva permite el uso de eval() en la aplicación, además es susceptible a técnicas comunes de evasión, como inyección URL de datos.
  • unsafe-hashes Esta directiva permite el uso de scripts/estilos en línea, asumiendo coincidan con los hashes especificados.
  • Recursos como scripts pueden ser permitidos de ser cargados desde cualquier origen mediante la utilización del comodín (*) source.
    • También considerar comodines basados en coincidencias parciales, como: https: //* o *.cdn. com.
    • Considerar si las fuentes listadas permitidas proporcionan JSONP de puntos final, lo cual podría ser utilizado para evadir CSP o la política del mismo origen.
  • Framing puede ser habilitado para todos los orígenes mediante el uso del comodín fuente (*) para la directiva frame-ancestors. Si la directiva frame-ancestors no está definida en la cabecera Content-Security-Policy, las aplicaciones pueden ser vulnerables a ataques de clickjacking.
  • Aplicaciones críticas para el negocio deberían requerir el uso de una política estricta.
  • Se sugiere configurar una política fuerte para seguridad de contenidos, la cual reduzca la superficie de ataque de la aplicación. Los desarrolladores pueden verificar la fortaleza de la política para seguridad de contenidos mediante herramientas en línea como Google CSP Evaluator.

    Fuentes:

    https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
    https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…
    https://csp-evaluator.withgoogle.com/

    Evaluar HSTS - Seguridad de Transporte Estricto para HTTP

    Body

    La función HTTP Strict Transport Security (HSTS) permite un servidor web informe al navegador del usuario, a través de una cabecera de respuesta especial, nunca debe establecer una conexión HTTP no cifrada con los servidores de dominio especificados. En lugar de esto, debería establecer automáticamente todas las peticiones de conexión para acceder hacia el sitio a través de HTTPS. Esto también evita los usuarios anulen los errores del certificado.

    Considerando la importancia de este mecanismo de seguridad, es prudente verificar el sitio esté utilizando esta cabecera HTTP para garantizar todos los datos viajen encriptados entre el navegador web y el servidor.

    El encabezado de seguridad de transporte estricto HTTP utiliza tres directivas específicas:

    • max-age: para indicar la cantidad de segundos en los cuales el navegador debe convertir automáticamente todas las peticiones HTTP hacia HTTPS.
    • includeSubDomains: para indicar todos los subdominios relacionados deben usar HTTPS.
    • preload No oficial: para indicar los dominios están en la lista de precarga y los navegadores nunca deben conectarse sin HTTPS. Si bien esto es compatible con todos los principales navegadores, no es una parte oficial de la especificación.

    A continuación se presenta un ejemplo de la implementación del encabezado HSTS:

    $ curl -s –head https:// www. xyz. pe

    Se debe verificar la presencia de este encabezado, pues su ausencia podría generar problemas de seguridad como:

    • Los atacantes interceptan y acceden a información transferida a través de un canal de red no cifrado.
    • Atacantes realizan ataques para manipulación en el medio (MITM), aprovechándose de los usuarios aceptando certificados los cuales no son de confianza.
    • Usuarios ingresando por error una dirección en el navegador usando HTTP en lugar de HTTPS, o usuarios haciendo clic en un enlace correspondiente a una aplicación web utilizando incorrectamente el protocolo HTTP.

    Se confirma la presencia de la cabecera HSTS examinando la respuesta desde el servidor.

    Fuentes:

    https://https.cio.gov/hsts/
    https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…
    https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transp…

    WhatWeb

    Body

    WhatWeb identifica sitios web. Su meta es responder a la pregunta "¿Qué es ese sitio web?". WhatWeb reconoce las tecnologías web, incluyendo los sistemas para administración de contenido (CMS), plataformas para blogs, paquetes para estadísticas/análisis, librerías JavaScript, servidores web, y dispositivos incorporados. WhatWeb tiene más de 1,800 complementos, cada uno para reconocer algo diferente. WhatWeb también identifica números de versión, direcciones de correo electrónico, ID de cuenta, módulos de framework web, errores SQL, y más.

    WhatWeb puede ser sigiloso y rápido, o minucioso pero lento. WhatWeb admite un nivel de agresión para controlar el equilibrio entre velocidad y fiabilidad. Cuando visita un sitio web en su navegador, la transacción incluye muchos indicios sobre cuales tecnologías web están impulsando este sitio web. Algunas veces, una sola visita hacia una página web contiene suficiente información para identificar el sitio web, pero cuando no es así, WhatWeb puede interrogar más al sitio web. El nivel predeterminado de agresión, llamado "sigiloso", es el más rápido y requiere solo una petición HTTP de un sitio web. Esto es adecuado para escanear sitios web públicos. Se han desarrollado modos más agresivos para su uso en pruebas de penetración.

    La mayoría de los plugins de WhatWeb son completos y reconocen una diversidad de señales, desde sutiles hasta obvias. Por ejemplo la mayoría de los sitios web de WordPress se pueden identificar mediante la etiqueta meta HTML, p. '', pero una minoría de sitios web de WordPress elimina esta etiqueta de identificación, pero esto no frustra a WhatWeb. El plugin de WhatWeb para WordPress tiene más de 15 pruebas, las cuales incluyen verificar el favicon, archivos de instalación predeterminados, páginas de inicio de sesión, y verificar "/ wp-content /" dentro de los enlaces relativos.

    Al ejecutar la herramienta whatweb con la opción “-h”, se muestra un resumen de sus principales opciones.

    $ whatweb -h

    El modo más simple para escanear un sitio web es simplemente definiéndolo.

    $ whatweb https:// cee xxxx.pe

    Se escanean dos sitios web con descripciones verbosas de los plugins

    $ whatweb -v https:// xxxx.pe https:// xxxx.pe

    La opción “-v“ genera verbosidad incluyendo las descripciones de los plugins. Utilizar dos veces para depuración.

    Dado el hecho se han definido dos sitios web a escanear, se presenta la información obtenida del segundo sitio web de manera secuencial.

    Se procede a ejecutar un un escaneo agresivo.

    $ whatweb -a 3 https:// xxxx .pe/

    La opción “-a” controla los niveles de agresión, una compensación entre velocidad/sigilosidad y fiabilidad. El número “3” implica si un plugin de nivel 1 coincide, se realizarán peticiones adicionales.

    Es factible con whatweb escanear una red rápidamente suprimiendo los mensajes de error.

    $ whatweb --no-errors 137.116.79.103/24

    La opción “--no-errors” suprime los mensajes de error.

    Entre la información obtenida de todos los escaneos realizados se tienen; país, tecnologías utilizada y sus versiones, direcciones IP, título, cabeceras poco comunes, mensajes de error, cabeceras HTTP, códigos HTTP, redirecciones, correos electrónicos, sistema operativo y su versión, versión SSL/TLS, métodos HTTP soportados, entre otros elementos.

    Esta información es muy importante para tratar de obtener una huella digital sobre los componentes utilizados por las aplicaciones web.

    Fuentes:

    https://github.com/urbanadventurer/WhatWeb
    https://www.morningstarsecurity.com/research/whatweb

    El Spider de Zed Attack Proxy

    Body

    El Spider o “Araña” es una herramienta la cual se utiliza para descubrir automáticamente nuevos recursos (URLs) en un sitio particular. Inicia con una lista de URLs a visitar, denominadas semillas, lo cual depende de como se inicie el Spider. Luego el Spider visita estas URLs, identificando todos los hipervínculos en la página, para luego agregarlos a la lista de URLs a visitar , continuando el proceso de manera recursiva, siempre se encuentren nuevos recursos.

    El Spider puede ser configurado e iniciado utilizando el recuadro de diálogo “Spider”.

    Durante el procesamiento de una URL, El Spider realiza una petición para obtener el recurso, para luego analizar la respuesta, identificando así los hipervínculos. Actualmente tiene el siguiente comportamiento al procesar tipos de respuestas:

    El Spider es configurado utilizando la Pantalla de Opciones del Spider.

    HTML

    Procesa etiquetas específicas, identificando enlaces hacia nuevos recursos:

    • Base - Manejo adecuado
    • A, Link, Area, Base - atributo 'href'
    • Applet, Audio, Embed, Frame, IFrame, Input, Script, Img, Video - atributo 'src'
    • Blockquote - atributo 'cite'
    • Meta: 'http-equiv' para 'location', 'refresh' y 'Content-Security-Policy', 'name' para 'msapplication-config'
    • Applet - 'codebase', atributos de 'archive'
    • Img - Atributos 'longdesc', 'lowsrc', 'dynsrc', 'srcset'
    • Isindex - atributo 'action'
    • Object - 'base de código', atributos 'data'
    • Param - atributo 'value'
    • Svg: atributos 'href' y 'xlink:href' de los elementos 'image' y 'script'
    • Table - atributo 'background'
    • Video - atributo 'poster'
    • Form: manejo adecuado de formularios con el método GET y POST. Los valores de los campos se generan de forma válida, incluidos los tipos de entrada de HTML 5.0 'form', 'formaction', 'formmethod', y los atributos de botones también son respetan.
    • Comentarios: etiquetas válidas encontradas en comentarios también se analizan, si se especifican en la pantalla de opciones del Spider.
    • Import - atributo de 'implementation'
    • Inline string: etiquetas 'p', 'title', 'li', 'h1', 'h2', 'h3', 'h4', 'h5', 'h6' y 'blockquote'

    Archivo robots.txt

    Si se configura en la pantalla de Opciones del Spider, también analiza el archivo 'Robots.txt', y se intenta identificar nuevos recursos utilizando las reglas especificadas. Cabe mencionar el Spider no sigue las reglas especificadas en el archivo 'Robots.txt'.

    Archivo sitemap.xml

    Si se configura en la pantalla de Opciones del Spider, el Spider también analiza el archivo 'sitemap.xml' e intenta identificar nuevos recursos.

    Archivos metadatos SVN

    Si se configura en la pantalla de Opciones del Spider, el Spider también debe interpretar los archivos de metadatos SVN e intentar identificar nuevos recursos.

    Archivos metadatos Git

    Si se configura en la pantalla de Opciones del Spider, el Spider también debe interpretar los archivos de metadatos de Git e intentar identificar nuevos recursos.

    Archivos .DS_Store

    Si se configura en la pantalla de Opciones del Spider, el Spider también debe interpretar archivos .DS_Store e intentar identificar nuevos recursos.

    Archivos Atom OData

    El Spider también debe interpretar los archivos .DS_Store, e intentar identificar nuevos recursos. El contenido de OData utilizando el formato Atom es actualmente soportado. Se procesan todos los enlaces incluidos (relativos o absolutos).

    Archivos SVG

    Los archivos de imagen SVG se analizan para identificar los atributos HREF y extraer/resolver cualquier enlace contenido.

    Respuesta de Texto No HTML

    Las respuestas de texto se analizan analizando el patrón de URL

    Respuesta No Texto

    Las respuestas de texto se analizan analizando el patrón de URL. Actualmente, el Spider no procesa este tipo de recursos.

    Otros Aspectos

    • Cuando se verifica si una URL ya se visitó, el comportamiento en relación a como se manejan los parámetros, se puede configurar en la pantalla de Opciones del Spider.
    • Cuando se verifica si una URL ya se visitó, existen algunos parámetros comunes los cuales se ignoran: jsessionid, phpsessid, aspsessionid, utm_*
    • El comportamiento del Spider con respecto a las cookies, depende de cómo se inicia el Spider y cuales opciones están habilitadas. Para obtener más detalles, consulte la pantalla Opciones de lSpider.

    Fuentes:

    https://www.zaproxy.org
    https://www.zaproxy.org/docs/desktop/addons/spider/

    humans.txt

    Body

    human.txt es una iniciativa para conocer a las personas quienes están detrás de un sitio. Toma la forma de un archivo de texto contiendo información sobre las diferentes personas quienes han contribuido con la construcción del sitio. Este archivo frecuentemente;pero no siempre; contiene información relacionada con la carrera o sitios/rutas laborales.

    El archivo "humans.txt" puede ser visualizado directamente a través de un navegador web, o ser descargado, para luego ser visualizado.

    El archivo puede estar presente en la raíz del servidor web o en el directorio de nombre /.well-known/

    https:// example. com/humans.txt

    Entre la información obtenida se incluyen los nombres completos de personas laborando para la organización, incluyendo su cargo. Como también detalles precisas sobre las tecnologías web utilizadas para el sitio web.

    Existen varias razones por las cuales esto podría ser de interés en los escenarios de prueba, incluyendo:

    • Recopilación de inteligencia desde fuentes abiertas
    • Reconocimiento y Mapeo de la aplicación web
    • Ataques de ingeniería social

    Fuentes:

    https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…

    security.txt

    Body

    “Cuando los riesgos de seguridad en servicios web son descubiertos por investigadores independientes en seguridad, quienes comprenden la severidad del riesgo, frecuentemente carecen de los canales para exponerlos adecuadamente. Como resultado de esto, los problemas de seguridad pueden quedar sin ser reportados. security.txt define un estándar para ayudar a las organizaciones a definir el proceso para los investigadores de seguridad divulguen las vulnerabilidades de seguridad de manera segura”.

    Los archivos security.txt han sido implementados por Google, Facebook, GitHub, gobierno del Reino Unido y muchas otras organizaciones. Además, el Ministerio de Justicia del Reino Unido, la Agencia de Seguridad de Infraestructura y Ciberseguridad (EE. UU.), el gobierno francés, el gobierno italiano, el gobierno holandés y el Centro de Seguridad Cibernética de Australia respaldan el uso de archivos “security.txt”.

    El archivo “security.txt” puede ser visualizado directamente a través de un navegador web, o ser descargado, para luego ser visualizado.

    El archivo puede estar presente en la raíz del servidor web o en el directorio de nombre /.well-known/

    https:// example. com/security.txt
    https:// example. com/.well-known/security.txt

    Existen múltiples razones por las cuales esto podría ser de interés en los escenarios de prueba, incluyendo:

    • Identificar rutas o recursos adicionales para incluir en el descubrimiento/análisis
    • Recopilación de inteligencia desde fuentes abiertas
    • Encontrar información sobre Bug Bounties, etc
    • Ingeniería social

    Fuentes:

    https://securitytxt.org/
    https://www.rfc-editor.org/rfc/rfc9116.html
    https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_A…

    Plugin headers de Nikto2

    Body

    Desde Nikto 2.1.2 los plugins puede ser seleccionados individualmente, además de ser factible definir directamente parámetros.

    Una cadena para la selección de plugins puede ser pasada a través de la línea de comandos, utilizando el parámetro “-Plugin”. Está constituida de una lista de nombres de plugins separados por punto y coma, incluyendo los parámetros de opción entre paréntesis.

    La opción “-list-plugins” mostrará los nombres de los plugins y parámetros.

    $ nikto -list-plugins

    Para la siguiente demostración se utiliza el plugin de nombre “headers” incluido en Nikto2, el cual realizará varias verificaciones contra las cabeceras devueltas desde una petición HTTP.

    $ nikto -host 192.168.0.82 -port 80,443,5800,5985 -Plugin headers

    La opción “-host” define la dirección IP o nombre de host a escanear

    La opción “-port” define el puertos o puertos a escanear separados por comas.

    La opción “-Plugin” define la cadena de plugins seleccionados a ejecutar

    Para la presente demostración se ha definido el escaneo de cuatro puertos TCP, en los cuales Nmap identifico previamente servicios HTTP.

    Finaliza la ejecución de Nikto2 y el plugin “headers”, en los resultados se encuentra información sobre versiones del servidor web, módulos y sus versiones, cabeceras no definidas, información sobre SSL, redirecciones, o algún tema relevante desde la perspectiva de la ciberseguridad.

    Aunque la información expuesta por el servidor no es necesariamente en sí misma una vulnerabilidad, es información la cual puede ayudar a los ciberatacantes a explotar otras vulnerabilidades existentes. Esta información también puede llevar a los ciberatacantes a encontrar vulnerabilidades específicas sobre la versión del servidor.

    Fuentes:

    https://cirt.net/Nikto2
    https://github.com/sullo/nikto/wiki/Selecting-Plugins