Mensajes

Lo más seguro que sea por el sistema operativo que tienes por que le falten algunas dependencias para lanzar la aplicación, en cualquier caso soy crítico con esa herramienta y te comento que no sirve como esperaba.

Muchas gracias, siempre lo digo, no obligo, pero se agradecen los comentarios más que uno no gana nada publicando estas cosas.

Salu2!;

[[list=1] Inicio La Idea Inconvenientes Pruebas [list=2] Firefox IExplorer Chrome Safari[/list] Más ideas Planteamiento del ataque[/list]]

[list=1]    Inicio
    La Idea
    Inconvenientes
    Pruebas
        [list=2] Firefox
        IExplorer
        Chrome
        Safari[/list]
    Más ideas
    Planteamiento del ataque[/list]



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')">

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')">

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.

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.

Fuente:http://code-disaster.blogspot.com.es

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

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

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.


Fuente: http://code-disaster.blogspot.com.es/

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.

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

Fuente: http://code-disaster.blogspot.com.es/

Después de tanto tiempo sin postear nada, traigo un XSS de esos que tan pocos se encuentran y que merecen de una entrada en el blog, ando liado y es cierto que no posteo hace mucho, igual voy encontrándome con casos extraños en el curro y los voy guardando para cuando tenga tiempo darle salida, como lo estoy haciendo hoy con este como poco 'raro' XSS.

Bueno, deciros que esta inyección se encuentra en un path ya sabéis mod_rewrite, como ya he venido haciendo otras veces por confidencialidad el enlace es cambiado completamente tanto el dominio, como el resto, que luego deis con él dorkeando jeje.

http://www.xxxxxx.com/imagenes/michyb/

Como se puede ver la cadena 'michyb' aparece en el HTML devuelto, en la etiqueta TITLE, en la etiqueta META dentro del atributo CONTENT y dentro de un DIV, pero el problema con el que me veo no se soluciona escapando de un atributo de una etiqueta si no como aparece en el título de la entrada se trata de hacerle un 'double url encode' para poder explotar una inyección XSS. Para ello nos vamos a centrar en la etiqueta DIV y vamos a ver cómo reacciona la web ante estos caracteres <d>.

Al inyectar <d> nos da un error '404 Not Found' esto tiene pinta de tener implementado algún WAF. Después de esta prueba realice dos pruebas más para ir averiguando de qué se trataba.

www.xxxxx.com/imagenes/michyb>/

www.xxxxx.com/imagenes/<michyb/

En los dos casos, el primero para conocer si se trataba del carácter > y el segundo para el <, en las dos pruebas me devolvía un 200 como 'Status Code', con lo cual no se trataba de alguno de estos caracteres por separado, así que me decidí por probar un 'double url encode'.

1 encode: %3Cmichyb%3E

2 encode: %253Cmichyb%253E

Con 'double url encode' la inyección en la URL quedaría así y como se ve en la respuesta nos devuelve un 200 en el 'Status Code'

http://www.xxxxx.com/imagenes/%253Cmichyb%253E/

Y Bingo!! Como se ve en el HTML devuelto de la respuesta se encuentra la cadena <michyb> y con ello logramos saltarnos el WAF e incluir etiquetas de cualquier tipo.

Así que lo último que queda es probar el mítico 'alert' que de veracidad de la explotación, para ello tuve que tener en cuenta que cualquier inyección no era válida ya que es una inyección en el path y no puede llevar ningún 'slash' ya que lo trataría como otro directorio. Así pues me decidí por un <a href=javascript:alert('Hacked!') >Michyb y el resultado fue.

Saludos y hasta la próxima.

Fuente:http://code-disaster.blogspot.com.es/2014/06/xss-con-double-url-encode.html

AAD v1.1 buscando variables vulnerables idexadas a google
http://www.youtube.com/watch?v=GQP0wP9em5Y

[Google]

Cuando necesitamos auditar una web y queremos tirar de los resultados de google hacking uno de los trucos que suelo tener en cuenta es tirar del operador -inurl: para descartar aplicaciones, variables de aplicaciones incluso dominios que ya he comprobado.
Un ejemplo sería el siguiente. http://www.tussam.es identifico la tecnología que voy a auditar en este caso php.

Imagen 1: Búsqueda con Dork sin exclusión

Entro en el primer resultado compruebo que no haya nada interesante y vuelvo a realizar la búsqueda descartando la variable id ya que he comprobado que no es vulnerable

Imagen 2: Búsqueda con Dork con exclusión

El problema de esta consulta es que pueden existir otras aplicaciones o directorios en la web que no contengan precisamente en la variable la cadena id, con lo cual estaríamos descartándola, pero sin embargo seriamos capaces de añadir más cantidad de operadores excluyentes si solo nos fijamos en las variables
Fijémonos entre la cantidad de exclusiones sin pasarnos del límite de palabras en la consulta, entre "dominio+aplicación+variable" (Primeros 2 bloques) y solo "variable" (último bloque).

Google
8 operadores sobrepasa el límite
site:www.tussam.es inurl:php
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
"www" (y las palabras que le siguen) se ignoró porque limitamos las consultas a 32 palabras.

Google
Búsqueda Exacta (la ideal)
Sin pasarme del límite 7 operadores
site:www.tussam.es inurl:php
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=

Bing
Búsqueda Exacta (la ideal)
13 operadores sin pasarme del limite
site:www.tussam.es -instreamset:(url):"php"
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="
-instreamset:(url):"www.tussam.es/index.php?id="

Google
Búsqueda en base a las variables GET
Sin pasarme del límite. 30 operadores con variables


Bing
Sin pasarme del límite. 20 operadores con variables

¿Vale la pena correr el riesgo basándonos solo en las variables? por supuesto que sí, tenemos más cantidad de exclusiones.
Filtrando correctamente con Google el límite ronda los 7 operadores mientras con Bing llegamos a 13 operadores sin pasarnos.
En cambio filtrando en base a las variables, Google con 30 frente a los 20 permitidos por Bing, queda claro con cual nos quedaríamos por ello hay que decir que Google la tiene más larga con 30 contra 20 de Bing y es que aquí el tamaño sí importa jeje.
Bueno pues hice una herramienta para automatizar este proceso, que trabaja con google y con su querido captcha problema que no tenemos con Bing
La herramienta tiene el siguiente aspecto.

Imagen 3: AAD Interfaz

Simplemente es necesario que en la primera entrada de datos se le envié el dork intentando filtrar lo más posible los resultados, por ello que filtro también por la tecnología para evitar html, jpg, png, etc, de este modo acortar los resultados.
En el segundo filtro se puede especificar con una expresión regular por ejemplo [?] de este modo aparecerían todas las urls parametrizadas, y es que a quien no le gustaría que a google se le pudiesen pasar expresiones regulares eh? El que no le guste que tire la primera piedra... ¬¬ vale sigamos.
Y la última opción que sirva para ver los operadores de exclusión con las variables GET encontradas en la web.

Imagen 4: ADD en acción y abajo misma ultima búsqueda de ADD pero en el buscador

Y hasta aquí este post espero que os haya gustado y es que últimamente no posteo tan seguido por que ando liado con la FaasT y cuando llego a la casa estoy sExo polvo :p.
Salu2!;

Se puede descargar de aqui:  https://sourceforge.net/projects/aadgoogle/

Fuente: http://code-disaster.blogspot.com

/logout.html

por ahí anda cerca a veces no hay que buscar un panel especifico de admin basta con el principal donde se logean cualquier usuario registrado.

Para los que no lo hayan visto del todo claro.
http://www.youtube.com/watch?v=8IGVy0troI0