Estamos migrando de sistemas de foros, por favor repórtanos cualquier problema a [email protected], si te llega a tu bandeja de entrada o a spam un correo que te dice que se solicitó el cambio de contraseña, no te alarmes, es un procedimiento normal de la migración, cambia tu contraseña porque no hay compatibilidad en el sistema de cifrado del viejo sistema con el sistema nuevo, por eso debes resetear tu clave con ese enlace.

De proxys, JavaScript y mas....

editado junio 2009 en Seguridad Web
Hola, [email protected]:

Últimamente me ha dado por estudiar, mejor dicho, comprender algo más profundamente cómo funcionan los proxys... cómo manejan los datos que les llegan y esas cosas que damos "por supuestas" ya que es labor del proxy realizar las tareas a las que están asignados.

Este post es un breve repaso a esta pequeña investigación, trata de varios puntos que espero que abra los ojos a muchas de las mentes inquietas que pasean por nuestros foros, antes de comenzar y catar el melón, voy a esbozar lo que se va a explicar:

1.- Detección de un proxy: Seguro que más de uno acude a estos foros y a algunos otros interponiendo un proxy, posiblemente anónimo... pues bien, en este primer punto intentaremos descubrir si quien visita nuestra web lo hace con proxy o sin él.

2.- Eliminando a TOR: Tomando como ejemplo pruebas anteriores y utilizando algo de lo aprendido en el punto 1, intentaremos averiguar si TOR, esa flamante joya que algunos elogian, es realmente tan anónimo como para confiar en él y que podamos acudir a un foro, a nuestro web-mail, a dónde sea y obtener resultados inexperados... o sencillamente ser baneado o redirigidos a otra página sólo por usar TOR como método de anonimizar la navegación por la Intesné razz.gif

3.- Usando proxys para lo que no están preparados: Este es un punto complejo, lo que terminaremos realizando es utilizar un proxy anónimo para evadir las reglas y políticas del mismo origen, esto es, saltar de un dominio a otro en una misma página sin las resticciones que incluyen los modernos navegadores.

4.- Inyectándo scripts en archivos .mov, .mp3, .pdf, .doc ... : Aunque parezca mentira, se puede usar este tipo de archivos para redirigir a un visitante a lugares "ocultos", ejecutar scripts y por qué, no... a usar un película "inofensiva" para enlazar con un proxy anónimo y que ejecute un virus o un gusano en el contexto del navegador del cliente... silenciosamente o a bombo y platillo como esos molestos spyware.

5.- "En construcción:" este apartado 5, lo tengo en mente... no está desarrollado (bueno sí en mi cabeza y con algunas prácticas, pero no escenificadas aún...)

¿Os gusta la idea?

Introducción

Todos sabemos lo que es un proxy, eso espero, para hacerlo sencillo, es algo a lo que nos conectamos y que nos representa ante terceros...

Hay muchos tipos y clasificaciones, anónimos, transparentes, socks, http, públicos, privados, etc... el caso es que son máquinas ubicadas en algún lugar y que ciertas comunicaciones o todas atraviesan esa máquina.

Las utilidades de los proxys, pues también son comunes, desde conectar una red al exterior o simplemente prestar un soporte de conectividad.

Aquí nos vamos a centrar en los proxys públicos, esto es, aquéllos que se nos permite usar "sin más" y más concretamente, en aquéllos que nos facilitan servicios de navegación (anónima o transparente).

Normalmente para utilizar estos proxys sólo se precisan de unos mínimos cambios en el navegador de sus clientes, una dirección y un puerto. A partir de ese momento, las peticiones web que realiza nuestro navegador, se las entrega a la máquina que actúa como proxy y éste, las redirige al verdadero destino que solicita el cliente.

Por tanto, el proxy es como una máquina interpuesta entre el cliente y el destino de la comunicación. Los riesgos de usar un proxy son proporcionales al uso que el administrador del mismo quiera hacer de él, protocolos "débiles" como autenticación web, http, correo, etc.. envían las contraseñas y datos sensibles en texto plano, entonces el administrador del proxy no necesita más que revisar los logs o registros de acceso y podrá verlos.

En contrapartida, algún beneficio tienen, entre ellos la caché que en determinados casos puede acelerar la navegación, la privacidad puesto que esos proxys anónimos sustituyen o cambian cabeceras e incluso conexiones por las suyas propias haciendo "invisible" al cliente frente al destino final, también pueden filtrar contenidos, evitar el acceso a determinados lugares, sitios, páginas, examinando el/los contenidos de las comunicaciones y tomando las decisiones que se hayan configurado.

Resumiendo, la misión principal de una máquina con funciones de proxy es la de brindar conectividad de toda una red o de determinadas máquinas hacia otras redes de tal forma que las peticiones pasan por el proxy y éste las redirige o enruta hacia los destinos solicitados, pueden cambiar o no los datos, las cabeceras, las ip's... cualquier cosa que el proxy haya sido configurado.

1.- Detección de un proxy

En este escenario vamos simular cómo un servidor web puede detectar si las conexiones que le llegan se realizan mediante un proxy, eso sí, sólo analizando algunos puertos comunes que utilizan los proxys anónimos para ocultar la identidad de sus clientes.

El mecanismo es sencillo y simple:
    a.- El servidor web recoge la IP de todo aquél que le solicita una página
    b.- El servidor web se intenta conectar a esa IP por puertos "bien conocidos" por los proxys
    c.- El Servidor web analiza la respuesta que recibe
    d.- El servidor web emite un resultado.

Antes de esto, vamos a verlo "manualmente":

Supongamos que nos decidimos por usar un Proxy anónimo del tipo anonymouse, para aquellos que no tengáis ni pajarera idea de lo que es esto, en las siguientes pantallas se muestra cómo usarlo:

Visitamos esta web: Anonymouse.org

p01.JPG

y en la casilla de texto donde pone “Enter URL:” sencillamente escribimos la dirección web que queremos visitar y pinchanos en el botón “surf Anonymously

En este caso, el destino a visitar es http://www.showmyip.com que es una de esas webs que nos muestran la IP con la que accedemos a ella... en otras palabras, la IP que estamos usando para “navegar” en este momento;

p02.JPG

Bien, como vemos, parece ser que nuestra IP es 85.195.123.26, realmente esa es la IP (o una de las IP’s) que utiliza la máquina anonymouse, nuestro Proxy.

Si visitas esa misma web (showmyip.com) sin usar anonymouse, pues obtendrás tu verdadera IP.

Bueno, pues vamos a realizar unas sencillas pruebas, asumiremos que el puerto que se está usando por el hipotético Proxy es el 80, por tanto, ahora vamos a conectarnos a esa ip por ese puerto a ver qué ocurre, lo haremos desde telnet, netcat o lo que quieras usar:

p03.JPG

Como vemos en la pantalla anterior, hemos hecho lo siguiente:

nc 85.195.123.26 80 (conexión mediante netcat hacia la ip de anonymouse y puerto 80), ni que decir tiene, que si no dispones de netcat no uses esa orden... prueba con:

Código: telnet 85.195.123.26 80

Una vez que la conexión se ha establecido, le pedimos una página mediante el método GET, en este caso GET /foo.bar, o cualquier otra que “sepamos” que no existe... lo del http 1.1 pues es eso... protocolo http versión 1.1

Escribimos cualquier cosa, en el ejemplo una sencilla pregunta: Eres un Proxy?? Y pulsamos varias veces enter...

Pues bien, si se trata de un Proxy, como es el caso, su misión es llevarnos a esa página y como no la encuentra, nos entrega un error “Bad Request”, pero si te fijas bien, además de eso nos repite como un lorito lo que le dijimos... esto es, “Eres un Proxy??”

Así de sencillo, nos conectamos, le pedimos algo y si nos lo repite... probablemente sea un Proxy... digo probablemente porque puede no serlo... puede que sea un servidor web “de verdad”, de hecho muchos de los servidores webs que hay por estos mundos son a su vez proxys... pero esa es otra historia.

Lógicamente si no podemos establecer la conexión por el puerto 80 debemos suponer que no es un Proxy, o si lo es, está utilizando un puerto diferente, para ello tendríamos que “escanear” esa ip, de eso tratará el siguiente código... calma....

También puede ocurrir que simplemente no responda (no repita) eso de “eres un Proxy??” y en este caso, también asumiremos que no es un Proxy, por ejemplo:

p04.JPG

Al no repetir la frasecita... también asumiremos que no se trata de un Proxy, o al menos, no de un Proxy que utiliza el puerto 80

Bien, pues ahora, lo único que tenemos que hacer es un pequeño programita que recoja la IP del que visite nuestro sitio y escanee a esa IP... por varios puertos... los que nos de la gana, eso sí, cuantos más puertos usemos mas tardará... pero bueno, puede servir como un escáner web “on line”, algo cutre... pero servirá:

Probemos esto: (una conexión al webserver de wadalbertia mediante anonymouse)

406 Not Acceptable [Anonymoused]

El resultado es:

p05.JPG

Ahora probamos “sin el anonymouse

http://www.wadalbertia.org/csrf/proxy.php

Y el resultado es:

p06.JPG

Ok... como ves, se “escanaea” tu ip real por varios puertos...

El script Proxy.php para que lo estudiarlo, modificarlo, comentarlo o lo que se os ocurra, lo podéis descargar de: http://www.wadalbertia.org/csrf/proxy.rar

No pongo su código aquí para que no sea demasiado largo el artículo... en el siguiente post os pegaré todos los códigos de todos los scripts que vayamos usando.

El mecanismo es el mismo que se ha descrito anteriormente... se recoge la ip, se escanean los puertos, si hay servicio en ellos se prueba a enviar una petición web y el famoso mensajito de “Eres un Proxy??” y si repite lo mismo, es un Proxy.

Bien, este primer punto ha sido fácil, no? Vaaale, hay muchas lagunas, pueden usar puertos “raros”, conexiones socks desde el cliente, túneles, etc.. y no lo detectaríamos... pero como aproximación, no está mal...

Ahora vamos a por otra cuestión, al punto 2.

2.- Eliminando a TOR

TOR es un Proxy “aleatorio” y que puede usarse por diferentes puertos. Con aleatorio me refiero a que no siempre se utiliza la misma IP como Proxy, podéis encontrar más información por este hilo:

Wadalbertia.org :: Seguridad Informática, Redes, Programación, Software Libre/Open Source, Pen-Test, Forensics, Wireless, Criptografía, IDS, Linux, Windows, Hardware, Software...

Wadalbertia.org :: Seguridad Informática, Redes, Programación, Software Libre/Open Source, Pen-Test, Forensics, Wireless, Criptografía, IDS, Linux, Windows, Hardware, Software...

y en este buen artículo que nuestro compañero aLeZX se trabajó para nuestro uso y disfrute, gracias.

Wadalbertia.org :: Seguridad Informática, Redes, Programación, Software Libre/Open Source, Pen-Test, Forensics, Wireless, Criptografía, IDS, Linux, Windows, Hardware, Software...

Casi este último enlace sería de lectura obligada antes de continuar con mi post... de verdad, no dejéis de leerlo que está muy clarito y os será de gran ayuda, no sólo para configurar TOR, también para entender otras muchas cuestiones acerca de la “ocultación” de IP’s, de los proxys, etc... LEEDLO antes de seguir, leñe!!!

Bueno, hay algunas cositas que aLeZX no nos comentó acerca de TOR... si ya lo habéis probado está muy chulo, si no es así hacedlo... pero... es sumamente sencillo descubrir si un usuario cualquiera accede a una web con TOR “por delante”.

TOR, no deja de ser como una especie de e-mule para con los proxys, realmente una de las cosas que hace nuestro cliente TOR cuando se conecta es buscar una serie de nodos para anonimizar la conexión, escoge “una ruta” y la usa, luego puede cambiar de ruta... así se puede ir “perdiendo” el rastro de nuestras conexiones...

Pero... pero es que esa lista de nodos (el equivalente a los servidores del e-mule) se puede consultar y verificar si la ip de conexión corresponde a un nodo TOR o no.

Si usáis TOR, probad a visitar este link... os dirá si entráis con un Proxy TOR o no....

http://www.wadalbertia.org/csrf/antiTOR1.php

El mecanismo es sencillo, como antes, se averigua la IP, se consulta con los nodos TOR y si coinciden.... pues ale!!!

La lista de nodos TOR la puedes encontrar aquí:

http://belegost.mit.edu/tor/status/authority

Y “mas detallado” junto con sus firmas, redirecciones, etc.. en:

http://belegost.mit.edu/

Bueno, y para dejar a TOR en paz... otro script ampliando en anterior que además de detectar el Proxy TOR, nos informa de su procedencia, país y banderita razz.gif

http://www.wadalbertia.org/csrf/antiTOR2.php

Podéis encontrar estos scripts en:

http://www.wadalbertia.org/csrf/antiTOR1.rar

http://www.wadalbertia.org/csrf/antiTOR2.rar

Y para éste último, necesitaréis los scripts de países y banderas que los podéis encontrar en:

http://www.wadalbertia.org/csrf/flags.rar

http://www.wadalbertia.org/csrf/ip_files.rar

Ambos archivos pertenecen a una “utilidad” llamada iptocountry que permite asociar una IP a su país de procedencia y su bandera (si se desea) sin necesidad de usar bases de datos.

Podéis encontrar éste y otros proyectos interesantes en:

Country identification based on IP address

Como por ejemplo: Country identification based on IP address: IP ranges for each country

Que os permitirá averiguar la lista de Ip’s que pertenecen a un país determinado según sus registros en la IANA, ARIN, RIPPE, etc...

Siguiente paso....

3.- Usando proxys para lo que no están preparados

Bien, esto se pone interesante...

Hasta ahora, hemos usado scripts php, los programas o códigos php se ejecutan en el servidor quien los lanza al navegador del cliente y presentarle así las páginas web o lo que corresponda.

JavaScript por el contrario se ejecuta en el lado del cliente, esto es, es el propio navegador del cliente quien ejecuta los programas, ambos pueden interactuar entre sí, de hecho es muy común que foros, webs, etc, utilicen ambos métodos o tecnologías.

Recuerda siempre esto, php o ASP se ejecutan en el servidor, JavaScript en el cliente.

Dado que PHP y ASP son lenguajes de lado servidor y JavaScript es un lenguaje de lado cliente, el orden en el que estos dos lenguajes serán ejecutados será siempre el mismo: primero PHP (o ASP) y luego JavaScript.

Así, cuando un usuario envíe una petición al servidor, el servidor va a tomar el archivo PHP (o ASP) y va a ejecutar su contenido de modo a producir una pagina comprensible por el navegador. Por supuesto, en esta pagina enviada al navegador puede haber cualquier script de lado cliente que ya sea JavaScript o VBScript.

Dicho de otra forma, podemos pasar variables de PHP (o ASP) hacia un código JavaScript residente en la misma pagina. Sin embargo, el paso inverso no es posible.

Y recalco esto último: RESIDENTE EN LA MISMA PÁGINA!!!!

¿Por qué tanto hincapié en esto?

Pues porque los navegadores actuales disponen de ciertos métodos que impiden que scripts procedentes de un dominio sean leídos, modificados o utilizados por otros scripts de diferente dominio, protocolo o puerto.

Ese comportamiento es lo que se llama política del mismo origen y si lo piensas un poco es obvio, si resulta que cualquier script cargado en una web cualquiera tuviese la posibilidad de leer datos (cookies, contraseñas, nombres de usuario, etc..) esto de navegar por Internet sería un desastre... sería como salir a la calle y cruzar la calzada sin mirar si vienen coches o si eres el que va en el coche, sin atender a las señales de tráfico.

Los scripts php o asp no se ajustan a las políticas del mismo origen, pero repetimos, php se ejecuta en el servidor... y serías un programador de risa si resulta que programas tu web en php para que todo quisqui que acuda obtenga una shell o muestres las contraseñas, etc...

Los navegadores no ejecutan php pero sí pueden ejecutar JavaScript a menos que se haya deshabilitado previamente.

Por ello, JavaScript atiende a políticas del mismo origen, ya que es el propio cliente quien ejecuta el código, el navegador se asegura que ese código no traspase los límites de la web/dominio al que estás conectado en ese momento, así por ejemplo, no podemos enviar un script a cualquiera que visite google.es y obtener las cookies de wadalbertia.org desde el dominio miweb.com

Resumiendo, los scripts del lado del cliente como es JavaScript, se limitan a lo que el servidor web envía al cliente dentro de una especie de “banco de arena” sin poder salir del mismo.

Si desde el servidor web de wadalbertia enviamos un código JavaScript a un cliente y ese código abre una ventana, por ejemplo de Hotmail, de yahoo, de google, o cualquiera que no sea del dominio wadalbertia.org, esas nuevas ventanas no podrán ser leídas por el script que wadalbertia envió al cliente.

Cuando esto se vulnera, si se puede, se conocen como ataques del tipo Cross Domain, o XSS Domain. Los desarrolladores de navegadores web son los encargados de implementar estas funciones, constantemente aparecen bugs y vulnerabilidades para las distintas aplicaciones (Mozilla, Internet Explorer, Opera, etc...) que consiguen saltarse las reglas del mismo origen y conducir a los usuarios de los mismos a sitios “imprevistos”, a robarles las cookies, cuentas de correo, etc..

Pero aquí no vamos a usar ninguno de esos bugs, no es eso lo que nos ocupa... porque para eso no hay mas que mirar en cualquier lista de seguridad y ya está... aquí vamos a ser mas “finos”, vamos a usar un Proxy público y anónimo para mas INRI, y vamos a conducir a los usuarios que visitan esa web “malvada” permitiendo el Cross Site Domain, o sea, rompiendo la política del mismo origen, desde JavaScript y ejecutándose del lado del cliente, no del servidor.

No... no consiste en que el inocente cliente use un Proxy... es que lo va a usar auque no quiera o sepa que lo está usando... la secuencia será esta:
    a.- El cliente visita una web y pincha en un enlace que le parece interesante
    b.- Ese enlace contiene JavaScript malicioso que conectará con un Proxy anónimo
    c.- se le abrirán varios iframes “
ocultos”, que pasan por el Proxy anónimo
d.- esos iframes pertenecen a distintos dominios, por lo que si nos atenemos a lo explicado antes, ningún código de esa página, de ese link visitado podrá leerlos... ja....
e.- Pues la cosa terminará en que nuestra web maliciosa será capaz de leer webs, imágenes, links o lo que sea de otro origen, permitiendo múltiples posibilidades, desde meterle un gusanito, un spyware, robarle las cookies, o conducirle a otro tipo de ataques como XSS (Cross Site) etc. Y todo ello... anónimamente por la gracia y olé del Proxy público


Si os fijáis, el directorio en el que estoy colgando los archivos, se llama csrf.

Esto no es nada malo en sí mismo, leedlo como “sea surf” (c=sea, srf=surf) y es eso... surfear por los mares... es la técnica, nada mas, no es que el directorio deba llamarse así para que funcione....

Para lograr esta “proeza” sin necesidad de recurrir a bug o vulnerabilidades conocidas, necesitamos otro actor en la película (por cierto... luego vendrá lo de las películas razz.gif)

Ese tercero en discordia es un Proxy, los proxys son “muy suyos” como ya hemos estado viendo, y es que para esto son una bendición del cielo...

No sólo esta misma técnica se puede aplicar a Proxys anónimos o “raros”, el mismo google nos puede ayudar gracias al servicio translate... yo elegí uno, no es el único, otros pueden facilitarnos esta misma tarea.

En http://proxy.org/ tenéis infinidad de ellos, lo acabo de ver y ahora hay mas de 1.000, son bastante rapiditos y cumplen bien su función, son libres, anónimos y casi todos ellos se pueden ajustar a lo que buscamos.

También podemos o podríamos usar el anonymouse explicado anteriormente, pero es que este, tiene una pega... que nos saca un “cartelito” de publicidad cuando navegamos con él... y es que ese cartelito fastidia el asunto, por eso utilicé este otro que lo podéis encontrar en la lista de Proxy.org., es: www.anon-proxy.com

Antes de lanzaros “al tun-tun” por cualquiera de ellos, hay que asegurarse, además de que funcionan, hay que asegurarse de cómo funcionan.

Tenemos proxys del tipo http://www.proxylizard.com que si bien funcionan, el mecanismo de conexión es complejo, usan codificaciones “propias” en el paso de las url a anonimizar, esto es, que en lugar de pasar la URL en texto plano pueden usar Base64 u otras formas de interpretación, es el caso de http://www.stupidproxy.com , y aunque no sería difícil codificar y descodificar los parámetros, no deja de ser un engorro añadido.

Así que vamos a usar uno que no nos complique la vida para el experimento...

www.anon-proxy.com utiliza un parámetro que es ?url=sitio a visitar.

Dónde sitio a visitar es el lugar destino, o sea, que si quisiéramos usar ese Proxy para acudir a los foros de wadalbertia de forma anónima, la dirección correcta sería:

www.anon-proxy.com

Si quisiéramos usar stupidproxy (que dicho sea de paso, de estúpido no tiene nada), la dirección es más complicada:

http://www.stupidproxy.com/index.php?q=aHR0cDovL3d3dy53YWRhbGJlcnRpYS5vcmcvcGhwQkIyL2luZGV4LnBocA--&hl=1011101001

Donde ese churro que le sigue a ?q= es la url a visitar en formato base64.

Código: aHR0cDovL3d3dy53YWRhbGJlcnRpYS5vcmcvcGhwQkIyL2luZGV4LnBocA==

Es Wadalbertia.org :: Seguridad Informática, Redes, Programación, Software Libre/Open Source, Pen-Test, Forensics, Wireless, Criptografía, IDS, Linux, Windows, Hardware, Software...

Y lo del &hl=1011101001 son unas opciones configurables por el Proxy,

p07.JPG

Ese recuadro verde con las casillas de verificación corresponden al parámetro hl, de tal forma que si está verificado es un 1 y si no lo está es un 0 (cero).

Comprenderéis ahora porqué es más sencillo usar el que vamos a usar que los otros...

Bien, pero... y esto qué tiene que ver con el Cross Site Domain, JavaScript y toda esa milonga de antes??

Pues bueno, los proxys, casi todos los proxys públicos – por no decir todos - , se tragan lo que les des... son máquinas pensadas, programadas, configuradas y preparadas para poder acceder a cualquier web o sitio que les digamos, otra cosa es que lo consigan, claro.

El ardid es el que sigue:

A.- Usamos nuestro Proxy y le decimos que nos muestre un marco con una página alojada en nuestro propio servidor.

B.- Esa página va seguida del carácter # y una etiqueta, por ejemplo #indice

Para los que sabéis poco de HTML, cuando una url presenta #indice, el navegador del cliente intentará encontrar en esa misma página un código html del tipo <A HREF="#indice"> bla, bla, bla... es decir, un enlace a una zona dentro de la misma página web que estamos visitando.

C.- Cuando el Proxy encuentra esa marca #indice, todo lo que venga a continuación lo carga en su caché y asume que pertenece al MISMO DOMNIO del Proxy.

Es decir, si abrimos un iframe parecido a este:

Código: <iframe src="http://proxy.com?url=http://www.wadalbertia.com/csrf/miweb.html#indice">;
</iframe>

El proxy “buscará” una referencia llamada indice y ejecutará lo que venga tras ella.

Pero lo hará dentro del contexto del dominio Proxy.com y no del dominio wadalbertia.org

Pero todavía no hemos conseguido lo que buscamos... aunque ya se anda cerca...

D.- Se abre un segundo iframe, pero éste dentro de la etiqueta <HREF=”#indice”> que es lo que buscaría el Proxy... sólo que este segundo iframe, no es una página de nuestra web... es de otro dominio, por ejemplo, algo así...

Código: <HREF="#indice">
<iframe src="http://proxy.com?url=http://www.yahoo.com">;
</iframe>
</A>

El navegador del cliente abrirá otro iframe en la misma página que pertenece wadalbertia.org “apuntando” al dominio yahoo.com, pero el Proxy asumirá que este nuevo iframe también pertenece a Proxy.com.

Por tanto ahora tenemos dos iframes en una página suministrada por wadalbertia.org, uno de ese mismo dominio y otro del dominio yahoo.com, pero para el Proxy... AMBOS PERTENECEN AL DOMINIO Proxy.com!!!! acabamos de saltar las restricciones de las políticas del mismo origen, si bien son orígenes diferentes, el Proxy nos ayudó a unificarlos.

Todavía no está todo ganado...

E.- Si bien podríamos desde el documento principal acceder al contenido de cualquier iframe, estos marcos se consideran “hijos” del principal y los “hijos” no pueden acceder a los documentos del padre, es decir, en términos JavaScript, los child iframes no pueden acceder a parent.location.

Aunque ya hemos “traspasado” las políticas del mismo origen, resulta que no podemos enviar los resultados desde los hijos al padre... poder no pueden acceder al parent.location, PERO SI PUEDEN acceder a parent.location.hash

Es decir, los hijos pueden enviar o pasar parámetros a la url del padre, no pueden establecer un document.location, por ejemplo, pero si pueden pasar un parámetros al padre.

Para que no os perdáis... un iframe no podrá hacer esto: document.location=”http......”

Pero podrá hacer esto otro: parent.location.hash

Dónde hash será un valor que se pasa como parámetro, por ejemplo google.es y quedaría así:

http://www.wadalbertia.org/csrf/miweb.html#google.es

El problemita es que eso sólo reemplaza la dirección del navegador, pero no lo ejecuta... para ello usaremos una función que espera un tiempo y lo lance... esa función se podrá ejecutar sin mas porque está dentro del documento abierto por el cliente y pertenece a wadalbertia.org, no se infringen las reglas de políticas del mismo origen....

Yaaaa.. parece muy complicado y es que lo es, pero una vez que se “pilla” es coser y cantar....

El ejemplo que viene a continuación se basa en esto mismo, va como sigue:

He colgado una web en el dominio wadalbertia.org (bueno, llamarle web a eso es una aberración) es un texto y un enlace... un enlace que llama a “otra web” que está alojada forohxc.com. (si.... suena a hxc... ya... pero es mío... ese dominio no tiene nada que ver con los extintos edito.... eso.... es un dominio concebido como “un bien” de cuando existían esos foros y allí se colgaron documentos interesantes)

El contenido de la web existente en forohxc.com contiene JavaScript malicioso que hace eso mismo, hay dos versiones, una en la que se ven los iframes que se abren y otra que no... para que comprendáis el funcionamiento.

Bueno, malicioso, malicioso, no es... simplemente “rastrea” los posibles enlaces que existan en una página, p.e. yahoo.com o google.es, usando la técnica descrita, dos iframes de diferentes dominios que interactúan con un Proxy y saltan las protecciones de políticas del mismo origen, puesto que un iframe accede al contenido del otro y luego pasa los parámetros (hash) al padre (parent.location) quien los muestra en el contexto del dominio forohxc.com razz.gif

Eso si... con Internet Explorer “falla algo”, estoy en ello... funcionar funciona... pasa los parámetros al padre... pero no muestra el resultado... por ello, probadlo con mozilla que va bien razz.gif

http://www.wadalbertia.org/csrf/p6.html

Podéis descargar los scripts en

http://www.wadalbertia.org/csrf/proxy666.rar

y

http://www.wadalbertia.org/csrf/proxy777.rar

4.- Inyectando scripts en archivos .mov, .mp3, .pdf, .doc ...

Finalicemos... en este apartado voy a explicar cómo inyectar código JavaScript dentro de una película en formato .mov para que cuando se visualice esta película desde la web y que sea QuickTime el visor adecuado se ejecute un el JavaScript que se “oculta” en la película...

Al contrario de lo anteriormente expuesto, vamos a empezar por los resultados y luego explico cómo se hace.

Este primer enlace es una película “sana”, os recuerdo que necesitáis QuickTime para que funcione:

http://www.wadalbertia.org/csrf/teoriadelembudo.mov

Las películas que siguen tienen “algo” dentro... no pasa nada... son inofensivas wink.gif

http://www.wadalbertia.org/csrf/teoriadelembudo2.mov

Era simplemente una alerta.... vamos con otra:

http://www.wadalbertia.org/csrf/teoriadelembudo3.mov

En esta última, una alerta y redirección hacia otra web/url, que en este caso es el “escaneador” de proxys del punto primero, probad a visitar este último enlace con uno de esos proxys web que hemos estudiado, con anonymouse sin ir mas lejos... veréis que escanea vuestra IP Real y no la del Proxy anónimo razz.gif

Bueno, esto mismo se puede hacer (se debe hacer) de forma silenciosa, sin avisos, sin moverse de la película... y de forma análoga, podemos hacer lo propio con documentos pdf, música en mp3, y por qué no... en imágenes... (ayyyy!!!! Alguno que yo me sé lo primero que va a pedir es aquello del EXIF Metadata Content... ya... vale... en el próximo cuento como incrustar imágenes con “regalo” dentro)

En fin, de momento me/nos/os contentaréis con saber cómo se hace con los archivos .mov y quicktime... es muy facilito, pero necesitaréis la versión completa de QuickTime, o QuickTime Pro, no sólo el visor... buscadlo por esos sitios que conocéis...

Para inyectar el código JavaScript es una película quicktime lo primero que haremos es crear un archivo de texto con el JavaScript que se debe ejecutar, así:

p08.JPG

Le damos un nombre y lo guardamos (en el ejemplo se llamó inyectar.txt)

Observad que comienza por A<, luego vienen las instrucciones JavaScript que correspondan y cerramos el código con > <T>

Cada aplicación tiene “su manera” de llamar o ejecutar JavaScript, texto, etc... esto mismo no puede ser aplicado de forma idéntica a un pdf, estos tienen su forma específica de llamar a JavaScript al igual que los mp3, así que no lo trasladéis a otro formato que no será efectivo.

En esta web podéis encontrar información de cómo hacerlo con un pdf:

September 2005: Advanced PDF features can keep documents and users more secure

De los otros.. ya los iremos sacando wink.gif

Venga, que me voy por las ramas... una vez que tenemos almacenado nuestro código en el fichero inyectar.txt, debemos elegir la película a la que se lo vamos a pegar... en los ejemplos, aquella inofensiva: teroriadelembudo.mov

Recordad que se necesita QuickTime Pro para poder hacer lo que viene a continuación:

Nos situamos en el archivo inyectar.txt y lo abrimos usando Quicktime Resource File como muestra esta pantalla:

p09.JPG

Y aparecerá algo así:

p10.JPG

Ahora abrimos del mismo modo la película que se visualizará:

p11.JPG

Sobre la primera película (la del archivo de texto) hacemos:

· Editar -> Seleccionar todo
· Editar -> Copiar

p12.JPG

p13.JPG

Y ahora vamos a la película de la teoriadelembido.mov, hecemos:

· Editar -> Añadir a la Selección y Escalar

Aparecerá esto:

p14.JPG

En esta misma película, accedemos al menú de Ventana y seleccionamos Mostrar Propiedades de la película, saldrá esto:

p15.JPG

Observad la última casilla... donde pone Pista de Texto, le quitaremos la marca de verificación y la renombramos como HREFTrack, así:

p16.JPG

Regresamos a nuestra película de teoriadelembudo.mov:

p17.JPG

como veis, ya no aparece el código JavaScript... pero está... lo último que hemos de hacer es guardarla con otro nombre, es decir:

Archivo -> Guardar Como y le ponemos otro nombre....

p18.JPG

p19.JPG

Y ya está... cerramos todas las ventanas de QuickTime y subimos el archivo pelichunga.mov a un servidor web y aquél que visite y quiera ver esa película se le ejecutará el JavaScript incrustado.

p20.JPG

En fin... hay muchas cosas que se pueden hacer... ¿por qué no que se autoejecute la peli (y por tanto el código incrustado) nada más entrar a la web?

Bien, eso ya... vosotros... que estoy algo cansado...

Espero que os pueda ser útil todo lo expuesto, seguro que alguno le saca un buen partido, a mi, me reconforta el gustazo que me he dado con aprender cómo funcionan las cosas en lugar de cómo hacer “gusanitos”.... Byes.
Fuente

Comentarios

Accede o Regístrate para comentar.