¿Quién nos presentará la realidad?

Adolfo García Yagüe | Acabo de leer el último artículo de Bill Gates sobre inteligencia artificial y me he quedado pensativo. No tanto por lo que dice Gates —aunque coincido bastante con su preocupación— sino porque me ha llevado de vuelta a dos textos que escribí hace muchos años. El primero, hace unos dieciséis años, cuando me preguntaba quién sería capaz de mover del papel de Gran Hermano a Google. Escribí entonces: «Es difícil imaginar quién moverá del trono a Google. En mi humilde opinión quizás sea algún anónimo Winston Smith que logre inventar una nueva forma de buscar en Internet empleando software de inteligencia artificial. Puestos a imaginar pienso en agentes personales que —manteniendo nuestro anonimato— hagan por nosotros el trabajo de búsqueda, análisis y consolidación de la información.» Lo releo ahora y me produce una sensación extraña. Aquello que entonces parecía una fantasía tecnológica ya no lo es. Los agentes de inteligencia artificial empiezan a hacer exactamente eso que imaginaba: buscar, leer, comparar, analizar, resumir y, cada vez más, actuar en nuestro nombre.

Pero hay algo que no imaginé entonces. No pensé demasiado en quién decidiría qué información debía buscar ese agente, qué debía considerar relevante, qué debía descartar y cómo debía presentarnos sus conclusiones. Y ahí aparece un segundo texto, todavía más antiguo en su inspiración: en él escribí sobre la cibercultura recordando consignas paradigmáticas como «El medio es el mensaje» de Marshall McLuhan (1911-1980). A través de ella se afirmaba algo que hoy me parece extraordinariamente actual: los medios no son invisibles. La televisión no es una ventana al mundo. No muestra simplemente imágenes a los espectadores. La propia naturaleza del medio condiciona aquello que vemos, la forma en que lo vemos y, en último término, la manera en que interpretamos la realidad. McLuhan nos invitaba a mirar no solamente el contenido que circulaba por un medio, sino el medio mismo. Quizá eso sea precisamente lo que deberíamos empezar a hacer con la inteligencia artificial. Porque la gran pregunta que se abre ahora no es solamente qué pueden hacer las máquinas. Es otra: ¿serán los agentes de inteligencia artificial quienes nos presenten la realidad?

Hasta ahora hemos vivido con una cierta ilusión de acceso directo. Queríamos saber algo y utilizábamos Google. Google nos ofrecía una lista de resultados. Nosotros elegíamos. Abríamos una página, leíamos, comparábamos con otra y, al menos en teoría, construíamos nuestro propio criterio. Era ya un filtro, naturalmente. El algoritmo decidía qué aparecía primero y qué quedaba perdido en la página diez. Pero todavía existía una cierta distancia entre el buscador y nosotros. Podíamos mirar los resultados, discrepar, saltar de una fuente a otra. La inteligencia artificial, en cambio, introduce una diferencia cualitativa. Podemos preguntarle algo y recibir no una lista de documentos, sino una respuesta. Ya no vemos necesariamente las fuentes antes de conocer la conclusión. Alguien —o algo— ha buscado por nosotros, ha seleccionado, ha ponderado, ha sintetizado y finalmente nos ha contado qué cree que necesitamos saber. El intermediario ha desaparecido de nuestra vista y precisamente por eso puede ser mucho más inquietante.

Aquí es donde vuelvo a McLuhan. Si «el medio es el mensaje», quizá hoy debamos añadir algo más: el modelo también es el mensaje. Porque, igual que McLuhan nos pedía mirar el medio, ahora necesitamos mirar el modelo que filtra, ordena y sintetiza la información antes de que llegue a nosotros. Quizá el verdadero mensaje de la inteligencia artificial no esté solamente en las respuestas que produce. Está en el hecho de que estamos delegando en ella una parte del proceso mediante el cual construimos nuestra propia representación del mundo. En mi opinión esto tiene consecuencias más profundas. Porque una cosa es utilizar una máquina para encontrar información y otra muy diferente es permitir que una máquina decida qué información merece nuestra atención. Una cosa es preguntarle a un buscador y otra es confiar ciegamente en un agente. El buscador nos devuelve posibilidades; el agente empieza a ofrecernos una interpretación.

Y si mañana esos agentes no solamente responden a nuestras preguntas, sino que anticipan nuestras necesidades, filtran nuestro correo, seleccionan nuestras noticias, recomiendan nuestras compras, preparan nuestros viajes, interpretan nuestros análisis financieros, nos ayudan a contratar servicios, nos sugieren qué leer y terminan tomando decisiones en nuestro nombre, entonces habremos construido algo mucho más peligroso que un nuevo buscador. Habremos construido un nuevo intermediario entre nosotros y la realidad.

Y aquí empieza mi desasosiego. No porque piense que la inteligencia artificial vaya a destruir el mundo. Tampoco porque crea que debamos detener el progreso tecnológico. Me preocupa algo más sencillo y, quizá, más difícil de resolver: ¿quién controla esos intermediarios? Porque una compañía no quiere quedarse atrás. Una potencia no quiere que otro país le adelante por la derecha. Un inversor no quiere perder la próxima gran oportunidad. Y así aparece el viejo problema de todas las carreras tecnológicas: incluso quienes conocen los riesgos tienen enormes incentivos para seguir acelerando. Por eso resulta tan significativo el diagnóstico de Bill Gates. Gates ha sido durante décadas uno de los grandes protagonistas del optimismo tecnológico. Por eso resulta significativo que ahora advierta sobre las consecuencias de una carrera de la inteligencia artificial que puede estar avanzando más deprisa que nuestra capacidad para comprenderla y gobernarla.

Por último, insisto en que mi preocupación tiene que ver menos con la capacidad de las máquinas y más con nuestra dependencia de ellas. Porque podemos imaginar un futuro en el que las máquinas sean capaces de hacer casi cualquier cosa. Creo que lo verdaderamente importante será decidir qué dejamos que hagan por nosotros. Durante siglos hemos desarrollado herramientas que ampliaban nuestras capacidades. El microscopio nos permitió ver lo que nuestros ojos no podían ver. El telescopio nos permitió mirar mucho más lejos. Las calculadoras y los ordenadores multiplicaron nuestra capacidad de cálculo. Internet potenció nuestra capacidad de acceso a la información. Google multiplicó nuestra capacidad de encontrarla. Con la inteligencia artificial corremos el riesgo de sufrir un retroceso inédito, porque puede disminuir nuestra capacidad de interpretar información.

Encontrar información y decidir qué significa son cosas muy distintas. Si delegamos la segunda, estamos delegando una parte de nuestra autonomía intelectual porque el agente que nos ahorra el trabajo de buscar puede acabar ahorrándonos también el trabajo de pensar.

Algoritmo de Shor y factorización

Adolfo García Yagüe | En mi profesión, que un cliente dedique una hora de su tiempo a escucharte es un privilegio. Si de ese tiempo quieres reservar al menos 15 minutos para escuchar su opinión o contrastar alguna información relevante, la exposición se queda en unos 45 minutos, de los que solo 40 son realmente útiles: pequeños retrasos, introducción de por qué estamos aquí, etc.

Siendo optimista, cuentas con 40 minutos para recorrer 26 diapositivas, lo que significa que dispones de apenas 1 minuto y medio por slide. Es evidente que, en cuanto intentes profundizar en ciertos temas, consumirás el tiempo en explicaciones en las probablemente quedarás atrapado…

Esta introducción me permite hablar de la presentación que compartí hace unas semanas sobre Computación Cuántica y PQC. Aunque está siendo muy bien recibida y, desde que la liberé en mayo, la he presentado ya en una docena de clientes con un feedback satisfactorio, es una presentación de elevado riesgo por su densidad conceptual y las ramificaciones hacia temas que suscitan numerosas preguntas… con el temido riesgo de hacer descarrilar cualquier planificación de tiempos…

Aun así, hasta el momento no se ha producido ninguna catástrofe. Al contrario, cada exposición se ha convertido en un ejercicio de mejora continua que me permite afianzar conceptos que antes tenía algo difusos. Esa evolución me ha llevado incluso a construir en Excel un sencillo modelo del Algoritmo de Shor, que me ha servido para entender con mayor precisión su funcionamiento y explicar sus fundamentos de forma más clara. Os lo dejo para que podáis experimentar con él; además, me apoyaré en este ejemplo para repasar paso a paso cómo funciona el algoritmo.

Cifrado de clave pública RSA
Para este ejercicio he tomado como punto de partida el sistema de cifrado RSA (Rivest, Shamir y Adleman), desarrollado en 1977 y todavía ampliamente utilizado. Recordemos que el elemento público más importante de RSA es el número N, obtenido como el producto de dos números primos, p y q. Si un atacante consiguiera factorizar N y recuperar esos dos números primos, podría reconstruir la clave privada.

Aunque algunos podéis pensar —con razón— que RSA está siendo sustituido poco a poco por algoritmos basados en criptografía de curva elíptica (ECC, Elliptic Curve Cryptography), ambos comparten la misma idea fundamental: su seguridad descansa en problemas matemáticos que un ordenador clásico no puede resolver en un tiempo razonable.

La ventaja de usar RSA como ejemplo está en que parte de su base matemática resulta más intuitiva que la de ECC. Al fin y al cabo, tod@s hemos trabajado con números primos en el colegio y, cuando llega el momento de aplicar Shor, no resulta confuso calcular un máximo común divisor o construir una función periódica. Como veréis, estos conceptos se asimilan fácilmente y permiten percibir la gravedad del problema con mayor claridad.

Antes de seguir y así evitar que alguien se frote las manos pensando que vamos a enseñar a romper RSA con Shor, es importante recordar que nuestro ejercicio toma números muy pequeños de 2 y 3 cifras. Esto, en el mundo actual de la seguridad, es ridículo y cualquier número empleado en RSA es superior a las 600 cifras (2048 bits) llegando incluso a superar las 1200 cifras (4096 bits).

Esto es así porque, para un ordenador convencional, recuperar p y q a partir de un N lo suficientemente grande es computacionalmente inabordable. El método básico de criptoanálisis por fuerza bruta obligaría a buscar divisores de forma secuencial y, aunque se empleen algoritmos como General Number Field Sieve (GNFS), el problema sigue siendo descomunal ya que romper un módulo RSA de 2048 bits continúa siendo una tarea computacionalmente inabordable con la tecnología actual.

Algoritmo de Shor
En 1994, el matemático Peter Shor (1959) demostró que la factorización de números no tenía por qué resolverse mediante una búsqueda exhaustiva. Su algoritmo transformó el citado problema de factorización de N en el de hallar el período de una determinada función. Para ello, el primer paso consiste en construir una función a partir del número N —recordemos, el módulo público del sistema RSA— y estudiar su período.

A primera vista puede parecer una idea extraña. ¿Qué tiene que ver el período de una función con la factorización de un número? Antes de responder a esa pregunta conviene olvidarnos por un momento de los ordenadores cuánticos. De hecho, podemos comprender la idea utilizando únicamente la hoja de cálculo adjunta.

El primer concepto que necesitamos conocer es la aritmética modular, también conocida como “la matemática de los relojes”. En un reloj, cuando pasan doce horas volvemos a empezar desde la una. No importa cuántas vueltas demos; el reloj siempre muestra un número comprendido entre 1 y 12.

La aritmética modular funciona exactamente igual. Si trabajamos, por ejemplo, módulo 12, cualquier resultado que supere ese valor vuelve a empezar desde el principio. Así, 9 + 5 = 14, pero como 14 deja un resto de 2 al dividirlo entre 12, escribimos simplemente:

14 mod 12 = 2

La criptografía RSA utiliza precisamente este tipo de matemáticas. En lugar de trabajar con números cada vez más grandes, realiza continuamente operaciones “módulo N”. Gracias a ello, aunque las cifras intermedias sean gigantescas, el resultado final siempre queda comprendido entre 0 y N − 1.

La función que empleó Shor es sorprendentemente sencilla:

f(x) = aˣ mod N

donde N es el módulo público de RSA y a es un número entero elegido de forma que no comparta factores con N. Para comprobarlo utilizamos una operación muy conocida en matemáticas: el máximo común divisor (MCD), que indica cuál es el mayor número que divide exactamente a otros dos. Si el MCD de a y N es igual a 1, decimos que ambos números son coprimos y podemos continuar. Curiosamente, si el MCD fuese mayor que 1, habríamos encontrado directamente uno de los factores de N, resolviendo el problema incluso antes de empezar. Veamos un ejemplo muy sencillo:

En nuestro ejemplo, supongamos que el módulo público es N = 15 y elegimos a = 2. Como el MCD de 2 y 15 es 1, podemos construir la función y empezar a calcular sus valores (podéis cambiar estos valores en la hoja hasta un máximo de N=101).

En esta tabla lo interesante es el resultado de la segunda columna. Si nos fijamos, en ella observaremos un patrón que se repite 1, 2, 4, 8, 1, 2, 4, 8… La función ha entrado en un bucle. Decimos entonces que su período r es igual 4, porque cada cuatro valores la secuencia vuelve exactamente al mismo punto.

Y aquí aparece la idea brillante de Peter Shor. Ese número, que a primera vista parece un simple dato más, contiene en realidad la información necesaria para recuperar los factores primos de N.

Sin entrar en la demostración matemática, basta saber que, cuando el período es par y se cumplen determinadas condiciones, tomamos el mismo valor de a que elegimos al principio y lo elevamos a la mitad del período (r/2).

En nuestro caso:

r = 4     y    a = 2

Por tanto:

2 ^(4/2) = 4

Nota: En este ejemplo ocurre una curiosidad ya que el período r vale 4 y el cálculo de a^(r/2) también da como resultado 4. Es una simple coincidencia. En general, ambos valores no tienen por qué guardar ninguna relación. Dicho esto, a partir de ese resultado solo tenemos que realizar dos cálculos utilizando el máximo común divisor.

Primero restamos una unidad:

MCD(4 − 1, 15) = 3

Después sumamos una unidad:

MCD(4 + 1, 15) = 5

Y, casi sin darnos cuenta, hemos recuperado los dos factores primos del número:

15 = 3 × 5

Una vez conocido el período, factorizar el número deja de ser un problema complicado. La verdadera dificultad consiste en descubrir ese período cuando N tiene cientos o miles de bits, como ocurre en las claves RSA reales.

Nuestra hoja de cálculo reproduce el método clásico: incrementa el valor de x, calcula aˣ mod N y espera hasta que la secuencia empieza a repetirse. Con números pequeños funciona perfectamente, pero con una clave RSA real esa búsqueda puede resultar prácticamente inabordable.

¿Cómo evita ese problema un ordenador cuántico? La clave está en la Transformada Cuántica de Fourier (Quantum Fourier Transform o QFT). Aunque su nombre resulte complejo, su función es muy sencilla: poner de manifiesto la periodicidad de la función.

Una buena analogía es la música. Cuando escuchamos una orquesta percibimos una única melodía, aunque en realidad está formada por muchos instrumentos. La transformada de Fourier actúa como una herramienta capaz de separar esos sonidos y revelar el patrón que había oculto. En el algoritmo de Shor hace algo parecido: utiliza la superposición cuántica para trabajar con muchos valores de x simultáneamente y, mediante la Transformada Cuántica de Fourier, hace visible el período de la función.

Esa es la auténtica revolución del algoritmo de Shor. El ordenador cuántico no factoriza números por arte de magia ni calcula las potencias modulares mucho más deprisa; simplemente encuentra el período de la función de una forma mucho más eficiente. Una vez conocido ese período, el resto del algoritmo vuelve a ser completamente clásico y permite obtener los factores primos mediante unas sencillas operaciones con el máximo común divisor. Y precisamente por eso ha sido necesario desarrollar una nueva generación de algoritmos PQC (Post-Quantum Cryptography) resistentes a este tipo de ataques.

[Descargar hoja de cálculo]

Computación Cuántica y Criptografía Postcuántica

Adolfo García Yagüe | Cuando hace unos meses hablábamos de radiotelegrafía, algunos lectores repararon en que entre los documentos de la colección hay un estadillo militar de 1912 donde se contabilizaban los mensajes cifrados del año anterior. Aquello, lejos de ser una singularidad, es una pequeña muestra de la relación que ha existido desde la antigüedad entre el cifrado y el mundo militar.

Desde los sacerdotes egipcios, que reservaban la escritura jeroglífica a una élite, hasta los espartanos del siglo V a. C., que empleaban la escítala para enviar órdenes secretas, la necesidad de ocultar información ha sido constante. Durante siglos, la criptografía fue un arte reservado a gobernantes, diplomáticos y militares. Hoy, sin embargo, forma parte de nuestra vida cotidiana, aunque la mayoría no seamos conscientes de ello: cada conexión con un servidor en Internet, cada pago electrónico, cada instalación de una app en el smartphone o, por ejemplo, cualquier procedimiento para certificar nuestra identidad digital dependen de la criptografía.

La complejidad y el oscurantismo que la rodean no son casuales, pues entender sus fundamentos exige conocimientos de matemáticas, informática, estadística y, antaño, lingüística. Aun así, su evolución puede narrarse como una sucesión de cambios de paradigma en los que historia y tecnología se entrelazan con acontecimientos decisivos. En este sentido, conviene recordar que hace un siglo la criptografía clásica quedó obsoleta frente a las máquinas de rotores y las técnicas inspiradas en el cifrado de Vernam. Más tarde, en los años setenta, ambas cedieron el paso al cifrado computacional basado en problemas matemáticos difíciles de resolver.

Hoy vivimos otro momento de transición en el que la computación cuántica amenaza esos problemas «difíciles» que sustentan a Diffie-Hellman, RSA (Rivest–Shamir–Adleman) y ECC (Elliptic Curve Cryptography), ya que un ordenador cuántico capaz de ejecutar el algoritmo de Shor podría factorizar números enteros y resolver logaritmos discretos con una eficiencia imposible para la computación clásica. Incluso los algoritmos simétricos robustos, como AES (Advanced Encryption Standard), o las funciones criptográficas, como SHA (Secure Hash Algorithm), se verán afectados por el algoritmo de Grover, al reducir el esfuerzo de fuerza bruta a su raíz cuadrada y obligar a duplicar los tamaños de clave para mantener el mismo nivel de seguridad. Por estas razones, y aunque aún hoy no existan máquinas cuánticas capaces de hacerlo a gran escala, el riesgo HNDL (Harvest Now, Decrypt Later) ya es real: los datos cifrados hoy podrían ser descifrados mañana.

En este contexto se enmarca esta presentación. Su objetivo es ayudar a los clientes de Axians —y a cualquier interesad@— a comprender la amenaza cuántica, explorando cómo funciona actualmente un ordenador cuántico y a qué desafíos se enfrenta esta tecnología. A continuación, explicaremos en qué se basan los nuevos algoritmos PQC (Post-Quantum Cryptography) estandarizados por el NIST (National Institute of Standards and Technology, EE. UU.) y cómo se integran en un certificado X.509 y en la negociación TLS (Transport Layer Security), IKE (Internet Key Exchange) e IPSec. Más adelante revisaremos las iniciativas impulsadas por diversas instituciones europeas y su impacto en la normativa vigente: DORA (Digital Operational Resilience Act), NIS2 (Network and Information Security Directive 2) y eIDAS (Electronic Identification, Authentication and Trust Services). Por último, presentaremos una estrategia de referencia para abordar la transición hacia PQC y analizaremos cómo algunos fabricantes de soluciones de seguridad están afrontando este reto.

No lo olvidemos: la criptografía es la capa matemática que garantiza la confidencialidad, la integridad y la autenticidad de los datos, además de salvaguardar la identidad y la confianza digital. Y, por primera vez en medio siglo, nos vemos obligados a replantear sus cimientos.

[Descargar presentación]

y llegó el día que más temía…

Sabía que este día llegaría y que algo acabaría fallando. Llevo más de 25 años alojando la web en Acens/Hostalia —desde los tiempos de RapidSite— y nunca he tenido quejas: buen servicio, buen precio… nada que reprochar. Pero, como era de esperar, han actualizado MySQL y ahora la base de datos requiere, como mínimo, PHP 7. En mi caso llevaba años (demasiados) anclado en PHP 5.6 para mantener en funcionamiento Gallery, es decir, el motor sobre el que reposa la galería de imágenes.

Ya os imagináis el desenlace: he tenido que actualizar a PHP 7 para que MySQL y WordPress sigan funcionando, y la galería nos ha dejado (espero que temporalmente).

Ahora me toca revisar el código a ver si puedo apañarlo. No sé cuánto tardaré ni si lo conseguiré. Paciencia.

[02-04-2026] Solucionado. Quiero agradecer el trabajo de Gregory Stoll por poner a disposición de la comunidad un fork para que Gallery2 funcione en PHP7 y 8. Me temo que sin su esfuerzo habría sido imposible resucitar la Galería.

Una breve historia de Internet

Adolfo García Yagüe | De cuando en cuando, amigos y familiares, mientras hacen limpieza de sus trasteros y bibliotecas, se acuerdan de mí. En una de esas, Nacho, mi compañero de trabajo, me ha hecho depositario de unos cuantos libros sobre malware y seguridad informática editados antes de los 90.

Entre estos tesoros también hay un pequeño cuaderno, publicado en 1998 por la revista Novática, con la traducción de un artículo firmado por Barry Leiner, Vinton Cerf, David Clark, Robert Kahn, Leonard Kleinrock, Daniel Lynch, Jon Postel, Lawrence Roberts y Stephen Wolff, cuyo título emociona: Una breve historia de Internet.

Debido a su valor documental, no he dudado un instante en escanear sus páginas y compartirlo con todos vosotros. Merece la pena. No esperéis un texto farragoso y extenso. Todo lo contrario: es claro, preciso y fiable, como una buena RFC del IETF 😉.

¡Gracias Nacho!

Colección | Una breve historia de Internet | ARPANET, X.25 e Iberpac | Internet e Infovía

Nueva Generación de Instrumentos Musicales Electrónicos

Adolfo García Yagüe | No podéis imaginar la ilusión que me ha hecho conseguir este libro. Conozco su existencia desde los años 80 y, desde entonces, no había sido capaz de hacerme con un ejemplar. Esta semana, por fin, la búsqueda concluyó y puedo incluirlo en la colección de Ccäpitalia, dentro de la galería de Grabación, Reproducción y Síntesis de Audio y Voz.

En mi opinión, y sin ningún género de duda, esta obra es la más importante de cuantas se han publicado en nuestro país sobre un tema tan específico como la Síntesis Analógica Sustractiva y, en general, sobre la creación de Música Electrónica. Tampoco tiene nada que envidiar a trabajos similares editados en el extranjero. Tal es su calidad que Marcombo, a través de su matriz Boixareu, lo publicaría en 1977 y reconoció su valor otorgándole el prestigioso galardón Mundo Electrónico.

Lo más sorprendente es que el libro fue escrito por un joven de veintipocos años, Juan Bermúdez Costa, y tiene su origen en la construcción de su propio sintetizador modular, el NAIROBI. Para sacar adelante su creación, Bermúdez llevó a cabo un profundo trabajo de investigación, llegando incluso a contactar con los principales fabricantes de sintes del momento, como Moog, EMS o ARP… Cuesta imaginar a aquel muchacho de los setenta intercambiando correspondencia con eminencias como Robert Moog.

Tras más de 30 años de su primera edición, en 2011 Juan Bermúdez publicó su obra en Internet, libre ya de compromisos editoriales y con algunas correcciones menores, para que todos pudieran disfrutarla.

Además del mencionado mérito técnico, este libro también tiene un gran valor sentimental, pues me trae grandes recuerdos de la época en la que chapoteé en la creación electrónica y Bermúdez representaba una institución para mí, un mito. Recuerdo sus artículos en la revista Música y Tecnología, cargados de sabiduría y frescura, y cómo con cada texto sentía que me acercaba un poquito más al núcleo de la música electrónica.

Juan, Gracias por iluminarnos el camino.

Origen y evolución del Malware, 1971-1995 (y 3)

Adolfo García Yagüe | Hacia el final de la década de los 80, las únicas herramientas con las que contaban las empresas para defenderse de una infección, era una suscripción a un buen antivirus, la aplicación estricta de políticas que prohibieran el uso de software no corporativo, y la existencia de copias de seguridad actualizadas… por si acaso. No había mucho más dónde elegir.

Malware en Redes Corporativas
El incidente sufrido por IBM con el virus Cascade, nos permite recordar el riesgo al que se enfrentaba cualquier organización con una red de área local (LAN) en la que sus usuarios compartían impresoras, disponían de almacenamiento centralizado o, simplemente, intercambiaban archivos. Como hemos comentado en otros artículos, la mayoría de estas redes LAN se articulaban sobre NetBIOS, que era una extensión del sistema operativo MS-DOS para ofrecer soporte de red. Como sabéis, con el despliegue de estas redes se pretendía que el usuario tuviera acceso a unas unidades de red que podían ser privadas o compartidas entre compañeros. Esto significaba, que si un virus ya se encontraba presente en el equipo del usuario, también tendría acceso a cualquier carpeta y fichero existente en las unidades remotas X:, Y: o Z:, por ejemplo. Es decir, para que una infección se propagase, no era necesario intercambiar un disquete con un colega, pues el virus se podía mover libremente en todo el entramado de la Red LAN.

Por otra parte, hasta la popularización de las mencionadas redes locales, en algunas organizaciones, la forma más habitual de trabajar contra un recurso central era a través del teleproceso ofrecido por un miniordenador y mainframe. Normalmente estos ordenadores funcionaban veinticuatro horas al día en instalaciones acondicionadas, la mayoría inexpugnables, y era en estos sistemas donde residía cualquier base de datos y allí se ejecutaban todas las aplicaciones de negocio o mensajería. Desde un usuario, en el caso de IBM, el acceso a estos sistemas estaba limitado al uso de una aplicación mediante un “terminal tonto” SNA 3270 o 5250 o, desde un PC, a través de la correspondiente emulación de terminal. En resumen, un usuario común no tenía ningún acceso al sistema operativo o los procesos que corrían dentro de la máquina central, por lo que era poco probable que un virus pudiese infectar al sistema. Además, recordemos, que el código de un malware para MS-DOS y el microprocesador Intel 8086 no tendría ningún efecto, por ejemplo, en un sistema MVS de IBM… aunque Bernad Fix, también conocido como Foxi, coqueteó con un virus para sistemas MVS/370 de IBM.

Por último, hay que recordar a los sistemas basados en UNIX y TCP/IP. Con una filosofía distinta a las comentadas anteriormente, este sistema operativo se utilizaba principalmente en el ámbito académico e Internet y, comparativamente, su empleo en el entorno empresarial estaba menos extendido, aunque en sectores como el ingenieril, era bien conocido gracias a su potencia y flexibilidad.

Un sistema corriendo UNIX, al igual que sucede en su descendiente GNU Linux, consta de decenas o cientos de servicios en ejecución y, para delicia de un malware o atacante, es habitual que alguno de estos servicios sea accesible remotamente a través de TCP/IP para, por ejemplo, intercambiar archivos (FTP), acceder vía terminal (Telnet) o enviar un correo electrónico (SMTP)…

Gusano Morris
Un sábado de noviembre de 1988, el programa Informe Semanal abrió uno de sus reportajes alertando “…en la red de comunicaciones auspiciada por el sistema de defensa americano y conectada con el programa más famoso y espectacular del presidente Reagan, conocido como Guerra de las Galaxias, el joven Robert Morris había introducido un virus informático…”. A continuación, en ese mismo espacio de televisión, uno de los españoles que mejor entendía los entresijos de la red afectada, José A. Mañas profesor de la Universidad Politécnica de Madrid (UPM), daba unas pinceladas sobre los virus informáticos y comentaba el suceso…

Tras esta introducción, quedé perplejo por su aparente magnitud y trascendencia. Aunque un año un año antes había leído sobre ARPANET en un artículo firmado por el propio Robert E. Kahn (1938), no fui capaz de dar sentido a lo escuchado y entender de qué se trataba. Lo único que me quedó claro es que en el incidente se vio afectado un futurista programa militar estadounidense del que conocíamos su existencia por los medios.

Meses más tarde supe que muchas instituciones académicas y científicas alrededor del mundo estaban conectando sus redes a través de TCP/IP y que, la mayoría de sus máquinas, eran sistemas UNIX… y que un tal Robert Tappan Morris (1965), a días de cumplir 24 años, había tumbado todo ese tinglado…

También conocí que el agente patógeno no era un virus, sino un gusano al que se había bautizado con el nombre de su autor. Es decir, se trataba de un código maligno con capacidad para propagarse a través de esa red mundial sin necesidad infectar e intercambiar ficheros. Ah, se me olvidaba, nuestro protagonista era hijo de Robert H. Morris, uno de los creadores de Darwin (1961) y, además, en el momento del incidente, papá Morris trabajaba en la NSA (National Security Agency)… alucinante… todo quedaba en casa…

Siguiendo un orden basado en la probabilidad de éxito, el gusano Morris podía emplear cuatro vectores diferentes en su intento de colonizar remotamente un objetivo:

• sendmail, a través del puerto TCP 25. Servicio para envío y recepción de correos. El gusano se aprovechaba del modo de depuración (activo por defecto) para ejecutar comandos arbitrarios sin autentificación. Probabilidad de éxito alta.
• fingerd, TCP 79. Demonio que permitía conocer remotamente el nombre de los usuarios y el estado de su sesión. Morris se aprovechaba de una vulnerabilidad de fingerd en la distribución UNIX Berkeley (BSD) permitiendo la ejecución remota de código. Probabilidad de éxito alta.
• rsh, TCP 514. Este servicio permitía la ejecución remota de comandos, sin contraseña, y estaba basada en autenticaciones de confianza que se configuraban en el archivo .rhost. Morris buscaba aquellos archivos .rhost que carecían de un permiso de acceso restrictivo para conocer las máquinas y usuarios que tenían concedido el acceso. Probabilidad media.
• rexec, TCP 512. Este servicio permitía la ejecución remota de comandos con contraseña. A diferencia de rsh, en rexec si era necesario introducir un nombre de usuario y una contraseña. El gusano Morris sorteaba esta barrera probando, una a una, diferentes contraseñas para cada nombre de usuario con palabras generadas a partir de un diccionario y/o permutaciones de estas. Probabilidad baja.

Trascurridas unas horas tras su liberación, el 2 de noviembre de 1988, el gusano Morris ya había logrado infectar a más de 6000 sistemas y se estimaba que unas 60000 máquinas se encontraban a su alcance… Recordar que en aquel año se contabilizaban en Internet, aproximadamente, 500 redes estadounidenses y no más de 100 redes internacionales (entre las que se encontraba la UPM). Precisamente, y según la declaración de Robert Morris tras su detención, justificó su acción diciendo que aquello era solo un experimento para intentar conocer la población y envergadura de Internet, y que se le fue de las manos…

La realidad es que este gusano, intencionadamente o no, contenía un error en su programación lo que permitió la reinfección de sus víctimas, ocasionando el agotamiento y el colapso de los sistemas afectados. Para atajar la crisis provocada por Morris, la mañana del 3 de noviembre se pusieron al frente expertos de la Universidad de Berkeley, el MIT y la Universidad de Purdue, y juntos lograron desentrañar su funcionamiento y desarrollar los parches necesarios para corregir el incidente.

Esta respuesta reactiva e improvisada, aunque efectiva, puso de manifiesto la necesidad de establecer algún tipo de coordinación y protocolo para gestionar futuras crisis. Por este motivo, tras el suceso, inició su andadura en la Universidad Carnegie Mellon el primer CERT o Computer Emergency Response Team y, entre sus atribuciones, quedaba la dirección de la respuesta ante un incidente de seguridad, además de analizar amenazas y vulnerabilidades.

Otra consecuencia del gusano de Morris fue la incorporación en los sistemas UNIX de capacidades para establecer filtros IP, como los TCP Wrappers (1990) e IPFilter (1992). En esta línea de protección conviene recordar el caso de ciertos routers, como los de Cisco Systems, que incluirían a partir de 1993 la posibilidad de establecer ACL (Access Control Lists). Inmediatamente después, gracias al servicio ipfw de UNIX, se desarrolla el concepto Firewall y aparecen las primeras soluciones específicas de seguridad, como FireWall-1 de Check Point que se apoyaba en estaciones Sun Microsystems y su sistema operativo Solaris.

Junto a estos avances, en algunas organizaciones cuyos servicios eran especialmente sensibles se fue un paso más allá en materia de ciberseguridad. Estas compañías eran conscientes del riesgo que representaba un adversario motivado y, por ello, se esforzaron en levantar barreras para proteger sus datos y cifrar sus comunicaciones. Esta preocupación aumentaba si contaban con una red de sucursales o delegaciones, o si formaban parte de una red bancaria internacional como SWIFT.

Más allá del trastorno y los cambios que provocó, el gusano de Morris puso en evidencia la realidad de los sistemas, dejando importantes lecciones que, en mi opinión, podrían formar parte de unos ficticios (pero todavía vigentes) Diez Mandamientos de la Ciberseguridad:

• No expondrás información que pueda ser aprovechada por un atacante (nombre y tipo de los sistemas empleados, nombre de usuarios, correos…).
• Corregirás cualquier vulnerabilidad de un sistema y/o sus programas.
• Siempre bastionarás un sistema y no dejarás desatendidas configuraciones por defecto.
• No dejarás servicios innecesarios expuestos y sin protección alguna.
• No dejarás ningún fichero de configuración y passwords a la vista de un atacante.
• No utilizarás passwords débiles y las sustituirás periódicamente.
• Establecerás controles para detectar y frenar reintentos al ingresar una contraseña.
• y cifrarás todo, comunicaciones y datos… aunque en 1988 esto no estaba al alcance de la mayoría de los sistemas.
• …

Con estas líneas daría por terminado el repaso al origen y primeros años del fenómeno malware. No obstante, es obvio que la cosa no acabó en 1995 y, en muchos sentidos, lo verdaderamente interesante empezaría a partir de aquel año. Permitirme recordar: Internet llega a los hogares; el correo electrónico se convierte en una popular herramienta de comunicación; las empresas adoptan masivamente redes LAN; aparece Windows 95, con todas sus luces y sombras; el uso de macros embebidas en los documentos ofimáticos; empezamos a usar teléfonos GSM, agendas y ordenadores de bolsillo con conexión a Internet… y los malotes se dan cuenta de que la propiedad de virus y gusanos para replicarse de forma sigilosa no tiene por qué ser un fin, sino que puede ser un medio para desarrollar ataques más sofisticados… Pero esto es otra historia que contaré en futuros textos…

Introducción a la Ciberseguridad | Origen y evolución del Malware, 1971-1995 (1) | Origen y evolución del Malware, 1971-1995 (2)

Origen y evolución del Malware, 1971-1995 (2)

Adolfo García Yagüe | En este texto continuamos con el repaso de los primeros años del fenómeno malware. Como en otras ocasiones, os ruego que seáis indulgentes si detectáis alguna omisión o imprecisión. Gracias.

Virus en ficheros .COM y .EXE
Seguimos en 1987, año en el que llegaron las primeras noticias de Vienna y su capacidad para infectar los conocidos ficheros .COM de MS-DOS. Este formato de archivos, que carecían de cualquier encabezado, era una imagen exacta del programa binario que ejecutaba el microprocesador y, al cargarlo en memoria, siempre se ubicaban en la dirección 0x100h ocupando, como máximo, un segmento de 64KB.

Cuando el virus Vienna se encontraba en la memoria de la víctima, buscaba archivos no infectados con la extensión .COM. Para identificar si un archivo ya había sido infectado, el virus realizaba una comprobación de la hora de creación: si los segundos de la marca de tiempo indicaban un valor de 62 segundos, consideraba que el archivo ya estaba infectado y lo ignoraba. Este timestamp de 62 segundos resultó ser una característica ingeniosa ya que, como todos sabemos, no es un valor válido en un reloj real cuyo máximo es de 59 seg.

En cambio, cuando el malware encontraba un archivo limpio, lo abría y sobrescribía sus primeros bytes con una instrucción de salto JMP. Este salto tenía como fin redirigir la ejecución del programa hacia el código malicioso. Después de ejecutar su propio código, el virus devolvía el control al programa original saltando a la dirección donde se encontraba el código sobrescrito. Finalmente, el virus cerraba el archivo .COM y actualiza su hora de creación estableciendo los segundos a 62 para marcarlo como infectado y evitar futuras reinfecciones.

Se especula que este virus fue originario de la ciudad de Viena, pero su autor siempre ha permanecido en el anonimato y lo único que sabemos es que fue descubierto por el austriaco Franz Swoboda, quien indicó que el virus le llegó a través de Ralf Burger, que afirmaba lo contrario… Lo único claro es que fue Bernad Fix quien programó un antídoto para eliminar Vienna y que el propio Burger aprovechó aquel suceso para publicar el polémico “Computer Viruses a high-tech disease” detallando el funcionamiento de Vienna y convirtiéndolo en un virus de referencia para desarrollar nuevas especies… En mi opinión, no es descabellado especular que tras la creación de Vienna se encontraba alguien del entorno del Chaos Computer Club de Alemania. Recordemos que allí, en 1986, Ralf Burger presentó el virus Virden y Bernad Fix a Rush Hour y que ambos virus fueron descritos, junto a otros especímenes, en el libro de Burger.

Estas líneas estarían incompletas si no recordara al famoso virus Jerusalem. Además de por su elaborada y efectiva técnica para infectar ficheros .COM y .EXE, este malware alcanzó los primeros puestos de popularidad debido a sus efectos -dañinos- que se materializaban cada día Viernes 13. Independientemente de la bomba de tiempo que alojaba, la mayor parte de los daños provocados por este virus eran consecuencia la inutilización de los ficheros .EXE que reinfectaba repetidamente. Con cada infección el tamaño de los ficheros se incrementaba 2KB, siendo lo que llamó la atención de sus descubridores de la Universidad Hebrea de Jerusalén.

A diferencia de Vienna, el virus Viernes 13 o Jerusalem tenía la capacidad de permanecer residente en memoria y monitorizaba constantemente las llamadas que hacía cualquier programa a la interrupción 21h, que era el punto de entrada para que MS-DOS realizara funciones básicas, como abrir o cerrar ficheros. Esto le permitía interferir en el acceso a cualquier fichero sin llamar la atención. En aquel instante, insertaba su código de manera similar a lo comentado antes, con la particularidad de que en los ficheros .EXE el virus tenía, además, que saber moverse en el encabezado de estos archivos para identificar el punto de entrada.

Primera generación de antivirus
A esas alturas los sufridos usuarios nos defendíamos como podíamos y la mayor parte de las ocasiones optábamos por el “fuego purificador” de un buen formateo. Este borrón y cuenta nueva era una práctica habitual hasta que llegaron las primeras copias -piratas, eso si- de programas antivirus.

Hasta el año 1988 no conocí un antivirus “de amplio espectro” con capacidad de detectar varios virus. En cambio, si llegó hasta mí algún programa que servía de vacuna frente a un tipo de virus particular e, incluso, algunos eran capaces de identificar ese malware y extirparlo. Como digo, eran remedios muy específicos y solo eran efectivos frente a un determinado código y cualquier variación, por pequeña que fuera, los hacia inútiles cuando no catastróficos inutilizando totalmente el archivo que se intentaba sanar.

El producto más popular de esta primera generación de antivirus fue ViruScan de McAfee Associates. Tras esta compañía estaba el excéntrico, pero visionario, John David McAfee (1945-2021) cuyo currículo incluía experiencia previa en compañías como la NASA, Univac, Xerox y Lockheed… Precisamente, en 1987 y durante su paso por esta última empresa conoció la existencia de Brain. Como hobby programó un antivirus para, posteriormente, distribuirlo a través de BBS en modalidad shareware. Ante el éxito de ViruScan, John McAfee dejaría su empleo en 1989 para profesionalizar los servicios que se ofrecerían a través de McAfee Associates, como la prestación de soporte telefónico, acceso a actualizaciones del producto a través de Compuserve, un modelo de registro y suscripción, y el desarrollo de un canal de ventas.

En esencia, aquellos antivirus se basaban en la identificación de firmas o una secuencia de códigos que permitían reconocer cada tipo de malware. Para ello, el fabricante de la solución debía dotar al producto de tantas firmas como virus fuera capaz de detectar, lo que exigía una actualización constante. Esta actualización, en la mayoría de los casos, no resultaba ni sencilla ni económica para, por ejemplo, un usuario español. La citada base de datos de firmas constituía el núcleo central del sistema del cual se alimentaban tres motores independientes: uno para el análisis de la memoria RAM; otro para los discos flexibles y el disco duro a bajo nivel; y un tercero para analizar el sistema de ficheros para ser capaz de examinar directorios completos o archivos específicos.

Normalmente, los primeros productos lanzados al mercado no eran capaces de limpiar un fichero colonizado y se limitaban marcarlo como infectado, borrarlo o ponerlo en cuarentena. En este sentido, todos los fabricantes insistían en la necesidad de tener y mantener copias de respaldo actualizadas.

De aquellos años, además del citado McAfee, me viene a la cabeza el sofisticado The Norton Antivirus (1990) de Symantec y su intuitiva interfaz de usuario (recordar, estamos en MS-DOS) junto con la posibilidad de actualizar manualmente las firmas conforme van apareciendo nuevos virus y su capacidad -más o menos eficiente- para extirpar el código malicioso de un fichero infectado. Pero, en mi opinión y dejándome llevar por el orgullo patrio, las dos soluciones antivirus con mayor repercusión en España fueron Anyware (1989) de Carlos Jiménez, y Artemis (1990) de Mikel Urizarbarrena, fundador de Panda Security.

Polimorfismo y virus Cascade
La ciberseguridad, salvando las distancias, es una carrera armamentística y la lucha contra el malware es un buen ejemplo de ello. Como era de suponer, era cuestión de tiempo que los métodos de detección basados en firmas quedaran obsoletos porque a alguien se le ocurriría la forma de alterar el código de un virus con cada copia y así, la apariencia de toda su descendencia, sería distinta e imposible de detectar mediante firmas conocidas.

Esta capacidad, llamada polimorfismo, está en la base de aquellos virus que, empleando alguna técnica de cifrado, consiguen alterar su apariencia para convertirlos en únicos. No es menos importante la ofuscación que consiguen de su código, complicando de esta forma el análisis de su funcionamiento.  Aunque pueda parecer que hay similitudes con el actual malware Ransomware -por aquello del cifrado- no hay que confundirlo. Estamos hablando de técnicas de cifrado muy elementales, de finales de los ´80, cuyo objetivo no era el cifrado masivo de ficheros y directorios, simplemente alterar el propio código para pasar desapercibido.

De nuevo volvemos a Centroeuropa, concretamente a Alemania, y allí encontramos las primeras señales del virus Casacade (1987), también conocido como 1701 y 1704 por el tamaño que añadía a los ficheros infectados, y otros tantos nombres con los que se identificó a sus mutaciones. Haciendo uso de una comparación biológica, podemos afirmar que el virus Cascade fue un salto evolutivo al incorporar un sencillo mecanismo que le permitía ser polimórfico. Afortunadamente, este virus no fue infalible frente a la mayoría de antivirus de primera generación, pues su algoritmo de cifrado podía ser identificado mediante firma, pero el resto del código del virus se encriptaba y éste era diferente en cada copia. Sin duda, aquello fue un comienzo y señaló el camino por donde evolucionaría el malware y las herramientas de detección.

Cascade infectaba ficheros .COM y aunque inicialmente estaba programado para atacar solo a equipos clónicos PC y excluir a máquinas IBM, su rutina para identificar al fabricante de dicho PC mediante el copyright de la BIOS no consideró las posibles variantes que hacía IBM en cada versión, por lo que afectó a casi a cualquier PC. Paradójicamente, sería la propia IBM de Bélgica uno de los mayores damnificados de esta plaga, teniendo que desarrollar un antídoto para frenar sus “simpáticos” efectos tras comprobar como a sus empleados se les caían -literalmente- los caracteres de sus monitores.

Como he comentado, en el código de Cascade existía una rutina de encriptación basada en la operación lógica XOR, fácilmente implementable a nivel ensamblador. En los primeros especímenes de 1701, la clave para el cifrado y posterior descifrado se correspondía con la longitud original del archivo infectado. Recordar que este mecanismo encriptación solo se aplicaba al payload del malware para ocultar su código frente miradas indiscretas y la descrita identificación a partir de firmas.

Este cambio de tendencia en el desarrollo de malware, unido a un incremento exponencial de virus y variantes, hizo insostenible seguir basando únicamente las capacidades de detección en una base de datos de firmas conocidas. Pensemos en la dificultad para mantener actualizado ese gigantesco repositorio de firmas y lo más complicado, desarrollar un motor lo suficientemente rápido para analizar decenas o cientos de ficheros contra esta base de datos de firmas.

Vacunación y primeros antivirus heurísticos
Bajo las técnicas de vacunación los antivirus fueron incorporando capacidades para identificar cambios inesperados en un fichero, como aquella basada en guardar el checksum o suma de verificación de cada archivo en una base de datos, para, si un malware alteraba ese fichero poder detectarlo, aunque no se conociese la identidad del artefacto responsable del cambio. Otra capacidad de detección muy básica consistía en conocer la fecha de creación original y la longitud del fichero víctima y, una vez más, ante un cambio no esperado se generaba una alerta.

Un paso más allá en la detección de agentes malignos desconocidos, y aproximándonos más al término heurístico, consistía en analizar -en tiempo real- el comportamiento de un posible malware e identificar ciertas acciones sospechosas, como las llamadas a la interrupción 13h para hacer accesos al sistema de almacenamiento a través de la BIOS. Recordar que por heurístico entendemos una forma de encontrar una solución de una manera rápida y, a veces, no del todo perfecta y óptima.

Como digo, estas técnicas, aunque efectivas, no eran perfectas y podían generar falsos positivos porque, por ejemplo, el funcionamiento de algunas aplicaciones precisaba hacer cambios en sus respectivos archivos e, incluso, algunos sistemas anticopia hacían un uso legítimo de la interrupción 13h, como aquella consistente en la detección de una marca láser en la superficie del disco. También, para sacar el máximo partido a estos mecanismos de vacunación, era necesario trabajar con ordenadores que tuvieran disco duro y que fuesen rápidos porque, de lo contrario, era inviable en un sistema con solo diskettes. [Continuará]

Introducción a la Ciberseguridad | Origen y evolución del Malware, 1971-1995 (1) | Origen y evolución del Malware, 1971-1995 (y 3)

Origen y evolución del Malware, 1971-1995 (1)

Adolfo García Yagüe | Tras el interés surgido con la presentación anterior, no he podido evitar recuperar algunos documentos para recordar como los Virus informáticos o más genéricamente, el Malware, se hicieron un hueco en nuestros corazones.

Origen teórico
Al hablar del origen de los virus informáticos, es común citar el artículo Self-Reproducing Machines de L. S. Penrose (1898-1972), publicado en junio de 1959 por Scientific American. En contra de lo que cabría esperar, en este trabajo no se tratan temas relacionados con ordenadores, lenguajes de programación o sistemas operativos, ahí son estudiadas las capacidades que debería tener una máquina para fabricar copias de sí misma que, como sabemos, es la característica esencial de cualquier virus. Como no podía ser de otra forma, el mencionado artículo de Penrose sigue la estela de los trabajos que previamente publicó John von Neumann (1903-1957) entre los años 1948 y 1952, abordando el tema de las máquinas autorreplicantes y el concepto de un autómata capaz de crear copias de sí mismo. El objetivo de Neumann no era otro que comprender los principios lógicos que subyacen en la replicación biológica.

Sin abandonar esta línea teórica, en ocasiones también se recuerda al Juego de la Vida de John Horton Conway (1937-2020), de 1970. Aquel no era un juego al uso y podría ser considerado un pseudo-autómata cuya programación, a través de reglas básicas (= algoritmos), emulaba el comportamiento de una célula y su ciclo vital de nacimiento, reproducción y muerte. Visualmente, la conducta de aquella célula era representada a través de los movimientos de una ficha dentro de una cuadrícula, siendo posible resumir este comportamiento mediante un  programa informático, como el desarrollado por Guy y Bourne en un Digital PDP-7. Una vez más, podemos trazar paralelismos entre un virus informático y una forma de vida artificial programada para evolucionar en su entorno y perpetuarse.

He querido recoger estas referencias porque es importante conocerlas, al ser consideradas como base teórica, pero, en mi opinión, para entender el fenómeno malware es necesario un enfoque más cercano al contexto de su creador, en concreto, su motivación y medios. Francamente, a veces tengo dudas que alguno de los primeros creadores de virus y gusanos encontraran la inspiración entre los eruditos trabajos de Newmann, Penrose o Conway.

Creeper y Reaper
Como digo, para entender el desarrollo de cualquier acontecimiento es preciso conocer el entorno circundante. Por eso es importante recordar que Creeper, el que es considerado primer gusano de la historia, fue programado en 1971 por Bob Thomas mientras trabajaba en BBN Technologies (Bolt, Beranek and Newman), la compañía responsable del desarrolló ARPANET. Aquel joven andaba metido en la compartición de recursos entre ordenadores Digital PDP-10 con sistema operativo TENEX y desarrolló un programa que saltaba entre equipos. Este programa saltarín, en su demostración, imprimía el mensaje “I’M THE CREEPER: CATCH ME IF YOU CAN” y, a continuación, pasaba a la máquina siguiente y se borraba en la anterior sin dejar rastro. Es decir, entre los ordenadores objeto del ensayo, en un determinado instante solo era perceptible una copia de Creeper. Sin lugar a dudas, Creeper incluía el atributo básico de cualquier gusano, que es la réplica remota sin necesidad de infectar ficheros, sin embargo, aquello solo fue un ensayo divertido y benévolo dentro de BBN que, no lo olvidemos, estaba tras del desarrollo del citado TENEX, nuevos protocolos de encaminamiento de paquetes y otras formas de comunicación, entre las que destaca el correo electrónico, inventado allí por Ray Tomlinson (1941-2016).

Precisamente, la información más fiable que ha llegado hasta nuestros días sobre Creeper ha sido a través de Tomlinson, quién modificó el Creeper original para que se perpetuase de forma indefinida y simultánea en múltiples máquinas sin desaparecer, eso sí, seguimos en el aquel laboratorio de BBN. Para asegurarse de que esta experiencia podía ser detenida y revertida sin riesgos, Tomlinson desarrolló un programa llamado Reaper que se encargaba de buscar y borrar a Creeper.

Virus informático: el nacimiento de una nueva especie
Hacia finales de 1983 Frederick B. Cohen (1956), entonces estudiante de la Escuela de Ingeniería de la Universidad del Sudeste de California, creó un programa experimental capaz de infectar y replicarse en otras máquinas. Este programa se camuflaba dentro del código de un software legítimo y se propagaba a través de un disquete.

Fue su profesor, Len Adleman (1945) -coinventor de la criptografía RSA-, quien sugirió el nombre de «Virus» para este tipo de software. Las experiencias y conclusiones de Cohen fueron recogidas en su artículo de 1984 “Computer Viruses – Theory and Experiments”. Aquel trabajo fue pionero al establecer definiciones que hoy consideramos evidentes, como, por ejemplo, la que se refiere a un “virus” como un tipo de programa capaz de infectar a otros programas, modificándolos para incluir una copia de sí mismo. En este sentido, Cohen insiste en distinguir los virus de otros programas de propagación, como los gusanos y, enfatiza, que la característica clave de un virus es su habilidad para infectar a otros programas.

Core War
De forma paralela a la publicación del trabajo de Cohen, Alexander Keewatin Dewdney (1941-2024), mientras ejercía como profesor en la Universidad de Western Ontario, empezó a escribir en 1984 en Scientic American bajo la sección Computer Recreations. En España la revista Investigación y Ciencia también publicaría sus trabajos dentro del apartado Juegos de Ordenador. En su primer artículo, publicado el mes de mayo, A. K. Dewdney hizo una descripción de Core War, un juego de ordenador que desarrolló junto a D. G. Jones. En aquel juego dos programas competían entre si -de manera autónoma- para hacerse con el control de la memoria de un ordenador. En estos enfrentamientos cibernéticos podía competir cualquier interesado mientras programara a su “campeón” en Redcode, que no era otra cosa que un conjunto reducido de instrucciones similares al ensamblador.

En el primer texto dedicado a Core War, A. K. Dewdney cuenta que encontró la inspiración tras conocer la anécdota de Creeper y Reaper, no obstante, es curioso comprobar que los datos que llegaron hasta él no parecen ser correctos y hace referencia a estos programas como «refritos» de otros dos programas, uno de ellos anterior, Darwin, desarrollado en 1961 por Malcolm Douglas McIlroy (1932), Victor Vyssotsky (1931-2012) y, quedaros con este nombre, Robert H. Morris (1932-2011) mientras trabajaban en Bell Labs. El otro programa al que hace referencia es Worm, un gusano programado por John F. Shoch en Xerox PARC en 1980 (¿casi 10 años después de Creeper?) mientras investigaba en las posibilidades de la computación distribuida a través de Ethernet.

Tras dar a conocer en Scientic American el funcionamiento de Core War, A. K. Dewdney no contaba con que su artículo daría visibilidad a un buen número de sucesos e iniciativas relacionadas con el malware… Por eso, en su segundo texto publicado solo unos meses después (en mayo de 1985 ed. española), Dewdney se afana en explicar que Core War es un proyecto lúdico, cercano a los planteamientos de la vida artificial y no guarda relación con el incipiente fenómeno malicioso. Para dejar claras estas diferencias, cita la aparición en la Universidad Politécnica Estatal de California de un gusano para Apple II, o nos recuerda que un muchacho de Pittsburgh, Richard J. Skrenta Jr. (1967), cuando contaba con 15 años escribió un virus para Apple DOS 3.3 al que llamó Elk Cloner…

Los virus, la nueva epidemia
Es atrevido aventurar fechas concretas, pero, según mis recuerdos, fue a partir de 1985 cuando el fenómeno malware salió de los círculos especializados y llegó a la opinión pública. De ese año me viene a la memoria el artículo “Los ordenadores, infectados por virus”, publicado en la revista Conocer. En sus páginas nos alertaban de la existencia de una nueva epidemia que podría afectar a nuestros discos y ficheros, y comentaba la reciente novela francesa de Thierry Breton y Denis Beneich “Softwar, la guerra suave” (ed. española en 1985). Softwar introduce una nueva variedad de malware llamado bomba lógica que sirve como preludio al enfrentamiento entre EE.UU. y la desaparecida URSS.

De esa época, también recuerdo un breve artículo que se publicó en 1986 en la revista Muy Interesante Ordenadores titulado “La nueva epidemia”. En él se advertía del riesgo al que podían estar expuestas las instalaciones militares frente a los virus y, acompañando el texto, incluían un pequeño ejemplo de un virus para Commodore 64… Aunque todavía era de Spectrum aquello me convenció de que era cuestión de tiempo de los virus se convirtieran en una amenaza seria.

Virus en el boot de diskettes y disco duro
En 1987 por fin llegó a mi familia un flamante Amstrad PC 1512 y, como tantos usuarios de PC, no paraba de intercambiar y acumular software. Sin duda alguna, aquella obsesión por copiar fue la principal razón de las primeras infecciones y era cuestión de tiempo, unos meses o un año quizás, para verse infectado con cualquier virus liberado al otro lado del mundo… Así es como me enteré de la existencia del legendario virus Brain, que empezó a circular en Pakistán en 1986 y aterrizó en Occidente hacia 1987-88. Fue programado por los hermanos Basit y Amjad Farooq Alvi y, según su relato, fue un intento para controlar las copias indiscriminadas que otros hacían del software que comercializaban desde su establecimiento, Brain Computer Services. Irónicamente, la mayor parte del software que distribuían eran copias piratas de programas comerciales…

Históricamente, aquel virus se recordará por ser el primero para ordenadores compatibles IBM PC y, sobre todo, por aprovechar a su favor el proceso de arranque de un PC para tomar el control de una máquina y así logar replicarse a otros diskettes. Recordar que esta técnica, con los matices propios de cada sistema, era la base del virus Elk Cloner (1982) y ya fue comentada por los italianos Roberto Cerruti y Marco Morocutti en el artículo que Dewdney publicó en 1985 en Investigación y Ciencia. En resumen, se trataba de copiar el código del virus en los 512 bytes del MBR (master boot sector: cilindro 0, cabeza 0 y sector 1) de un diskette formateado para arrancar el sistema MS-DOS, es decir, donde estuvieran los archivos de kernel (IO.SYS y MSDOS.SYS), junto al intérprete de comandos COMMAND.COM. Si este disco infectado estaba insertado en la disquetera cuando finalizase el bootstrap de la BIOS, el virus pasaba a memoria y tomaba el control. A continuación, se cargarían los citados ficheros de kernel e intérprete de comandos y el usuario seguirá trabajando como si no pasara nada, pero, desde ese momento, todos los disquetes empleados para cargar y guardar otros archivos serian infectados…

Este proceso, con ciertas variaciones, inauguró la primera generación de virus para PC y fue imitado por otros virus célebres como, por ejemplo, Stoned (1987), Ping-Pong (1988) y el temido Michelangelo (1991) y su devastador borrado del disco duro cada 6 de marzo. [Continuará]

Introducción a la Ciberseguridad | Origen y evolución del Malware, 1971-1995 (2) | Origen y evolución del Malware, 1971-1995 (y 3)

Introducción a la Ciberseguridad

Adolfo García Yagüe | Hacia el final de este año escolar, me pidieron que diera una pequeña charla a jóvenes que estaban terminando la ESO. El objetivo era que conocieran una profesión y les ayudara a enfocar su carrera profesional.

En la presentación, intenté resumir algunos conceptos clave de la ciberseguridad: su evolución histórica, cómo se desarrolla un ataque y qué es MITRE ATT&CK. 40 diapositivas no dan para mucho y sé que me dejé miles, quizás millones, de cosas en el tintero.

Espero haber despertado alguna inquietud o, al menos, haber contribuido a que todos seamos más cuidadosos cuando hacemos clic. Si alguien se aburre este verano se puede descargar el PDF, está limpio 😉

Introducción

• Perspectiva histórica
• Automatización, Criptomonedas, Darknet e IA
• Adversario

Desarrollo de un Ciberataque

• Activos
• Superficie de exposición
• Riesgo
• Información
• Vulnerabilidades
• Exploits
• Malware
• Movimiento Lateral
• Ransomware
• Herramientas

Modelos de Amenazas y Marcos de Referencia

• Cyber Kill Chain
• Pirámide del Dolor
• MITRE ATT&ACK

[Descargar presentación]