Mis inicios en la seguridad informática

3 11 2009

Disclaimer: Atención! Todo lo que leas a partir de ahora puede ser una paja mental mía, una mentira como un piano, o algo que a tí no te interese lo más mínimo. Si es así, deja de leer esto….

Cuando contaba yo con unos 8 años de edad, me empezó a interesar la electrónica y la informática. Lo primero por la energía, y lo segundo por las cosas que podías hacer con esa máquina. El principal problema radicaba en que mi familia no tenía dinero para costearme un ordenador potente, como un Amstrad o un Spectrum. En aquella época también empezó a interesarme el cine y el mundo que lo rodeaba.

Otro problema que tenía, era que pagar 350 pesetas por ver una película se convertía en una odisea, ya que era un verdadero pastón para mi. Así que tenía que conformarme con ir al cine con la familia de algún colega mío o alguna invitación por radio o familiar.

Pero un nuevo campo se abrió ante nosotros. El video-club. Un sitio en el que alquilabas una película por 150 pesetas y podías visionarla tantas veces como quisieses en un plazo pequeño (24 horas). Por aquella época, mi padre pudo comprarse a plazos un vídeo Panasonic a precio desorbitado (120.000 pesetas). El vídeo no se utilizaba mucho, ya que no había mucho que grabar, debido principalmente a que no había canales. En aquella época teníamos “la primera y la segunda” (La 1 y la 2 de televisión española). Finalmente, entre todos los vecinos, pagaron una cuota mensual para poder disfrutar del “Vídeo comunitario”, y un mundo se abrió ante nosotros. Poder realizar grabaciones de películas se convirtió en un hecho, ya que entre todos juntábamos dinero para pagar las cintas VHS, y posteriormente las grabábamos gracias al Video grabador Panasonic.

Con el tiempo, pude conseguir un vídeo grabador con la carcasa rota, ya que la familia que me lo “donó” tenía poder adquisitivo como para comprar otro. Fue en esa época en la que se nos encendió la bombilla a todos. Y si juntamos los vídeos y grabamos películas del video-club?

Así que iniciamos el proyecto. Entre todos compramos un cable EuroConector, un par de cintas VHS y nuestra primera película en el videoclub. The Goonies. Juntamos los dos vídeos, y comenzamos la grabación. Mientras grababa, algunos veían la cinta, mientras que otros, mirábamos los tiempos en los vídeos y observábamos como el símbolo rojo de “REC” estaba en marcha. Cuando terminó la grabación, procedimos a ver la cinta y…. FAIL con mayúsculas.

La cinta tenía defectos en el visionado. La imagen se veía solapada por la parte superior y se oscurecía la imagen cada ciertos segundos. Repetimos la operación varias veces (en el mismo día) y no hubo manera. Había una protección anticopia de la que no teníamos constancia. El proyecto se dió por terminado, ya que al día siguiente teníamos que devolver la cinta al videoclub. El sueño había muerto.

Como no había dinero para repetir más pruebas, dejamos la inventiva por considerarla algo imposible. En aquella época ninguno de nosotros teníamos conocimientos de electrónica, ni de hertzios, cintas magnéticas, etc…

Pasado un tiempo, y debido a ciertos trabajos extra, conseguí tener unas 5 cintas VHS de varios formatos de tiempo. Tenía de 90, 120 y 240 minutos. Como no tenía esos conocimientos “extra”, no podía hacer otra cosa que seguir probando e intentando comprender por qué pasaba eso. Como mi conocimiento se ajustaba más bien a apretar tornillos, me dispuse a hacer algo que sabía. Desatornillar la cinta.
En su interior me encontré con algo bastante básico y mecánico. Un rollo de cinta parecida al carrete fotográfico, y unos raíles por donde pasaba la cinta. Observando la cinta resolví una cuestión decisiva. Y si abro otra cinta e intercambio los rollos? Me la cargaré? funcionará?

Como tenía unas 5 cintas, podía permitirme el lujo de estropear en el intento 2 cintas, así que me puse manos a la obra. Abrí dos cintas, e intercambié los rollos. Para pegar el rollo utilicé pegamento imedio. Puse el rollo en el carril de la otra cinta, atornillé la caja, tensé la cinta con un boli bic, y la puse en el grabador. Para la prueba utilicé una cinta que tenía grabado un programa de la tele y otra cinta que no tenía grabación alguna. Bingo!! La prueba había sido un éxito!

Un día más tarde, le conté el hallazgo a mis colegas, y otra vez el proyecto cobró vida! Juntamos semanalmente dinero para alquilar las películas, realizabamos la copia, cambiabamos los rollos y las devolvíamos al videoclub en un intervalo de 24 horas. Meses más tarde profesionalizamos el cambio de rollo, utilizando como pegamento la laca de uñas de mi madre, ya que el pegamento inutilizaba la cinta a veces.

Años más tarde averigué que el solapamiento de la imagen y el oscurecimiento de la misma, ambos ocasionados de forma secuencial, se debía a una protección llamada Macrovisión.

Hasta otro capítulo!
Saludetes!!

http://es.wikipedia.org/wiki/VHS

http://www.hackerscatalog.com/Services/TECH_Notes/nineteen.html
 

 





Analizando Tráfico de Red III de III

11 10 2009

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 II de III

25 09 2009

Hola a tod@s! Seguimos con esta entrega dedicada al análisis forense de tramas de Red. En esta entrada nos vamos a centrar en protocolos que no están muy documentados.  La gran mayoría de analizadores de red ofrecen soporte a protocolos que están bien documentados y dan parte de soporte o ninguno a protocolos que no están documentados. Este tipo de problemas se pueden dar en algún tipo de investigación forense, y casi seguro que alguno de los lectores se habrá visto en algún caso parecido.  

En nuestro caso, vamos a centrarnos en un protocolo que no está muy documentado, pero que es ampliamente utilizado. Es el caso de la mensajería instatánea con Windows Live Messenger y derivados.

Los primeros atisbos de información que nos encontramos, los tenemos en la Web del Internet Engineering Task Force. En dicha Web, mantienen un borrador de un protocolo llamado Messenger Service . Leyendo este documento, tendremos una idea básica de cómo el protocolo de Windows Live Messenger trabaja a la hora de enviar y recibir información.

Más adelante (hablando de tiempo), Webs como Hypotetic.org o MSNPiki documentarían más este protocolo, realizando ingeniería inversa sobre el mismo.

Wireshark implementa un único filtro para filtrar la comunicación a través de Messenger llamado MSNMS. Gracias a este filtro, podremos trabajar sólo con este protocolo.

Al ser un protocolo que envía los mensajes en texto plano, es fácil extraer una conversación de Messenger aplicando como búsqueda la cadena “Text/Plain” en el filtro de búsqueda por paquetes que dispne Wireshark.

Conversación

Imagen 1.- Extracción conversación Messenger con Wireshark

Herramientas comerciales como MSN-Sniffer, pueden capturar este tráfico y parsearlo directamente a una salida más “humana”.

Lo malo de todo esto, es que no toda la información enviada a través de este cliente de mensajería se envía a través del protocolo MSNMS. El envío de mensajes de Voz, ficheros o vídeo se realiza a través de protocolos comunes como TCP o UDP. Y, en este caso, ni MSN-Sniffer ni ninguna otra herramienta (que yo conozca) es capaz de detectarlo y extraerlo.

En el caso del envío de ficheros a través de Messenger, y leyendo la valiosa información de la Web MSNPiki, nos encontramos con que primeramente se envía un número de identificador único (GUID), el cual se especifica para determinar que lo que se va a transmitir es un fichero. En el mismo paquete, se añade un identificador llamado APPID.

Base64FileTransfer

Imagen 2.- Envío de ficheros a través de Messenger

Si se observa con atención este paquete, en el contexto de este campo (AppID), aparecen una serie de caracteres codificados en Base64. Decodificando este texto nos daría el nombre del fichero que se está enviando.

DecodeBase64

Imagen 3.- Decodificando mensaje Base64

Una vez recibida esta información se empieza con el envío de datos. La transmisión de ficheros a través de Messenger es algo complicada, ya que se pueden enviar a través de TCP o UDP, y, en mi caso, no conozco ninguna herramienta que, a través de un archivo PCAP y en modo Offline, pueda reconstruir los ficheros enviados a través de este cliente de mensajería instantánea. Tanto el señor Maligno como Dani Kachakil tienen muy buenos artículos sobre cómo extraer ficheros enviados a través de Messenger. La idea básica es ir recopilando cada paquete (ya sea TCP o UDP), para después unir todas las tramas y formar el fichero extraído.

followTCP

Imagen 4.- Follow TCP transmisión de paquetes en Messenger

Como esto se complica cuando se transmiten varios ficheros simultáneamente, nuestro compañero Rodol, de informática64, se curró una herramienta muy chula hace tiempo que realizaba esto mismo. Capturar todos los paquetes transmitidos a través de messenger, para después reconstruir los ficheros realizando un fingerprinting de los mismos.

MessengerSniffer

Imagen 5.- Sniffer de Messenger con funciones de recomposición de ficheros

Esta herramienta, junto con muchas más, las damos en exclusiva a las personas que se apunten a los cursos FTSAI que impartimos en informática64.

Hasta la próxima entrega!

 





Analizando Tráfico de Red I de III

21 09 2009

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

16 09 2009

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(“http://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





Bing Hacking?

6 07 2009

Hola a tod@s!

En cualquier auditoría informática pueden pedirnos que realicemos tareas de footprinting o “búsqueda de información”.

Una de las técnicas más utilizadas es realizar consultas utilizando la lógica de los buscadores. En función de lo acertada que sea nuestra consulta junto con las limitaciones del propio buscador, unido a la información que los buscadores tengan indexada, así serán los resultados que obtengamos por pantalla.  

Para realizar estas tareas, se suelen utilizar las consultas avanzadas que nos ofrecen los buscadores. Para echar un vistazo a las posibles consultas avanzadas que ofrece el nuevo buscador de Spectra “Bing”, se puede consultar estos comandos en el siguiente link.

Llevo un rato jugando con este nuevo buscador, y si siguen optimizando los resultados, podemos encontrarnos con un “buen buscador” para este tipo de tareas. Por ejemplo, he realizado una simple búsqueda de OWA (Outlook Web Access) tanto en Google como en Bing, y aquí están los resultados:

Resultados Bing

Resultados Google

Un problema que le veo a este buscador, es la nula posiblidad de buscar por tipos de ficheros, aunque lo tiene reflejado con la orden “filetype”, los resultados han sido penosos. Tan solo he encontrado resultados para los ficheros pdf y para los doc. No como el buscador de Google, que encuentra ficheros, gracias a una mezcla entre extensiones y tipos de fichero. Esto último ya lo comentó el maligno en su blog. Esto afecta a la forma en que vayamos a realizar algunas consultas. Como ejemplo, pongo dos consultas con el parámetro filetype.

Resultados Bing

Resultados Google

En cambio, si consultamos ficheros del tipo xml, Bing no devuelve ningún tipo de resultado, y Google devuelve algunos Links:

Resultados Bing

Resultados Google

Lo mismo pasa para ficheros con extensión sql, ldif, etc…

En cambio, si buscamos por lo que devuelve el fichero, o la estructura del mismo, la cosa cambia y Bing empieza a devolver resultados. Fijáos en los resultados cuando se busca la cadena “– MySQL dump 10.11″ en ambos buscadores:

Resultados Bing

Resultados Google

En google, que no en Bing, se puede todavía filtrar más si a la consulta le añadimos la opción filetype:sql. En su contra, hay resultados que deja de mostrar y que sí corresponden a ficheros de tipo sql.

Puede ser que todavía quede un largo camino por recorrer para que Bing sea aceptado en la comunidad, así que me despido con una frase que escuché una vez y me hizo mucha gracia.

El buscador de Spectra busca, y el de Google encuentra.

Esta frase se la escuché a alguien que comparó el antiguo buscador de Spectra (Live) con el de Google.  

Según las pruebas que he realizado, he de decir que Bing, al igual que Google, encuentra.

Saludetes!





Windows Vista y Alternate Data Streams parte II de III

17 06 2009

Como comentamos en la primera parte de  estos tres artículos dedicados a los ADS (Alternate Data Streams) en Windows Vista, fácilmente se llega a la conclusión de que Vista sigue soportando de forma nativa los forks o ADS en su sistema de ficheros.
La primera prueba que haremos para verificar si Vista sigue soportando los ADS es sencilla, y no es más que intentar crear un ADS de la misma forma en que la hemos estado creando estos últimos años con XP/2K3.

Foto1

Imagen 1.- Creación de ADS en Windows Vista

En la imagen anterior se pueden apreciar varias cosas:

- El ADS se puede crear perfectamente y se puede visualizar de forma correcta con el comando MORE

- Tal y como se puede leer en el artículo Q101353 de Spectra, los dos puntos que hacen referencia a un ADS, pueden variar en un futuro. En Windows Vista esta convención sigue vigente, tal y como se muestra en la imagen anterior.

En ese mismo artículo se cita algo muy importante. Y es que algunos comandos soportan múltiples ADS y otros no.
En Windows XP, el comando START soporta de forma nativa este tipo de flujos de datos, pudiendo acceder de forma correcta a ellos. La sintaxis que se seguía y se sigue usando es la siguiente:

start RUTA_FICHERO:ADS

Si el intérprete de comandos se encuentra en la misma ruta en donde se encuentra el fichero a iniciar, se puede ejecutar el comando START de la siguiente manera:

start .\Fichero:ADS

Foto2

Imagen 2.- Error de ejecución en comando START bajo Windows Vista

En la imagen anterior nos encontramos con algo muy interesante, y es que el comando START, ejecutado en Windows Vista,  manda ejecutar el ADS, pero el explorador de Windows no encuentra una aplicación adecuada para poder abrir el fichero. Si realizamos la misma operación, pero analizando las llamadas que se realizan al sistema operativo, nos encontramos con que el comando es válido y que accede al ADS correctamente. El explorador de Windows es el que no puede encontrar una aplicación adecuada para abrir este tipo de fichero (En este caso el notepad). El resultado que obtiene el explorador de Windows para este evento es NAME INVALID.

Foto3

Imagen 3.- Evento NAME INVALID Process Monitor

FOTO4

Imagen 4.- Evento Process Monitor

En este caso, y para que Windows Vista ejecute la aplicación asociada a a este fichero, tendremos que invocar directamente a la aplicación que deseemos utilizar para visualizar este ADS. En nuestro caso utilizaremos el Notepad.

Foto5

Imagen 5.- Ejecución ADS en Windows Vista

Como se puede comprobar, la aplicación notepad sigue teniendo soporte para los forks en el sistema de ficheros. Se puede repetir este mismo proceso, pero con otro archivo, como una imagen por ejemplo. Así se puede comprobar qué aplicación soporta ADS y qué aplicación no.

foto6

Imagen 6.- Ejecución ADS en Windows Vista

Tal y como comenté en otro artículo dedicado a los ADS, muchos de los creadores de Malware utilizan este tipo de técnicas para dar “jugo” a sus creaciones. Entre todas ellas, los ADS se pueden utilizar para:

- Ocultación de datos
- BBDD
- Ejecutar ficheros binarios (EXE, MSI, BAT, COM, VBS)

Con respecto a Windows XP/2K3, Windows Vista ha cambiado su modelo de ejecutar archivos ejecutables dentro de un ADS.

Si introducimos un archivo ejecutable dentro de un ADS tal que así:

type p0C.exe > fichero.txt:malware.exe
start .\fichero.txt:malware.exe

Obtendremos un bonito error igual que el visto en la imagen número II. Si monitorizamos las llamadas al sistema, vemos que el sistema operativo es capaz de abrir el fichero, pero se encuentra con un error al tipear el comando START. Un resultado llamado FAST IO DISALLOWED.
Bajo mi punto de vista, y según lo que he podido averiguar, este error (FAST IO DISALLOWED) de acceso es causado por un filtro que maneja las operaciones de entrada y salida del sistema de ficheros. Aunque el fichero se puede abrir sin ningún problema, el filtro rechaza la operación, se genera la advertencia de nombre inválido (NAME INVALID) y posteriormente genera el error por pantalla.

Esta duda la dejo abierta, por si nos lee algún otro Forensic-Boy y nos quiere arrojar más luz sobre el asunto.

En una primera instancia, los resultados obtenidos nos dicen algo bueno para la seguridad del equipo. Y es que en Windows Vista no se pueden invocar archivos ejecutables a través de ADS. En la tercera y última parte, seguiremos con las pruebas (Esta vez con archivos ejecutables) y repasaremos las posibles vías de infección con malware ejecutable que se pueden presentar en Windows Vista y NTFS, utilizando forks.

Saludos a tod@s!

Referencias

Disallowing a Fast I/O Operation in a Preoperation Callback Routine

Fast I/O

Managed file system filter model and architecture (Patente) 

Malware y WordPress





Google Hacking Database Offline

11 06 2009

Hola a tod@s!

A veces nos encontramos con que en una auditoría de seguridad necesitamos realizar búsquedas en Google sobre una determinada Web, o sobre un trabajador de una empresa por ejemplo.

La base de datos de GHDB (Google Hacking Database) de Johnny Long nos puede servir de gran ayuda en esa tarea, y numerosas herramientas utilizan esta base de datos como valor añadido a la aplicación. La herramienta de análisis Acunetix, y herramientas  como Nikto o Wikto en su versión de Windows, utilizan esta base de datos como añadido.

Esta tarde, realizando unas pruebas, me he encontrado con que la Web de Johnny Long está caida, y por consiguiente, la base de datos de GHDB también arroja un bonito error 404.

La falta de esta clase de recursos para nuestras auditorías puede ocasionar que haya pruebas de seguridad que no se realicen o que se realicen de forma incorrecta. Para solucionar este problema (No tengo idea de si estará de nuevo Online en un futuro) hay personas que han realizado una labor de mirroring sobre la base de datos de Johnny Long.

En el caso de la Base de datos de GHDB, el mirror es el siguiente: http://ghdb-mirror.freehostia.com/index.HTM

Si se quiere acceder a todos los Google Dorks, la URL es la siguiente: http://ghdb-mirror.freehostia.com/_0toc.html

Y por último, si se necesita descargar toda la BBDD, la URL es la siguiente: http://ghdb.mirror.googlepages.com/ghdb.jar

Si alguien conoce algún otro mirror o tiene algún enlace más actualizado de los que yo utilizo, que no tarde en ponerlo!

Espero que os sirva de ayuda.

Salu2 a tod@s!





Windows Vista y los Alternate Data Streams I parte

7 06 2009

Hola a tod@s!

En esta ocasión, y, tras haber leído en estos últimos días nuevos artículos que hablan sobre los flujos de datos en sistemas de archivos NTFS, me he decidido a escribir dos pequeñas entradas en el blog acerca de los flujos de datos en sistemas de archivos NTFS, pero esta vez realizando las pruebas en mi flamante Windows Vista. Los nuevos artículos que he leído no arrojan nada nuevo, realizando las mismas pruebas de hace 7 años,  y, en algunos casos, fomentan la desconfianza general sobre el sistema de archivos NTFS, dando a creer al usuario, en ciertos párrafos, que la mejor alternativa es “volver” a viejos sistemas de ficheros como FAT o FAT32.

Empezamos!

Al soportar Windows Vista casi íntegramente el formato NTFS, es lógico llegar a la conclusión de que Windows Vista soporta de forma nativa los Alternate Data Streams (En adelante ADS). El caso que nos ocupa en estos tres artículos es la forma en la que Windows Vista accede a esta característica.

Al contrario de lo que he leído estas últimas semanas en los artículos que referencian a ADS, sólo muestran inquietud en el formato de archivos NTFS, y, en especial, a pruebas realizadas en Windows 2000 y XP/2K3.

Microsoft adoptó la decisión de soportar este tipo de datos asociados (llamados forks) en el sistema de archivos NTFS, ya que en su día, multitud de sistemas de archivos dotaban de esta característica a sus sistemas de archivos. Hoy día, existen multitud de sistemas de ficheros que soportan de forma nativa esta característica.

Los forks, al igual que los atributos extendidos, se utilizaban antiguamente para mantener información adicional sobre un fichero o directorio, sin cambiar la estructura del mismo, es decir, sin modificar el fichero.

Sistemas de ficheros como HFS (Hierarquical File System), UFS (Unix File System), o UDF (Universal Disk Format) soportan estas características (forks o atributos extendidos).

Volviendo al tema de arquitectura de ficheros NTFS, el stream de datos se identifica a través de los “:” (sin comillas). Según Microsoft, en el sistema operativo, residen comandos que pueden o no soportar estos flujos de datos, y que en cierta manera depende de ellos si le dan soporte o no a ese comando en un futuro. Lo mismo pasaria en el caso contrario, en donde tuviésemos un comando que soporta de forma nativa estos flujos de datos y en un futuro no. Según Microsoft, la identificación de los dos puntos para relacionar el flujo de datos podría cambiar en un futuro.

En posteriores artículos veremos en qué manera ha cambiado Windows Vista en el soporte de ADS.

Referencias

Windows NT Supports Multiple Data Streams Inconsistently

How To Use NTFS Alternate Data Streams

Fork (filesystem)

The Data Fork and the Resource Fork

Universal Disk Format 

Hasta la próxima entrega!





Respuesta desde 192.168.2.1: bytes=32 tiempo<1453276898 TTL=4

1 06 2009

Ando por aquí zagales…. ;-)