parseando el fichero consolidated.db

Estándar

Hola a tod@s!

Como ya conoceréis, Iphone, al igual que otros smartphones, guarda información geográfica sobre los puntos en donde ha estado “el móvil”. Entre toda esta información, también se guarda la información de los puntos de acceso WI-FI que se encuentra en “el camino”, incluyendo su MAC.

Imagen 1.- Fichero Consolidated.db

En Seguridad Apple tienen un artículo bastante interesante sobre las aplicaciones existentes en Windows, las cuales extraen esta información y las pintan en Google Maps.

En el curso de Análisis Forense de dispositivos móviles que estamos impartiendo Juan Luis García Rambla y un servidor, y en donde nos estamos peleando con una serie de dispositivos, incluyendo el Iphone, estamos analizando esta información, junto con otras muchas más.

Uno de los puntos que tenemos que tocar, es la creación de herramientas simples que consigan extraer la información necesaria en alguno de los puntos de recogida de información.

Para ello, hemos preparado algunas demos con Python. Una de ellas, es la creación de dos scripts, los cuales extraerán y pintarán en Google Maps la información del fichero Consolidated.db de un Iphone 4.

El script lo único que hace es extraer los campos latitude y longitude de las tablas CellLocation y WifiLocation.

Imagen 2.- Campos WI-FI

Para ello, hemos utilizado un Wrapper llamado PyMaps, el cual pinta el mapa añadiendo las coordenadas extraídas previamente del fichero.

Los scripts no toman ningún parámetro como entrada, y únicamente tendremos que poner en un directorio creado previamente los siguientes ficheros:

Para el script GetCoords.py, una vez lanzado, éste devolverá un fichero HTML. Una vez abierto el fichero, podremos ver algo parecido a esto:

Imagen 3.- Extracción de coordenadas

En el caso del script GetWifi.py, una vez lanzado, éste devolverá un fichero HTML. Una vez abierto el fichero, podremos ver algo parecido a esto:

Imagen 4.- Extracción de coordenadas Wi-Fi

El código de los scripts….

GetCoords.py

#Horrible Script para extraer las coordenadas del fichero Consolidated.db
#El fichero se encuentra en el directorio private/var/root/Library/Caches/locationd
#Horriblemente codeado por Silverhack
import sys, sqlite3
from PyMaps import Map, PyMap
# Creamos un mapa
NewMap = Map()
NewMap.zoom = 3
connection = sqlite3.connect("consolidated.db")
cursor=connection.cursor()
cursor.execute("SELECT Latitude,Longitude from CellLocation")
for row in cursor:
 print "La latitud es %s, y la longitud es %s" % (str(row[0]),str(row[1]))
 </p>
     # Latitud y longitud
     # Importamos de la BD consolidated a las variables
     # que posteriormente pasaremos al Script PyMaps

 latitud= str(row[0])
 longitud = str(row[1])

  # Insertamos codigo html
 pointhtml = "I see you..."

     # Anyadimos el punto al mapa
 point = (latitud, longitud, pointhtml)

 NewMap.setpoint(point)
 gmap = PyMap(key="clave", maplist=[NewMap])

 mapcode = gmap.pymapjs()
showhtml = gmap.showhtml()
print showhtml
file = open('Coordenadas.html', 'w')
file.writelines(showhtml)
# Cerramos el fichero
file.close()

GetWifi.py


#Horrible Script para extraer las coordenadas WIFI junto con su MAC del fichero Consolidated.db
#El fichero se encuentra en el directorio private/var/root/Library/Caches/locationd
#Horriblemente codeado por Silverhack
import sys, sqlite3
from PyMaps import Map, PyMap
# Creamos un mapa
NewMap = Map()
NewMap.zoom = 3
connection = sqlite3.connect("consolidated.db")
cursor=connection.cursor()
cursor.execute("SELECT MAC, Latitude, Longitude from WifiLocation")
for row in cursor:
 print "La MAC es %s, La latitud es %s, y la longitud es %s" % (str(row[0]),str(row[1]),str(row[2]))
 

     # Latitud y longitud
     # Importamos de la BD consolidated a las variables
     # que posteriormente pasaremos al Script PyMaps

 latitud= str(row[1])
 longitud = str(row[2])

  # Insertamos codigo html
 pointhtml = str(row[0])

     # Anyadimos el punto al mapa
 point = (latitud, longitud, pointhtml)

 NewMap.setpoint(point)
 gmap = PyMap(key="clave", maplist=[NewMap])

 mapcode = gmap.pymapjs()
showhtml = gmap.showhtml()
print showhtml
file = open('WiFi.html', 'w')
file.writelines(showhtml)
# Cerramos el fichero
file.close()

 Para la ejecución de los scripts, tan sólo tendremos que utilizar Python 2.6 y pysqlite.

Saludos!

SYSTEM, causa y efecto. I de IV

Estándar


SYSTEM, causa y efecto II de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a todos!!

En esta serie de 4 capítulos, examinaremos las sutiles diferencias entre un usuario administrador y un usuario de sistema (SYSTEM). Estas diferencias, serán cruciales a la hora de decidir qué tipo de cuenta será necesaria para la explotación de un fallo en el sistema, o decidir si es o no imprescindible el uso de técnicas para ganar una posible elevación de privilegios. También nos ayudarán a conocer el porqué de ciertos comportamientos dispares entre cuentas aparentemente similares.
A nivel de sistema operativo, tanto la cuenta Administrador como la cuenta de sistema, son cuentas con los mismos privilegios. Esta equidad, sólo se manifiesta a nivel de ficheros. A nivel de directorios, la cuenta SYSTEM tendrá, obligatoriamente por diseño del sistema operativo, mayores privilegios que una cuenta de tipo Administrador.
La cuenta SYSTEM, es usada por el sistema operativo para la carga o precarga de elementos cruciales en el inicio del sistema operativo. Servicios y procesos que necesita Windows para el buen funcionamiento del sistema, y para el inicio del mismo. La cuenta, diseñada para ese propósito, es una cuenta interna, y por tal motivo, no podemos administrarla utilizando funciones básicas de administración, como por ejemplo las siguientes:

  • Administración de usuarios
  • Añadir o eliminar de grupos
  • Derechos especiales de usuario

Para demostrar esto, se pueden utilizar dos ejemplos básicos. Uno es a nivel de ficheros, y otro por ejemplo, es a nivel de Registro.
En Windows XP, por defecto la cuenta SYSTEM tiene control total en todos los ficheros y directorios del sistema operativo, y no como la cuenta Administrador, que tiene control total en casi todos los elementos del sistema. Un ejemplo válido es la carpeta SYSTEM VOLUME INFORMATION, ubicada en la raíz del sistema instalado, y que tiene como objetivo el almacenamiento de las copias de seguridad o puntos de restauración. Si se intenta obtener acceso a este directorio a través de una cuenta con privilegios únicamente de administrador, obtendremos un bonito error, ya que a nivel NTFS, no tenemos privilegios.

 
Imagen 1.- Acceso denegado en SYSTEM VOLUME INFORMATION

Otro ejemplo válido lo tenemos a la hora de visualizar elementos del registro de Windows. La cuenta SYSTEM tiene, por diseño del propio sistema operativo, control total sobre ciertas claves de registro, imprescindibles para el buen funcionamiento del mismo. Algunos de estos ejemplos son la clave SAM, en donde se almacenan los datos de los usuarios existentes en el sistema, y la totalidad de los permisos en la clave SECURITY, ubicada en la clave HKLM (HKEY LOCAL MACHINE). En la siguiente imagen, se puede visualizar un ejemplo de este tipo.


Imagen 2.- Elementos de registro visibles a través de la cuenta SYSTEM


A partir de Windows Vista en adelante, en el apartado referente al control de ficheros y directorios, y siempre hablando a nivel NTFS, se añade una nueva entidad con control total en el sistema. Esta entidad, llamada TrustedInstaller, es la encargada de una nueva característica en Windows Server 2008 y Windows Vista/7, llamada Windows Resource Protection.

Imagen 3.- Lista de control de acceso discrecional en Windows 7

En el siguiente post, repasaremos el funcionamiento de ambas cuentas a nivel de sesiones de usuario, evaluando el funcionamiento de las mismas en base a los perfiles que éstas crean.
Saludos!!
Referencias
Funcionamiento de ICACLS
http://technet.microsoft.com/es-es/library/cc753525(WS.10).aspx
Mecanismos reemplazados en Windows Server 2008
http://msdn.microsoft.com/en-us/library/aa382540(v=vs.85).aspx
Cómo es usada la cuenta SYSTEM en Windows
http://support.microsoft.com/kb/120929/en-us

Solución Network Puzzle 4

Estándar

Hola a tod@s!

Este es el primer solucionario que vamos a publicar sobre el reto número 4 de SANS, enmarcado bajo el título Network Forensics Puzzle Contest.

Antes de continuar con el solucionario, tanto Pedro como yo, queremos dar la enhorabuena a todos los participantes del mismo. Allá vamos!

Lo primero que haremos antes de analizar cualquier evidencia, será comprobar la autenticidad de la misma. Para ello, el reto nos adjunta como argumento una firma MD5 que corresponde con el fichero original de captura. Para verificar la evidencia, utilizaremos la herramienta md5sum, con el siguiente argumento:

md5sum evidence04.pcap

Esto nos devuelve como resultado lo siguiente:

804648497410b18d9a7cb1d4b2252ef7 *evidence04.pcap

El siguiente paso a seguir será examinar el archivo de captura con un analizador de protocolos. Para este reto usaremos una herramienta ampliamente conocida. Esta herramienta es Wireshark. Utilizaremos esta herramienta por su versatilidad y eficiencia, así como por su potencia bajo línea de comandos.

Al abrir el archivo de captura lo primero que vemos es lo siguiente:

1Imagen 1.- Evidencia en Wireshark

Según el supuesto, nos relata que el SR X, al infiltrarse en la subnet propiedad de ANFRF, realiza un reconocimiento de la Red. Para ello, supuestamente realiza un escaneo de la Red, cometiendo un grave error al no ocultar sus pasos. Así que lo primero que haremos será extraer las direcciones IP, tanto de origen como destino, implicadas en el caso.

Wireshark permite realizar esta tarea bajo línea de comandos utilizando para ello su herramienta Tshark. Para ello, utilizaremos el siguiente comando:

Tshark -r evidence04.pcap -T fields -E separator=, -e ip.src -e ip.dst > \Users\Silverhack\IP.txt

De esta lista se extraen el conjunto de direcciones implicadas en el caso forense, las cuales son las siguientes:

IPImagen 2.- Direcciones IP implicadas

Una vez extraída esta información, necesitamos conocer los equipos que han tenido contacto entre ellos. El problema que se presenta es la gran cantidad de paquetes transmitidos y enviados y al número de direcciones IP implicadas. Para solucionar este problema, elaboraremos una estadística de conversaciones por dirección IP, y mostraremos el resultado de forma gráfica y por pantalla. Gracias a ello, nos permitirá comprobar, a través de dos formatos, el contacto de estos equipos entre sí.

Para construir una fotografía de las conexiones, necesitaremos hacer uso de librerías gráficas y scripts que permitan la creación de ficheros que relacionen estos datos. Para ello, utilizaremos la colección de scripts llamados AfterGlow. Esta colección de scripts facilitará la tarea a la hora de generar la gráfica.

Una vez descargado el conjunto de Scripts, y haciendo uso del comando anterior (Tshark), podemos tunelizar los datos de salida hacia el script, generando un nuevo fichero de gráficos.

Tshark -r evidence04.pcap -T fields -E separator=, -e ip.src -e ip.dst | Perl afterglow.pl > IPGraph.dot

Una vez generado el nuevo fichero, podemos utilizar cualquier aplicación válida para representar este fichero en un archivo gráfico. En el caso que nos ocupa, hemos utilizado la aplicación neato, incluida en la suite Graphviz.

Neato -Tgif -o IPGraph.gif ./IPGraph.dot

El resultado de aplicar los comandos anteriores es la siguiente imagen:

IPGraphImagen 3.- Mapa de direcciones IP

Según este gráfico, podemos extraer que el único equipo que ha tenido comunicación con el resto de participantes de la red ha sido la dirección IP 10.42.42.253. Gracias a este gráfico, podemos determinar con exactitud la dirección IP que ha realizado el descubrimiento de equipos.

Otra forma de llegar a esta conclusión es elaborar estadísticas por pantalla. Tshark permite la inclusión de este tipo de características en sus consultas. Un comando válido para ello sería el siguiente:

Tshark -r evidence04.pcap -q -z conv,ip,ip.src==10.42.42.25

Este comando, elaborará una estadística de conversaciones aplicando un filtro por dirección IP. En este caso, sólo muestra las conversaciones de la dirección IP 10.42.42.25

TsharkStatistics

Imagen 4.- Estadísticas Tshark

Tan sólo necesitaríamos elaborar una estadística por cada dirección IP, y comprobar resultados.

El próximo punto a cubrir, será averiguar el tipo de fabricante que se esconde detrás de cada dirección MAC. Gracias al identificador único que poseen estas direcciones, unido al control que se tienen sobre ellas, y mediante listas actualizadas, se puede averiguar con cierta facilidad el fabricante de las mismas. El propio Wireshark, contiene una lista actualizada de estos fabricantes, aunque esta lista también puede ser consultada en la Web de IEEE. http://standards.ieee.org/regauth/oui/oui.txt

Una vez consultadas estas listas, el resultado es el siguiente:

MAC Imagen 5.- Relación IP & MAC

El siguiente punto a cubrir será relacionar cada dirección IP con un sistema operativo.

Llegados a este punto, y gracias a la cantidad de paquetes que se encuentran en la evidencia, podemos realizar un fingerprinting del sistema operativo. Este fingerprint se puede llevar a cabo gracias a que principalmente, cada sistema operativo implementa la pila tcp/ip de forma diferente. El tamaño de la ventana, así como la cantidad de nops incluidos en el paquete, son pistas para averiguar el tipo de implementación de la pila, y, por consiguiente, el tipo de sistema operativo. Existen numerosas herramientas capaces de realizar un fingerprint pasivo en base a un archivo de captura. Una de ellas es NetworkMiner, que, entre otras cosas, posee las firmas de P0f y satori para realizar un fingerprint de sistemas operativos.

Imagen 5Imagen 6.- Network Miner

Una vez analizado la evidencia con esta herramienta, ésta es capaz de devolver el siguiente resultado:

OS

Imagen 7.- Relación IP & MAC & OS

Antes de intentar averiguar el tipo de escaneo que se ha realizado, nos detendremos en averiguar si el escaneo descubrió algún tipo de puerto abierto en alguna de las máquinas. Para realizar esta tarea, se pueden emplear varios métodos. En una comunicación orientada a conexión entre dos equipos, como es el caso de la comunicación vía TCP, la comunicación se establece bajo una negociación en tres pasos. El cliente enviará un paquete con el flag SYN activo a un servidor. Si el puerto estuviese abierto, el servidor respondería con un paquete y los flags SYN y ACK activos. Si el puerto estuviese cerrado, el servidor enviaría un paquete con el flag RST activo. Un método lógico de búsqueda de puertos abiertos, es averiguar qué equipos respondieron a una llamada con un paquete y los flags SYN y ACK activos. Gracias a que estos flags tienen un valor asignado, se pueden rastrear con Wireshark de una forma sencilla. Los valores que tienen estos flags son los siguientes:

Flags

Imagen 8.- Tabla de asignación Flags

En Wireshark y Tshark, en su versión línea de comandos, es muy fácil filtrar esta información. Un comando válido en Tshark para esta tarea sería el siguiente:

Tshark -r evidence04.pcap tcp.flags==18 -T fields -E separator=, -e ip.src -e tcp.srcport

Este comando nos devuelve que el equipo que tiene puertos abiertos es el mostrado en la siguiente tabla:

OpenPort

Imagen 9.- Relación puertos abiertos

Llega el punto, una vez analizados todos los datos anteriores, de intentar averiguar qué tipo de escaneo utilizó el atacante para realizar el descubrimiento de puertos. Como ya sabemos la dirección IP que propició el escaneo (10.42.42.253), podemos aplicar un filtro en Wireshark que muestre sólo lo referente a esta dirección IP.

Imagen 6

Imagen 10.- Filtro dirección IP en Wireshark

Analizando el archivo de captura de forma visual, notamos que bajo esta dirección IP, hay numerosas conexiones con el flag SYN activo. Además se observa que se intentan conexiones a diferentes puertos con este mismo procedimiento. Este procedimiento es común en escaneos de tipo TCP SYN o de TCP Connect. A continuación mostramos un cuadro comparativo de tipos de escaneo con respecto a flags activos.

FlagsScan

Imagen 11.- Relación Flags con tipos de scan

Para confirmar el tipo de escaneo y la herramienta utilizada, podemos utilizar algún sistema de detección de intrusos y visualizar el log posterior. Para este reto, utilizaremos snort, debido a que tiene muchas firmas relativas a escaneo de puertos. Para ello, el comando utilizado es el siguiente:

snort.exe -A full -v -r c:\evidence04.pcap -c c:\Snort\etc\snort.conf

Analizando el log de salida, podemos visualizar numerosas entradas con la siguiente información:

[**] [1:2009582:1] ET SCAN NMAP -sS window 1024 [**]

[Classification: Attempted Information Leak] [Priority: 2]

02/03-00:43:10.186883 10.42.42.253:36020 -> 10.42.42.25:3389

TCP TTL:44 TOS:0x0 ID:19276 IpLen:20 DgmLen:44

******S* Seq: 0x113F23CF Ack: 0x0 Win: 0x400 TcpLen: 24

TCP Options (1) => MSS: 1460

Según Snort, parece claro que la herramienta NMAP es la causante del escaneo, así como que el tipo de escaneo es SYN Scan (-sS).

Aunque este tipo de escaneo pueda ser interpretado como TCP SYN Scan, nos decantamos por TCP Connect Scan, debido principalmente a varias características que a continuación exponemos:

La primera es que examinando el TimeLine de los paquetes, nos encontramos con que la primera respuesta recibida es un paquete con los flags RST+ACK. Esto demuestra que se ha establecido con éxito un intercambio a 3 vías o Three Way HandShake. Un escaneo del tipo TCP SYN SCAN no llega nunca a completar la conexión, de ahí a que sus creadores marquen este escaneo como STEALTH (Oculto).

Otro punto a destacar, típico de este tipo de escaneos, es la cantidad de paquetes necesarios para el descubrimiento de un puerto, llegando a intentar conectar desde varios puertos origen.

Connect Imagen 12.- Connect Scan

En la captura de datos, la fragmentación de paquetes no es visible, por lo que este tipo de opción, también incorporada en NMAP, parece ser que no fue establecida en el escaneo.

Otro punto interesante, es el referente al tiempo de escaneo. En esta captura, se han intentado varias conexiones a un mismo puerto de destino, pero desde diferentes puertos origen. Analizando la captura, hemos encontrado, al menos, dos intentos de conexiones a un mismo puerto de destino, desde diferentes puertos origen. Este comportamiento es común en varios casos. Cuando se intenta realizar un fingerprint del sistema operativo, y cuando se ajusta las condiciones de Timing en NMAP, al parámetro INSANE. Este parámetro, indica a NMAP que intente una conexión tan rápido como sea posible.

Esperamos que os guste este primer solucionario!

Saludetes!

Analizando Tráfico de Red III de III

Estándar

Para el análisis forense de tramas de Red, existen herramientas que son capaces de automatizar el proceso de extracción, siendo válidas para extraer “de una tirada” conjuntos de datos que viajan a través de un protocolo.

Una herramienta bastante potente para realizar este tipo de extracciones es Xplico. Esta herramienta, de momento sólo existe para sistemas operativos Linux. Hasta la fecha es la herramienta más interesante, ya que de momento, está realizando una muy buena labor de soporte para muchos protocolos. Para saber más sobre la misma, aconsejo leer el post de Sergio Hernando, que habla sobre ella.

Para Windows, la única herramienta que vale la pena, se llama NetWork Miner. Es una herramienta bastante interesante, ya que, además de la extracción de datos, es capaz de realizar tareas de fingerprinting sobre los paquetes de datos para averiguar, por ejemplo, el sistema operativo que envía o recibe paquetes. Su funcionamiento se basa en las bases de datos que utilizan diversas herramientas de auditoría, como por ejemplo, NMap. Un buen artículo sobre esta herramienta, lo tenemos en la Web SoyForense.

Lamentablemente, y utlizando esta herramienta con un fichero PCAP, en cuyo interior se encontraban datos relativos a conversaciones de Vídeo, audio y datos, transmitidos todos ellos a través de mensajería instantánea con Windows Live Messenger, ésta no ofrece ningún avance positivo.

netWorkMiner

Imagen 1.- Extracción de datos fallida con NetWork Miner

Después de la prueba fallida, lo siguiente es analizar “a pelo” cada paquete de la captura, para encontrar una huella, o pista que nos de esperanza para continuar.

Para ello, decido leerme, sin mucho éxito, parte del documento que tiene Microsoft sobre la implementación de RTP en Streaming de audio o vídeo.

Analizando la captura de datos, me encuentro con un paquete algo especial, con el formato siguiente:

RecipientID

Imagen 2.- RecipientID en Windows Live Messenger

Observando varios foros sobrre desarrollo de aplicaciones para mensajería instantánea, comprendo que este paquete es utilizado por Windows Live Messenger para establecer la conexión. Una vez que la conexión está establecida, envía regularmente un paquete de las mismas características para asegurarse de que la conexión sigue permanente.

Wireshark tiene, como añadido a la herramienta, opciones de traducción de paquetes. Esta capacidad, dota a la herramienta con un decodificador de paquetes. Con este tipo de opciones, podemos escoger un paquete, y decirle a Wireshark que lo decodifique según un protocolo establecido.

Nuevo intento, fallido, de decodificar todo protocolo UDP como si fuese RTP. Resultados cero.

Inspeccionando el tráfico UDP, me encuentro con que existen patrones que se repiten a la hora del envío de paquetes a través de Windows Live Messenger. En cada envío de paquetes, me encuentro con unos mismos valores para distintos paquete. Este tipo de patrón da a pensar que podemos estar ante algún tipo de Payload. Para ello, voy copiando en una tabla, todos los valores repetidos que me voy encontrando. La lista que obtengo es la siguiente:

  • 44
  • 48
  • 66
  • 4A

Buscando y rebuscando en internet, me encuentro con un post en un foro, el cual ya no existe, en el que se retrata este mismo payload. Pero lo más interesante es que un tipo, llamado Ramiro Polla (No es coña…), ya lleva tiempo con esta investigación y ha recreado un un paper y una herramienta que realiza toda esta labor.

Los payloads anteriormente descritos, se refieren a qué tipo de acción va a realizar Windows Live Messenger. Es decir, si va a realizar una conexión, enviar una trama de audio, enviar una trama de vídeo, etc…

Hablando de la herramienta, cabe decir que la mayor característica de la misma, es la capacidad de trabar “offline” con capturas de datos. Una vez que se carga la captura de datos en la herramienta, se procede a la extracción de paquetes de audio y vídeo.

WebCamRecorder

Imagen 3.- Añadido de capturas offline

Una vez que la herramienta ha realizado su trabajo, se puede proceder a exportar los datos, pudiéndose utilizar compresores de audio y vídeo, para que la captura final sea más pequeña.

imagenExtraida

Image 4.- Captura final y posibilidad de extracción de datos

Como nota final, vía Sergio Hernando me entero de que también existe una herramienta similar en Linux, llamada MSN Shadow. Leyendo el Blog del autor de la herramienta, me entero de que si queremos versión para Windows, tendremos que esperar un poco, ya que, según sus palabras:

So, to support my additional work on this project like a version for Windows, capture of file transfers and others improvements, I would like to ask for some donation if you can.
I would not like to stop providing this software in open source format, but I can not work for nothing!

Hasta un nuevo post!!

Saludetes!

Analizando Tráfico de Red I de III

Estándar

Hola a tod@s!

En esta tanda de 4 artículos nos vamos a entretener en conocer cómo podremos analizar nuestra Red en busca de patrones. El análisis del tráfico de red, junto con su contenido, es esencial para conocer qué uso se le ha dado a la red en un momento determinado.

Imagináos un servidor infectado mediante un exploit lanzado de forma remota. O conocer a ciencia cierta que están robando información confidencial de la empresa. Gracias a la reconstrucción del tráfico de red, es posible que se puedan dar respuesta a un buen número de cuestiones.

Mi amigo Pedro, de Conexión Inversa, tiene un estupendo artículo sobre redes trampa de baja y alta interacción que recomiendo que leáis. Por lo que comentaba en el artículo, parece ser que nos deleitará con más series de éstos, dedicados al análisis forense de la Red.

En mi caso, yo me centraré más en la reconstrucción de ciertos tipos de datos capturados por la red y en última instancia recomendaciones para la automatización en este tipo de tareas.

Para ello, y en mi laboratorio de pruebas, he procedido a capturar tráfico de dos puntos en una LAN y guardarlos en un archivo PCAP. Las siglas PCAP (Packet Capture) corresponden a una API desarrollada para capturar tráfico de una red. En el laboratorio de pruebas, utilizaré el port para Windows WinPcaP. Posteriormente utilizaremos la herramienta Wireshark para la extracción de posibles datos.

Comenzamos!

Algo que puede que nos interese, en lo referente al análisis de la red, es la reconstrucción de la navegación Web, guardado en un determinado fichero de captura PCAP.

Para intentar reconstruir ese tráfico, Wireshark implementa varios filtros con los que podemos jugar. En un principio puede que nos interese todo el tráfico, pero gracias a los filtros, podremos centrarnos en ciertas partes del tráfico que más nos interese.

Para captura Web, Wireshark implementa el filtro HTTP. Gracias a este filtro, podremos extraer prácticamente todos los objetos enviados y recibidos mediante este protocolo.

httpFilter

Imagen 1.- Aplicando filtro http en Wireshark

¿Y cómo podemos extraer datos una vez aplicado este filtro?. Wireshark implementa varias formas de realizarlo con el protocolo HTTP.

Una de ellas es la capacidad de poder exportar un conjunto de bytes, utilizando únicamente para ello el botón derecho del ratón.

ExportDataWireshark

Imagen 2.- Exportar Bytes Wireshark

Otra forma de realizar esta exportación de datos, es utilizando el filtro http.content_type, el cual nos mostrará sólo los paquetes que contengan algún tipo de dato y hayan viajado a través de ese protocolo.

Contenido

Imagen 3.- Filtro http Wireshark

Como podéis observar en la imagen, el tipo de dato o recurso que viaja por HTTP no siempre es texto. De ahí que se deba analizar con cuidado, por si nos encontramos con el lanzamiento de un exploit, un ataque de denegación de servicio, aplicaciones, objetos comprimidos, etc…

Desde hace algún tiempo, Wireshark implementa una forma rápida de agrupar todos los objetos HTTP en una sola ventana, para que así nos resulte más fácil “ver” qué viaja por este protocolo. Para disfrutar de esta característica, debemos ir a File –> Export –> Objects –> HTTP

HTTPObject

Imagen 4.- HTTP Objects List

Otro filtro importante que tenemos a nivel de HTTP, es el filtro HTTP.Date. Este filtro, nos situará exactamente en la cabecera de HTTP que contenga el campo fecha. Esta acción nos puede ser muy útil para realizar un timeline de peticiones y poder reconstruir una sesión de navegación, por ejemplo.

HTTPDate

Imagen 5.- Filtro http.date

Visto lo visto. Wireshark puede reconstruir todo el tráfico de cualquier protocolo?. La respuesta es que NO. Wireshark permite capturar todo tipo de paquetes pero eso no quiere decir que pueda diseccionarlos todos. Existen protocolos que están docuentados o se basan en una RFC, y protocolos para los que no hay apenas documentación pública. Para este tipo de protocolos es en donde entra en juego la ingeniería inversa. En el siguiente artículo nos centraremos en reconstruir datos partiendo de protocolos que Wireshark no es capaz de entender.

Espero que esta primera aproximación al análisis forense de la Red os haya gustado. Hasta la próxima entrega!

Saludetes!

Referencias

http://en.wikipedia.org/wiki/Pcap

http://www.wireshark.org/docs/dfref/h/http.html

http://www.wireshark.org/docs/wsug_html_chunked/ChIOExportSection.html

Altenate Data Streams en Windows Vista III de III

Estándar

Alternate Data Streams en Windows Vista I

Alternate Data Streams en Windows Vista II

En el anterior artículo realizamos pruebas de ADS en Windows Vista y como respuesta deducimos que Windows Vista todavía tiene soporte para forks en su sistema de archivos NTFS. La prueba más fehaciente es la inclusión del parámetro /R en su comando DIR, el cual listará secuencias alternativas de datos en un fichero pasado como argumento.

El soporte, en este caso y bajo este sistema operativo, es limitado en funciones y mantenido a diversos programas locales como por ejemplo el bloc de notas  o la aplicación Paint. Este tipo de soporte, como vimos en el primer artículo, puede cambiar según la política interna de Microsoft con respecto a los forks. La explicación sobre este soporte se puede consultar en el siguiente boletín.

En las pruebas realizadas con ejecutables, nos encontramos con que el comando start, (En primera instancia), ya no soporta forks bajo el sistema operativo Windows Vista, debido a que el explorador de Windows, junto con un filtro llamado Fast I/O, deniegan la ejecución. En su lugar, añaden el parámetro /R al comando DIR para buscar secuencias alternativas.

Esto dejaria a los creadores de Malware en una posición extraña, al no poder usar este método de infección en posibles usuarios que utilicen Windows Vista.

Y digo dejaria, porque Windows Vista, al tener soporte su sistema de archivos a forks, éstos, si son lanzados de determinada manera, se ejecutan sin mayores problemas.

El mayor problema ahora, y según lo que he podido averiguar, reside en el Scripting y en sus motores de ejecución.

Lenguajes como Visual Basic Script, Perl o Python soportan la ejecución de scripts, incluso si están dentro de una secuencia alternativa.

Para ejecutar las pruebas he utilizado un script para cada uno de los motores.

Script en Python

import os                                        #Importamos el módulo OS
ruta = ‘C:\Windows\system32\calc.exe’      #Path de la aplicación
os.system(ruta)                              #Ejecución de la aplicacón

Script en Perl

system(“calc.exe”);

Script en VBS

msgbox(“https://windowstips.wordpress.com“)

Estos scripts, los he introducido en un fichero llamado p0c.txt. En la siguiente imagen se refleja este acto.

dir

Imagen 1.- Secuencias alternativas en un fichero

Para la primera ejecución utilizaré el motor de ejecución de scripts que trae Windows Vista. Este motor de scripts tiene un parámetro por el cual podremos indicarle con qué motor vamos a lanzar el script.

cscript

Imagen 2.- Ejecución de ADS a través motor de Scripting

En la segunda ejecución utilizaré el motor de ejecución de scripts de Python para lanzar un sencillo script que abra la calculadora de Windows.

python

Imagen 3.- Ejecución de ADS a través del motor de Python

En la tercera y última ejecución, utilizaremos el motor de ejecución de scripts de Perl para lanzar otro sencillo script que abra la calculadora de Windows.

perl

Imagen 4.- Ejecución de ADS a través del motor de Perl

Como se puede comprobar, la ventana de propagación de malware a través de esta técnica todavía está vigente en Windows Vista, con lo que tendremos que seguir protegiéndonos de la misma manera con la que nos protegíamos cuando teníamos Windows 2K/XP/2K3.

Saludetes!

Referencias

ADS Qué es y cómo funciona

The Dark Side NTFS

Ceregumil concentrado II + GMAIL 1ª Parte

Estándar

Hola a tod@s!

Me tomo la libertad de plagiar el título del Post de mi compi Pedro Sánchez para hablaros de otra herramienta similar a la que os ofrece Pedro en su Blog.

Este caso es ligeramente diferente, pero sigue un mismo fin. El caso es que se presupone que puede haber información de cuentas de GMAIL en memoria RAM o almacenadas por el proceso. Como bien comenta Pedro, el proceso puede guardar, dependiendo de cómo esté de recursos la máquina en ese momento, la información en varios lugares. Nosotros intentaremos realizarlo desde la RAM. Para ello vamos a utilizar una herramienta de Spectra que, no sé por qué, ha pasado desapercibida durante mucho tiempo. La herramienta se llama User Mode Process Dumper, y sobre ella vamos a trabajar.

Esta herramienta tiene la capacidad de volcar al vuelo, y sin tener que matar al proceso, la memoria del proceso que le pasemos como parámetro. Vuelca incluso procesos de sistema!

Para ello, tenemos dentro de la herramienta, un ejecutable llamado Userdump.exe, el cual utilizaremos para este fin. La herramienta tiene soporte para 64 bits y plataformas basadas en Itanium, lo cual es un punto a su favor.

Y para los desarrolladores, esta herramienta tiene un instalador, el cual instala un driver en el sistema, para que pueda Hookear ciertas llamadas al kernel. Realizará estas funciones para dotar a la herramienta de volcar la memoria de un proceso cuando éste finalice de forma no planeada, forzosa, etc…

El funcionamiento de esta herramienta es bastante lógico y muy sencillo de utilizar. Para ello, no tendremos ni que utilizar la herramienta TaskList para visualizar los procesos por línea de comandos, ya que la herramienta viene programada, con el parámetro -p, para realizar esta función.

userdump1

Imagen 1.- Userdump mostrando procesos

Una vez que hayamos visualizado los procesos por línea de comandos, podremos extraer el contenido de la memoria del proceso que queramos, utilizando para ello la herramienta userdump.exe. El funcionamiento básico, como hemos dicho antes, es bastante sencillo de utilizar.

userdump

Imagen 2.- UserDump extrayendo memoria de un proceso determinado

Una vez extraído la memoria del proceso, podremos utilizar le herramienta de SysInternals-Spectra Strings para extraer el texto.

Strings iexplore.dmp > iexplore.txt

Una vez realizado ese cambio, podremos buscar, con la herramienta FindStr o Find texto específico o cadenas de texto específico.

strings

Imagen 3.- Resultado extracción Strings

En el próximo post veremos diferentes técnicas para extraer la misma información, pero automatizando las tareas.

Saludos!