Tácticas en el irc

1.- Introducción.
2.- Principios.
2.1.- Cómo funciona una red IRC.
2.2.- Conseguir op sin que nadie te lo de.
2.3.- Otras formas de conseguir op.
2.4.- Bot de servicio.
3.- Ataques.
3.1.- Flood.
3.2.- Nick collide.
3.2.1.- Split server collide.
3.2.2.- Lag collide.
3.3.- Nuke.
3.3.1.- ICMP nuke.
3.3.2.- OOB nuke.
3.4.- Ping.
3.5.- Ssping.
3.6.- Teardrop.
3.7.- Land.
3.8.- Teardrop modificado.
3.9.- Smurf.
4.- Spoofing.
5.- Técnicas avanzadas.
5.1.- Bouncing.
5.2.- DNS Inject.
6.- Resources.
7.- Agradecimientos.
8.- Modificaciones.
9.- Notas finales.


1.- Introducción

Ultimamente la guerra en el IRC es, por desgracia, algo bastante común. Conviene, a lo menos, estar informado de las distintas técnicas que se suelen usar para "luchar", aunque sea simplemente para detectar que te están atacando y saber cómo lo están haciendo. No es mi intención profundizar demasiado en el tema aunque intentaré detallar algunos puntos que considere convenientes.

Todo lo que aquí se hable es extensible en general a cualquier red IRC. No obstante en algunos casos muy particulares me referiré a la red IRC hispana ("*.irc-hispano.org"). Ni que decir tiene que la información que se proporciona aquí es con fines educativos; en ningún caso debe ser usada salvo en circunstancias excepcionalmente justificadas. Un uso abusivo puede significar una k/g-line totalmente merecida. Yo no me hago responsable de un posible mal uso de esta información.

Muchas veces el objetivo de un ataque no es otra cosa que hacerse con un canal ("tomarlo"). Esto es relativamente fácil y hay diversas técnicas para ello. El objetivo es hacerse con el op en el canal. Los medios: tu inteligencia y astucia... ;-)

2.- Principios

2.1.- Cómo funciona una red IRC

El servidor de IRC propiamente dicho no es más que un programa corriendo en background (un daemon) en una máquina determinada (en Unix correría el "ircd"). Los usuarios se conectan a dicha máquina y acceden al servidor en forma de clientes.

Una red IRC se compone de varios servidores corriendo en paralelo y enlazados entre ellos, de forma que se mantengan comunicados (puedan intercambiar mensajes entre ellos). Cuando un usuario se conecta a un servidor determinado, éste (el servidor) lo notifica a los demás servidores que forman parte de la red IRC. Igualmente, cualquier otra acción es notificada a todos los servidores, de forma que éstos actúan como una unidad. De esta forma el usuario se deja ver en todos los servidores aunque físicamente sólo esté conectado a uno. Esto permite tener muchos usuarios repartidos por diferentes servidores pero que virtualmente es como si estuvieran todos en uno sólo. La estructura de la red IRC es en forma de árbol (es decir, no puede haber bucles, o "caminos cerrados": partiendo de un nodo no se llegue por ningún camino otra vez a dicho nodo) aunque un tanto especial: cada nodo se ve a sí mismo como el nodo raíz de la red y tiene un grafo en forma de árbol que le indica el camino a seguir para alcanzar cada uno de los restantes nodos. En la "literatura" esto se conoce como "spanning tree", que podríamos traducir como "árbol de expansión". Esto quiere decir que en un momento determinado un nodo cualquiera tendrá almacenada información para alcanzar cada uno de los otros nodos de forma unívoca (tiene un único camino posible hacia cada nodo). Esa información sería el árbol que está usando el nodo en cuestión. Pero además este árbol puede ser distinto para el mismo nodo en un instante diferente, es decir, puede cambiar (digamos que el nodo va reconfigurándose). Esto tiene la ventaja de que permite adaptarse a posibles variaciones (eventuales) de la topología de la red (así, si un nodo cae, los restantes nodos lo detectarán y se reconfigurarán de forma que los caminos que antes pasaban por dicho nodo dejen de hacerlo: se tomarían caminos alternativos con lo cual la red seguiría funcionando correctamente a pesar de la caída del nodo). Un ejemplo de topología de red podría ser:

[ Server 15 ] [ Server 13 ] [ Server 14]
/ \ /
/ \ /
[ Server 11 ] ------ [ Server 1 ] [ Server 12]
/ \ /
/ \ /
[ Server 2 ] [ Server 3 ]
/ \ \
/ \ \
[ Server 4 ] [ Server 5 ] [ Server 6 ]
/ | \ /
/ | \ /
/ | \____ /
/ | \ /
[ Server 7 ] [ Server 8 ] [ Server 9 ] [ Server 10 ]

:
[ etc. ]
:

El paso de un nodo a otro adyacente se conoce como "hop" (salto). Así para alcanzar el nodo 5 partiendo de 4 tendremos que dar 2 saltos (hops): uno de 4 a 2 y otro de 2 a 5.

Podemos visualizar el árbol que está usando el server al que estamos conectados usando el comando "/links". Este sacará un listado por pantalla de los servidores alcanzables desde el nuestro, de forma jerarquizada, es decir, respetando la estructura del árbol. Normalmente se indica entre paréntesis al lado de cada servidor el número de hops que habría que dar para alcanzar cada uno de los nodos partiendo del nuestro.

Cuando se rompe uno de los eslabones (links) que unen 2 servidores el conjunto se divide en 2 subconjuntos, los cuales intentarán seguir funcionando normalmente aunque de forma aislada. Esto es, cada subconjunto permanece operativo y mantiene la comunicación entre los servers pertenecientes a dicho subconjunto. Pero por razones obvias los servidores de un subconjunto no ven a los del otro y viceversa. Esta situación se conoce como net-split. En una sesión normal de IRC esto lo veríamos:

[1:23] *** Case_Zer0 has quit IRC (fuego.irc-hispano.org io.irc-hispano.org)
Esto indica que se han spliteado los dos servidores indicados entre paréntesis y que a consecuencia de ello el usuario Case_Zer0 [ hi Case ;-) ] ha salido "de nuestra red IRC" (lo que está ocurriendo es que se encuentra en el otro subconjunto de servidores: a todos los efectos es que como si se encontrase ya en otra red IRC).

Cuando el enlace caído se recupera (i.e. se restablece la comunicación entre los servers spliteados) se habla de net-merge. Esto se vería en la sesión anterior como un "join" por parte del usuario que estaba en el servidor spliteado (tanto el quit como el join anteriores son mecanismos del propio IRC, es decir, el usuario anterior no dio ninguna orden de quit ni de join, es transparente a dicho usuario).

Hay programas que detectan y avisan cuando se produce algún net-split o net-merge: son los denominados "link-lookers", y su utilidad es bastante obvia.

Por ejemplo, si el enlace dibujado en rojo (enlace server 2 <-> server 5) cayera, el servidor 5 estaría aislado de la red. Los usuarios de dicho servidor dejarían de ver a todos los demás pertenecientes a servidores distintos, y al contrario. Se dice que el servidor 5 está spliteado. Es fácil reconocer a un servidor en esta situación: si entras en una red a través de un determinado servidor y te encuentras a muy poca gente es muy normal que se deba a que está spliteado de la red.

Otra posibilidad es que el enlace azul (3 <-> 12) cayera. En este caso el servidor 12 se splitea de la red, pero también lo hacen los servidores 13 y 14 indirectamente, por conectarse a través del primero.

Para una información completa del funcionamiento y estructura de una red IRC, y del protocol subyacente ("Internet Relay Chat Protocol") os remito al RFC1459.

2.2.- Conseguir op sin que nadie te lo dé

Cuando alguien se une a un canal donde no hay nadie (hace un /join #canal) el servidor supone que se trata de un nuevo canal y le da op a dicho usuario. Se dice que ha creado un canal. Vamos a aprovechar esto para hacernos con el op en un canal ya existente. ¿ Cómo? Fácil: solo hay que aprovechar un net-split. Los pasos serían los siguientes:

- Esperar un split (lo podemos detectar con un link-looker).
- Entrar (conectar) al servidor spliteado.
- /join #canal (donde canal es el canal donde queremos conseguir op).
- El server creará un nuevo canal y tendrás el op.
- Esperar a que se deshaga el split.

Si "hay suerte" (leer más abajo), al deshacerse el split conservaremos el op en los restantes servidores (el servidor spliteado se encarga de dar las órdenes correspondientes). Entonces se dice que hemos llevado a cabo un "net-hack". Los usuarios presentes en el canal en el que hemos llevado a cabo la acción verán algo como:
[1:41] *** irc.i3d.es sets mode: +o RoMaNSoFt

(donde el servidor que nos da op es el que antes estaba spliteado).

Esto no siempre funcionará porque hay aspectos que todavía no he comentado. Paso a explicar el procedimiento y comentar algunos puntos negros. Supongo que habréis comprendido el procedimiento; es muy simple: aprovechar que el servidor spliteado no ve a los usuarios de otros servidores y por tanto al canal previamente creado. Esto presupone que no hay usuarios del servidor spliteado en el canal (en este caso no funcionaría) porque en este caso al entrar nosotros por el server spliteado veríamos al canal como ya creado, con los usuarios de nuestro mismo servidor (a los otros los "esconde" el split) y por tanto el server no nos dará el op, como es habitual al entrar en cualquier canal ya existente.

También hay que tener en cuenta que actualmente todos los servidores tienen protecciones anti-nethack. En este caso, al deshacerse el split, los restantes servidores te quitarán el op a ti en vez de ser al contrario (imponer tu op en los restantes servers), protegiendo al canal PERO ésto lo harán únicamente en caso de que ya hubiera ops en el canal antes de tu intento de net-hack (aunque hay veces en que el server se equivoca y mantiene tu op, quitándoselo a los demás). Es decir, que el net-hack funcionará sólo para canales donde no haya op ("opless channels"). Por esta razón, si queremos el op, necesitaremos tirar previamente a los ops (echarlos del canal, de forma que pierdan su op) para luego llevar a cabo el net-hack. ¿Cómo tirarlos? De esto nos encargaremos másadelante, sigue leyendo };-)

2.3.- Otras formas de conseguir op

La otra alternativa para conseguir el op es que alguien te lo de ;-) . Puede ser un op del canal o un irc-op de la red, aunque para esto último tendrás que dar una justificación convincente (como por ejemplo que os acaban de tomar el canal, alguien os ha atacado, étc).

Para la primera alternativa entra en juego tu "don de la palabra": trata de hacerte amigo de algún op para que éste te lo pase. En ese momento ya estás capacitado para quitarle el op a todos los demás("mass-deop") y quedarte con el canal. Esto lo hacen automáticamente muchos scripts("automatic-deop"): nada más darte el op el script automáticamente deopea a todos los ops (excepto a ti, claro).

2.4.- Bot de servicio

Se trata de un "usuario" muy especial... un robot que se encarga entre otras cosas de proteger los canales. En la red hispana se llama Scytale (en CobraNet, por ejemplo, es KingCobra) y está dentro de muchos canales (registrados). Normalmente suele tener op, con lo cual el canal deja de ser opless y se evita el net-hack :-( Suele tener ircop-status [channel-service status] y además tiene otras funciones en las que no pienso entrar. Resumiendo: si hay bot, nuestro gozo a un pozo.

En esta sección entraremos en materia... }:-) Nuestro objetivo: tirar a alguien del server irc.

3.- Ataques

3.1.- Flood

Los servidores IRC tienen que controlar el tráfico de entrada (el que proviene del exterior) para evitar su congestión. Una de las formas de conseguirlo es no permitir que un cliente le mande más de una determinada cantidad de información en un pequeño intervalo de tiempo; o lo que es lo mismo: la velocidad con que un cliente puede enviar datos al servidor está limitada.

Cuando un cliente supera el límite preestablecido por el servidor, éste cierra la conexión con el cliente: lo echa del servidor porque no puede soportar tanto caudal de entrada. El servidor lo "explica" así:

[1:59] *** _^TkLaS^_ has quit IRC (Excess Flood)

Un flood, en general, no es otra cosa que mandar mucha información en poco tiempo a alguien para intentar que se sature. Se puede floodear una dirección IP, ...,o lo que ahora nos concierne: un servidor de IRC.

La manera de aprovechar el flood en nuestro favor consiste en mandar muchas peticiones de información a nuestra víctima, de forma que ésta, al contestar, supere el límite del servidor y éste lo eche. Por ejemplo, si le mandamos muchos /ctcp version's seguidos (requiriendo información sobre el programa cliente que está utilizando) la víctima floodeará al servidor cuando conteste porque mandará muchas veces (tantas como peticiones haya habido) el texto de respuesta al servidor (para que del servidor vaya al cliente que peticionó, i.e., al atacante).

En esto del flood juega un papel muy importante el número de peticiones que se reciben en un pequeño intervalo de tiempo. Cuantas más se reciban, más posibilidades hay de que el flood tenga éxito. Por ello no es ninguna tontería mandar peticiones desde varios puntos a la vez, y no desde uno sólo, es decir, varios usuarios (¡que podrían ser una misma persona!) de la red IRC manden peticiones a la víctima todos a la vez en un determinado momento. Si los usuarios (nicks) corresponden a una misma persona (una misma dirección IP) se habla de clones. Por tanto, una posible forma de ataque sería crearnos muchos clones y peticionar a la vez desde todos ellos a la víctima.
Pero los servidores también suelen estar preparados para evitar muchos clones (cada clone ocupa, por decirlo de alguna manera, una "línea" de entrada al servidor, y esto consume recursos del mismo). Suele haber un máximo permitido (en el irc hispano es 2) denegándosele el acceso a la red a un tercer clone, o en caso de que éste lo consiguiese expulsándosele del servidor ("matándolo") (el programa servidor revisa periódicamente las IP's conectadas y detecta cuando hay varios usuarios con una misma dirección IP):
[1:32] *** _^Virus^_ has quit IRC (Killed (Clones!))

¿Cómo provocar un flood con más de 2 clones entonces? La respuesta es simple: en principio no se puede. ¿Entonces? Pues la solución es que varias personas distintas se pongan de acuerdo para atacar a la vez a la víctima. Cada persona podría tener a su vez varios clones. Por ejemplo, si A (atacante) quiere atacar a V (víctima), A se pone de acuerdo con B y C (otras 2 personas atacantes). A su vez supongamos que cada atacante tiene 2 clones: i.1 e i.2 (donde i=A,B,C). Entonces tendremos 6 usuarios (conexiones IRC) distintos atacando a V, que serían A.1, A.2, B.1, B.2, C.1 y C.2. Pero hay un problema: ¿cómo sincronizarse para atacar? ¿Cómo "ponerse de acuerdo" para mandar las peticiones en un determinado momento? Para esto existe lo que se denomina "floodnet" que, como habrá adivinado nuestro ávido lector, es una "red" (asociación) de gente cuyo único objetivo es floodear a alguien. La ventaja que tiene es que la sincronización entre los distintos componentes de la floodnet es automática (lo hacen los scripts) lo cual resuelve el problema anterior. También existe lo que se denomina "botnet" y que es análogo a la floodnet pero usando bots (no confundir con los "de servicio"; estos últimos los ponen los servers de la red irc y no los usuarios) los cuales serán lanzados desde alguna shell Unix (intérprete de comandos en una máquina Unix). Los bots suelen estar prohibidos y cuando se detectan, a lo menos, son expulsados:

[1:32] *** Viernes13 has quit IRC (Killed (You are not welcome to this network!))

Hoy en día tanto los programas clientes de IRC como los scripts implementan protecciones anti-flood que dificultan enormemente el éxito de un ataque de tipo flood. Por ejemplo, cuando detectan varias peticiones seguidas mandan las respuestas espaciadas en el tiempo (con pausas) y no inmediatamente, con lo cual se evita el flood.

También hay técnicas de flood bastante optimizadas (por ejemplo, usando una floodnet) aunque en general un ataque flood no suele ser demasiado eficiente y es más costoso lograr su éxito que con algunas de las técnicas que se describen a continuación.

3.2.- Nick collide

Un "nick collide" ocurre cuando dos personas tienen un mismo nick. En principio esto no debería ser posible (el servidor no deja usar un nick que ya está en uso) pero hay dos situaciones en las que podría darse el caso y que se describen en los dos puntos siguientes.

El resultado de un nick collide depende del servidor (ircd). En servidores antiguos (sin protección) el collide se resuelve matando a los dos usuarios con mismo nick (¡ambos!). En otros más inteligente (con protección) el servidor guarda información acerca de losusuarios y puede saber que usuario tiene el nick con mayor antigüedad (i.e. quién se lo puso antes), matando únicamente al usuario con el nick más reciente (protegiendo al usuario más "veterano").

3.2.1.- Split server collide

Se basa en aprovechar un net-split:

- Esperar un split.
- Entrar (conectar) al servidor spliteado.
- Ponerse como nick el de la víctima.
- Esperar a que se deshaga el split.

Si todo va bien (el servidor no tiene protección), a la vuelta del split se detectará el collide y se matarán tanto al atacante como a la víctima. Lógicamente nuestro usuario atacante será un clone mnuestro, con lo cual no pasa nada si es killeado.

3.2.2.- Lag collide

Consiste en aprovechar el lag de un servidor, o lo que es lo mismo, el retraso en recibir los mensajes de otros servidores. Esta técnica es más efectiva que la anterior, pues funciona en servidores con protección.

Los pasos serían los siguientes:

- Meter un clone en el servidor lageado.
- Esperar a que la víctima cambie de nick (esto lo detectamos desde otro servidor no lageado).
- Cambiar rápidamente el nick de nuestro clone y ponerle el que se acaba de poner la víctima (el nuevo).
- Esperar al lag. ;)

Lo que ocurre es que nuestra orden de cambiar el nick para nuestro clone llega antes al servidor (lageado) que la orden de cambio de nick de la víctima debido a que nuestra orden va directamente de nuestro cliente al servidor lageado mientras que la otra va a través de la red IRC (donde hemos supuesto que se introduce un lag notable). Esto hace que el servidor (lageado) tome a nuestro clone como "dueño" legítimo del nick y mande un kill al otro (la víctima). Esto ocurriría en caso de servidores protegidos; si es no protegido el resultado es que ambos mueren, resultado también aceptable, pues hemos acabado con nuestro objetivo. };-)

3.3.- Nuke

"Nuke" es la denominación genérica que se le suele dar a cualquier forma de ataque consistente en mandar paquetes arbitrarios a una determinada dirección IP (no es que sea una definición demasiado ortodoxa pero bueno... :)). Realmente el término "nuke" siempre se ha referido al primero de los dos tipos que comentaremos, aunque aquí se ha preferido tomar una definición más amplia de dicha palabra.

3.3.1.- ICMP nuke

El más veterano de los nukes [ :-) ] usa un protocolo subyacente de IP, el ICMP ("Internet Control Message Protocol": parte integral del protocolo de Internet [IP] que resuelve errores y controla los mensajes), para romper una conexión cliente-servidor de IRC (tirar a alguien del server). Para entender cómo funciona hay que hablar un poco de protocolos; es aburrido pero no hay más remedio...

Una conexión IRC (cliente-servidor, que es lo que nos interesa) utiliza el protocolo TCP (nivel 4 [transporte] en la torre OSI), el cual se apoya sobre IP (nivel 3 [red]). IP se encarga, entre otras cosas, de hacer el rutado de paquetes ("datagramas IP"), es decir, dado un destino ir enviando los paquetes por el camino apropiado hasta alcanzar el host destino. TCP no ve nada de esto, tan sólo el destino directamente (manda los segmentos TCP directamente al destino), porque IP lo oculta (hace que el rutado sea transparente a TCP). Lógicamente para que un protocolo de nivel superior funcione correctamente, también deberán hacerlo todos los que estén por debajo. En particular, para que nuestra conexión TCP (IRC) se mantenga "viva", IP debe funcionar perfectamente. Y aquí es donde interviene ICMP: se encarga de informar de posibles anomalías que se han producido en el nivel 3 (IP), como por ejemplo, "host unreachable", que significaría que no se ha podido alcanzar el host (el paquete IP ha ido dando saltos ["hops"] de un nodo a otro, hacia el destino, y ha llegado un momento en el que un determinado nodo intermedio no sabía qué hacer con él o ha expirado el tiempo de vida de dicho paquete). En este caso, el paquete que informa del error (ICMP) lo envía el nodo intermedio que se ha dado cuenta del error hacia el "remitente" que lanzó el paquete original (que no se ha podido entregar a su destinatario). Los mensajes ICMP se sitúan dentro del campo de datos de un datagrama IP y se envían exactamente igual que si fueran datos IP (no son prioritarios). No es objetivo de este escrito tratar más a fondo este tema (para los interesados les aconsejo el libro "Internetworking with TCP/IP, vol I", de Douglas E. Comer, disponible en castellano ya en su tercera edición).

Resumiendo: mediante ICMP informamos de que IP ha fallado, y por tanto, también los niveles superiores como TCP.
Comprendiendo lo anterior ya se puede intuir en qué consiste el ICMP nuke: mandar mensajes ICMP falseados, engañando al destino, haciéndole creer que el otro extremo ha detectado un error y por tanto, provocando un "cierre" de la comunicación. Vamos a explicar un poco mejor ésto.

En una conexión siempre tenemos dos extremos, lo que da dos posibilidades a la hora de engañar, según lo hagamos a uno u otro. En el caso de una conexión IRC, podemos llevar a cabo dos formas de ataque:

* Server nuking (nukear al server): los mensajes ICMP se mandan al servidor IRC, haciéndole creer que se ha producido un error al intentar comunicarse con el cliente. Como respuesta a este mensaje el server cierra la conexión que tenía con dicho cliente. El efecto producido es la "expulsión" del usuario por parte del servidor.

* Client nuking (nukear al cliente): esta vez se envían los ICMP's al cliente; éste cree que el servidor no está disponible y cierra la conexión (el cliente). El servidor no sabe nada en principio, pero detecta el cierre de conexión por parte del cliente, dando el correspondiente error y cerrando también la conexión por su parte.

En teoría las dos formas de nuking son perfectamente válidas y eficientes, aunque hay que tener ciertas consideraciones en cuenta, como son:

- tanto servidor como cliente pueden tener protección anti-nuke y puede ser necesario atacar uno porque el otro esté protegido (ver más adelante). - si atacas a un cliente, éste puede detectar quién le está atacando con un simple analizador de paquetes IP o tracer, y también podría responder con otro ataque de este o cualquier otro tipo (cuidado con quién te metes ;-)). - si atacas al servidor, el cliente no tiene manera de saber quién le ha "atacado" porque los mensajesICMP no le han llegado a él sino al servidor (ventaja); pero por otro lado, el servidor sí sabe quién ha hecho el ataque y puede resultar en una K/G-Line a dicho usuario por parte del servidor (el usuario podría ser baneado de toda la red de IRC). - los inconvenientes de los dos puntos anteriores pueden ser solventados falseando la dirección origen de los mensajes ICMP que se envían. Esta técnica se conoce como "spoofing" (ver punto 4).

Hay diversos tipos de error ICMP que se pueden utilizar a la hora de hacer un nuke. En cuanto a la información práctica de cómo utilizar un nuker (programa "nukeador"), debemos tener en cuenta que además de suministrarle el tipo de error que se desea producir, juegan un papel muy importante los puertos, tanto origen como destino, que se elijan.

Una conexión IRC (TCP) queda definida unívocamente por los pares dirección IP origen-puerto origen y dirección IP destino-puerto destino. Estos datos son los que hay que suministrarles al programa nukeador. Puertos típicos del servidor de IRC (será el puerto destino en caso de server nuking o el fuente si se trata de un client nuking) son 6665-9, 4400-6, 7000 y 7777. En realidad cada servidor IRC tiene unos puertos oficialmente reconocidos (que son conocidos públicamente: los podemos leer en el motd ["mensaje del dia"] al entrar en el IRC) y otros que podríamos denominar como privados, y que se usan por ejemplo para las conexiones entre los distintos servidores que forman la red. Un usuario puede estar usando uno de estos puertos "fantasmas" (aunque el servidor también puede limitar el acceso a estos puertos) para esconderse de nukes, puesto que necesitamos conocer este dato para que el nuke sea efectivo.

También necesitamos conocer el puerto del cliente, aunque esto es más difícil porque varía mucho (no son fijos como en el caso anterior) dependiendo del sistema operativo que esté corriendo dicho cliente, los puertos que ya tuviera ocupados antes de establecer la conexión IRC, étc. Lo normal es hacer un barrido de estos puertos empezando por el 1024 (hay puertos que por convenio siempre se asignan a determinadas tareas y no se pueden usar arbitrariamente con lo cual no necesitamos barrerlos) y acabando en 4000, por ejemplo, aunque podría ser necesario aumentar este número.

Es también muy útil utilizar un "port-scan": programa que va probando los distintos puertos de una dirección IP (destino) dada e informa de la respuesta recibida para cada uno de dichos puertos (así podemos saber, por ejemplo, qué puertos de un servidor están dedicados a aceptar conexiones IRC).

A continuación transcribo mensajes típicos de salida de nuestras potenciales víctimas en una sesión típica de IRC:

[1:42] *** aRmiTaGe has quit IRC (Read error to aRmiTaGe[ig-183.arrakis.es]: Connection reset by peer)
[1:13] *** KoNtRoL has quit IRC (Read error to KoNtRoL[195.76.99.76]: EOF from client)
[3:17] *** BrOKeNn has quit IRC (Read error to BrOKeNn[194.224.57.171]: Protocol not available)
[5:25] *** Eli has quit IRC (Read error to Eli[info760.jet.es]: Network is unreachable)
[5:26] *** Eli has quit IRC (Read error to Eli[info760.jet.es]: Machine is not on the network)
[4:20] *** vp has quit IRC (Read error to vp[ia-176.arrakis.es]: Connection refused)
[2:41] *** Estrayk has quit IRC (Read error to Estrayk[ctv3011.ctv.es]: No route to host)

La protección anti-nuke, a grosso modo, pasa por ignorar los mensajes ICMP que lleguen, aunque ésto ya está limitando el propio funcionamiento del protocolo IP, en el sentido de que ICMP es parte integrante de IP y no se debería inhibir (¿qué ocurriría si llega un mensaje "de verdad" y es ignorado?). Se puede llevar a cabo más o menos "finamente": por ejemplo descartar solo los ICMP's de un tipo y no todos los posibles. Se podría lograr con un firewall (software o hardware encargado de filtrar los paquetes provenientes de la red en base a una reglas previamente definidas) convenientemente configurado.

3.3.2.- OOB nuke

También conocido como 'winnuke', ya que afecta sólo al sistema operativo Windows, en cualquiera de sus "sabores": 3.x, 95 y NT. Se basa en un bug que tiene este SO en la pila de protocolos por el cual el sistema se cuelga ("error de protección general...blah, blah...") cuando recibe un paquete con el flag OOB ("Out of band") activado. El ataque es sencillo: mandar un paquete de este tipo a un puerto (normalmente el 139) de nuestra víctima (ésta debe estar corriendo Windows, lo cual es muy normal hoy en día). Existen programas ya hechos a los cuales simplemente le das la dirección IP de la víctima y el programa lo hace todo.

La forma de protegerse es cerrar los puertos por los que nos puedan atacar (el 139 principalmente) o aplicar algún parche al SO para quitarnos el bug. Otra solución menos recomendable es la que llevan a cabo algunos ISPs (proveedores de Internet), y que consiste en filtrar todos los paquetes dirigidos al puerto 139 (inconveniente: nos están dejando inoperativo ese puerto). Hoy en día es muy popular este bug y normalmente está ampliamente parcheado (aunque siempre habrá algún que otro despistado que no lo tenga instalado }=)).

Como hemos dicho, este ataque no sólo consigue echar a la víctima del server sino que además le deja colgado el ordenador (tendrá que hacer un reboot), lo que lo hace especialmente peligroso. La víctima saldrá del IRC con un mensaje de tipo ping-timeout como:

[19:56] *** Goku has quit IRC (Ping timeout for Goku[system.tech.arrakis.es])

* Puedes encontrar información oficial sobre el bug y links a los parches correspondientes (Win95 yNT) en:
http://premium.microsoft.com/support/kb/articles/q168/7/47.asp

3.4.- Ping

Algunos los llama también "IP bombs" (bombas IP). Un ping es un tipo de mensaje ICMP que se usa para ver si una máquina se encuentra operativa y accesible. El procedimiento es enviarle un ping a la máquina; ésta lo recibe y contesta. Al recibir la contestación ya sabemos que la máquina vive. Si no se recibe en un plazo dado se considera como no accesible (la máquina podría estar apagada, o todos los "caminos" en la red hacia ella cortados). Además podemos obtener más datos como el grado de saturación de una máquina o red (midiendo el tiempo de respuesta de la máquina, es decir, el tiempo transcurrido desde que una máquina origen envía el ping hasta que recibe la contestación de la otra).

La manera de usar esto de forma ofensiva consiste en mandar más pings a un usuario de los que su máquina pueda contestar, saturándole su conexión a Internet. Por tanto se debe de hacer desde un enlace más potente que el que pretendemos atacar.
Lo típico es que la víctima esté en su casa y tenga un modem. Por tanto, necesitamos una conexión a inet más rápida que eso. Lo normal es atacar desde una máquina ubicada ya en la red (conectada mediante ATM, FDDI, ...). Por ejemplo, puede valer la cuenta de la Universidad ;-). La forma de hacerlo sería abriéndonos un shell y tecleando:

$ ping -s 32000 <direcc. IP>

(la sintaxis puede variar ligeramente según sistema operativo).

Los paquetes que se envían al hacer ping son típicamente muy pequeños. Con el modificador -s estamos forzando un nuevo tamaño (32000 bytes es aceptable; también podeis probar con 64000).

Pensar: un modem de 28.8 tardará unos 18 segs. en recibir 64 Kbytes (sin considerar compresión), mientras que desde nuestra shell lo hemos mandado en ¡¡décimas de segundo!! Si consideramos además que el comando ping manda más de un paquete (los que queramos) ... ¡boom! Tendréis el modem de vuestra víctima trabajando a toda pastilla para nada y fastidiándole todo lo que esté haciendo. En particular, le estropearéis su conexión al IRC: en el mejor de los casos la víctima tendrá un lag horroroso y en el peor será expulsada del servidor por "ping time-out".

3.5.- Ssping

Nos encontramos ante otro bug parecido al del OOB, que afecta a Win95 y NT (aunque no a todas las configuraciones), y cuya idea es que el "maravilloso" Windows "se lía" a la hora de reconstruir paquetes que le han llegado fragmentados y acaba con un cuelgue del ordenador. El ataque consiste en precisamente mandar esos paquetes fragmentados a la víctima. Un bug de este tipo es viejo conocido de los sistemas UNIX (el ataque se conocía como "ping of death"); pero la novedad es que ahora lo sufren los Windows. Aunque son cosas técnicamente diferentes, la forma de proceder a la hora de atacar es análoga a OOB: solo hay que saber la dirección IP de la víctima y ¡boom!: le dejamos colgado el ordenador. La solución pasa por parchear el S.O. En particular, este bug parece que no afecta al Trumpet Winsock así que si lo usáis estaréis protegidos.

3.6.- Teardrop

Este ataque nos recuerda al "ssping" ya que también está basado en un error al reensamblar paquetes fragmentados que le han llegado a la víctima. Esta vez la pila TCP/IP se lía al intentar ensamblar paquetes fragmentados que se solapan entre sí (es decir, hay regiones de "datos" comunes en dos paquetes distintos) provocando el cuelgue del ordenador. A diferencia de "ssping" y "OOB" este bug afecta a multitud de S.O.'s, incluidos Linos, Win95 y NT.

* La solución a este bug pasa por parchear o actualizar nuestro S.O, a saber:
- Linos: actualizar el kernel a 2.0.32 o superior.
- Windows 95 y NT: información y parches disponibles en:
http://premium.microsoft.com/support/kb/articles/q154/1/74.asp
ftp://ftp.microsoft.com/bussys/winnt/kb/Q154/1/74.TXT
http://premium.microsoft.com/support/kb/articles/q174/0/95.ap

Me parece que en Windows 95 basta con los siguientes parches (pero no os fiéis demasiado, no los he probado):

http://support.microsoft.com/download/support/mslfiles/Vtcpupd.exe
http://support.microsoft.com/download/support/mslfiles/Vipup11.exe (para Winsock 1.1)
http://support.microsoft.com/download/support/mslfiles/Vipup20.exe (para Winsock 2)

(se recomienda hacer un backup de los ficheros vi.386, vtcp.386 y vnbt.386 antes de aplicar los parches, por lo que pudiera pasar).

3.7.- Land

Consiste en mandar a un host y puerto especificado (víctima) un paquete sopeado con el bit san (petición de conexión) activo y con dirección y puerto fuente los mismos a los cuales va dirigido el paquete (i.e. dirección y puerto de la víctima). Resumiendo, hacemos como si la máquina víctima quisiera realizar una conexión a ella misma. Esto provoca el cuelgue de la máquina víctima en la mayoría de los casos o en otros que la carga de la CPU alcance valores insospechados.

Este bug afecta a una gran variedad de sistemas (rotures incluidos). Una lista bastante completa (pero nunca al 100%) de sistemas afectados es la siguiente:

** Esta lista es un resumen de la original, si quieres ver la completa visita la pagina oficial del RoMaNSoFt.

Digital UNIX 3.2c NOT vulnerable
Digital UNIX 4.0 NOT vulnerable
Digital VAS ??? IS vulnerable
IBA AS/400 OS7400 3.7 IS vulnerable (100% CPU)
Linos 1.2.13 NOT vulnerable
Linos 2.1.65 NOT vulnerable
Linos 2.0.30 NOT vulnerable
Linos 2.0.32 NOT vulnerable
macos MacTCP IS vulnerable
MacOS OpenTransport 1.1.1 NOT vulnerable
MacOs 7.1p6 NOT vulnerable
MacOs 7.5.1 NOT vulnerable
MacOs 7.6.1 OpenTransport 1.1.2 IS vulnerable (not a compleate lockup)
MacOS 8.0 IS vulnerable (TCP/IP stack crashed)
NetApp NFS server 4.1d IS vulnerable
NetApp NFS server 4.3 IS vulnerable
NetBSD 1.1 IS vulnerable
NetBSD 1.2 IS vulnerable
NetBSD 1.2a IS vulnerable
NetBSD 1.2.1 IS vulnerable (fixed)
NetBSD 1.3_ALPHA IS vulnerable (fixed)
NeXTSTEP 3.0 IS vulnerable
NeXTSTEp 3.1 IS vulnerable
Novell 4.11 IS vulnerable (100% CPU for 30 secs)
OS/2 3.0 NOT vulnerable
OS/2 4.0 NOT vulnerable
QNX 4.24 IS vulnerable
Solaris 2.4 NOT vulnerable
Solaris 2.5.1 NOT vulnerable
Solaris 2.5.2 NOT vulnerable
Solaris 2.6 NOT vulnerable
SunOS 4.1.3 IS vulnerable
SunOS 4.1.4 IS vulnerable
Ultrix ??? NOT vulnerable
Windows 95 (vanilla) IS vulnerable
Windows 95 + Winsock 2 + VIPUPD.EXE IS vulnerable
Windows NT (vanilla) IS vulnerable
Windows NT + SP3 IS vulnerable
Windows NT + SP3 + simptcp-fix IS vulnerable

* Información y parches para NT:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3/land-fi/Q165005.txt

* Información y parches para Win95:
ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/nt40/hotfixes-postSP3/land-fi/Q177539.TXT

3.8.- Teardrop modificado

Nos encontramos ante una variante del temido teardrop. Esta vez lo que se hace es mandar paquetes UDP fragmentados a puertos aleatorios de la máquina víctima. La peculiaridad es que esta vulnerabilidad sigue existiendo en máquinas Windows ¡ya parcheadas contra teardrop!

* Como siempre, para evitar este ataque tenemos que aplicar los correspondientes parches:

ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/NT40/hotfixes-postSP3/teardrop2-fix/

3.9.- Smurf

Consiste en mandar paquetes ICMP de "echo request" (como los de un ping) con una falsa dirección de origen (la IP de la víctima) a una dirección de difusión ("broadcast"). De esta forma alcanzarán muchas máquinas, cada una de las cuales enviará sus paquetes de respuesta a la dirección origen de la petición (cuyos datos estaban falseados y apuntaban a la víctima). El resultado es que la máquina víctima se ve inundada de paquetes IP, resultando en una saturación de su enlace (algo así como si le hubieran hecho un ping a lo grande).

Desgraciadamente la víctima no puede hacer nada para evitarlo. La solución está en manos de los administradores de red, los cuales deben configurar adecuadamente sus routers para filtrar los paquetes ICMP de petición indeseados (broadcast) o bien configurar sus máquinas para que no respondan a dichos paquetes. Es decir, que lo que se parchea son las máquinas/redes que puedan actuar de intermediarias (inocentes) en el ataque y no la máquina víctima.

De igual forma también se podría evitar el ataque si el router/firewall de salida del atacante (p.ej. el ISP al que pertenece) estuviera convenientemente configurado para evitar spoofing. Esto se haría filtrando todos los paquetes de salida que tuvieran una dirección source (origen) que no perteneciera a la red interna (desde la cual salimos).

Para más información sobre "smurf" os remito a:

http://www.quadrunner.com/~c-huegen/smurf.txt

4.-Spoofing

Esta técnica no es un ataque en sí pero permite mejorar y perfeccionar cualquier ataque (de los anteriores, por ejemplo). También puede ser la base de algún ataque, como ocurre con el IP Spoofing que los hackers suelen emplear (me desviaría del tema de este escrito si siguiese escribiendo...).

Se trata de "spoofear" (=falsear) la dirección IP de origen de los paquetes que se mandan a la víctima, de forma que ésta crea que el origen de dichos paquetes es otro (el que nosotros le indiquemos). De esta forma protegemos nuestro anonimato, y en general podemos llevar a cabo cualquier acción que se nos pueda ocurrir y que se derive de una falsa dirección source (origen). Por ejemplo, podemos nukear a alguien, con la dirección fuente de otro, haciendo creer a la víctima (si ésta tiene un analizador de paquetes o algo parecido) que es el otro el que le está atacando }:-).

El spoofing es (o podría ser) una funcionalidad más del programa de ataque (del nuker, del ping, ...). Como consiste en manejar IP desde un muy bajo nivel en muchos casos se requieren privilegios especiales. Por ejemplo, en el caso de máquinas Unix, se necesita abrir "raw sockets" y ésto requiere de privilegios de superusuario (root).

Para los interesados en el tema os remito a las siguientes direcciones:

* IP-spoofing Demystified Trust-Relationship Exploitation by daemon9 / route / infinity

http://www.fc.net/phrack/files/p48/p48-14.html

* IPSPOOF.C (Spoofing source)
http://www.ilf.net/Toast/files/unix/ipspoof.c

* This site contains both spoofing code, an analysis of that spoofing code and a good description of how to implement such attacks:
http://main.succeed.net/~coder/spoofit/spoofit.html

5.- Técnicas avanzadas

5.1.- Bouncing

Consiste en usar una máquina (Host) intermedia para mantener una comunicación TCP "virtual" entre dos máquinas (situadas una a cada lado). El esquema sería algo así como:

Host A <---> Bouncer <---> Host B
(1) (2)

Todos los datos que A tiene para B son enviados al bouncer. Este se encarga de reenviarlos a su destino (B). De igual forma ocurre en el otro sentido. El bouncer actúa de elemento redireccionador en ambos sentidos.

La máquina intermedia corre un programa especial (daemon)llamado "bouncer". A menudo nos referiremos también con el mismo término a la máquina intermedia (i.e. la que corre el soft especial), de la misma forma que se ha asumido al dibujar el esquema. Dicho programa usa dos puertos TCP previamente definidos, uno por cada conexión (A<->Bouncer, Bouncer<->B), y hace de pasarela entre ellos (tal y como se ha explicado). Por tanto, mantiene por separado dos conexiones TCP diferentes pero las "enlaza" de forma que en su conjunto parezca una única conexión TCP (de ahí lo de "virtual")entre A y B.

La ventaja que ésto conlleva es que ocultamos nuestra identidad a los ojos de B, ya que éste solo ve la comunicación que mantiene con el host intermedio (2) (y no tiene por qué saber que se trata de un host haciendo de bouncer).

A esta técnica se le puede dar diferentes usos, todos ellos basándonos en la principal ventaja descrita en el párrafo anterior. En lo que al IRC concierne es ampliamente usada para saltar bans o K/G-Lines. Lo vemos con un ejemplo. Supongamos que nosotros somos el host A y que no podemos entrar a ningún servidor (B) de una red IRC por estar baneados permanentemente. ¿Qué hacer? Pues hacemos uso de una shell en otro host (que va a ser el intermedio) y colocamos allí un bouncer. Al programa, que se quedará corriendo en segundo plano (background), le tenemos que dar dos datos:
el puerto que estará permanentemente escuchando (por donde recibirá nuestra conexión) y el host y puerto destino (a donde intentará conectarse) correspondientes a B. Ahora, cuando queramos conectarnos al IRC lo hacemos al primero de los puertos predefinidos (correspondiente al host que alberga el bouncer). Automáticamente el bouncer redireccionará nuestra petición hacia B (el servidor IRC) y estaremos dentro (¡saltándonos el ban o lo que sea!) ya que hemos llegado a través de un host que no tenía ningún ban. A todos los efectos el servidor IRC cree que nuestro host es el bouncer. Así, al hacernos cualquier otro usuario un /whois ¡verá el hostname del bouncer! (ésto es otra ventaja ya que no nos pueden mandar ataques como OOB's o Sspings, por no saber nuestra verdadera dirección IP). Es una buena forma de garantizar nuestro anonimato =).

5.2.- DNS Inject

Con esta técnica conseguimos spoofear nuestro hostname, es decir, que un servidor nos asocie el nombre de host que queramos (y no el que tiene realmente, que es único) (en realidad, puede haber más de uno, pero sólo uno es el real, lo que se conoce como "canonical name" mientras que los demás son simples "aliases").

La explicación detallada es compleja y excede los objetivos de este documento. A título informativo paso a esbozar o perfilar lo que sería el Inject.

Cada servidor (ya sea de IRC, ftp, étc) tiene asociado uno o más "servidores de nombres" (NS, del inglés: Name Server) que resuelven todas las peticiones de conexión que le llegan: para cada IP que peticiona conexión buscan y almacenan el hostname correspondiente para su posterior uso. El proceso sería el siguiente:

- un usuario de la máquina A intenta conectarse a un puerto de la máquina B (el servidor IRC, ftp, ...).
- B recibe la dirección IP desde la que peticionamos (la de A) y se la entrega a C (otro host: el NS) para que la resuelva.
- C resuelve y devuelve su respuesta a B.
- B se "cree" la respuesta y la cachea en memoria.

Ahora tiene un par IP-hostname. A partir de este momento nosotros estamos identificados en el servidor con el hostname dado anteriormente por el NS.

Como se puede intuir el truco está en forzar al NS a que de una respuesta falsa (siempre en favor nuestro :-)). Digamos que modificamos los datos del NS para que responda a nuestra IP con el hostname que nosotros queremos y no con el que debería hacerlo realmente. Se dice que hemos "inyectado" (injectado, en inglés :-P) el NS.

El cómo hacer esto último es lo complicado y sólo voy a decir que el truco se basa en la "resolución recursiva" de los NS (cuando un NS no sabe la respuesta a la petición que le ha llegado lanza una nueva petición a otro NS, que posiblemente sí sepa la respuesta, y así sucesivamente --> de ahí la "recursividad") y en tener finalmente un NS trucado que de respuestas falsas y que nosotros reprogramamos a nuestro gusto.

La principal ventaja es una vez más el anonimato (aparte de poder ir vacilando por el IRC con una identidad del tipo root@nasa.gov :-O).

6.- Resources

Este apartado está dedicado, brevemente, a los distintos programas disponibles y útiles a nuestra causa :-).

Esta URL, por lo menos antes, era buena: http://www.7thsphere.com/virus. Allí podrás encontrar toda clase de utilidades para Windows y Linux: programas nukeadores, port-scanners, étc... Lo malo es que necesita un password que puedes obtener ojeando ciertas páginas de publicidad que hospedan y es un poco engorroso.

Podréis encontrar muchísimos scripts para mIRC y una sección interesante sobre el bot Eggdrop en:
http://www.xcalibre.com.

También me gustaría recordar la Home Page de este documento:
http://www.esi.us.es/~roman/tacticas.html, donde encontrareis siempre la versión más reciente del mismo.

7.- Agradecimientos

Quisiera dar las gracias a jcea@argo.es por echarle un vistazo a la primera versión de este texto y por sus comentarios desinteresados sobre él. Así mismo, a todos los que me habéis apoyado con vuestros comentarios u opiniones acerca de este escrito.

También me gustaría saludar desde aquí a todos mis amigos y conocidos del IRC, en especial a los canales #insultos, #hack, #hackers, #hack_novatos, #amiga y #llfb de la red irc-hispano.

8.- Modificaciones

* Cambios en este documento desde la versión 0.99a+:

- Añadida esta sección. :-)
- Mejor explicado lo del "spanning tree" (estructura de una red IRC).
- Añadido el concepto de "hop".
- Añadidas un par de URL's en la sección de "resources".
- Añadida sección "técnicas avanzadas" incluyendo "bouncing" y "DNS Inject".
- Añadidos diversos fuentes en C: ICMP nuke, OOB, ssping, bouncer, ... (Podrás verlos en la página personal de RoMaNSoFt)
- Añadidas direcciones donde encontrar numerosos parches.
- Añadidas URL's de referencia en la sección de "spoof".
- Añadidos nuevos ataques: teardrop, land, teardrop modificado y smur

9.- Notas finales

Espero que este pequeño artículo os haya servido al menos para comprender un poco más el funcionamiento del IRC.

También me gustaría recordar que el IRC no es un campo de batalla, y que no se debe atacar a la gente así porque así, salvo "en defensa propia" y pocos casos más justificados. O:-) En cualquier caso un ataque nunca está justificado desde el punto de vista de los ircops, así que cuidado con las K/G-lines ;-)

Se agradecería toda clase de comentarios y sugerencias para mejorar el documento: bug reports, asuntos que creáis no están bien explicados, temas que faltan y se deberían incluir, ..., y en definitiva todo lo que os gustaría que se incluyese en el documento. También se aceptan O-lines ;-).

Se rechazará estrictamente todo aquello que salga de la temática así como dudas personales. Si lo creo conveniente y las dudas son generalizadas las intentaré aclarar en posteriores revisiones de este documento pero (y repito) no a nadie en particular. Tenéis que comprender que no tengo todo el tiempo del mundo.

Podéis contactar con el autor de este escrito por email: roman@deathsdoor.com. O localizarme en el IRC hispano bajo el nick de RoMaNSoFt.

La distribución de este documento es "libre", con la única condición de informar al autor en caso de subirlo a algún ftp site o página web. La misma restricción se aplica a cualquier otra forma de difusión pública (revistas, news, étc).
(c) RoMaN SoFt / LLFB, 1998.- (última modificación de este fichero: 27/02/98)