Tanta crisis que hasta me cortan la conexión!!!

Publicado por Pedro C. el 08-02-2013

Estamos sentados en un "locutorio" (antes llamado cibercafé) y de repente cuando nos queda ese último segundo para acabar de descargar ese fichero tan ansiado con las "fotos de la semana blanca", entonces alguien misteriosamente alguien hace zas!!! y nos corta la conexión impidiéndolo!!! >:(

Supongamos que no es así y que lo que realmente queremos hacer es finalizar una conexión TCP sin matar el proceso que la ha generado. Aunque para las malas intenciones, también puede ser empleado en una red para "matarle la conexión al vecino" y vamos a suponer que sois buenas personas.

Vamos a emplear la archiconocida suite de herramientas dsniff para pentesting y auditoría de red.

Al grano...

Con nuestro sistema operativo Debian escribiremos:

#apt-get install dsniff				
				

En concreto, vamos a emplear tcpkill con una sintaxis de lo más básica:

tcpkill [-i interface] [-1...9] expresion				
				

Con el parámetro -i especificaremos la interface (normalmente eth0), con el parámetro -1..9 podemos especificar la agresividad para matar las conexiones enviando paquetes con el flag RST. Por defecto es 3 pero en conexiones rápidas es necesario incrementarlo. Y por último, expresión es un filtro clásico de tcpdump (BPF o Berkley Packet Filter) como host, net, port, mask, ip, src, dst, etc... y que podeis recordar con la chuleta que hemos encontrado navegando por la red.

Por ejemplo, vamos a finalizar la conexión del equipo con ip 127.0.0.1 y también del servidor mega:

tcpkill -i eth0 host mega.co.nz and host 127.0.0.1				
				

Ahora, vamos a finalizar todas las conexiones al servicio de SSH

tcpkill -i wlan0 port 22				
				

Jugando con los filtros, podemos finalizar las conexiones para unos equipos pero no para otros:

tcpkill -i eth0 ip host 192.168.19.120 and not 192.168.19.128	
				

Aunque "cantaría" un poco que nadie pudiera hacer nada excepto el 192.168.19.128

El porqué de las cosas

TCP es un protocolo orientado a la conexión por lo que debe mantener un estado y un control del flujo de los paquetes para evitar "colar" paquetes ilegítimos en una conexión ya establecida como hace la herramienta tcpkill. Pero entonces... ¿Cómo lo hace la herramienta?

Estamos en una situación de Hijacking que podemos definir como un ataque activo ya que vamos a "robar" una conexión establecida previamente y activa a partir de los datos que nos ofrece el propio protocolo TCP.

Os proponemos que realiceis una presentación del proceso de hijacking y nos la mandeis a la lista ex-alumnos o a nuestro email de contacto para poder valorarlas (cuanto más sencilla y que explique todos los conceptos mucho mejor) y conseguir la presentación ganadora SER PARTE DEL PROXIMO BOLETIN de noticias del mes de Marzo. Podeis basaros en un excelente artículo de SET (Saqueadores Edición Técnica) de hace muuuchos años pero que sigue vigente en la actualidad y seguirá mientras no se subsanen los "pequeños grandes fallos" de los protocolos que tanto nos gustan.

Recordaros que en los Cursos especializados de Seguridad Informática y Administración de Sistemas que ofrecemos en Academia MADESYP realizamos y establecemos las contramedidas con todo esto y mucho más...

Ser buenos y no hagáis maldades!