blog

EDRM crea un recurso práctico para mejorar el descubrimiento electrónico y el gobierno de la información. Fue lanzado en el mes de Mayo del año 2005. EDRM fue creado para hacer frente a la ausencia de estándares y directrices en el mercado del descubrimiento electrónico. EDRM publicó el Modelo de Referencia para Descubrimiento Electrónico en el mes de Enero del año 2006, seguido por recursos adicionales como IGRM (Information Governance Reference Model), CARRM (Computer Assisted Review Reference Model) y la Matriz de Tareas de Talento. Desde su lanzamiento, EDRM ha comprometido a más de 260 organizaciones, incluyendo 170 proveedores de servicios y software, 63 firmas de abogados, tres grupos de la industria y 23 corporaciones involucradas con el descubrimiento electrónico y gobierno de la información.

El diagrama RDRM representa una vista conceptual del proceso de descubrimiento electrónico, no un modelo literal, lineal o de cascada. Se podría participar en algunos, pero no en todos las fases delineadas en el diagrama, pero se podría seleccionar un orden diferente para realizar las fases mostradas.

El diagrama también representan un proceso iterativo. Se podría repetir la misma fase varias veces, conduciendo a un conjunto más preciso de resultados. Se podría también pasar nuevamente sobre las fases anteriores, refinando el enfoque para una mejor comprensión de los datos que surgen.

El diagrama pretende ser un base base para la discusión y el análisis, no como una receta de la manera correcta de proceder con el descubrimiento electrónico.

A continuación se presenta un resumen con las explicaciones de cada fase del EDRM.

Gestión de la Información

Tener un hogar electrónico con el fin de mitigar el riesgo y gastos podría convertir en un problema al descubrimiento electrónico, desde la creación inicial de la información almacenada electrónicamente hasta su disposición final

Identificación

Localizar probables fuentes de ESI (Información almacenada electrónicamente) y determinar su alcance, amplitud y profundidad.

Preservación

Asegurarse que la ESI está protegido contra alteración inapropiada o destrucción.

Recolección

Capturar la ESI para uso posterior en el proceso de descubrimiento electrónico (procesamiento, revisión, etc.)

Procesamiento

Reducir el volumen de ESI y convertirla, si es necesario, a formas más confortables para revisión y análisis.

Revisión

Evaluar la ESI de relevancia y priilegio.

Análisis

Evaluar la ESI de contenido y contexto, incluyendo patrones clave, tópicos, personas y discusión.

Producción

Entregar la ESI a otros en formas adecuadas y utilizando mecanismos de entrega adecuados.

Presentación

Mostrar la ESI ante audiencias (en las deposiciones, audiencias, juicios, etc.) especialmente en formas nativas o casi nativas, para generar mayor información, validar hechos o posiciones, o persuadir a una audiencia.

Fuente:

http://www.edrm.net/resources/edrm-stages-explained

Detectar malware al nivel del BIOS o “bootkits” es una ardua tarea utilizando herramientas estándar como antivirus y otros sistemas IDP/IPS. La instalación de un "bookit" puede ocurrir antes de que el sistema operativo sea instalado, como en la cadena de suministro del fabricante, o por un troyano que tiene permisos de root para “flashear” el BIOS con su propia versión parcheada. Los ataques dirigidos a sistemas de hardware específico pueden ser realizados utilizando tales métodos. La mayoría de soluciones basadas en software para detectar esto pueden ser fácilmente comprometidos, si el Sistema Operativo es comprometido. Con Bootjack se presenta una solución basada en hardware que finge ser una unidad usb para escanear la BIOS y el MBR de los discos duros, además de realizar una verificación de firmas y análisis forense del BIOS.

El video con la presentación de Bootjack puede ser visualizado desde el siguiente enlace:

http://vimeo.com/81611881

En los cursos de Informática Forense que tengo la oportunidad de dictar, siempre se formula una pregunta recurrente, la cual versa sobre la legalidad, sustento, cuestionamieto, refutación de utilizar herramientas open source; como las encontradas en GNU/Linux; durante un análisis forense. Lo siguiente, es una introducción en idioma español de un excelente documento que expone bien este tema, escrito por Brian Carrier desarrollador principal de The Sleuth Kit & Autopsy.

El Argumento Legal
Escrito por Brian Carrier

Resúmen

Este documento versa sobre las herramientas de análisis forense y su utilización en un entorno legal. Para ingresar evidencia científica en una corte de los Estados Unidos, una herramienta debe ser confiable y relevante. La confiabilidad de la evidencia se prueba mediante la aplicación de las directrices de “Daubert”. A la fecha, existen pocos retos legales contra la evidencia digital, pero conforme el campo madure esto cambiará. Este documento examina la directriz de Daubert y muestra que las herramientas open source podrían apegarse de forma más clara y global con estas directrices que las herramientas de código cerrado.

Introducción:

El debate entre el software open source y herramientas de código cerrado ha librado problemas filosóficos, de seguridad, de confiabilidad, y soporte. Cada lado tiene sus argumentos que resuena con diferentes poblaciones de usuarios y no parece tener un claro ganador.

Este documento versa sobre el software que es utilizado para análisis forense forense digital y examina el rol del open source. Estas herramientas son utilizadas para analizar datos digitales y algunas veces encontrar evidencia de lo que alguien hizo o no en la comisión de un crimen. Como la salida de la herramienta puede ser evidencia presentada en una corte, debe cumplir ciertos requisitos legales. Este documento examina los requerimientos legales que las herramientas open source deben satisfacer.

El Forense digital ha existido durante tanto tiempo como las computadoras han almacenado datos que podrían ser utilizados como evidencia. Por muchos años, el forense digital ha sido realizado principalmente por agencias del gobierno, pero se ha hecho más común en el sector comercial durante los últimos años. Originalmente, mucho del software de análisis era personalizado y propietario y eventualmente un software de análisis especializado se hizo disponible para los sectores público y privado. Recientemente, se han desarrollado alternativas open source que proporcionan características comparables.

La primera parte de este documento proporciona una breve revisión de como las herramientas forenses digitales son utilizadas, seguido por directrices legales para proporcionar confiabilidad de la evidencia científica. Estas directrices son luego expuestas con respecto al software open source. Finalmente, se propone una solución balanceada que permite a las compañías de software comercial permanezcan competitivas manteniendo código fuente cerrado relacionado a la interfaz mientras se tiene el código de extracción open source y disponible para revisión pública . La solución permite a los usuarios tener soporte comercial y la libertad de seleccionar una herramienta basada en la interfaz y facilidad de uso.

Fuentes:

http://www.digital-evidence.org/papers/opensrc_legal.pdf
http://en.wikipedia.org/wiki/Daubert_standard
http://papers.ssrn.com/sol3/papers.cfm?abstract_id=498786

Mientras que los servicios más populares en Internet se ejecutan sobre el protocolo TCP, los servicios UDP están ampliamente desplegados. DNS, SNMP, y DHCP (en los puertos registrados 53, 161/162, y 67/68) son los tres más comunes. Debido a que el escaneo UDP es generalmente más lento y más difícil que TCP, algunos auditores en seguridad ignoran estos puertos. Esto es un error, pues servicios UDP explotables son comunes y los atacantes ciertamente no ignoran este protocolo. Afortunadamente Nmap puede ayudar a inventariar los puertos UDP.

El escaneo UDP se activa con la opción (-sU). Puede ser combinada con un tipo de escaneo TCP, tal como el escaneo SYN (-sS) para verificar ambos protocolos en la misma ejecución.

El escaneo UDP funciona enviando paquetes UDP a cada puerto del objetivo. Para algunos puertos comunes como el 53 y 161, se envía una carga específica del protocolo, pero la mayoría de puertos el paquete está vacío. La opción (--data-lenght) puede ser utilizada para enviar una carga aleatoria a cada puerto o (si se especifica el valor de 0) se deshabilita la carga. Si un error “ICMP port unreachable” (tipo 3, código 3) es devuelto, el puerto está cerrado (closed). Otros errores “ICMP unreachable (tipo 3, códigos 1, 2, 9, 10 y 13) marcan el puerto como filtrado (filtered). Ocasionalmente, un servicio responderá con un paquete UDP, indicando que está abierto (open). Si no se recibe respuesta después de las retransmisiones, el puerto es clasificado como abierto|filtrado (open|filetered). Esto significa que el puerto podría está abierto, o tal vez filtros de paquetes están bloqueando la comunicación. El escaneo de detección de versión (-sV) puede ser utilizado para ayudar a diferenciar los puertos abiertos en verdad de aquellos filtrados.

Un gran reto para los escaneos UDP es hacerlos rápidos. Los puertos abiertos o filtrados raramente envían una respuesta, dejando a Nmap un tiempo de espera y luego realizar una retransmisión, solo en caso que la prueba o respuesta sea perdida. Los puertos cerrados son frecuentemente un gran problema. Estos usualmente no envían de regreso un error“ICMP port unreachable”. Pero a diferencia de los paquetes RST envían por los puertos TCP cerrados en respuesta a un escaneo Connect o SYN, muchos host raramente limitan los mensajes “ICMP port unreachable” por defecto. Linux y Solaris son particularmente estrictos sobre esto. Por ejemplo el kernel de Linux 2.4.20 limita los mensajes “destination unreachable” a uno por segundo (en net/ipv4/icmp.c).

Nmap detecta el límite de velocidad y desacelera para evitar la inundación de la red con paquetes inútiles que la máquina objetivo descarta. Desafortunadamente, el limite al estilo linux de un paquete por segundo hace que un escaneo UDP a 65,536 puerto pueda tomar más de 18 horas. Algunas ideas para mejorar la velocidad de los escaneos UDP, implican escanear más objetivos en paralelo, realizar primero escaneos rápidos a los puertos más populares, escanear por detrás del firewall, y utilizar (--host-timeout) para evitar objetivos lentos.

Utilizando nmap se realiza un escaneo UDP contra Metasploitable2. Nótese como el tiempo aproximado para el termino del escaneo es de aproximadamente 19 horas.

Utilizando otro escaner de puertos unicorscan, se procede a realizar el mismo escaneo de puertos UDP. Nótese como el tiempo total no supera los 4 minutos.

Para verificar la fiabilidad de los resultados, se sugiere compararlos con los puertos UDP en atención en Metasploitable2.

Fuentes:

http://nmap.org/book/man-port-scanning-techniques.html
http://www.unicornscan.org/
http://sourceforge.net/projects/metasploitable/files/Metasploitable2/

Es un entorno Linux “Vivo” basado en Ubuntu, el cual ha sido configurado previamente para funcionar como un entorno para realizar Pruebas de Penetración Web. Contiene las mejores herramientas libres y open source, las cuales están orientadas a evaluar y atacar sitios web y sus aplicaciones. Los creadores basaron la selección de las herramientas incluidas en Samurai, en aquellas que son más utilizadas en sus trabajos.

Samurai WTF 2.0 tiene más de 100 herramientas, extensiones, y scripts, entre los cuales se incluyen; W3af (Open Source Web Application Security Scanner), BeEF (Browser Exploitation Framework), Burp Suite, OWASP ZAP (Zed Attack Proxy), Grendel-Scan, Rat Proxy, OWASP DirBuster CeWL (Custom Word List generator), SQLmap, Maltego CE, OWASP WebScarab, Nmap, Nikto2, Metasploit Framwork, etc.

Samurai WFT 2.0 puede ser descargado como un archivo ISO o como una máquina virtual. Así mismo se puede descagar libremente las diapositivas en idioma inglés utilizadas en un excelente Curso titulado "Assessing and Exploiting Web Applications with SamuraiWTF", o por su traducción al idioma español "Evaluando y Explotando Aplicaciones Web con Samurai".

Características de Samurai

• SamuraiWTF 2.0, es una reconstrucción completa de esta distribución orientada a Pruebas de Penetración Web.
• Incluye KDE, Gnome y Unity.
• Duplica el número de herramientas de su antecesor.
• Ahora todas las herramientas pueden ser accedidas en el $PATH.
• El objetivo es mover todo el software y configuraciones a paquetes de Debian.
  • Actualizar todas las herramientas unicamente con el comando “sudo apt-get upgrade”.
  • La capacidad de añadir herramientas de SamuraiWTF a cualquier distribución Ubuntu/Debian editando el archivo “/etc/apt/sources.list”.
  • Facilitar la colaboración dentro del equipo de desarrollo.

Fuentes:

http://www.samurai-wtf.org/
http://sourceforge.net/projects/samurai/files/

Los ataques Cross Site Scripting son un tipo de problema de inyección, en el cual scripts maliciosos son inyectados dentro de sitios webs confiables y benignos. El ataque XSS ocurre cuando un atacante utiliza una aplicación web para enviar código maliciosos, generalmente en la forma de un script en el lado del navegador, a un usuario final diferente. Las fallas que permiten a este tipo de ataque ser satisfactorios está ampliamente diseminados y cuando en cualquier lugar donde la aplicación web utiliza una entrada del usuario para la salida que esta generada sin validarlo o codificarlo.

Un atacante puede utilizar un XSS para enviar un script malicioso a un usuario desprevenido. El navegador del usuario final no tiene manera de conocer si el script podría no ser confiable, y podría ejecutar el script. Debido a este pensamiento de que el script proviene de una fuente de confianza, el script maliciosos puede acceder a cualquier cookie, tokens de sesión, y otra información sensible retenida por el navegador y utilizado con este sitio. Estos script puede reescribir el contenido de un página HTML.

Para los siguientes ejemplos se utiliza DVWA (Damn Vulnerable Web Application) que se incluye en la Máquina Virtual de OWASP Broken Web Applications Project.

Nivel Bajo (Low)

Esto se obtiene al visualizar el código fuente:

Se realiza la evaluación utilizando el siguiente código:

Siendo el resultado de la prueba lo mostrado en la siguiente imagen

Nivel Medio (Medium)

Al visualizar el Código fuente se identifica la función str_replace de PHP, la cual devuelve un string o un array con todas las apariciones de search en subject reemplazadas con el valor dado de replace.

Si no se necesitan reglas complicadas de reemplazo (como expresiones regulares), se puede utilizar siempre esta función en lugar de preg_replace().

Se realiza la evaluación utilizando el siguiente código

Siendo el resultado de la prueba lo mostrado en la siguiente imagen

Nivel Alto (High)

Al visualizar el Código fuente se identifica la función htmlspecialchars.

Ciertos caracteres tienen un significado especial en HTML y deben ser representados por entidades HTML si se desea preservar su significado. Esta función devuelve un string con estas conversiones realizadas. Si se requiere que todas las subcadenas de entrada tengan asociadas entidades con nombre para que sean traducidas, use htmlentities() en su lugar.

Si el string de entrada pasado a esta función y el documento final comparten el mismo conjunto de caracteres, esta función es suficiente para preparar entradas para su inclusión en la mayoría de los contextos de un documento HTML. Sin embargo, si la entrada puede representar caracteres que no están codificados en el conjunto de caracteres del documento final, y es necesario conservar dichos caracteres (tales como números o entidades con nombre), esta función y htmlentities() (la cual solamente codifica subcadenas que tienen equivalentes de entidades con nombre) podrían ser insuficientes. Se podría usar mb_encode_numericentity() en su lugar.

Fuentes:
https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
https://www.owasp.org/index.php/OWASP_Broken_Web_Applications_Project
http://www.dvwa.co.uk/
http://www.php.net/manual/es/function.str-replace.php
http://php.net/htmlspecialchars

SHODAN Motor de Búsqueda que permite encontrar computadores (routers, servidores, etc.) específicos, utilizando una variedad de filtros. Algunos también lo han descrito como un directorio público de escaneo de puertos o un motor de búsqueda de banners.

Los motores de búsqueda web, como Google y Bing, son magníficos para encontrar sitios web. ¿Pero que sucede si se está interesado en encontrar computadoras ejecutando cierta pieza de software (como Apache)? ¿O que sucede si se desea conocer cual es la versión de Microsoft IIS más popular?, ¿O que sucede si se desea conocer cuantos servidores FTP anónimos existen?. ¿O que sucede si se ha publicado una nueva vulnerabilidad y se desea conocer cuantas computadoras podrían ser infectadas?. Los motores de búsqueda tradicionales no permiten responder estas interrogantes.

¿Cómo es que indexa entonces SHODAN? Estas es una buena pregunta. La mayoría de datos es tomado de los “banners”, los cuales son metadatos que el servidor envía de regreso al cliente. Esta puede ser información sobre el software del servidor, cuales son las opciones que soporta el servicio, un mensaje de bienvenida o cualquier cosa que el cliente puede desear conocer antes de interactuar con el servidor.

Para utilizar algunas de las funcionalidades de Shodan es necesario registrarse para obtener una cuenta de usuario. Al ingresar con un usuario y contraseña válido, esta es la interfaz de Shodan.

Guía Rápida de Filtros

after/ before Limita los resultados por fecha en el formato día/mes/año (ejemplo before:01/12/2013)

city Nombre de la ciudad (ejemplo: city:"Lima")

country Código del país en 2-letras (ejemplo country:PE)

port 21, 22, 23, 80, 161 o 443

os Sistema operativo (ejemplo os:Linux)

net Rango de direcciones IP utilizando notación CIDR (ejemplo net:190.118.176.0/24 )

hostname Nombre del host completo o parcial (ejemplo hostname:peru)

Fuente: http://www.shodanhq.com/

Características

El sistema Bugtraq ofrece la distribución más amplia, óptima, y estable con un manejador de servicios automático en tiempo real. Esta distribución basada en un kernel 3.2 y 3.4 genérico está disponible en 32 y 64 bits con una amplia gama de herramientas de penetración, forense y de laboratorio. Los sistemas están disponibles en 11 diferentes lenguajes.

Herramientas

Una de las principales novedades de Bugtraq es el amplia gama de herramientas en diferentes ramas. Se pueden encontrar herramientas para forense de móviles, laboratorios para prueba de malware, herramientas de la comunidad Bugtraq, herramientas de auditoría para GSM, inalambrico, bluetooth, y RFID, herramientas integradas en Windows, herramientas enfocadas en IPv6, y las herramientas típicas de pruebas de penetración y forense que no deben faltar en Bugtraq 2.

Fuente: http://bugtraq-team.com/

Mientras que muchos escaners de puertos tradicionalmente agrupan todos los puertos en estados de abierto o cerrado, Nmap es mucho más preciso. Divide los puertos en seis estados: open, closed, filtered, unfiltered, open|filtered o closed|filtered

Estos estados no son propiedades intrínsecas del puerto por si mismo, sino que describen como Nmap los visualiza. Por ejemplo un escaneo con Nmap en la misma red del objetivo puede mostrar el puerto 135/tcp abierto, mientras que un escaneo al mismo tiempo con las mismas opciones a través de Internet podría mostrar que el puerto está “filtered” (filtrado).

Los seis estados de puertos reconocidos por Nmap son:

1. open

Una aplicación está activamente aceptando conexiones TCP, datagramas UDP o asociaciones SCTP a este puerto. Encontrarlos es frecuentemente el principal objetivo del escaneo de puertos. Gente mentalizada en seguridad conoce que cada puerto abierto es una vía para un ataque. Los atacantes y hackers éticos desean explotar estos puertos abiertos, mientras que los administradores intentan cerrar o protegerlos con firewalls sin impedirlos a usuarios legítimos. Los puertos abiertos también son interesantes para escaneo no orientados a la seguridad porque muestran servicios disponibles para ser usados en la red.

2. closed

Un puerto cerrado se puede acceder (este recibe y responde a los paquetes de prueba de Nmap), pero no hay una aplicación atendiendo en este. Esto puede ser útil para mostrar que un host está en funcionamiento en una dirección IP (descubrimiento del host, o escaneos ping), y como parte de la detección del Sistema Operativo. Debido a que los puertos cerrado son alcanzables, puede ser útil escanearlos más adelante en caso alguno se abra. Los Administradores deben considerar bloquear estos puertos con un firewall. Luego aparecerán con un estado filtrado (filtered), discutido en el siguiente punto.

3. filtered

Nmap no puede determinar si el puerto esta abierto debido a un filtrado de paquetes que evita a las pruebas alcanzar al puerto. El filtrado puede ser en la forma de un dispositivo firewall dedicado, reglas de u router, o software de un firewall basado en host. Estos puertos frustran a los atacantes debido a que proporcionan poca información. Algunas veces responden con mensajes de error ICMP, tal como un tipo 3 código 13 “destino inalcanzable: comunicación administrativamente prohibida” (destination unreachable: communication administratively prohibited), pero los filtros que descartan las pruebas sin responder son más comunes. Esto obliga a Nmap a intentar varias veces en caso la prueba haya sido descartada debido a la congestión de la red en lugar del filtrado. Esto hace dramáticamente más lento el escaneo.

4. unfiltered

Este esta significa que el puerto se puede acceder, pero Nmap no es capaz de determinar si está abierto o cerrado. Solo el escaneo ACK, el cual es utilizado para mapear reglas de firewall, clasificar los puertos en este estado. El escaneo de puertos sin filtrar con otros tipos de escaners como escaneo Window, escaneo SYN, o escaneo FIN, puede ayudar resolver si el puerto está abierto.

5. open|filtered

Nmap pone un puerto en este estado cuando este no puede determinar si el puerto esta abierto o filtrado. Este ocurre par un tipo de escaneo en el cual los puertos dados no responden. La ausencia de respuesta podría significar también que un filtro de paquetes descarga la prueba o cualquier respuesta generada. De esta manera Nmap no conoce con seguridad si el puerto está abierto o está siendo filtrado. Los escaneos, UDP, protocolo IP, FIN, NULL, y Xmas clasifican los puertos de esta manera.

6. closed|filtered

Este estado es utilizando cuando Nmap no es capaz de determinar si un puerto está cerrado o filtrado. Este es solo utilizado para el escaneo idle IP ID.

Fuente: http://nmap.org/book/man-port-scanning-basics.html

Autopsy permite realizar una investigación forense digital. Es una interfaz gráfica para The Sleuth Kit y otras herramienta.

Las características principales de Autopsy incluyen: importar fuentes de datos (imagen, disco, archivos) y explorar estos sistemas de archivos, ejecutar módulos de análisis (asimilación), visualizar resultados de asimilación, visualizar contenido y generar reportes.

Autopsy es una aplicación que se puede expandir, proporciona un framework que permite a otros proporcionar plug-ins y proveer asimilación adicional de imagen y archivo para nuevos tipos de análisis, visores de contenido variado y diferentes tipos de reportes a ser soportados. Estos son plug-ings para varios módulos de asimilación, visores y reportes que son incluidos por defecto con autopsy.

He realizado la traducción de toda la documentación oficial de Autopsy 3; tanto la residente en el sitio web del proyecto como la documentación de ayuda que pueda ser accedida desde el programa: con el objetivo de acercar y difundir esta excelente herramienta (Autopsy 3) y también esta apasionante área de la Informática Forense.

Pueden descargar el documento en formato PDF desde el siguiente enlace.

http://www.reydes.com/archivos/Autopsy3_ReYDeS.pdf

Si encontrarán algún error o desean realizar alguna anotación sobre el documento, agradeceré me lo comuniquen directamente a mi correo electrónico: reydes@gmail.com. Muchas Gracias.

Referencias:
Autopsy3 - http://www.sleuthkit.org/autopsy/index.php
Autopsy 3 Quick Start Guide - http://www.sleuthkit.org/autopsy/docs/quick/index.html