5. Recogiendo datos

A la mañana siguiente en que Andrew y yo llegamos a San Diego tras el ataque a mis ordenadores, la sala 408 del Centro de Superordenadores se convirtió en nuestro centro de operaciones de guerra.

Situado en la planta superior, el amplio salón tuvo en un tiempo una vista al océano, recientemente bloqueada por el nuevo edificio de la Escuela de Asuntos Internacionales, y actualmente obstaculizada aún más por un par de monitores, una cámara y otros aparatos para videoconferencias que cubrían parcialmente los ventanales de aquel lado del recinto. Pero por lo demás, los diversos elementos con que contaba —una extensa mesa de conferencias, tableros blancos contra las paredes, y conexiones con la red para nuestros ordenadores portátiles— eran perfectos para nuestros propósitos.

Nuestro grupo de urgencia empezó a organizarse a eso del mediodía. Aunque estábamos en la semana de Navidad y no había clases, siempre quedaban en el Centro algunos investigadores, estudiantes, posgraduados, e incluso algunos funcionarios y técnicos, de modo que pudimos reunir un improvisado equipo investigador para tratar de recrear la intrusión. Con el fin de añadir un pequeño incentivo encargamos la comida a la Thai House, una de nuestras favoritas, como a diez kilómetros del campus. Yo había decidido que si Sid iba a soltar dinero para los gastos, debíamos intentar hacer algo útil con él, como alimentar a la gente.

Mediante una ronda de llamadas telefónicas había logrado reunir un ecléctico escuadrón de personas dispuestas a dedicarme parte de su tiempo. Debido a las prisas del planteamiento, era una especie de ejército anárquico, y mientras que algunos de sus integrantes asumían tareas específicas, otros estaban allí simplemente para prestar su apoyo moral, o por curiosidad. Rama Ramachandran era un antiguo estudiante de la UCSD que ahora estaba en la escuela empresarial de la Universidad de Chicago y se encontraba de visita por vacaciones. A mí me seguía desconcertando aún el extraño mensaje de error de sintaxis del intérprete PostScript X-NeWS que había estado en el visualizador de la consola de Ariel el día anterior, y como Rama era un verdadero gurú en PostScript, le pusimos enseguida a trabajar examinando el intérprete a ver si había sido empleado para lograr el acceso.

Entre quienes se unieron a nosotros estaban John Moreland, programador científico de visualización, y Henry Ptasinski, un estudiante en ingeniería eléctrica e informática graduado en la UCSD. Por entonces, Henry era asimismo uno de los administradores de sistema en CERFnet, un proveedor de servicio de Internet estrechamente vinculado al Centro.

En el Centro había además un encargado de la seguridad de las redes. Tom y yo generalmente nos llevamos bien siempre que no tengamos que trabajar juntos, pero le gusta intervenir en todo y a veces me refiero a él como “obstáculo ambulante”. Puede que parezca una desconsideración, pero nunca he sido capaz de encontrar la manera de ser tolerante con los responsables del mantenimiento de las normas y reglamentos burocráticos que al parecer hacen que cualquier vasta organización funcione. Julia dice que mi palabra favorita es “payaso”, y sostiene que debería tratar de ser un poco más diplomático. Lo intenté esta vez, cuando se presentó a ver si podía hacer algo útil. Le entregué un fragmento de código llamado rpc.ttdbserverd^[15] —que facilita la comunicación de algunos programas a través de una red de ordenadores— y le pedí que se lo llevara para analizarlo en busca de vulnerabilidades ignoradas por nosotros. Nos había entrado la sospecha de que aquello podía haber jugado un papel en el forzamiento, porque en uno de nuestros archivos de registros de actividad figuraba un acceso inusual al mismo en una noche de Navidad.

Cuando él abandonó la sala, uno de los estudiantes graduados se volvió hacia mí y preguntó: “¿Por qué le has encargado una cosa como ésa? Siempre te estás quejando de él”.

Andrew y yo nos miramos, y yo repliqué: “Básicamente para mantenerle tranquilo y que no nos moleste”.

“Tú sabes que no va a dejarte en paz”, dijo el estudiante.

“Bueno”, dije yo, “al menos esto lo va a tener un buen rato ocupado”.

A esas alturas todavía estábamos recopilando datos, y las cosas aparecían bastante negras, lo cual me puso todavía más malhumorado. Ya había extraído información de Rimmon y Astarte, las máquinas de casa. Por entonces podíamos asegurar que Osiris había sido interferido, pero no cómo. En cada uno de estos ordenadores habíamos hecho comprobaciones para ver si algún archivo había sido alterado y si se habían dejado atrás cualquier programa dudoso. Al no ver ninguno inmediatamente empecé a preocuparme todavía más, porque eso indicaba que nuestro incursor conocía algún otro modo de meterse, y que creía poder volver sin ser detectado. Yo no podía pensar en volver a estar conectado hasta hacer una estimación sobre el riesgo de una nueva intrusión. Todo el mundo se enfrascó en su respectiva tarea, dejándonos a Andrew y a mí en los ordenadores portátiles que habíamos instalado.

Los progresos resultaron esporádicos. Debido a la edad de Ariel, obtener datos útiles del ordenador era un proceso frustrante que nos llevó buena parte del día. En un ordenador moderno, la mayoría de los componentes están conectados por un haz de líneas conocido como bus de datos. Microprocesadores, memoria, disqueteras, visualizadores gráficos y periféricos varios, todos conectan a través de esta autopista principal, que en realidad no es sino un conjunto de cables paralelos que permiten que la información circule en ambos sentidos con increíble rapidez. Ariel era tan antiguo que utilizaba un bus llamado VME, inventado en los años ochenta para los miniordenadores. Sus disqueteras se basaban también en un estándar anticuado, de modo que no había forma de poder conectar los discos de Ariel directamente a mis ordenadores portátiles, que utilizaban disqueteras SCSI más modernas. En consecuencia, teníamos que copiar primero todos los datos necesarios extraídos de Ariel para luego poder trabajar con seguridad en él.

Anduvimos los dos explorando el edificio buscando algunos discos extra para almacenar aquella enorme cantidad de información, y por fin, ya avanzada la noche, conseguimos arrancarle a la gente de CERFnet un disco de dos gigabytes. (Para entender cuánta información representan dos gigabytes, piénsese que uno de esos discos podría almacenar cómodamente la Enciclopedia Británica entera, texto e ilustraciones, todo en la palma de una mano). Empleamos varias horas tratando de resolver cómo trasladar toda la información de forma que estuviese organizada exactamente como estaba almacenada en Ariel.

A las 10 de la noche tuve toda la información de Ariel transferida al disco duro y lista para ser examinada en mi RDI portátil. Para entonces casi todos los demás habían abandonado el Centro, y Andrew y yo sentimos la necesidad de hacer un paréntesis para cenar. Bajamos en el ascensor y nos alejamos del campo en coche hasta Rubio’s, un local barato de pescado y tacos que a ninguno de los dos nos gustaba especialmente. “Oye, tenemos una cuenta para gastos y en realidad deberíamos comer algo mejor que esto”, le dije a Andrew. “No quiero presentarle a Sid una nota de 4.95 dólares por una cena”. Pero después de las diez de la noche no hay en aquella parte de San Diego muchos lugares donde elegir. Comimos rápidamente, deseosos de regresar al Centro a ver qué nos diría la información de Ariel.

De vuelta en la sala 408, me llevó cerca de un cuarto de hora ejecutar los programas de detección que, como con Rimmon y Astarte en casa, desvelaron a cuáles archivos de Ariel alguien había accedido y cuáles había modificado o corrompido. Por primera vez supe realmente qué habían robado de Ariel: virtualmente todo lo existente en mis directorios. Gran parte era valioso para mí y mi trabajo, incluyendo decenas de miles de mis mensajes del correo electrónico, el código fuente para programas que yo había escrito y delicada información privilegiada. Pero de aquella lista de elementos no podía extraerse ninguna conclusión, pues el ladrón o los ladrones habían sido tan poco selectivos que habían empleado también horas en copiar programas libremente disponibles en cualquier parte de la Red, incluyendo diversas herramientas que yo mismo había bajado de la Free Software Foundation.

Nuestro análisis de los datos de Ariel produjo por cierto una noticia: los intrusos habían estado robando archivos apenas dos horas antes de que Andrew descubriese la intrusión. De modo que ahora teníamos un cuadro bastante completo de lo que había ocurrido y cierta noción de cuándo. Pero seguíamos sin responder a la pregunta que, para mí, era la más importante: “¿Cómo lo hicieron?”.

Yo sabía que a Osiris, la máquina de la cabecera de mi cama, habían accedido antes que a Ariel, en mi oficina del SDSC, pero no sabía cómo habían llegado a una y otra, ni si habían utilizado una para llegar a la otra. Y luego estaba aquel mensaje de error del programa intérprete XNeWS PostScript en Ariel, que parecía indicar un intento de sondeo desde Colorado SuperNet. ¿Era significativo… o era una pista falsa? Si nuestro atacante sabía realmente lo que hacía, la desinformación era una posibilidad que teníamos que tener en cuenta.

Había asimismo otros elementos aislados que formaban un rompecabezas que yo todavía era incapaz de resolver. Uno de ellos era un misterioso programa, Tap, que yo había visto el día anterior mientras examinaba la memoria de Osiris. Era un programa temporal que alguien había creado y colocado en la memoria de mi ordenador para una tarea específica. Cuando el ordenador fuese apagado o vuelto a arrancar, se borraba para siempre. ¿Y qué pasaba con el fantasma del archivo oki.tar.Z, cuya creación sugería que alguien andaba detrás del software del teléfono móvil, no obstante la ausencia de selectividad en el saqueo?

El examen de la información de Ariel dio lugar a otro descubrimiento crucial: el intruso había tratado de escribir encima de nuestros registros comprimidos, en los que conservábamos una relación detallada de los diversos paquetes de datos enviados a nuestras máquinas, o recibidos por ellas, a través de Internet. Los archivos de registro borrados revelaron que al intentar sobreescribir en ellos el intruso no había tapado enteramente los originales. Era como si hubiese tratado de ocultar sus huellas en la arena arrojándole encima más cubos de arena: en algunos lugares todavía quedaba a la vista un talón, un dedo gordo, incluso un pie entero. Al parecer, teníamos nuestras primeras pistas. Puede que no tuviésemos enteramente la ruta de escape, pero al menos sabíamos en qué dirección comenzar a rastrear.

De hecho, aunque ninguna de las piezas del rompecabezas encajaba aún, el registro compacto nos proporcionó una forma potencial de comenzar a ordenar nuestros indicios. La alteración por el intruso de aquel registro de actividad aislado había sido lo primero que había alertado a Andrew sobre el ataque. Ahora, la chapucera sobreescritura del archivo de registro compactado nos daba la posibilidad de recrearla, gracias a la tecnología empleada para encaminar fragmentos de datos —paquetes— por Internet.

Esta tecnología se llama “transferencia de paquetes” y, como la propia Internet, es el resultado directo de una idea concebida a comienzos de los sesenta por un investigador de la Rand Corporation llamado Paul Baran. En aquellos días, en plena guerra fría, los militares estaban obsesionados por el problema de sobrevivir a una guerra nuclear, de manera que uno de los encargos asignados a sus think tanks o gabinetes de estrategia fue inventar un sistema de comunicaciones que continuase operando incluso si algunos de sus enlaces resultaban destruidos.

Baran concibió la idea de una red de ordenadores que fuera capaz de reconducir automáticamente el tráfico. La técnica, la transferencia de paquetes, consistía en fragmentar cada mensaje en un gran número de paquetes pequeños. Cada paquete contenía únicamente una pequeña porción del mensaje, acompañada de un packet header o guía direccional provisto de información suficiente para que en cada punto de la ruta durante su pasaje por la red cada uno de aquellos pequeños paquetes de datos pudiera ser reconducido en caso necesario y arribar con seguridad a su destino final. Los ordenadores router estaban dotados de suficiente inteligencia como para que aunque los paquetes tomaran rutas diferentes y llegasen desordenadamente, o incluso se perdiesen, fuera posible reconstruir el mensaje en el orden correcto y requerir el reenvío de los paquetes extraviados.

La de Baran fue una brillante concepción, y a fines de los años sesenta la Agencia de Investigación de Proyectos Avanzados (ARPA) del Pentágono financió un proyecto experimental para desarrollar una red de ese tipo. El primer mensaje —“Watson, venga aquí. Necesito su ayuda”— circuló en 1970 entre el Instituto de Investigación de Stanford (actualmente SRI International), en Menlo Park, y un grupo de investigadores informáticos en la UCLA. A partir de entonces, las cosas se han salido un poco de madre: de las dos primitivas localizaciones de ARPAnet, la red Internet se había expandido a más de 6,6 millones de máquinas y seguía creciendo en proporción geométrica.

Pero al tiempo que la multiplicidad de máquinas y usuarios está sobrecargando Internet en varios sentidos, y suministrando cobertura a gente dedicada a hacer daño, cada uno de los billones de paquetes flotando a través de la red sigue llevando esa etiqueta informativa, que dice no sólo adonde va el paquete, sino de dónde se supone que viene. Y puesto que yo sabía que un filtro de paquetes puede tomar debida nota de toda esa información, tenía la esperanza de que los registros de paquetes de Ariel pudieran oportunamente ayudar a recrear las acciones del intruso.

Pero había una complicación: aunque el intruso no había logrado suprimir la escritura anterior del archivo de registros compactado al escribirle encima, su esfuerzo por borrarla iba a dificultar la lectura. La forma en que la información se almacena en un disco duro se asemeja al modo en que una biblioteca organiza sus fondos. Lo que uno realmente quiere de una biblioteca es poder dirigirse al bibliotecario, pedir un determinado libro y que se lo entreguen; no le importa dónde esté colocado. Del mismo modo, la información sobre los archivos que uno crea en un ordenador está toda almacenada en un lugar en el disco duro —cabe considerarlo como el fichero de una biblioteca— pero la información en sí se conserva en otra parte, generalmente diseminada en pequeños bloques por toda la superficie del disco.

Como los bibliotecarios, los sistemas operativos de los ordenadores se encargan de la tediosa labor de almacenar y localizar la información. Cuando el sistema operativo borra un archivo, lo que hace en realidad es borrar los indicadores que conducen a la información, la tarjeta del fichero, más bien que la información en sí, que permanece hasta que todo el espacio disponible en el disco duro está lleno y llega un momento en que nuevos datos almacenados se sobreescriben sobre los datos borrados. (Tratar de impedir esa sobreescritura fue uno de los motivos por los que hice detener el funcionamiento de Ariel y las otras máquinas tan pronto como me enteré del forzamiento).

De modo que aunque el archivo de paquetes había sido borrado, era efectivamente posible que sus datos pudieran aún reconstruirse a partir del disco; sólo que la tarea era ímproba. Como primer paso de procedimiento, Andrew sugirió: “Creo que puedo escribir un programa que localice el punto del archivo donde acaba la corrupción y luego busque el sitio donde empieza la información real”. Sería un punto de partida útil, pero que no necesariamente nos permitiría dar con todos los diferentes fragmentos de datos que estábamos buscando, pues aquello sólo pondría de manifiesto la información escrita en el archivo después de haber sido manipulado.

Se me ocurrió que podría haber una forma mejor y menos obvia de encontrar la misma información. Como físico pienso mucho en conceptos como entropía y caos, y he pasado mucho tiempo construyendo herramientas que detectan esquemas o estructuras que de otra manera podrían pasar desapercibidas. Un cuerpo de datos puede parecer ruido, pero de hecho puede poseer una estructura oculta. El reto consiste en revelar esa estructura, que puede existir en forma clara o en una que requiera el filtro adecuado para verla.

En cierto sentido me enfrentaba al mismo problema que un criptógrafo romano intentando descifrar un antiguo lenguaje codificado conocido como clave de César. En este procedimiento, los mensajes militares se escribían en la superficie de un pergamino envuelto alrededor de un cilindro o un cono. El único modo de decodificar el mensaje era encontrar un objeto del mismo tamaño y forma y envolver el papel alrededor hasta alinear la escritura.

De un modo semejante, yo necesitaba encontrar un esquema en los diminutos fragmentos de datos diseminados por la superficie de nuestros discos. Como todos los datos informáticos, estaban en forma de código binario: hileras de unos y ceros que pueden representar dígitos, letras y otros tipos de información. Cada fragmento de hilera era un eslabón de una cadena de información; el problema era descubrir el esquema según el cual aquellos eslabones individuales habían sido diseminados, para poder encontrarlos y rehacer la cadena. Yo lo había dejado para más tarde, porque parecía una apuesta arriesgada. Pera lo que hasta entonces habíamos conseguido a través de otros análisis era insuficiente, de modo que se nos presentaba como el necesario siguiente paso.

“Veamos quién es capaz de conseguirlo el primero”, le dije a Andrew a eso de la una y media de la mañana. Convinimos en que él escribiese su programa convencional para recuperar la información del paquete mientras que yo escribía uno para buscar esquemas en el disco y después intentar reordenarlos en algo que se pareciese al archivo original. Nos instalamos delante de nuestras estaciones de trabajo en una mesa de conferencias, el uno frente al otro, Andrew tecleando en su RDI portátil y yo con mi nueva versión del mismo ordenador, una máquina en la que cada vez depositaba más confianza a pesar de tratarse de un prototipo no probado.

Escribí un programa llamado Hunt para investigar el disco que puse en funcionamiento por primera vez alrededor de las 2:45 de la mañana, y un segundo programa llamado Catch, diseñado para organizar lo que Hunt encontrase. Gané efectivamente la carrera por un pelín, cuando mis programas terminaron su tarea a las 4, apenas antes que el de Andrew. Al final, los dos tuvimos éxito recuperando datos, y el archivo parcial de Andrew fue útil para contrastar mi botín de datos relevantes: 14 millones de bytes que habían estado esparcidos entre cerca de otros 2 billones, y que ahora nos permitían por fin recrear las acciones de nuestro intruso.

Saboreando el momento, me eché atrás en el asiento y exploré someramente nuestro reconstituido archivo de paquetes de registros. Con aquella información podríamos tener la oportunidad de repetir su mismo tecleado, algo muy semejante a rebobinar una cinta de vídeo para volver a ver un programa de televisión. Ahora teníamos la ocasión de reconstruir el rompecabezas. Era la primera vez en tres días que me sentía bien.

El intruso había supuesto que sobreescribiendo en la información la haría desaparecer. Debió haber sabido que no era así. “Probablemente, es un usuario de MS-DOS”, murmuré. Si intentaba ser invisible no debió haber sido descuidado. Empecé a preguntarme cuán bueno era en realidad. Una de las estrategias estándar en el submundo informático es compartir recetas de “cocina” para efectuar ataques y luego utilizar esos programas paso a paso contra objetivos en Internet. Ocurre con frecuencia: alguien roba un código fuente de una empresa de hardware o software, o tropieza con software corriente de seguridad de ordenadores como el que había habido en mis archivos robados, o estudia revistas de informática y encuentra cómo introducirse en un sistema. Si tiene éxito hace correr la voz entre su amigos por la red, o hace figurar los detalles del cómo en cualquiera de las numerosas tablas de anuncios que funcionan como punto de encuentro de granujas en Internet. Tal vez nuestro intruso fuera simplemente otro niñato que había aprendido a leer manuales técnicos o tablas de anuncios, y no se había percatado de que ocultar las huellas en el mundo digital no es siempre tan fácil como parece.

Por prometedores que fueran los indicios, era la tercera noche que yo dormía poco, de modo que acordamos abandonar la búsqueda. Me fui a casa, y mientras el Acura se deslizaba por las calles desiertas yo paladeaba la satisfacción de saber que aún si en el archivo de paquetes de registro no encontrásemos suficiente información como para iniciar decididamente la persecución de nuestro intruso, cuando menos deberíamos poder enterarnos de cómo había entrado y, por tanto, encontrar la forma de mejorar nuestras defensas. Cuando llegué a casa las primeras luces del alba se filtraban en mi dormitorio, pero a pesar de mi agotamiento físico no tenía sueño. Me senté con las piernas cruzadas en mi futón ante Osiris, examinando nuestros sistemas en busca de otros indicios. Estuve tecleando distraídamente con rpc.ttdb-serverd. ¿Por qué lo habían dejado funcionando la noche de la intrusión? ¿Poseía el intruso algún programa inteligente que recorriese una red de ordenadores entera para violar la seguridad? El tema me preocupaba, pero al cabo de otra hora de búsqueda infructuosa pareció un callejón sin salida.

Mientras mi coche ascendía por la colina hacia el SDSC a última hora de esa mañana, en lugar de sentirme abatido yo experimentaba por anticipado la excitación del desafío que tenía por delante. Andrew ya había llegado a la sala 408, al igual que la mayoría de los otros, y habían vuelto a ordenar que trajesen la comida. Mientras comíamos, sonó el teléfono en la sala de conferencias.

Era Mike Bowen, a quien yo conocía de la CERFnet. Ayudante técnico y un gurú en cierto tipo de tecnología digital conocida como tecnología telefónica ISDN, se mantenía también atento a los rumores del submundo informático. Yo había hablado con él el día anterior sobre la posibilidad de que hubiese oído comentar algo sobre nuestro problema. Él me había dicho que conocía a un tío llamado Justin Petersen, de quien yo había oído hablar, que estaba en prisión en Los Ángeles por estafa con tarjetas de crédito y tratando de llegar a un trato con los fiscales federales. Petersen había estado intentando persuadir a Mike para que utilizara sus contactos en la comunidad de la seguridad informática con vistas a que alguien pudiera convencer a los federales de escuchar su coartada: que Kevin Mitnick lo había hecho caer en una trampa mientras él —Petersen— intentaba ayudar al FBI a atraparlo. ¿Querría yo tal vez charlar con Petersen?. “Desde luego”, le había dicho yo a Mike, “¿por qué no?”.

Ahora Mike volvía a llamar para decir que había arreglado las cosas. Como Petersen estaba en la cárcel, sólo le permitían llamadas telefónicas de una lista restringida de personas. Para que él hablase con cualquier otra persona, alguien de la lista hacía la llamada y luego le hacía intervenir en la conversación. Mike dijo que eso estaba a punto de ocurrir y que estuviese atento. Y colgó.

Pocos minutos después sonó nuevamente el teléfono. “Hola, estoy con la persona de la que esperabas noticias”, dijo una voz que no reconocí.

“¿Quién habla?”, pregunté.

“¿Por qué no me llamas Eric?”, respondió otra voz en la línea. Petersen había decidido utilizar uno de sus numerosos alias, aunque el más conocido era el de Agente Robo.

Justin Tanner Petersen era un personaje curioso. Nativo de Baja California, había sido detenido por primera vez en Dallas en 1991 acusado de estafa con tarjeta de crédito y otros delitos informáticos. Gracias a un acuerdo con el Servicio Secreto y el FBI, fue puesto en libertad para trabajar bajo supervisión federal ayudando a perseguir a delincuentes informáticos, mientras otros cargos contra él se sustanciaban en los tribunales californianos. Al parecer Petersen había puesto al FBI sobre la pista de Kevin Mitnick en 1992, forzando a éste a andar ocultándose. Y también había colaborado con los representantes de la ley en reunir pruebas contra Kevin Poulsen, un programador de Silicon Valley que había sido detenido en 1991 y acabó confesándose culpable en junio de 1994 de hacerse electrónicamente con el control de una centralita telefónica de una oficina central de la Pacific Bell para amañar concursos en dos estaciones radiofónicas de Los Ángeles, en los que ganó dos Porsche, más de 200.000 dólares en efectivo, y al menos dos viajes a Hawai. (Si usted controla la centralita de la oficina central de la compañía telefónica puede convertirse cuando quiera en el afortunado número noventa y cinco en llamar). Entretanto, el FBI poseía un extenso expediente contra Poulsen por otras actividades en informática y telecomunicaciones, tales como escuchar las conversaciones telefónicas de su ex-novia, interceptar las de funcionarios de seguridad de la compañía telefónica que lo investigaban a él e incluso las comunicaciones electrónicas de los agentes del FBI que seguían los pasos a la hija de Imelda Marcos en Woodside, California.

Pero mientras trabajaba para el FBI parece que Petersen reincidió en el delito informático. En octubre de 1993, en una reunión en el juzgado con un fiscal de la oficina legal del distrito de Los Ángeles confesó una estafa con tarjeta de crédito. A continuación, en plena reunión, le dijo a su abogado que necesitaba un descanso, salió de la habitación y huyó. Vivió a salto de mata hasta que volvieron a capturarle, en agosto de 1994, y ahora, más de cuatro meses después, estaba a punto de ser condenado y esperaba que yo le ayudase a hacer un trato y rebajar su sentencia a cambio de colaborar con nosotros en la captura de Kevin Mitnick. Aunque había estado tratando de negociar con el Departamento de Justicia, sus perspectivas parecían oscuras. Como yo conocía a Scott Charney, el principal fiscal contra los delitos electrónicos, Petersen mantenía cierta esperanza de que pudiese ayudarle a hacer un trato.

Creía que Mitnick era quien lo había entregado a los federales en su detención más reciente, y eso no parecía gustarle. Tenía el acento llano de los oriundos de Baja California y me dio claramente la sensación de que no estaba siendo muy sincero.

“Ni siquiera sé si fue Kevin Mitnick el que se introdujo en mis ordenadores”, dije.

“Parece ciertamente el modus operandi de Kevin”, respondió Petersen.

Yo desconfiaba. Había potencialmente miles de personas que podrían andar tras mis máquinas. “¿Qué necesitaría para encontrarle?”, pregunté. “Tengo entendido que se encuentra en una situación difícil, dado que se burló de los federales al menos una vez”.

Él se mostró vago. “Yo sé cosas que obviamente no quiero decir por este teléfono”, replicó.

Petersen empezó a proponer que nos viésemos personalmente y entonces él podría contarme más. Dijo que creía estar muy cerca de pescar a Mitnick, que eso llevaría tal vez un mes. Habló de dinero para gastos. Era difícil formarse una idea del hombre, y yo seguía intentando sacar en limpio si realmente tenía o no algo que ofrecer.

Después de hablar durante cerca de tres cuartos de hora, dije finalmente: “Si tengo ocasión, le mencionaré esto a la gente de la ley, pero no creo que eso lleve a alguna parte”. Agregué que si yo estaba en Los Ángeles le visitaría en la prisión. Colgamos, y llamé a Mike Bowen para decirle “¿Debo creer algo de todo esto?”.

“No lo sé, es posible”, respondió Mike. Tal vez Mitnick le había realmente tendido una trampa a Petersen. “Pero existe otra posibilidad”, prosiguió. “Puede que a Justin le preocupe que Kevin Mitnick tenga suficientes datos sobre él para ponerle fuera de juego por mucho tiempo”.

Decidí que por ahora, al menos, me beneficiaría más analizar los datos de Ariel que confiar en gente como Justin Petersen.

Poco después de las cinco de la tarde, Andrew y yo estábamos listos para empezar a reconstruir una crónica segundo a segundo de los sucesos de la irrupción en uno de los grandes tableros situados a lo largo de la pared. Habíamos atraído a una pequeña audiencia de buscadores de curiosidades que se habían enterado de nuestro proyecto, incluyendo a Jay Dombrowski, el gerente del Centro encargado de redes y comunicaciones.

Nos encontrábamos en el punto álgido de nuestra investigación, y hacerlo tan públicamente implicaba un cierto riesgo: no causaríamos una gran impresión si salíamos con las manos vacías. Pero la oportunidad que todos nosotros teníamos de enterarnos de algo superaba el riesgo de pasar vergüenza.

Durante la tarde yo había maquillado el archivo de paquetes de registro reconstruido con un programa escrito por mí, llamado Cook, que lo despojó de todo lo extraño. También había ordenado los diversos datos de investigación que habíamos reunido —en primer término, los registros de los archivos que habían sido violados— y los había combinado en un archivo, organizado cronológicamente, que nos proporcionaba una línea temporal única de todos los hechos. El archivo de paquetes de registros estaba organizado de este modo de antemano. Todo cuanto habíamos hecho los últimos días había sido una preparación para esto: ahora compararíamos sistemáticamente los registros de paquetes, que nos mostrarían exactamente lo que el atacante tecleó o transmitió, con los datos de la investigación que revelarían las consecuencias de cada una de dichas acciones.

Andrew se situó de pie ante el tablero con un marcador especial, y yo me senté ante mi estación de trabajo RDI. Empecé a decir en alta voz cada acción según la extraía de las listas que habíamos compilado y combinado.

Comencé por la tarde del día de Navidad, poco después de pasar junto al ordenador de la entrada en Toad Hall y se me ocurrió comprobar el correo en mi red.

“14:09:32”, canté en voz alta. Por el reconstruido paquete de datos vimos que Ariel recibió por Internet la siguiente orden, una sonda exploratoria:

finger —1 @ariel.sdsc.edu

Finger es una utilidad estándar de Unix que despliega información sobre cada usuario registrado, y Ariel respondió proporcionando información básica, diciéndole al que sondeaba que existían conexiones ordinarias con Astarte, Rimmon y Osiris, y que mi ordenador había estado desatendido durante varios días. En los siguientes tres minutos del tiempo disponible de nuestro ordenador ejecutó otros seis sondeos, cada uno dirigido a diferentes aspectos de mi red.

“14:11:49”, leí. “Eh, han operado una llamada de procedimiento remoto a Osiris”.

Andrew rodeó la mesa y estudió la pantalla de mi portátil. Era experto en llamadas de procedimiento remoto —Remote Procedure Call o RPC—, una función de sistema operativo que permite que un programa solicite a un ordenador remoto que haga una determinada cosa. El resultado que estaba estudiando estaba expuesto en formato hexadecimal, el sistema de numeración de base 16 que los buenos operadores aprenden a leer como un segundo idioma. “Eso es un showmount -e^[16] para mostrar sistemas de archivos exportados”, dijo. En otras palabras, era una orden que permitía a la persona que la emitía determinar qué discos duros eran compartidos por los otros ordenadores de mi red. Alguien trataba de construir lo que se denomina un trust model de mi red, para ver cuántos ordenadores tenían una relación especial, con pocas barreras de seguridad entre ellos. Era un intento de ver qué ordenadores de mi red “confiaban” entre sí, como lo hacían Osiris y Rimmon, por ejemplo.

Examiné más de cerca los sondeos e hice un sorprendente descubrimiento: Todos provenían de toad.com.

“Esto es muy extraño”, le dije a Andrew. “Yo estaba en Toad Hall cuando se hicieron estos sondeos, a menos de diez metros de la máquina de la que vinieron”. Vi que la RPC había venido del puerto fuente 721 en toad.com, lo que quería decir que había sido emitida por alguien que estaba enraizado en Toad. Yo sabía que no había habido nadie más físicamente presente en Toad Hall en aquel momento aparte de Julia y yo, y me daba cuenta de que el ataque podía haber sido organizado desde cualquier parte de Internet. Aun así, no pude dejar de preguntarme si el intruso era alguien a quien yo conocía.

Estaba intrigado, pero no había nada que hacer más que lanzarse hacia adelante.

Seis minutos más tarde vimos en la corriente de datos una prueba de que alguien intentaba iniciar una conexión de Internet: una solicitud llamada SYN (de sincronizar, en inglés synchronize).

“14:18:22”, dije. “Veo una conexión de acceso remoto desde 130.92.6.97 con Rimmon… Un momento, ¡hay un montón más!”. Aquello me sorprendió. Normalmente, una solicitud SYN debería haber iniciado una secuencia de saludo de ordenador individual, el breve saludo e interrogación entre dos máquinas antes de convenir en comunicarse por Internet. Eso requiere que el par de ordenadores creen e intercambien una secuencia de números de un-solo-uso para asegurarse de que esa conversación no se confunda con ninguna otra de las conversaciones que cualquiera de los dos puede estar manteniendo simultáneamente.

Pero en este caso era como si aquella máquina remota estuviera diciendo “hola”, “hola”, “hola”, “hola”, en rápida sucesión, sin escuchar la réplica de Rimmon. ¿Por qué ocurría aquello?

Me detuve y traté de descubrir de dónde había venido aquella rápida descarga de SYNs. Los dígitos 130.92.6.97 eran la dirección en Internet del ordenador remoto, y la respuesta requirió varios interrogatorios a diversas bases de datos de Internet, pero finalmente la conseguí: en la actualidad no había tal ordenador. Los mensajes a Rimmon parecía haber venido de una red en Suiza:

Esa red existía, como lo indicaban los primeros cinco dígitos: 130.92. Pero parecía que el ordenador que había intentado conectar con Rimmon, la máquina designada por la dirección completa, 130.92.6.97, no contestaba, o no existía, al menos no ahora. El ordenador podía haber estado apagado desde el ataque, supuse, y, por tanto, no sería visible en la base de datos. Había otra posibilidad: la dirección podía haber sido falsa.

Continué con la cronología: “14:18:25”. Eran precisamente tres segundos más tarde en nuestra línea temporal de datos. Y ahora había otro SYN, esta vez a Osiris desde un ordenador llamado apollo.it.luc.edu. Volví a interrogar la base de datos de Internet y me encontré con que luc.edu era la Universidad Loyola, en Chicago. Como había ocurrido con Rimmon desde la misteriosa máquina en Suiza, Osiris estaba recibiendo una serie de solicitudes de conexión de acceso desde la máquina de Loyola.

“Esto es muy raro”, murmuré. ¿Qué estaba pasando? Osiris estaba recibiendo una serie de SYNs, cada cual con un número secuencial para iniciar el saludo. Pero una vez que Osiris respondía —SYN-ACK— incluyendo un segundo número secuencial, la máquina de Loyola no daba el siguiente paso normal. En vez de replicar con un tercer número secuencial, el ordenador de Loyola iniciaba el proceso de nuevo emitiendo el mandato RST, restaurar. Esto ocurrió veinte veces en rápida sucesión. ¿Por qué?

Continué buscando a través de los datos, y entonces vi algo que de entrada no tenía ningún sentido. Todos los paquetes de datos que estábamos analizando eran paquetes que habían venido de Internet a través de Ariel, que se hallaba en el armario de cableado aquí en el Centro de Superordenadores. Pero ahora, nuestros registros habían empezado a mostrar un tráfico que parecía discurrir directamente entre Osiris y Rimmon, dentro de mi casa. “Un momento, ¡yo no debería estar viendo esos paquetes!”, exclamé. “¿Cómo es que estoy viendo el tráfico local entre Osiris y Rimmon?”.

Pero de repente me asaltó la respuesta que había estado buscando continuamente los últimos tres días. El ordenador remoto se había aprovechado del hecho de que Osiris “confiaba” en Rimmon y había falsificado una conexión de sentido único con Osiris que parecía provenir de Rimmon pero en realidad venía directamente del intruso.

“Ah, ya entiendo”, dije. Se hizo el silencio en el recinto, mientras yo miraba a Andrew. “De modo que es así como entraron”.

Todos aquellos saludos abortados cobraban ahora sentido. El atacante había necesitado poder predecir el número secuencial que Osiris estaba enviando con cada SYN-ACK. Un número secuencial, en este caso, era simplemente un autentificador, muy semejante al número que te dan cuando estás en la cola de la tienda para que cuando te llegue el turno de dirigirte al hombre que está detrás del mostrador, él y todas las demás personas reconozcan tu derecho a hacerlo. Nuestro intruso planeó disfrazarse de Rimmon, un ordenador en el que Osiris confiaba, y para conseguirlo tenía que poder responderle a Osiris con el número secuencial —o sea, el de la cola de la tienda— que éste esperaba de Rimmon.

Y ahora comprendía por qué el intruso había enviado aquella primera tanda de mensajes a Rimmon. Habían tupido la cola de entrada, amordazando de hecho a Rimmon para que no pudiese responder cuando llegara el momento de presentar su número secuencial. Una vez atado y amordazado Rimmon, el atacante había enviado aquella serie de veinte SYNs a Osiris, para enterarse de la fórmula mediante la cual Osiris generaba sus números secuenciales —cada uno sumaba 128.000 al anterior— y de esa forma estar listo para deslizarse en el lugar de Rimmon en la cola de la tienda y responder con el número secuencial adecuado. Después, el intruso dio el número secuencial que Osiris estaba esperando y lo utilizó para abrir un canal de comunicaciones.

Andrew se había acercado y estaba observando la pantalla por encima de mi hombro. Una vez que hubieron entrado, ¿qué hicieron? Simulando ser Rimmon, el atacante en el ordenador de Loyola había enviado el siguiente breve mensaje a través del canal de sentido único: “echo ++ >/.rhosts”. Este simple mandato dio lugar a que el propio Osiris suprimiera todas sus defensas posibilitando que cualquiera conectase con él sin una contraseña. El intruso había convencido a Osiris de que estaba abriendo una conversación digital con su fiable servidor de archivos, Rimmon, situado en el cuarto contiguo.

Eran ya casi las seis, y Andrew había vuelto al tablero para escribir la secuencia. Jay Dombrowski, que estaba siguiendo parte pero no toda la cronología creada por nosotros, se excusó cortésmente para irse a casa a cenar.

Después de pensar un momento me di cuenta de que el estilo del ataque me era familiar. Con un hábil juego de manos el atacante había logrado que paquetes provenientes del exterior de nuestra red pareciesen proceder del seguro ámbito interno. Era un ataque “parodiando el IP”, un tipo que había sido descrito teóricamente en la literatura de ciencia informática pero, que yo supiese, nunca había sido llevado a cabo como operación hostil.

El ataque se basaba en un fallo en el conjunto de instrucciones para las comunicaciones técnicas para el tráfico de Internet, conocido como Protocolo de Control de Transmisiones/Protocolo Internet (TCP/IP, sus siglas en inglés), que habían sido desarrolladas a finales de los años setenta y principios de los ochenta. Parodiar el IP, o sea manipular los números secuenciales de salutación para hacer pasar un ordenador por otro, era posible porque los procedimientos de saludo, creados en una era en la que a nadie preocupaba mucho la seguridad en Internet, habían sido diseñados simplemente para clarificar quién era quién en la Red, no para verificarlo.

Yo conocía un artículo técnico sobre los problemas de seguridad en el TPC/IP, escrito en 1989 por Steve Bellovin, investigador en seguridad informática de Laboratorios Bell, en el que había descrito el procedimiento de ataque llamado IP-spoofing.^[17] Pero el potencial de usar un IP-spoofing para hacerse pasar por un ordenador “de confianza” ya había sido expuesto a la atención de la comunidad informática con anterioridad, en un artículo escrito en 1984 por un estudiante llamado Robert Tappan Morris mientras estaba como interno de verano también en Laboratorios Bell. En la última página de su informe, Morris había dado una descripción pormenorizada de cómo funcionaba ese ataque. Más de diez años después, el artículo parecía profético: “Laboratorios Bell posee una creciente red TCP/IP que conecta máquinas con diversos requerimientos de seguridad; tal vez deberían darse pasos para reducir la vulnerabilidad entre ellas mismas”.

Con la caída de la noche, la sala 408 se bañó de una fría fluorescencia mientras nosotros continuábamos siguiendo el rastro digital del ataque. Una de las cosas que yo había descubierto el martes era que tanto en Ariel como en Osiris, el atacante había insertado un programa directamente en la memoria del sistema operativo del ordenador. El Unix de Sun Microsystem tiene un elemento estándar que permite modificar el centro mismo del sistema operativo estando éste en funcionamiento, para añadir nuevas funciones. Estos programas se llaman “módulos de núcleo” y pueden colocarse directamente en “ranuras” del software en el sistema operativo mientras el ordenador continúa funcionando. Normalmente se podría usar uno si se estuviera añadiendo un periférico al ordenador. El que estaba en Ariel parecía no ser más que basura, pero yo había tratado de analizar el que había encontrado en la memoria de Osiris y no pude de entrada sacar mucho en limpio acerca de para qué había sido diseñado. No obstante, tenía un nombre ciertamente sugestivo: Tap 2.01.

En el momento me pregunté si era un programa sniffer o “fisgón”, que permitiese al atacante supervisar a continuación el tráfico por mi red, buscando cosas tales como contraseñas que pudieran favorecer subsiguientes intrusiones en mis máquinas o en los ordenadores de otras personas que se comunicasen conmigo. Pero ahora veía, en los rastros de nuestros datos compactados, lo que había ocurrido. Tras instalar y hacer funcionar un programa clandestino en Osiris, el intruso regresó a través de su puerto de red secreto, un canal aparte que era precisamente uno de los que nuestros registros de paquetes no estaban controlando, y en consecuencia perdimos el rastro directo de sus pulsaciones en el teclado. Pero durante ese punto ciego en nuestro archivo de paquetes de registro todavía podíamos seguir sus actividades, las consecuencias de tales pulsaciones, consultando nuestros datos de investigación sobre dicho periodo de tiempo.

Vimos que había insertado un programa de módulo de núcleo llamado Tap en una ranura del sistema operativo de Osiris. Casi inmediatamente después observamos que la actividad del intruso saltaba de Osiris, en casa, a Ariel, en el Centro. Si bien Osiris y Rimmon mantenían una relación de confianza que les hacía vulnerables a un IP-spoofing, no la había entre Osiris y Ariel. Iniciar una sesión de comunicación con Ariel habría requerido un conjunto de procedimientos mucho más complicado, incluyendo una contraseña. El atacante había necesitado otra estrategia, y ahí fue donde entró Tap. Como él vio con finger, la máquina de mi casa tenía ya en marcha y en pantalla una sesión abierta con Ariel. Al parecer, ese Tap le había permitido literalmente apoderarse de aquella ventana abierta en la pantalla de Osiris, y usarla para controlar a Ariel. Tap fue el programa que proporcionó al ladrón un poder de gran titiritero, permitiéndole enviar sus pulsaciones a través del portal tal como si hubiese estado sentado en mi cama.

Era pasada la medianoche, y Andrew y yo éramos una vez más los únicos trabajando a deshoras en la sala 408. Los inactivos terminales de videoconferencia junto a las ventanas me dirigían su mirada opaca, y de pronto recordé cómo dos días antes me había intrigado la ventana vacía en el visualizador de Osiris. Ahora estaba claro: el intruso había violado aquel portal-pantalla de forma muy semejante a como un ladrón forzaría una ventana para introducirse por ella. Y una vez dentro de Ariel, pudo disponer a gusto de mi software y mis mensajes de e-mail, y después llevárselos a quién sabe dónde en Internet.