»Si deseas saberlo, te diré que estas puertas se abren hacia afuera. Puedes abrirlas desde dentro empujándolas con las manos. Desde fuera nada las moverá excepto la contraseña indicada. No es posible forzarlas hacia adentro…

Gandalf en The Lord of the Rings de J. R. R. Tolkien.

El 15 de febrero de 1995 el FBI detiene a Kevin Mitnick, en Raleigh, Carolinadel Norte. Mitnick era, en ese entonces, el hacker más famoso y fugitivo que se conocía; fue acusado de haber atacado numerosas compañías de comunicaciones, en California y Carolina del Norte, así como de haber causado daños y robado información propietaria.

Su caso fue nota de mucha relevancia, en los medios y en la comunidad hacker. Fue puesto en libertad después de estar 5 años en prisión y condenado a no poder acercarse a algún sistema informático.

Su captura fue registrada a través de un libro Takedown, aunque el mismo Mitnick ha dicho que no es la verdad absoluta. Existe otra publicación que cuenta una versión distinta de la captura, The Fugitive Game.

Pero ¿como fue capturado? ¿Como se dio cuenta Shimomura que habían penetrado en su sistema? es más, ¿Como lo hizo Mitnick? Vamos a analizarlo:

Mitnick utilizó dos mecanismos de ataque en los sistema de Shimomura (osiris y ariel):

• IP spoofing (Suplantación de IP)
• Predicción de números de secuencia TCP/IP

Primeramente, desde un equipo previamente comprometido (toad.com), reviso los sistemas de Shimomura para obtener la detección de Sistema Operativo (OS fingerprinting), y se dió cuenta que existía una relación de confianza entre osiris y rimmon:

toad.com# finger –l @ariel.sdsc.edu
toad.com# finger –l @rimmon.sdsc.edu
toad.com# finger –l root@rimmon.sdsc.edu
toad.com# finger –l @osiris.sdsc.edu
toad.com# showmount –e osiris.sdsc.edu
toad.com# rpcinfo –p osiris.sdsc.edu
toad.com# finger –l root@osiris.sdsc.edu

Entonces, inició un ataque de SYN flood hacia rimmon, para anestesiarlo y poder suplantarlo, como es esto? Anteriormente, veíamos como funcionaba el protocolo TCP/IP, y mencionábamos el saludo de tres vías (three-way handshake). Supongamos que el equipo A, quiere comunicarse con el B:

1. A -> B   (“quiero hablar contigo”)
SYN
2. B -> A (“¿seguro que quieres hablar conmigo?”)
SYN/ACK
3. A -> B (“seguro, hablemos”)
ACK

En este caso, el ataque sería algo como:

1. A -> B   (“quiero hablar contigo”)
SYN
2. B -> A (“¿seguro que quieres hablar conmigo?”)
SYN/ACK
3. A -> B   (“quiero hablar contigo”)
SYN
4. B -> A (“¿seguro que quieres hablar conmigo?”)
SYN/ACK
…

Desde una IP falsificada (sin usar) envía peticiones de conexión (SYN) hacia el puerto 513 (login) de rimmon:

1. 130.92.6.97 -> rimmon   (“quiero hablar contigo”)
SYN
2. rimmon -> 130.92.6.97 (“¿seguro que quieres hablar conmigo?”)
SYN/ACK
3. 130.92.6.97 -> rimmon   (“quiero hablar contigo”)
SYN
4. rimmon -> 130.92.6.97 (“¿seguro que quieres hablar conmigo?”)
SYN/ACK
…

Con rimmon, anestesiado, Mitnick realiza un intento de conexión, desde otro equipo comprometido (apollo.it.luc.edu), hacía osiris, con el fin de analizar los números de secuencia de osiris:

1. apollo.it.luc.edu -> osiris   (“quiero hablar contigo”)
SYN
2. osiris -> apollo.it.luc.edu (“¿seguro que quieres hablar conmigo?”)
SYN/ACK
3. apollo.it.luc.edu osiris -> osiris   (“adiós”)
RST

En los números de secuencia se observa:

14:18:25.906002 apollo.it.luc.edu.1000 > osiris.shell: S 1382726990:1382726990(0) win 4096
14:18:26.094731 osiris.shell > apollo.it.luc.edu.1000: S 2021824000:2021824000(0) ack 1382726991 win 4096
14:18:26.172394 apollo.it.luc.edu.1000 > osiris.shell: R 1382726991:1382726991(0) win 0
14:18:26.507560 apollo.it.luc.edu.999 > osiris.shell: S 1382726991:1382726991(0) win 4096
14:18:26.694691 osiris.shell > apollo.it.luc.edu.999: S 2021952000:2021952000(0) ack 1382726992 win 4096
14:18:26.775037 apollo.it.luc.edu.999 > osiris.shell: R 1382726992:1382726992(0) win 0

Los números iniciales de secuencia  son incrementados en 1, por cada conexión; lo cual indica que los paquetes SYN no están siendo generados por la implementación de TCP del sistema, lo que provoca que se generen RST’s como respuesta a cada SYN/ACK, de modo que la cola de conexiones de osiris no se llena. También, puede observarse, que cada paquete SYN/ACK enviado por osiris tiene un número de secuencia inicial que es 128,000 más que el anterior.

Con estos datos, y rimmon dormido, se inicia la suplantación de rimmon, desde apollo se envía una solicitud de conexión:

1. (apollo.it.luc.edu) rimmon -> osiris   (“quiero hablar contigo”)
SYN
2. osiris -> (apollo.it.luc.edu) rimmon (“¿seguro que quieres hablar conmigo?”)
SYN/ACK
3. (apollo.it.luc.edu) rimmon -> osiris (“seguro, hablemos”)
ACK

Normalmente, el número de secuencia del SYN/ACK es necesario para generar un ACK válido. Sin embargo, si el atacante es capaz de predecir el número de secuencia contenido en el SYN/ACK, basado en el comportamiento conocido del generador de números de secuencia TCP, es posible crear un ACK válido, aún sin haber visto el SYN/ACK.

En los logs del sistema de osiris, Shimomura observo esto:

14:18:36.245045 rimmon.login > osiris.shell: S 1382727010:1382727010(0) win 4096
14:18:36.755522 rimmon.login > osiris.shell: . ack 2024384001 win 4096

Ahora, el equipo spoofing (apollo) mantenía una conexión con osiris, que parecía ser desde rimmon, con el cual, mantenía un mecanismo de confianza. Con la suplantación lograda, Mitnick envía un comando que le aseguraba una conexión abierta a osiris, mediante la configuración del archivo .rhosts:

apollo.it.luc.edu(rimmon)# rsh osiris echo “+ +” >> /.rhosts

Al configurar el archivo .rhosts con los símbolos “++“, se permite el acceso a cualquier usuario, desde cualquier equipo.

Con el acceso asegurado como root, envía un modulo de kernel, llamado “tap-2.01” para compilarlo en osiris:

osiris% modstat
Id Type Loadaddr Size B-major C-major Sysnum Mod Name
1 Pdrv ff050000 1000 59. tap/tap-2.01 alpha

osiris% ls -l /dev/tap
crwxrwxrwx 1 root 37, 59 Dec 25 14:40 /dev/tap

Aparentaba ser un modulo del kernel, el cual, podía ser insertado dentro de la pila de módulos del kernel y ser usado para tomar el control de los dispositivos tty. Esto fue usado para tomar el control de una sesión activa en ese mismo momento, cerca de las 14:51 PST.

Con este método de acceso, ya solamente faltaba el premio, para demostrar que había entrado en los sistemas de Shimomura. Mitnick copio algunos archivos sobre teléfonos celulares (oki.tar.gz).

La defensa de Mitnick, en este sentido, consistía en argumentar que nunca utilizo los archivos copiados con lucro, solamente los obtuvo como demostración de haber penetrado en el sistema.

Actualmente, Kevin Mitnick se dedica a la seguridad de la información, con su propia empresa(Mitnick Security Consulting, LLC). Desde la perspectiva de la Ingeniería Social; ya que, según la filosofía de Mitnick, más allá de los conocimientos técnicos de software/hardware que se puedan implementar en los sistemas, el factor determinante de la seguridad de los mismos es la capacidad de los usuarios de interpretar correctamente las políticas de seguridad y hacerlas cumplir.

Kevin Mitnick estará participando en la próxima Campus Party México 2010, en la cual dará una presentación sobre seguridad de la información; aquí les dejo la agenda completa por si piensan asistir. Yo asistiré, a ver si consigo una tarjeta de presentación de Kevin (o una foto al menos).

Después haré algunas entregas de lo visto en la Campus Party.

Si quieren saber más de estos temas, les dejo unas cuantas ligas:

The Kevin Mitnick/Tsutomu Shimomura affair

Takedown (sitio oficial)

IP Spoofing Desmitificado

Debilidades en el Protocolo TCP/IP de Robert Morris

Espero les sirva.

Este post lo dedico a quien me dió la oportunidad de desarrollarme en unix/seguridad, de quien agradezco me enseñara el camino y a caminar en él; y sobre todo, sus sinceras palabras cuando le preguntaban de mi persona: “Cuando lo conocí, ni siquiera sabía tirar un ls…”

Gracias!