martes, 16 de septiembre de 2014

Fingerprinting with local HTML files

 

  1. Inicio
  2. La Idea
  3. Inconvenientes
  4. Pruebas
    • Firefox
    • IExplorer
    • Chrome
    • Safari
  5. Más ideas
  6. Planteamiento del ataque

 

Inicio

El tema del siguiente articulo como bien dice el titulo se trata de la recopilación de información del sistema mediante un fichero HTML que se encuentre almacenado en local.

Esta técnica que hago pública pretende ser una alternativa a la recopilación de información de un sistema mediante un tipo de fichero no comúnmente utilizado para este fin, que va a resultar menos sospechoso que un binario, evidentemente esta técnica no se puede comparar con la cantidad de información que puede recabar otras herramientas spyware pero como bien digo es una alternativa.

La idea

La idea básicamente es utilizar el esquema URI ‘file://’ para apuntar mediante una etiqueta HTML a un recurso de la maquina en la que se abre el fichero HTML y apoyándose en Javascript, más concretamente en los eventos o en el tiempo de retardo de los mismo o en la ausencia de estos, poder identificar si ese recurso existe o no, más delante se detallará más este concepto.

Inconvenientes

  • Javascript: Puede ser que se esté bloqueando la ejecución de Javascript en la página web que recoge la información del sistema.
  • Esquema URI ‘file://’: El inconveniente de este esquema URI es que no puede ser utilizado si la aplicación web que lo utiliza para hacer referencia a un fichero la brinda un servidor web, o lo que es lo mismo, solo se puede utilizar si la aplicación web que utiliza este esquema URI se abre desde la máquina de la víctima.

Pruebas

Con IExplorer es posible detectar los recursos internos de un sistema en el ejemplo siguiente, detectar los directorios de aplicaciones cuando el evento Javascript onLoad no es llamado, es decir que cuando un recurso no existe el evento onLoad es llamado y por el contrario cuando existe no lo es.

En la imagen que se muestra a continuación se puede ver una lista que se determinar cómo se ha explicado antes, dependiendo de si el navegador no llama al evento onLoad cuando se haga referencia a un directorio existente mediante un iframe.

<iframe src=”file://C:/” onLoad=”alert(‘NO EXISTE’)”>

clip_image001

Con Firefox al contrario que con IExplorer es posible determinar de si el directorio al que se apunta existe SI el evento onLoad es llamado.

<iframe src=”file://C:/” onLoad=”alert(‘EXISTE’)”>

clip_image003

Como conclusión para IExplorer y Firefox se puede decir según las imágenes que es posible determinar: el lenguaje del sistema, el hardware en base al software instalado, software instalado, antivirus, sistema operativo, por fuerza bruta usuarios en el sistema, directorios compartidos, unidades de disco, etc.

Para Chrome no es tan fácil ya que no se puede en base a eventos determinar nada ya que los eventos son llamados existan o no los directorio utilizando iframe, sin embargo si se puede determinar los directorios con grandes cantidades de ficheros y subdirectorios en base al tiempo de retraso en el renderizado de los mismos.

En el siguiente ejemplo se apunta a cinco directorios que no existen y a seis que si, como se puede apreciar los que si existen y que además tienen gran cantidad de elementos tardan mucho más en llamar al evento onLoad que va a servir para calcular el tiempo entre la creación del iframe y el final de la cargar del recurso.

clip_image005

Por ultimo hablar sobre el tratamiento de Safari que cuando la etiqueta apunta a un directorio desde un iframe, el funcionamiento de este se traducía en lanzar un explorador de Windows apuntando al directorio que se había establecido en el atributo src del iframe, entonces dejando de lado la posibilidad de detectar los directorios de forma discreta lo que quedaba era realizar un ataque que se basa en añadir una cantidad ingente de iframe apuntando a directorios existentes del sistema por ejemplo a la unidad C: con ello se consigue que el escritorio de la víctima se vea inundado de ventanas del explorador de Windows.

Más ideas

Estos problemas de eventos, ausencias de ellos o retraso en los mismos, o como sucede con Safari que abre un explorador de Windows, no suceden cuando se apunta a imágenes u otro tipo de ficheros según el tipo de etiqueta utilizada.

<img src="file://C:/test.pngs" onload="alert('existe')">

<img src="file://C:/no-existe.pngs" onload="alert('existe')">

Funcional en Chrome, IExplorer, Safari, Firefox.

De esta forma se podría realizar un script que además de apuntar a directorios apuntase a imágenes, css, js etc para obtener más información del sistema.

Planteamiento del ataque

Y para acabar el articulo exponer un simple escenario de ataque donde intervienen un atacante(1) que envía un correo donde adjunta un fichero HTML(2) que va a recabar información del sistema de la víctima y este enviara a un panel de control(3) toda esa información donde a posterior visualizara el atacante.

clip_image007

martes, 9 de septiembre de 2014

Tip para inyecciones en Mongo DB

 

En auditorías donde nos encontramos ante bases de datos NOSQL como puede ser Mongo DB uno de los problemas con los que nos solemos encontrar al igual que con bases de datos SQL es el filtrado de los parámetros enviados, este filtrado con la idea de combatir inyecciones se suele centrar en el remplazo o escapado de caracteres como las comillas simples o las dobles y las backslash, pero como veremos en este artículo a veces cuando nos encontramos ante ciertas situaciones es posible sin necesidad de escapar los caracteres entre los que se encuentra enjaulado el parámetro existe posibilidad de obtener todos los resultados de una colección.

En el ejemplo siguiente, si se estuviesen filtrando caracteres como las comillas simples o las dobles y las backslash no podríamos inyectar otra instrucción

{ "ip" : " Parámetro_enviado_por_GET "}

clip_image001

Sin embargo si nos encontrásemos con un escenario como el siguiente que aun no siendo tan común es posible, no sería necesario escapar los caracteres anteriormente mencionados para poder armar una buena en la auditoría por ejemplo listando todos los resultados de la colección.

{ "ip" : { $regex: ' Parámetro_enviado_por_GET ', $options: 'i' }}

Y es que como veremos a continuación, basta con añadir dos caracteres que raramente son tenidos en cuenta a la hora de filtrar los datos de entrada a la aplicación

clip_image002

Así de sencillo dos puntos o cualquier otro carácter y un asterisco y como se aprecia nos devuelven todos los resultados de la colección, en este caso 50, así que ya sabéis chavales añadid un caracter cualquiera y un asterisco a vuestros diccionarios de inyecciones que os pueden dar una grata sorpresa en vuestras auditorías, a mí me la dio, ya que me devolvieron todos los usuarios y sus datos de la colección ordenaditos en una tabla, que más se puede pedir.

miércoles, 3 de septiembre de 2014

DS_Store Analyzer Online

 

Bueno para los que no lo sepan los ficheros DS_Store son originales de los sistemas Mac OS que están ocultos, y se encarga el propio Finder de crearlos con información del tipo de vista, iconos, columnas, etc, aparece la configuración de la personalización del directorio donde se ha creado, además de los nombres de los ficheros y directorios que cuelgan de él y por este detalle desde el punto de vista de la seguridad existe una fuga de información, ya que los usuarios incautos al mover directorios en un Mac OS a su servidor web accesible por cualquiera revela ficheros y directorios que tal vez no podrían listarse de otra forma. Hace algún tiempo hice una tool en Java y en C# para obtener nombres de ficheros y directorios ocultos en los ficheros .DS_Store, ya por fin traigo una aplicación online para analizar estos ficheros que encuentro en mis auditorías.

Lo cierto es que hacía tiempo que andaba con la idea de hacerla online pero por una cosa u otra además por lo cansado que termino cuando llego del curro pues la he ido dejando aparcada, al final aprovechando mis vacas en Fuerteventura me he puesto y la he terminado.

image
Imagen1: DS_Store Analyzer Online

La característica más interesante a remarcar de la aplicación, es la cantidad de patrones de búsqueda utilizados para encontrar los nombres de los ficheros y directorios en el archivo DS_Store.

Patrones de búsqueda: Ilo, icg, lg1, moD, ph1, lsv, vSr.

Más adelante mi intención es tener la opción de devolver los resultados en XML o JSON.

Y sin más les dejo el enlace

http://disaster-lab.itsm3.com/ds_store.php