Haciendo el gamberro en intranet & hacking con dos piedras (1ª parte)

A quién no le ha pasado que, cuando te faltan 5 minutos para descargar ese archivo que parece infinito, se conecta alguien en tu red y te ralentiza la descarga bastante. O estar trabajando con tu compañero y que se te ocurra de repente que sería gracioso entretenerte un poquito "magreándole" sus conexiones. 

Dicen que cuando el diablo se aburre mueve la cola. Y ¿por qué no? si Dios les dió aletas a los peces sería para nadar...

La verdad que es algo cruel pero muy gracioso ver hasta que punto se desespera el teleco de al lado y te pregunta muy insistentemente "PERO A TI TE VA LA CONEXION?", o ver a tu compañero de laboratorio de informática, ese que aprovecha para chatear con su novia, soltar improperios...

La verdad es que esta entrada tiene un carácter lúdico aunque ayuda a repasar algunos consejos. Como todo, la informática también tiene su lado cómico ;D, todo no va a ser trabajar y trabajar... La gente que tenga este episodio superado (que será mucha) puede quedarse o irse, no le pondremos falta...:D 

En el primer ejemplo, del cual confieso haber echado mano más de una vez y no sólo para divertirme, interviene el protocolo ARP. Para quien no conozca el protocolo Address Resolution Protocol, haré un ínfimo resumen, pues tenemos que tener al menos una vaga idea de cómo funciona ARP si queremos saber a qué estamos jugando.

Cuando una máquina quiere enviar un paquete a otra, lo que hace es simplemente lanzar una pregunta. Para ello se envía un paquete (ARP request) a la dirección de difusión de la red (broadcast (MAC = FF FF FF FF FF FF)) del estilo: "¿Quién tiene esta dirección IP?". 

La máquina poseedora de la misma responderá un (ARP reply) con la dirección Ethernet que le corresponde. Por temas de rendimiento, cada máquina va guardando las respuestas obtenidas en lo que se denomina tabla ARP.

Algo muy importante es el hecho de que el protocolo ARP no tiene estado de la conexión. En otras palabras, se pueden recibir respuestas sin haberse hecho las preguntas. Una vez más se trata de una decisión que afecta positivamente al desempeño del protocolo, pero que sin embargo nos deja la puerta abierta al ARP Poisoning ... 

1. Deshaciéndonos de alguien:

Imaginemos que tenemos un compi de red que pone el torrent a toda morcilla y no nos deja ancho de banda o simplemente queremos dejar sin conexión a alguien en nuestra red porque es más guapo, porque nos cae mal, o por lo que sea.
 
Aprovechando este protocolo lo que haremos es bombardearle con ARP-REPLY diciéndole que la mac del router es una en concreto que nos inventaremos... con esto lo que conseguiremos es mandarlo a pescar peces al desierto.

Hay infinidad de maneras de hacerlo (siempre que la red no esté protegida) pero aquí y con carácter pedagógico veremos dos, la fácil y la difícil... 

Primero la fácil : Teniendo scapy instalado en nuestro sistema pasaremos a crear un script, le daremos permisos de ejecución, lo rularemos y listo. El equipo víctima estará en Parla preguntando por la Giralda hasta que lo paremos:
 

Ahora la difícil o más aparatosa y desde luego la más bonita pues supone coger un paquete retocarlo a mano y mandarlo (muy pedagógico):

Arrancaremos Wireshark y lo pondremos a escuchar en el protocolo arp, mandaremos un ping desde nuestra máquina al router, capturamos, seleccionamos y guardamos como paquete .cap (con la opción guardar un sólo paquete seleccionado) un arp-reply que venga desde la puerta de enlace:

Le echamos un vistazo al paquete para saber que campos tenemos que retocar:

Ignoraremos los primeros 32 bytes y a partir de hay tenemos:

Destination address: que de momento es nuestra mac, la cambiaremos por la mac de la víctima.
Source address: la mac del router, como no queremos que la víctima la encuentre nos inventaremos una. Los siguientes 4 bytes son el tipo de hardware y protocolo, no se toca...
Sender ip: la ip del router en formato hexadecimal. La dejaremos como está.
Target ip: nuestra IP en hexadecimal. La cambiaremos por la de la víctima.

Para pasar las ip a hexadecimal nos ayudaremos de cualquier herramienta capaz de hacerlo. Por ejemplo la calculadora:

192=C0   168=A8    0=00      109=6D

El paquete quedará tal que así:
 
Ahora guardamos los cambios en el paquete .cap y lo abrimos con PackeTh, una herramienta gráfica muy útil para manejo de paquetes. Configuramos la interface de red que vayamos a usar y lo mandamos.

Podríamos también enviarlo con otra herramienta que admita .cap. Por ejemplo, de haber trabajado el paquete en crudo RAW podríamos mandarlo con file2cale.

Pasamos a ver a nuestro vecino de red escardando cebollinos en el limbo:
  

¿¿Estáis vivos todavía?? Vaya rollazo sin venir a cuento.....jajaja es muy instructivo y nunca viene mal saber de donde vienen los niños... esto es el arp poisoning, con esta misma técnica  diciéndole al router que nosotros somos la víctima y a la víctima que nosotros somos el router y poniendo el  echo “1″ > /proc/sys/net/ipv4/ip_forward conseguiremos un man in the middle... para que veáis lo que sudan las herramientas como ettercap o scapy...:D

2. Cortando ciertas conexiones:

En el siguiente ejemplo vamos a intentar ser mas quirúrgicos, sólo cortando las comunicación de ciertos puertos o conexiones que nos interesen...
Siguiendo con el estilo de la entrada vamos a ver la manera fácil o automática y la manera difícil más a pelo.

Por poner un ejemplo, imaginaros que queremos privar a nuestro compañero de red de su navegador preferido tan solo deberíamos poner:

Manera fácil:

Lo mas fácil que se me ocurre a vote pronto es utilizar la herramienta TCPkill que viene junto al archi-conocido paquete Dsniff.

tcpkill -i wlan0  host www.google.es and host victima 
  

Como podemos ver tcpkill mata todas las conexiones salientes y procedentes de www.google.es.

Tcpkill es bastante versátil permitiéndonos matar todas las conexiones, sólo las que se hagan por determinado puerto, las que se dirijan hacia ciertos hosts o todas la del segmento local de red.

También a un/os host/s si y a otro/s no. Por ejemplo:
 
tcpkill ip host 192.168.1.2 and not 192.168.1.111

Vamos a ver más detenidamente como funciona este ataque y seguramente aprendamos un poquito mas de el por qué de las cosas:
 
Es inevitable hablar un poco del protocolo TCP-IP que, al contrario del protocolo ARP, si tiene un estado de conexión y por consecuencia un control sobre el flujo de los paquetes. En cristiano, no podemos meter paquetes alegremente en una conexión establecida como hemos hecho antes.
 
Aquí es donde entra en juego la técnica del hijacking, quizás en su forma más simple.
 
Una conexion TCP/IP esta definida por cuatro parámetros, la dirección IP del emisor (el que inicia la conexión), dirección IP del receptor (el que recibe la conexión), el puerto TCP del emisor y el puerto TCP del receptor.

El mecanismo que utiliza TCP/IP para saber si debe o no debe aceptar un paquete está basado en chequear una serie de valores en cada paquete. Si estos valores son los esperados por el receptor, el paquete es válido, en caso contrario se rechazan.

Veamos estos valores:

       SVR_SEQ : numero de secuencia del siguiente byte que va a ser enviado por el servidor.
       SVR_ACK : siguiente byte que va a ser recibido por el servidor (es el numero de secuencia del ultimo byte recibido más uno)
       CLT_SEQ : numero de secuencia del siguiente byte que va a ser enviado por el cliente.
       CLT_ACK : siguiente byte que va a ser recibido por el cliente.
       CLT_WIND : tamaño de bytes que puede recibir el cliente sin tener que verificarlos.
       SVR_WIND : tamaño de bytes que puede recibir el servidor sin tener que verificarlos.
 
En cada nueva sesión se generan nuevos y diferentes números de secuencia para evitar que dos sesiones simultáneas tengan la misma serie de identificadores. Aparte de los números SEQ/ACK la cabecera de un paquete TCP contiene los siguientes campos:

       SOURCE PORT :        Puerto de origen
       DESTINATION PORT :   Puerto de destino
       SEQUENCE NUMBER :    El número de secuencia del primer byte de este paquete
       ACKNOWLEDGE NUMBER : El número de secuencia esperado para el siguiente byte que se va a recibir
       DATA OFFSET :        Segmento de datos

Con lo que se debe cumplir siempre : 
 
           CLT_ACK = SRV_SEQ y SVR_ACK = CLT_SEQ
   
En el caso en que no se cumplan estas igualdades nos encontraremos ante un estado desincronizado.  

Lo que vamos a intentar a continuación es resetear una conexión ssh activa entra dos máquinas, o sea, apoderarnos de una conexión que no es nuestra y cortarla...
 
Una conexión se puede cerrar de dos formas, o enviando un paquete con el flag FIN activo, o enviando un paquete con el flag RST activo .Si es el flag FIN 
el que se activa, el receptor del paquete se queda en un estado de espera
CLOSE-WAIT y empieza a cerrar la conexion. Si es el flag RST el que está activado, el receptor del paquete cierra la conexión directamente y pasa a un estado CLOSED liberando todos los recursos asociados a esta conexión.

Lo primero será echarle un ojo al paquete TCP RST:
 

Una vez identificados los campos los haremos coincidir con el server y la víctima.
Con TCPDUMP veremos el SYN-ACK enviado por el server al cliente con el ack number que espera recibir en el siguiente paquete.

# tcpdump -i wlan0 host 192.168.0.102

Ahora toca sumar al número ack la cantidad de bytes enviados que son 1433 y tendremos un ack válido para cerrar la sesion. 

3219733713 + 1433 = 3219735146 y lo pasamos a hexadecimal BFE9426A.

Tocamos nuestro paquete rst cambiando el seq number:
  
y lo enviamos con packeth un par de veces:
 

y colorín colorado la conexión se ha acabado:

Como veis de una forma muy rudimentaria hemos cortado la conexión entre cliente y servidor....a veces es sorprendente lo que se puede conseguir con dos neuronas y un editor hexadecimal  O_o.

Espero que os esté pareciendo cuando menos interesante ... si no vaya peñazo...
 
En vista de lo que se ha alargado la entrada os emplazo a  una segunda parte... un saludo.

Fuentes: http://www.set-ezine.org/ezines/set/19/0x0D.txt
http://tools.ietf.org/html/rfc826
http://www.rfc-es.org/rfc/rfc1180-es.txt