SYSTEM, causa y efecto IV de IV

Estándar

Artículos anteriores

http://windowstips.wordpress.com/2011/01/10/system-causa-y-efecto-i-de-iv/

http://windowstips.wordpress.com/2011/01/11/system-causa-y-efecto-ii-de-iv/

http://windowstips.wordpress.com/2011/01/17/system-causa-y-efecto-iii-de-iv/

Hola a tod@s!

En este último post, nos centraremos en cómo la cuenta SYSTEM se comporta a la hora de ser utilizada de forma interactiva.

Para ello, y en el banco de pruebas que hemos montado, realizaremos una elevación de privilegios, tal y como se ha comentado ampliamente por la Red. Tenéis artículos con formas de realizar este tipo de elevación en los siguientes links:

http://vtroger.blogspot.com/2005/09/mas-vale-quedarse-corto.html

http://www.securitybydefault.com/2010/12/bienaventurados-los-que-no-ven-porque.html

Al realizar el truco, (que no vulnerabilidad) y cambiar alguno de los componentes de accesibilidad por una Shell de Windows, ésta se iniciará de forma interactiva y podremos interactuar con la misma. Entre las “curiosidades” iniciales que nos encontraremos, podremos enumerar las siguientes:

  • El panel de control, no funciona
  • El explorador de Windows, junto con el escritorio, funciona de forma parcial
  • La Shell finaliza al cabo de un tiempo

El acceso total al sistema, lo tenemos única y exclusivamente a través de la línea de comandos.

Esta “irregularidad” viene dada por culpa de las claves de registro que se asocian a cada perfil de usuario.

Cuando un usuario se crea en el sistema, éste recibe un perfil de usuario. La cuenta de sistema, es decir, la cuenta SYSTEM, precarga en  memoria la clave HKEY_LOCAL_MACHINE, y el usuario que trabaja de forma interactiva en el sistema cargará a su vez la clave HKEY_CURRENT_USER, la cual se carga a través de un fichero en el perfil de usuario, que se llama NTUSER.DAT.

Si realizamos una comparación de las claves de registro que crea en el perfil la cuenta SYSTEM, con las que se crean cuando iniciamos sesión con una cuenta de usuario normal, podremos ver ciertas características que no se encuentran en el perfil de SYSTEM.

Si analizamos esas claves con alguna herramienta que permita abrir este tipo de ficheros (NTUSER.DAT), podremos ver ese tipo de diferencias, y contemplar qué claves carga la cuenta SYSTEM cuando inicia sesión en el sistema.

Para el desarrollo de este artículo, se utilizará la herramienta Windows Registry Recovery, la cual nos permite visualizar este tipo de ficheros de forma amistosa y rápida.

Imagen 1.- Claves cargadas por el usuario SYSTEM en Windows 7

Como se puede ver en la anterior imagen, la cuenta SYSTEM carga lo justo y necesario para realizar su trabajo, sin cargar más de lo necesario.

Imagen 2.- Claves cargadas por un usuario típico en Windows 7

En cuando a la imagen anterior, se puede visualizar que un usuario típico, carga lo que necesita para poder interactuar con el sistema. Algo lógico por parte del sistema operativo, ya que estos usuarios son los que están diseñados para trabajar de manera interactiva con el sistema.

Por otra parte, el usuario SYSTEM, opera desde la instancia HKEY_USERS\.DEFAULT. Esta instancia, es en realidad un alias de HKEY_USERS\S-1-5-18, instancia que identifica al SID de la cuenta SYSTEM. Al inicializar la elevación de privilegios, y siempre que no se inicie otro usuario en el sistema, la cuenta SYSTEM, utilizará una instancia que se cargará en 3 sitios diferentes. La ruta de carga es la que se muestra a continuación:

  • HKEY_CURRENT_USER
  • HKEY_USERS\.DEFAULT
  • HKEY_USERS\S-1-5-18

Para verificar lo anterior, desde la Shell de comandos arrancada cuando se realiza la elevación de privilegios, se puede crear una clave en HKEY_CURRENT_USER. Esta clave, se mostrará a su vez en las claves HKEY_USERS\.DEFAULT y HKEY_USERS\S-1-5-18.

Imagen 3.- Instancias cargadas por el usuario SYSTEM

Imagen 4.- Instancias cargadas por el usuario SYSTEM

Estas instancias, a su vez, contienen la información para interactuar con el sistema, es decir, contienen las claves de registro necesarias para lanzar un escritorio interactivo, pero tienen pequeñas diferencias. Estas diferencias, analizadas con cualquier herramienta de monitoreo, muestran como a la hora de lanzar el escritorio interactivo, éste falla al intentar encontrar ciertas claves de registro, necesarias para mostrar iconos, accesos directos, y rutas de lanzamiento a las aplicaciones. El efecto final es que el sistema operativo es capaz de “pintar” el escritorio, pero al no encontrar rutas a las aplicaciones, ni accesos directos que llamen a un programa, éste se queda “a medias”.

Imagen 5.- Rutas no encontradas

 

Como habréis podido observar a lo largo de estos cuatro artículos, es que una elevación de privilegios en Windows implica el conocimiento de muchos factores a la hora de lanzar un posible ataque, y las posibles consecuencias de que este funcione, o no…

Un saludo a tod@s!

SYSTEM, causa y efecto. II de IV

Estándar

SYSTEM. causa y efecto I de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a tod@s!!
En la primera entrega dedicada a las diferencias entre la cuenta SYSTEM y una cuenta de tipo administrador, estuvimos repasando las diferencias a nivel de privilegios que tienen estas cuentas, diferencias a nivel de ficheros, directorios y registro.
Este capítulo, lo dedicaremos a repasar las diferencias que tienen estos usuarios, pero a nivel de sesión de usuario.
A la hora de administrar un equipo basado en Windows, siempre hay que pensar, como mínimo, en la existencia de dos usuarios iniciados como mínimo en el sistema operativo. Uno de estos usuarios podrá ser una cuenta, como máximo, con un privilegio de cuenta administrativa, y como mínimo, con el mínimo privilegio posible, o lo que es lo mismo, con una cuenta de usuario o usuario de dominio. La otra cuenta, será la cuenta SYSTEM, que será la encargada de administrar las operaciones internas que necesite realizar el sistema.
Cuentas como SYSTEM o LOCALSYSTEM, son cuentas que no tienen contraseñas asociadas a ellas, y cualquier intento de asociar una credencial a ellas, como por ejemplo a la hora de utilizar estas cuentas para iniciar un servicio, serán ignoradas por el propio sistema operativo.
También este tipo de cuentas, al ser internas del propio sistema operativo, tampoco tienen un perfil asociado en el administrador de cuentas del sistema (SAM), tal y como se puede ver en la siguiente imagen.


Imagen 1.- Cuentas extraídas a través de la SAM

A cada cuenta de usuario, se le asocia un perfil, una vez que se autentica correctamente en el sistema por primera vez. Este perfil, será el que utilice para las tareas comunes del sistema, y será en su perfil, en donde se guardará toda la información y modificación que sobre esta sesión realice.
Los perfiles de usuario, en sistemas basados en Windows XP/2003 se almacenan en el directorio DOCUMENTS AND SETTINGS. En sistemas basados en Windows Vista/7/2008, estos perfiles se almacenan en la raíz del sistema operativo, en el directorio USERS.
Cada cuenta, a su vez, puede iniciar sesión en el sistema de forma independiente, y compartir sesiones entre diferentes usuarios al mismo tiempo, con la única diferencia de que cada cuenta cargará única y exclusivamente su perfil.
Cuando el sistema operativo arranca, éste necesita cargar en memoria aplicaciones y claves de registro en el inicio del mismo. Estas tareas, las realiza la cuenta SYSTEM por diseño. A la hora de autenticarse en el sistema, Windows carga un subsistema de autenticación llamado MSGINA (Componentes de identificación y autorización). Este subsistema, es el que utilizaremos para autenticarnos debidamente en el sistema.
Por diseño, Windows también carga componentes de accesibilidad, necesarios para personas con carencias físicas, tales como falta de visión, miembros amputados, etc, etc…

Por otra parte, la cuenta SYSTEM, también es utilizada a nivel de políticas de grupo en equipos que formen parte de los servicios de Directorio Activo, para asuntos relacionados con la instalación y desinstalación de aplicaciones, ejecución de scripts, etc…, ya que existen políticas de grupo a nivel de máquina, y a nivel de usuario.
Windows también tiene otras cuentas de usuario asociadas a la creación y administración de servicios. En sistemas basados en Windows XP/2003, estas cuentas, tienen sus perfiles de usuario ubicados en el siguiente directorio:


Imagen 2.- ubicación de perfiles de sistema en Windows XP/2003

En sistemas basados en Windows Vista/7/2008, los perfiles de estas cuentas se almacenan en:


Imagen 3.- Ubicación de perfiles de sistema en Windows Vista/7/2008

Dicho esto, y para resumir, si en un sistema basado en Windows XP por ejemplo, existe como mínimo una cuenta SYSTEM arrancada en el sistema antes de iniciar sesión, ésta cargará con su perfil única y exclusivamente, pero… Dónde se encuentra ese perfil??
La cuenta SYSTEM, al ser una cuenta especial de usuario del propio sistema, tiene una ubicación propia. A partir de Windows XP, la ruta en donde se encuentra este perfil de usuario, es la siguiente:


Imagen 4.- Ubicación del perfil de usuario de la cuenta  SYSTEM

A nivel de sesiones, las cuentas de sistema, se comportan de diferente manera a las cuentas de usuario normales, ya que cada cuenta se ejecuta en una sesión diferente, y por ende, en diferentes espacios de memoria.
Si por ejemplo un usuario normal, crea un objeto nuevo en el sistema operativo, y tiene control total sobre el mismo, puede que la cuenta de SYSTEM, no pueda tener privilegios para tener acceso a ese objeto.
Un ejemplo válido lo tenemos con el comando SUBST. Este comando, permite asociar una unidad física del sistema a un determinado PATH. Dependiendo de quién cree este objeto en el sistema, y en qué sesión de usuario se haya ejecutado el comando,  un usuario podrá tener control total sobre él, y el otro no.

 
Imagen 5.- Acceso a objetos. El usuario SYSTEM no accede al objeto

Pero como toda ley, tiene su trampa. Si se necesita obtener acceso a ese objeto, siempre se puede recurrir a la impersonalización, es decir, utilizar la capacidad de poder ejecutar código bajo un contexto de seguridad distinto al de nuestro usuario.
Para que un usuario pueda suplantar a otro cliente tras la autenticación, es necesario tener un determinado privilegio. Este privilegio se llama SeImpersonatePriviilege, y en Windows Vista/7/2008 se puede visualizar con el comando WHOAMI /PRIV.


Imagen 6.- Privilegios para impersonalizar a otro usuario

En el siguiente capítulo, hablaremos de los SID de usuario en Windows, cómo se forman, cuál es su estructura, y la forma de acceso a ellos.  
Saludos!!

REFERENCIAS

Personalización de GINA
http://msdn.microsoft.com/en-us/magazine/cc163803.aspx
Comando SUBST
http://www.computerhope.com/substhlp.htm
Perfiles Locales
http://msdn.microsoft.com/en-us/library/bb776894(VS.85).aspx
Cuenta LOCALSYSTEM
http://msdn.microsoft.com/en-us/library/ms684190(v=vs.85).aspx
Derechos de usuario en Windows
http://technet.microsoft.com/en-us/library/bb457125.aspx
Impersonalización y secuestro de Tokens
http://www.argeniss.com/research/TokenKidnapping.pdf

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 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

Google Hacking Database Offline

Estándar

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!