OpenSSL, DNS o BGP: ¿algún bug histórico más?

En los últimos meses no hacen más que anunciarse fallos de seguridad que afectan a los protocolos base de Internet, yo al menos no recuerdo una época en la que saliesen a la luz tantos avisos considerados como “el peor bug de la historia” y que además tuviesen tanto eco en publicaciones no especializadas de carácter general quienes, por desgracia, caen con suma facilidad en el sensacionalismo.

El “apocalipsis” comenzó en mayo cuando Luciano Bello avisó de que la generación de números aleatorios del paquete OpenSSL incluido en Debian era de todo menos aleatoria, lo cual dejaba en entredicho todo el material criptográfico generado desde la incorporación a la distribución de la versión 0.9.8c-1.

El origen de este fallo es totalmente absurdo, se comentaron unas líneas de código para evitar unos warnings en la compilación, y quitar ese código significó el no inicializar correctamente con datos aleatorios el PRNG (Pseudo Random Number Generator) de OpenSSL, el cual se inicializaba únicamente en base al PID del proceso actual… esto hace que sea totalmente predecible su resultado ya que pueden replicarse en cuestión de horas los 32.768 posibles escenarios (uno por cada posible PID) y generar todas las claves RSA de 1.024, 2.048, 4.096 bits… esto supone: vulnerar la autenticación RSA de servidores SSH, romper el intercambio de claves Diffie-Hellman, clonar certificados SSL… es decir, hay que regenerar todo aquello que se generó en base a un PRNG predecible :(

Las herramientas para explotar este fallo no se hicieron esperar, y como no, el bug tuvo su pequeño hueco en la DefCon de este año de mano de su descubridor, Luciano Bello, quien ofreció una presentación sobre el tema.

Aún estábamos actualizando servidores y certificados cuando a principios de julio Kaminsky nos viene con el tema del DNS, que ya comenté en el post “El culebrón del DNS“. Pero por si esto no fuera poco, la DefCon revive viejos fantasmas, y me estoy refieriendo al protocolo de encaminamiento BGP (Border Gateway Protocol), uno de los pilares sobre los que se apoya la Internet que conocemos hoy día.

Las debilidades de BGP son bien conocidas, organismos como el NIST, han elaborado informes analizando la seguridad del protocolo y lleva hablándose de este tema desde hace más de 10 años, pero estas cosas son como cuando se barre y se mete la basura debajo de la alfombra, cada cierto tiempo alguien te recuerda que la mierda sigue ahí y que sería mejor hacer una limpieza a fondo.

En esta ocasión los encargados de recordarnos que debajo de la alfombra hay aún mucha mierda que limpiar han sido Alex Pilosov y Anton Kapela, quienes demostraron un ataque MitM en toda regla redirigiendo todo el tráfico destinado a la red de la DefCon hacia sus sistemas de Nueva York (pilosoft.com) antes de enviarlo de nuevo hacia Las Vegas. Lo mejor es que echéis un vistazo a su presentación.

¿Y esto se pueda hacer?… pues sí, se puede hacer y el problema es que “cualquiera” lo puede hacer, ya que no se trata de explotar un 0-day ni nada por el estilo, es una cuestión de diseño de la red, de abusar de un protocolo que se diseñó para una red en la que los nodos confiaban unos en otros… está claro que la ARPANET de los 70 está bastante lejos de la Internet actual. Un comportamiento inadecuado por parte de uno de los nodos, ya sea de forma intencionada o no, puede provocar una situación “delicada” a nivel de routing en Internet.

El ejemplo más claro en este sentido lo protagonizaron el pasado mes de febrero, el Gobierno de Pakistán y YouTube. El Gobierno de Pakistán quería evitar que se accediera a YouTube desde su país debido a un video que estaba publicado y que consideraban ofensivo, así que le pidió a Pakistan Telecom que bloquease el rango de direcciones correspondiente al servicio de Google. Una mala configuración en los routers provocó que se anunciara por BGP el rango de direcciones 208.65.153.0/24, subred que pertenece a YouTube. El peer de Pakistan Telecom, PCCW no filtró estos anuncios, así que se propagaron. El problema está en que esa subred pertenece a un prefijo más general, el 208.65.152.0/22, que es anunciado por el AS36561 (YouTube). Al anunciar el AS17557 (Pakistan Telecom) una ruta más específica, provocó que a los pocos minutos esa información fuera incorporada por el resto de routers de Internet y que todo el tráfico destinado a servidores de YouTube dentro de esa subred se perdiera, ya que los routers de Pakistan Telecom estaban descartando todo el tráfico destinado a esa subred. Se produjo un DoS en toda regla durante casi 2 horas.

Si os sorprende que un “despiste” de este tipo pueda ocasionar un escenario tan grave, os recomiendo que veáis el video donde la gente de RIPE explica el seguimiento que se hizo a este suceso.

El caso de YouTube fue un accidente, o al menos esa fue la declaración oficial de Pakistan Telecom. Ahora bien, ¿y si se quiere capturar tráfico destinado a redes que no nos pertenecen de forma malintencionada?… este es el escenario del cual se ha advertido en la DefCon, y del cual se viene advirtiendo desde hace más de 10 años ya.

Un atacante podría anunciar por BGP direccionamiento que no le pertenece. Si el anuncio que hace consigue ser más “atractivo” que el anuncio de la victima, conseguirá desviar hacia sus sistemas el tráfico destinado hacia el prefijo de la víctima. Se puede ser “más atractivo” publicando una ruta más específica o presentando un AS-path más corto. El resultado es un ataque en el cual el tráfico capturado puede ser analizado y/o modificado antes de ser reenviado al destino legítimo. Hay que notar que “la belleza” de la técnica presentada en la DefCon es conseguir hacer el hijacking sin generar una pérdida de tráfico, es decir, generar un MitM limpio para que el tráfico desviado finalmente alcance su destino, por lo que puede ser un ataque dificil de detectar a no ser que se estén comprobando en tiempo real las rutas que sigue el tráfico, en busca de AS intermedios no autorizados anunciando tus prefijos, a modo de “IDS BGP“.

Pilosov y Kapela hicieron su demo en base a un “AS path prepending” para conseguir reenviar el tráfico capturado a su destino original y no causar un DoS sino hacer un MitM. Por otra parte jugando con los TTL de los paquetes consiguieron ocultar los AS intermedios.

El “AS path prepending” es un “truco” para influir en el camino que seguirá el tráfico hacia un destino, en base a hacer el atributo AS-path más corto o más largo, sabiendo que se prefieren los AS-path más cortos, es decir, el camino hacia un destino con menos AS intermedios. Si un AS hace “AS path prepending” lo que está haciendo es indicar varias veces su AS en un anuncio BGP, de tal forma que se favorezca la llegada de tráfico por un camino en vez de por otro. Esto es típico cuando se tienen varias conexiones a Internet con diferentes ISP y se quiere favorecer el enlace principal en vez de el de backup. Se haría “AS path prepending” por el enlace de backup.

Ahora bien, no nos confundamos, aplicado a este escenario de ataque, el “AS path prepending” es usado para incluir en los anuncios del prefijo para el cual se está haciendo el IP hijacking los AS que se quieren usar para hacer llegar el tráfico IP de vuelta al destino. Cuando estos AS ven el anuncio enviado por el atacante lo descartan, ya que ven en el AS-path que ellos están incluidos en el camino hacia el destino, eso implicaría un bucle, y por tanto lo descartan. De esta forma el atacante consigue tener un camino “sin contaminar” con sus anuncios, y que tomará sus decisiones de routing en base a otra información, que seguramente sean los anuncios BGP originados en el AS atacado. El atacante debe establecer una ruta estática hacia el primer nodo de este camino de vuelta para poder hacer llegar el tráfico IP al destino una ve haya sido interceptado.

Pero pensemos que el hacer un MitM limpio no siempre es el objetivo. Publicar un prefijo ajeno, para terminar las conexiones en tus sistemas haciéndote pasar por el sistema atacado puede ser un escenario muy grave si pensamos en distribución de malware, phising, etc.

¿La solución? Que los routers no confien en la información de routing que les llega, ser más desconfiado, y comprobar que los AS que anuncian redes lo están haciendo de prefijos que les pertenecen y no se están apropiando del direccionamiento de otros.

Decir la solución es fácil, implementarla ya es otra historia. Eliminar esta amenaza implica que los ISP apliquen estrictas políticas de filtrado con sus peers de BGP, de tal forma que únicamente se acepten los prefijos declarados de los peers autorizados. Otro acercamiento al problema es desplegar SBGP, que ofrece la posibilidad de autenticar los anuncios de rutas, de tal forma que se pueda validar un anuncio BGP en base al AS que lo emite y al prefijo que anuncia. Esto implica el despliegue de toda una infraestructura PKI y de dar soporte para ello en los routers.

Desgraciadamente, es improbable que se ponga en marcha debido al tiempo y dinero que llevaría el desplegar esta arquitectura, y las estimaciones más optimistan hablan de un tiempo de implantación de unos 2 años si empezásemos a trabajar en ello ahora mismo.

Por tanto, por el momento, es interesante el hacer uso de los servicios de monitorización y alerta ante cambios en el AS-path hacia tus prefijos en espera de que se haga un filtrado generalizado a nivel de ISP y/o se desplieguen mecanismos como SBGP.

Build your own LiveCD collection

There are lots of live Linux distros out there. Some of them are general distros, designed to have a fully functional Linux environment without the need of installing it on a hard disk partition. On the other hand, there are some specialized live distros, that can boot from CD/DVD and run from RAM.

Personally, I find these distros the most useful ones, since I get a system designed to be used for a specific task and with loads of tools to perform network/system security audits, system forensics, system cloning, password cracking, parallel computing… You can visit livecdnews, livedistro or distrowatch to know some of them.

As but one example, I have in my toolbox the following:

All those distros together take up less than 4 GB, so would be great to join all of them in only one DVD. Depending on each live CD design, it will require changes to many scripts inside the initial ramdisk and/or the compressed root file system, but in most cases the system will boot smoothly after twiking the init script to adjust the path where it expects to find the distribution files.

First of all, the directory tree for the distros and the isolinux files have to be created:


mkdir ~/dvdiso
mkdir ~/dvdiso/isolinux
mkdir ~/dvdiso/clonezilla
mkdir ~/dvdiso/gparted
mkdir ~/dvdiso/cdrouter
mkdir ~/dvdiso/bt
mkdir ~/dvdiso/fccu
mkdir ~/dvdiso/inq
mkdir ~/dvdiso/ophcrack
mkdir ~/dvdiso/ntpasswd

The isolinux directory contains the bootloader isolinux.bin, the main configuration file isolinux.cfg where all the menu options are described and the menu.c32 file to create the text menu.

The isolinux.cfg file have to be created ad-hoc to contain a menu item for each distro on the collection. For example:


DEFAULT menu.c32
PROMPT 0
ALLOWOPTIONS 1

MENU TITLE FuTuR3 Live Collection

LABEL clonezilla
MENU LABEL Clonezilla Live 1.1.0-8 (800×600x16)
KERNEL /clonezilla/live/vmlinuz1
APPEND initrd=/clonezilla/live/initrd1.img boot=live union=aufs noswap vga=788 ip=frommedia

LABEL gparted
MENU LABEL GParted Live 0.3.7-7 (800×600x16)
KERNEL /gparted/live/vmlinuz1
APPEND initrd=/gparted/live/initrd1.img boot=live union=aufs noswap vga=788 ip=frommedia

LABEL inq
MENU LABEL Inquisitor 3.0 LiveCD
KERNEL /inq/isolinux/alt0/vmlinuz
APPEND initrd=/inq/isolinux/alt0/full.cz live fastboot automatic=method:cdrom stagename=/inq/altlinux/livecd showopts

LABEL router
MENU LABEL Linux LiveCD Router 2.0
KERNEL /router/vmlinuz
APPEND initrd=/router/initrd.gz livecd_subdir=/router load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=13312 rw root=/dev/ram0 console=tty0 pci=bios,biosirq ether=0,0,eth1 ether=0,0,eth2 ether=0,0,eth3

LABEL fccu
MENU LABEL FCCU Gnu/Linux Boot CD
KERNEL /fccu/live/vmlinuz1
APPEND initrd=/fccu/live/initrd1.img boot=live keyb=es noswap username=fccu hostname=fcculive union=aufs

LABEL bt
MENU LABEL BackTrack 3 (1024×768x24 KDE)
KERNEL /backtrack/boot/vmlinuz

APPEND vga=0×314 initrd=/backtrack/boot/initrd.gz ramdisk_size=6666 root=/dev/ram0 rw autoexec=xconf;kdm

LABEL ophcrack
MENU LABEL Ophcrack LiveCD 2.0.1
KERNEL /ophcrack/boot/vmlinuz
APPEND initrd=/ophcrack/boot/initrd.gz ramdisk_size=6666 root=/dev/ram0 rw autoexec=xconf;startx changes=/slax/

LABEL ntpasswd
MENU LABEL NTpasswd
KERNEL /ntpasswd/vmlinuz
APPEND rw vga=1 initrd=/ntpasswd/initrd.cgz,/ntpasswd/scsi.cgz

Note that the kernel and initial ram disk files have to be refered with the correct path, depending on the directory structure created.

When a distro is selected from the isolinux menu and starts booting, the kernel is loaded and the initrd file is decompressed and mounted as the initial root file system. At this point, problems show up, inside the initrd there are scripts that search for the main distro directory in the root filesystem of the bootable media, but that directory has been moved to a subdirectory (remember that each distro has its own subdirectory under the root) so we need to fix all those wrong paths.

Let’s see what have to be changed in each case, from easiest to hardest ;)

Inquisitor v3.0 Live CD

Boots like a charm, so no fixing needed.

NTpasswd

No modification is needed.

Linux LiveCD Router 2.0

Note that i have just added the parameter livecd_subdir=/router. That’s enough to make it boot.

GParted 0.3.8

The initrd file have to be mounted to modify a path in the live script. To decompress and mount the initrd file, follow these steps:


mkdir /tmp/initrd
mv ~/dvdiso/gparted/live/initrd1.img /tmp/initrd1.img.gz
cd /tmp/initrd
gzip -cd /tmp/initrd1.img.gz | cpio -i --no-absolute-filenames

Now we can edit the scripts/live file and change the LIVE_MEDIA_PATH variable from:

LIVE_MEDIA_PATH="live"

to

LIVE_MEDIA_PATH="gparted/live"

After this, you have to rebuild the initrd file:


rm /tmp/initrd1.img
find | cpio -H newc -o > ../initrd1.img
gzip -9 ../initrd1.img
mv ../initrd1.img.gz ~/dvdiso/gparted/live/initrd1.img
chmod 444 ~/dvdiso/gparted/live/initrd1.img

FCCU GNU/Linux Boot CD 12.0

The same case that previous one. You have to fix the LIVE_MEDIA_PATH variable in the live init script.

Backtrack 3

To make BT3 bootable, the initrd file have to be adapted too. In this case, the file is a compressed ext2 filesystem, so it’s easier to make the needed changes:


mkdir /tmp/initrd
mv ~/dvdiso/bt/boot/initrd1.img /tmp/initrd1.img.gz
cd /tmp/initrd
gzip -d /tmp/initrd1.img.gz
mount -t ext2 -o loop,rw /tmp/initrd1.img /mnt
vim /mnt/linuxrc

Search the following snippet of code in the linuxrc shell script, and add the subdirectory name where the backtrack distro is (bt/ in my case):


if [ "$DATA" = "" ]; then
# from= is not used or it didn't contain valid data
DATA=$(find_in_computer bt/$LIVECDNAME/$SGN)
DATA=$(dirname $DATA 2>/dev/null)
fi

Ophcrack

Same case as previous one as both distros are based in linux-live scripts. Search the same code snippet in the linuxrc file and add the directory where the distro was copied:

DATA=$(find_in_computer ophcrack/$LIVECDNAME/$SGN)

Clonezilla 1.1.0-8

At first, edit the ocs-live.d/S03prep-drbl-clonezilla script and add to the possible_path variable the path /live/image/clonezilla


possible_path="/live_media /cdrom /live/image /live_media/clonezilla /cdrom/clonezilla /live/image/clonezilla"

Uncompress and unpack the initrd file. Edit the scripts/live file, and change the path in the LIVE_MEDIA_PATH variable:

LIVE_MEDIA_PATH="live"

to

LIVE_MEDIA_PATH="clonezilla/live"

Finally, uncompress the squashfs file system:

mkdir /tmp/squashfs
cd /tmp/squashfs
mount -t squashfs -o loop,ro ~/dvdiso/clonezilla/live/filesystem.squashfs /mnt
cp -va /mnt/* .
umount /mnt
vim etc/rcS.d/S99start-ocs-live

Edit the file /etc/rcS.d/S99start-ocs-live and change the variable possible_path from:


possible_path="/live_media /cdrom /live/image"

to


possible_path="/live_media /cdrom /live/image /live_media/clonezilla /cdrom/clonezilla /live/image/clonezilla"

Note the path really used is /live/image/clonezilla. Rebuild the squashfs:


rm ~/dvdiso/clonezilla/live/filesystem.squashfs
mksquashfs /tmp/squashfs/ ~/dvdiso/clonezilla/live/filesystem.squashfs
chmod 555 ~/dvdiso/clonezilla/live/filesystem.squashfs

OK, just finishing… at this stage, we can build the ISO and test it before burn it in a DVD:


mkisofs -r -J -l -V "LiveDVD" -o livedvd.iso -b isolinux/isolinux.bin -c isolinux/isolinux.cat -no-emul-boot -boot-info-table -boot-load-size 4 dvdiso/


qemu -m 128 -boot d -cdrom livedvd.iso

If all seems to work fine in qemu, burn the ISO in a DVD and enjoy your new LiveCD collection! :)

Happy Hacking! :)

Intrusiones en repositorios de software

¿Cuál es la forma más sencilla de meter una “puerta trasera” en miles de servidores?. Pues como le diría Obi Wan al joven padawan: “use the source Luke“. Es decir, si el punto de origen de distribución del software es vulnerado, los paquetes modificados serán distribuidos e instalados en miles de servidores.

Terminábamos la semana pasada con la noticia de que precisamente ésto es lo que había ocurrido en Red Hat, tal y como se anunciaba oficialmente el pasado viernes.

Por el momento no se han desvelado los detalles de cómo se realizó la intrusión en sus sistemas, pero el resultado sí es conocido, el intruso generó nuevos paquetes firmados de OpenSSH dentro del repositorio oficial de RHEL:

Haciendo esto quería asegurarse el acceso a todos aquellos servidores que instalasen estos paquetes relativos a SSH, ya sea mediante modificaciones al cliente que podrían tener como objetivo el desvelar las claves privadas generadas o el ejecutar de forma encubierta comandos en los servidores accedidos, o bien mediante modificaciones al servidor, orientadas a dejar directamente una puerta trasera que permitiera el acceso.

En cualquier caso, lo que le permitió realizar dichas modificaciones a los paquetes oficiales de la distribución, es la obtención de la clave con la que firmar sus paquetes para que éstos puedan ser validados sin problemas por aquellos sistemas que los fuesen a instalar.

Es decir, se vulneró el sistema de cifrado basado en clave pública, lo que implica que el atacante consiguió acceso a la clave privada (de alguna forma se tuvo que desvelar la passphrase con la que debiera estar protegida) con la que se firman los paquetes que posteriormente son validados por la clave pública de la distro.

Según afirma Red Hat, los paquetes falsos no se han distribuido a través de RHN (Red Hat Network) y es recomendable detectar su presencia mediante este script que comprueba la firma MD5 de los paquetes instalados susceptibles de haber sido falsificados.

Y por si esto no fuera suficiente, se anuncia, prácticamente al mismo tiempo, que varios de los servidores de Fedora también han sido vulnerados. De nuevo, el objetivo del ataque es el servidor usado para generar la firma de los paquetes, aunque en esta ocasión parece ser que el atacante no consiguió saltarse la passphrase para obtener el codiciado acceso a la clave privada con la que firmar los paquetes de la distro. Las claves han sido regeneradas, como es normal.

Si hacemos un poco de historia, podremos ver que atacar los servidores de proyectos, lejos de ser algo excepcional se está convirtiendo en algo habitual. Recordemos: ataque a un servidor de Debian en julio de 2006, ataque al servidor de wordpress en marzo de 2007, ataque a varios servidores de Ubuntu en agosto de 2.007.

Algunas reflexiones personales sobre el asunto:

La información quiere ser libre…

… o al menos lo intenta ;)

Todos los años surge alguna anécdota en la DEFCON, periodistas expulsadas a patadas en un improvisado “spot the press“, ponentes europeos a los que se les deniega el acceso en la frontera, piques personales entre investigadores como el de Ptacek y Rutkowska y, como no, censura y prohibiciones de última hora para evitar que se celebre alguna charla, como lo que ocurrió con el exploit para el IOS de Cisco hace un par de años y lo que ha pasado este año con los estudiantes del MIT.

Para el pasado domingo 10 de agosto estaba prevista la presentación “The Anatomy of a Subway Hack“, resultado de la investigación realizada por tres estudiantes del MIT, Zack Anderson, RJ Ryan y Alessandro Chiesa. sobre los fallos de seguridad presentes en los sistemas del metro de Boston.

Dos días antes, el viernes día 8 de agosto, la MBTA (Massachusetts Bay Transportation Authority) presentaba ante una corte federal la solicitud de prohibición temporal de esta ponencia. El objetivo era evitar que esa información fuese conocida hasta que la MBTA lograse solucionar los fallos que estos tres estudiantes del MIT pretendian exponer, y de los cuales informaron a la MBTA en un análisis que le entregaron el mismo día que se interpuso la demanda. Aunque al parecer el primer contacto fue una semana antes, a través de Ronald L. Rivest, quién actuaba de profesor encargado del proyecto y a la vez de interlocutor entre la MBTA y los estudiantes.

De nuevo nos encontramos con el eterno debate del full disclosure y cuál debe ser el comportamiento responsable de un investigador ante un fallo de seguridad. En primer lugar hay que informar al afectado, darle un margen de actuación para que pueda parchear el sistema y, por último, hacerlo público.

Su investigación se ha centrado en el sistema de tarjetas de transporte usadas en el metro de Boston, tanto en su modalidad de banda magnética (CharlieTicket) como en la basada RFID (CharlieCard). Mediante ingeniería inversa analizaron el contenido del CharlieTicket, usando lectores/grabadores de bandas magnéticas estándar, de los que se pueden adquirir por unos 200 euros para TPV, y mediante herramientas software que desarrollaron para hacer el análisis. El resultado final era la posibilidad de cargar la tarjeta con un crédito de $655 (el máximo permitido por la tarjeta). Por otro lado, el cifrado de la CharlieCard también fue roto, a pesar de que según la MBTA era una versión mejorada de las tarjetas MiFare estándar que fueron totalmente rotas hace algo menos de un año. A parte, también desvelan cómo consiguieron clonar tarjetas de acceso de empleado y como aplicaron ingenieria social para extraer información de empleados.

Desde un punto de vista técnico, merece la pena echar un vistazo a las slides de la presentación. El software que desarrollaron desgraciadamente no ha sido aún liberado, debido a la orden judicial. Sería realmente interesante poderles ver en diciembre en Berlín dando, en el CCC, la charla que tenian previsto dar en la Defcon.

Actualmente los tres estudiantes están siendo representados por la EFF atendiendo a su Coder’s Right Project. Su defensa se basa en que se ha realizado una censura previa que va en contra de la primera enmienda. Por otro lado la MBTA, escudándose en la Computer Fraud and Abuse Act, alega que la información que se pretende dar está claramente orientada a explicar cómo hacer un uso fraudulento del sistema, lo cual repercutiría muy negativamente en ellos. En caso de que la MBTA siga adelante contra los tres estudiantes, es improbable que la EFF pueda seguir respaldándolos ya que no cuentan con abogados que puedan ejercer en Massachusetts.

How about a nice game of chess? (revisited)

Lo que pongo a continuación es un comentario que ha dejado Juan Carlos Jimenez a mi post “How about a nice game of chess?” ampliando muchísimo la información sobre el duelo Kasparov-Deep Blue. Dada su extensión y tremendo interés, y con el permiso de Juan Carlos, lo publico como post en vez de como comentario para que pueda ser leido con más comodidad. Os recomiendo también que visitéis el blog personal de Juan Carlos, donde encontraréis información sobre sus viajes a Japón y, como no, sobre Ajedrez :)

Aunque comentas de pasada el tema del segundo encuentro entre Kasparov y Deep Blue, ya que el tema central del post es el Go, me gustaría aprovecharme de mi afición al ajedrez para matizar cosas que deberían saberse :P

Es justo que en un post como este aparezca toda la información…

Deep Blue y Kasparov se enfrentaron en “tres” ocasiones (en la primera como Deep Thought y las últimas dos como Deep Blue) a ritmo de juego lento o torneo que consiste en 2 horas para las primeras 40 jugadas y luego una hora más a finish (señalo esto porque a ritmo de juego rápido una máquina es bastante superior a un jugador de ajedrez y es en la modalidad lenta donde se juegan los torneos de ajedrez validos para calcular la puntuación ELO de los jugadores y donde estos expresan su mejor cualidad ajedrecística).

La primera fue en 1989 en un match de dos partidas que ganó Kasparov, la segunda y tercera contra Deep Blue en los años 1996 y 1997 en sendos match a 6 partidas que terminaron 4-2 para Kasparov el primero y 3′5-2′5 para Deep Blue el último.

Pero hubo muchas dudas y razones que hacen pensar que en el último enfrentamiento, la legalidad del match fue dudosa y es que éste nunca se planteó en situación de equidad.

En primer lugar, Deep Blue contaba en su base de datos con todas las partidas de Kasparov (aparte de varios millones más de partidas de otros Grandes Maestros) mientras que Kasparov nunca recibió de IBM ni una sola partida de Deep Blue pese a haberlas pedido repetidas veces para estudiar el juego de su adversario.

En la sala de juego acondicionada para las partidas se encontraba el Gran Maestro, el tablero y un operario con un terminal y un ratón a través de los cuales enviaba las jugadas y recibía las respuestas de Deep Blue. Kasparov pidió comprobar las comunicaciones de dicho terminal y/o poder ver que efectivamente la máquina y sólo la máquina estaba conectado al mismo pero se le negó. Esto resulta importante ya que a dicho terminal podían estar llegando las respuestas de Deep Blue o de cualquier otra cosa. Cualquiera pensaría que sería tonto no conectar a dicho terminal a la máquina más potente que existía para jugar al ajedrez, pero es que dicha máquina no es el mejor jugador de ajedrez del planeta… Un grupo de Grandes Maestros que estuvieran analizando la partida y jugándola desde otra habitación en pleno coloquio (como usualmente se reúnen los grupos de analistas y entrenadores de los grandes maestros) bastarían para derrotar al mejor jugador humano del mundo.

El grupo de analistas de Deep Blue estaba compuesto por varios Grandes Maestros de todo el mundo. Entre ellos se encontraba Miguel Illescas (en el momento campeón de España e ingeniero informático). La función de los analistas era dialogar con los programadores para afinar la función de evaluación que se calcula sobre cada variantes de los varios cientos de millones que calculaba DB por segundo.

¿Pero era ese el único cometido de dichos analistas? Durante el match, Deep Blue era afinado en tiempo real en cada jugada por dichos analistas y programadores en función de las respuestas que daba a cada movimiento el campeón del mundo (algo del todo ilógico ya que la máquina debería ser autónoma y proseguir su cálculo con total normalidad sin ser afectada en cada jugada por ajedrecistas humanos).

Hago un inciso aquí para explicar un detalle importante que la gente menos conocedora del ajedrez debe conocer para comprender lo que sigue a continuación. En ajedrez hay dos componentes: la táctica y la estrategia (o posición). Los valores tácticos resultan de la continuación de varias jugadas en adelante para conseguir una mínima ventaja (un peón de más, cambiar un caballo por un alfil, etc.). Los ordenadores hasta el momento sólo se limitaban a calcular posiciones en profundidad (con el algoritmo minimax de Shannon y el podado alfa-beta). A mayor potencia de cálculo mayor profundidad de jugadas calculadas (aunque si la función de evaluación de las posiciones no está bien afinada, de nada sirve ver 10 jugadas por delante si estas no son perfectas). Una componente hoy por hoy casi imposible de definir perfectamente en una máquina capaz de jugar al ajedrez es la componente posicional del juego (para la que sí está preparado un humano). La evaluación del programa, que se basa en hechos concretos y tiene dificultades para incorporar evaluaciones posicionales a más largo plazo, no tiene en cuenta este aspecto estratégico o posicional del juego (al menos como estaba programado DB en aquel momento).

Con tantas irregularidades como se habían cometido hasta el momento, Kasparov tendió una trampa a Deep Blue: en la última partida Kasparov perdió fulminantemente en muy pocas jugadas tras plantear deliberadamente (es imposible en el ajedrez de élite que dicha jugada se tratara de un lapsus o un error) una variante de apertura muy dudosa, y bastante conocida incluso entre aficionados. La explicación a aquella aplastante derrota es que Kasparov planteó esa línea con el convencimiento de que la máquina no realizaría un sacrificio de caballo muy fuerte, a cambio de dos peones, en las primeras jugadas de la partida. Entre humanos es conocido que ese sacrificio, que no obtiene ventaja inmediata sino una presión posicional continuada pero abstracta, es muy fuerte y plantea grandes dificultades al bando defensor. Kasparov confiaba en que la evaluación del programa, que se basa en hechos concretos y tiene dificultades para incorporar evaluaciones posicionales a más largo plazo, descartaría el sacrificio por una cuestión simplemente numérica, teniendo en cuenta el valor de las piezas intercambiadas y la compensación resultante. El caso es que Deep Blue sacrificó el caballo en la partida decisiva (el marcador señalaba un empate en ese momento) y Kasparov tuvo que rendirse en tan sólo 21 movimientos.

Como informático y jugador de ajedrez me queda muy claro que existió una mano humana tras aquel sacrificio y Kasparov así lo hizo saber en la rueda de prensa posterior al match.

Kasparov acusó a IBM de haber hecho trampas enumerando todas estas razones y argumentando muchas otras y ofreció la posibilidad de revancha el año siguiente con las normas adecuadas para que el match posterior se llevara a cabo en igualdad. IBM nunca aceptó el reto…

Si os interesa el tema y queréis más información al respecto os recomiendo encarecidamente el documental ‘Game Over: Kasparov and the machine’ (documental del que se ha sacado el vídeo que se incluye en este post) en el que durante una hora se explica, argumenta e intenta demostrar todo esto explicado aquí.

Si te parece que el comentario es muy largo (que lo es) y prefieres publicar todo el texto en un nuevo post de tu blog, hazlo con toda libertad.

Humans are deprecated!

Cuando el pasado día 14 leía la noticia del robot “controlado” por una red de neuronas de rata, tengo que reconocer que me dejó bastante impactado.

Este tipo de cosas son resultado de una de las líneas de investigación desarrolladas en la Universidad de Reading por el CIRG (Cybernetic Intelligence Research Group), y en concreto se trata del proyecto Animat que se engloba dentro de un conjunto más amplio de investigaciones cuyo objetivo es crear interfaces biológicos con sistemas informáticos.

Dentro del proyecto Animat se estudia la interconexión de sistemas informáticos con cultivos de neuronas haciendo uso de arrays de electrodos. Estas redes neuronales emitirán impulsos eléctricos como salidas en base a otros impulsos eléctricos que les llegan como entradas. Las salidas están destinadas a actuar sobre elementos como, por ejemplo, motores que permitan controlar el movimiento de un robot o diferentes partes del mismo. Por otro lado las entradas provienen de distintos sensores, que permiten capturar información de estado del entorno en el que se encuentra el robot y de su situación dentro de este entorno.

Y esto es justamente lo que han hecho. Han partido de una base robótica muy simple, como la que todos hemos hecho cuando hemos jugado con este tipo de cosas, consistente en un pequeño robot móvil con ruedas y sensores de ultrasonidos para detección de los obstáculos presentes en el entorno. La actuación sobre los motores para mover al robot y la lectura de los sensores de ultrasonidos para detectar obstáculos y la distancia a la que éstos se encuentran se realiza a través de un interface bluetooth, de tal forma que se independiza el “cuerpo” del “cerebro”.

La parte novedosa no se encuentra en la parte mecánica, sino que aparece cuando analizamos cuál es el “cerebro” del robot. En este caso no se trata de ningún microcontrolador ni sistema informático similar, sino que se trata de un cultivo de neuronas de rata.

Este cultivo está compuesto por un número de neuronas de entre 50.000 y 100.000. Las neuronas son obtenidas de fetos de rata y se han separado unas de otras mediante un compuesto con enzimas, de tal forma que incialmente no están unidas entre ellas. Las neuronas se introducen entonces en un medio rico en nutrientes y constante en temperatura, y se disponen en un array de 60 electrodos que tiene un tamaño de 8×8 cm. Este array de electrodos hace de interface entre la parte biológica, constituida por las neuronas, y la parte artificial constituida por el módulo que recibe los impulsos eléctricos originados en la red neuronal, los interpreta y genera la comunicación con la base robótica a través del módulo bluetooth.

Cuando el robot se aproxima a un obstáculo, éste es detectado por los sensores de ultrasonidos, los cuales generan una señal eléctrica directamente proporcional a la distancia del objeto detectado. Este pulso eléctrico alimenta el array de electrodos, y la red neuronal reacciona ante él, generando a su vez una señal eléctrica que es recibida por los electrodos y transmitida hacia la base robótica para actuar sobre los motores.

Según los investigadores, el crecimiento de la red es realmente rápido. A las 24 horas los axones de las neuronas ya estaban creciendo e interconectándose con otras neuronas y a la semana ya se generaban impulsos desde la red. La respuesta que se espera de la red neuronal frente a determinados estimulos es algo que no se obtiene espontáneamente, sino que la red debe ser “entrenada” para ir fijando ciertos comportamientos e ir erradicando otros, para ello los investigadores utilizan diferentes sustancias químicas que refuerzan o inhiben los caminos entre las neuronas atendiendo al estímulo recibido y a la respuesta deseada.

Esta red neuronal, tal y como se ha descrito, es la única fuente de control sobre el robot. Y lo mejor para ver qué han conseguido es ver el siguiente video donde se ve a Gordon, ya que así es como se llama el robot, en acción.

En el video aparece hablando Kevin Warwick, uno de los pioneros en el mundo de la cibernética. Personalmente, la primera vez que leí algo de Kevin Warwick fue hace ya algunos años, en un artículo de la revista Wired. Por aquella época, a finales de los 90, Warwick estaba experimentando en su propio cuerpo el concepto de interface humano-ordenador, mediante un implante en su brazo izquierdo que permitía una monitorización de Warwick por parte del sistema informático de su laboratorio. Es lo que llamó proyecto Cyborg 1.0. Hoy día, 10 años después, no parece demasiado espectacular ya que esto mismo se está haciendo con implantes subcutáneos de RFID para identificación de mascotas e incluso localización de personas, pero en su momento causó un gran impacto el ver a un investigador realizar este tipo de experimentos en su propio cuerpo.

En el año 2.002, cuatro años después de los primeros experimentos, realizó lo que denominó el proyecto Cyborg 2.0. En esta ocasión conectaba directamente su sistema nervioso a sistemas informáticos. Uno de los experimentos más interesantes que hizo fue controlar un brazo robótico, cogiendo y dejando objetos, que imitaba los mismos gestos que él hacía con su mano, abriéndola y cerrándola. Los impulsos eran transmitidos a través de Internet, ya que Warwick estaba en Inglaterra y el brazo robótico en EEUU. El experimento es interesante no únicamente por el método de telecontrol descrito, sino porque Warwick sentía directamente en las yemas de sus dedos la presión ejercida por el objeto sobre los sensores de la mano robótica. Habia un feedback directo hacia su sistema nervioso.

Warwick se puede sentir orgulloso… ha sido el primer humano en tener su sistema nervioso conectado a Internet con su propia dirección IP ;)

A parte de este tipo de avances en el campo de la cibernética, Warwick es un evangelista de lo que se considera la Singularidad dentro del movimiento Transhumanista. Warwick considera al ser humano tal y como lo conocemos actualmente toalmente obsoleto, defiende el uso de la tecnología a nuestro alcance para nuestra propia mejora y defiende un futuro en el que la unión hombre-máquina, el cyborg, sea la evolución natural de la raza humana, relegando al humano actual a un tipo de subespecie inferior… Intentaré tratar este tema tan interesante en el blog más adelante, ya que me parece realmente interesante.

Otro video interesante de Kevin Warwick, es el de su charla en las conferencias LIFT del pasado mes de febrero.

Sin lugar a dudas me quedo con la última frase de Kevin Warwick en este último video: “… let’s upgrade as humans instead of staying in the lowest level with the dinosaurs, let’s improve and use technology with us in order to move forward into the future…”

Nueva serie: Fringe

Se avecina nueva temporada de series y una de ellas es Fringe. Aún faltan 3 semanas para su estreno y ya le ha salido web no oficial en castellano. La serie será emitida por la cadena Fox y uno de sus responsables es J.J. Abrams creador de series como Lost y Alias, y que se encuentra actualmente trabajando también en la próxima película de Star Trek para la que tendremos aún que esperar un año.

Un resumen simplista de la nueva serie es que Fringe se presenta como unos X-Files 2.0 o X-Files Reloaded, al menos eso se desprende del capítulo piloto (el cual podréis encontrar a poco que busquéis por la red) y en espera de que se estrene oficialmente el 9 de septiembre. Por otro lado, y al igual que sucedió con Heroes, tendremos cómic a partir del 27 de agosto, publicado por DC Comics.

En Fringe tendremos a Olivia Dunham, un agente del FBI que se enfrenta de la noche a la mañana con un extraño caso en el cual un avión proveniente de Hamburgo aterriza en Boston con toda la tripulación y pasajeros muertos, aparentemente por algún tipo de virus o sustancia química que ha disuelto su carne. Olivia comienza a investigar junto a su compañero John Scott, quién persiguiendo a un sospechoso es herido por una explosión en donde una sustancia química hace que su piel se vuelva transparente y se degrade rápidamente. Olivia empieza a indagar el origen de esta sustancia y llega hasta el Dr. Walter Bishop, quien se encuentra recluido en una institución psiquiatrica desde hace 20 años. Al parecer el Dr.Bishop participó en linieas de investigación “alternativas”. La unica forma de poder contactar con el Dr.Bishop es a través de su hijo Peter Bishop, quien pasa a formar parte del equipo junto con su padre y Olivia. En el transcurso de la investigación se desvela la existencia de una organización que hace uso de conocimientos y tecnologías ciertamente sorprendentes… y con la que parece estar relacionado el agente Scott.

Ya os podéis ir haciendo una idea… agente del FBI, científico loco, hijo que se reencuentra con su padre y que trabajará resolviendo casos raros junto con la guapa agente del FBI, y toda una variedad de “fringe science“, conspiranoias y organizaciones en la sombra.

Esperaremos ansiosos 3 semanas hasta que la empiecen a emitir para ver si la serie se logra mantener a la altura del capítulo piloto.

Juegos de guerra 2

Con el título “Wargames: The Dead Code” se estrenó hace unas semanas directamente en DVD lo que pretende ser la sequela del clásico Wargames de 1.983.

¿Quién no vió en su día Juegos de Guerra?… para mí es uno de esos clásicos que junto con Tron me marcó cuando la ví a los 8 o 9 años. Recién descubierto el mundo de la informática gracias a mi querido e inolvidable Spectrum, me encuentro con una película en la que descubro por primera vez la figura del Hacker/Phreaker, en la que veo cómo hay todo un mundo más allá del ordenador gracias al modem (con acoplador acústico incluido), en el que me deja literalmente alucinado Joshua/WOPR y la idea del supercomputador controlando el destino de la humanidad.

Si no has visto Juegos de Guerra porque has estado escondido en una cueva los últimos 25 años o te acabas de despertar de un coma ;) creo que es una buena oportunidad para que la veas.

Ahora bien, si eres de los que has visto una y mil veces Wargames… ¿qué puedes esperar de Wargames 2?. Pues aquí tienes el trailer y detrás de él… spoiler :)

Wargames: The Dead Code es básicamente la misma trama que Wargames pero adaptado a los tiempos modernos. En esta ocasión el “hacker adolescente” no se topa con el superordenador militar del gobierno mediante su wardialing de rutina sino que el superordenador se hace pasar por un servidor de juegos multijugador en Internet en el que además puedes apostar y ganar dinero. Aunque esto no es más que una tapadera para identificar perfiles potencialmente peligrosos en un futuro y ficharlos de antemano para hacerles un seguimiento.

El superordenador esta vez se llama Ripley, y no se dedica a jugar a la “guerra termonuclear mundial” como lo hacia la WOPR, ni la principal amenaza en esta ocasión es la amenaza nuclear propia de la época de guerra fría de los años 80. En esta ocasión, Ripley se dedica a evaluar escenarios de ataques terroristas y amenazas biológicas, que está mucho más en consonancia con las amenazas con las que nos atormentan la existencia hoy día.

Por otro lado, la presencia de la tecnología se moderniza, ahora se hackean las llamadas a móviles, se hackean las conexiones inalámbricas, aparecen portátiles, webcams, hacks con una lata de Pringles para aumentar la recepción de una antena… es decir, look&feel modernizado, pero misma historia por detrás.

Pero nos espera una sorpresa… un guiño a la película original… reaparece nuestro querido Dr.Falken quien tiene a la WOPR en el sótano de una fábrica dedicada a controlar la instalación eléctrica.

Por lo que cuenta el mismo Dr.Falken en la película, Ripley es el sucesor de WOPR. El estaba totalmente en contra del proyecto, así que simuló su propia muerte para volver a desaparecer. El as que se escondia debajo de la manga nuestro querido Dr.Falken es que tenia pensado usar a Joshua contra Ripley.

El momento cumbre del guión se alcanza cuando Ripley lanza un ataque tele-controlado contra la fábrica en la que se encuentra el Dr.Falken y la WOPR, destruyendo las instalaciones, la WOPR y supuestamente matando al Dr.Falken… aunque no descarto que si hay un Wargames 3, vuelva a aparecer como por arte de magia :) Pero en el último momento, el Dr.Falken logra transferir a Joshua desde la WOPR a Ripley, y empiezan a “jugar”… la misma idea que en la película original… la única forma de que Ripley no haga una limpieza de varias ciudades de EEUU que se cree que se encuentran bajo ataque terrorista es que crea que no va a ganar… así que Joshua y Ripley empiezan a simular escenarios de “aniquilación total mutua” en una versión moderna de las famosas partiditas de tic-tac-toe de la película original.

Y al final del todo… ¿qué creeis que dice Ripley?… “what a strange game, the only way to win is not to play”. ¿No os resulta familiar? ;)

Resumiendo… la película Wargames original de los 80 es todo un clásico, un imprescindible, una de las películas de referencia en la videoteca de cualquier Geek. Este remake es una película totalmente prescindible, no aporta nada nuevo de interés, es simplemente cine de entrenimiento que aprovecha la trama de una película que después de 25 años se ha convertido en un clásico para ofrecernos una versión adaptada a los tiempos actuales.

El culebrón del DNS

Recién finalizadas tanto la BlackHat como la Defon de este año, me gustaría comentar brevemente el “culebrón” del DNS, que realmente ha dado muchisimo juego durante estos últimos meses, y que tiene como colofón la charla de Dan Kaminsky en ambas convenciones sobre este tema.

Kaminsky descubrió un problema de envenenamiento de caché DNS a principios de este año. Dada la gravedad del asunto, ya que podría afectar potencialmente a la mayoria de DNS presentes en Internet, en marzo se reune con los principales fabricantes e ISPs para exponerles la vulnerabilidad y que tomen las medidas necesarias para solventarlo. Comienza un proceso de parcheo de servidores DNS. A principios de julio Kaminsky hace pública la vulnerabilidad y se generan los avisos de seguridad correspondientes.

Kaminsky pide a la comunidad de expertos en seguridad que no adelanten detalles, al menos hasta que él haga público oficialmente el fallo durante el mes de agosto, en el BlackHat y la Defcon. Esta ventana de 1 mes entre la publicación oficial del fallo y la explicación técnica detallada que Dan promete para el BlackHat tiene el objetivo de dar algo de tiempo para que se realice el parcheo de todos los servidores vulnerables presentes en Internet antes de que se publiquen exploits.

Parte de la comunidad critica durametne a Kaminsky y le acusan de orquestar todo este tema para publicitarse… no hay que olvidar que Dan Kaminsky tiene una gran parte de showman y algo así le viene fenomenal para publicitarse y aparecer en la BlackHat y la Defcon como el principal ponente. Prueba de ello es que en su aparición en la Defcon consiguió reunir a más de 1.000 personas en su charla y no me extrañaría que en diciembre, este tema del DNS aún le siga dando juego para su participación en el CCC de este año.

Al poco de hacerse pública la vulnerabilidad, empezaron a aparecer explicaciones técnicas en muchos blogs, siendo algunas hipótesis realmente acertadas y detalladas, lo que permitía la generación de exploits sin ningún problema a poco que se entendiese de qué iba el asunto y se tuviesen ciertas habilidades de programación.

En un par de semanas ya había un par de módulos (DNS BailiWicked Host Attack y DNS BailiWicked Domain Attack) del framework Metasploit que comprobaban y explotaban el fallo. No se había agotado el tiempo de 1 mes marcado por Kaminsky antes de su aparición en la BlackHat. Surge la polémica y se reabre el eterno debate del full disclosure. Hay que tener en cuenta una cosa… que un fallo de seguridad no se haga público o que sus detalles técnicos no salgan a la luz, no significa que no haya exploits “in the wild“.

Llega agosto, se celebra la BlackHat y la Defcon. Kaminsky hace su multitudinaria aparición y hace la tan esperada presentación.

Y ahora, lo divertido… ;)

Supongamos que queremos envenenar la caché de ns.victima.es para meterle un RR que asocie la dirección IP 1.2.3.4 al nombre www.banco.es

Generamos múltiples consultas por nombres dentro del dominio banco.es del tipo 001.banco.es, 002.banco.es, 003.banco.es … 999.banco.es y se las enviamos a ns.victima.es

ns.victima.es comenzará el proceso de resolución necesario para obtener la respuesta a esas consultas, que para todas y cada una de ellas será un NXDOMAIN desde ns.banco.es, que es el servidor DNS autorizado para el dominio banco.es, ya que el nombre consultado es desconocido para él.

A nosotros nos interesa hacernos pasar por ns.banco.es y que nuestra respuesta llegue antes del NXDOMAIN para que sea introducida en la caché del servidor ns.victima.es

Para que nuestra respuesta sea aceptada, el TXID debe ser el mismo que el que generó ns.victima.es para la consulta. Nosotros no sabemos cuál es, pero podemos enviarle un número considerable de respuestas, cada una de ellas con un TXID y sentarnos a ver qué pasa ya que la probabilidad juega a nuestro favor.

Si alguna de nuestras múltiples respuestas a una de las múltiples consultas, que hemos forzado a ns.victima.es a realizar, tiene el TXID correcto, el RR de respuesta será aceptado y cacheado durante el tiempo que se indique en el TTL. Lo que se va a enviar en estas respuestas son registros NS, es decir, referencias a los DNS que pueden resolver el nombre por el que se pregunta. En resumen, lo que aparentemente ns.banco.es le está diciendo a ns.victima.es es lo siguiente: “me has preguntado por 137.banco.es y yo no sé cuál es su dirección IP, pero quién lo sabe y a quién tienes que preguntar es www.banco.es cuya dirección IP es 1.2.3.4″.

Cuando ns.victima.es recibe esta respuesta de quien aparentemente es ns.banco.es y que es a quien ha preguntado, y la acepta porque el TXID es correcto, automáticamente cachea la asociación www.banco.es/1.2.3.4

Los administradores de ns.victima.es hacen bien su trabajo, y no permiten consultas recursivas a sus DNS desde Internet. ¿Son vulnerables?. La respuesta es sí. Desde luego, si desde Internet podemos forzar a un DNS a generar una consulta porque permita recursividad, nos están poniendo las cosas muy fáciles. Pero eso no implica que no se pueda “forzar” a un DNS a generar ciertas consultas, ya que cualquier usuario que navegue por una web en donde haya un recurso que requiera esa resolución, generará una consulta a su DNS, la recepción de una conexión SMTP en donde se indique ese dominio en el HELO o en el MAIL FROM provocará una consulta… hay muchas formas de generar ese tipo de consultas de forma indirecta.

La solución a este tipo de escenario es complicada desde el punto de vista de que se está explotando una característica propia del diseño del protocolo DNS. El cómo explotarlo se ve simplificado por el hecho de que el único impedimento entre la aceptación de una respuesta falsificada o una real es un TXID que tiene “unicamente” 65.536 posibles valores. El puerto origen suele ser fijo (53) o secuencial, por lo que es trivial de predecir y no añade complejidad de cara al atacante.

Una mejora es usar puertos origen aleatorios en las consultas. De esta forma no hay que “predecir” únicamente el TXID sino también el puerto origen.

Por otro lado el servidor de DNS puede ser capaz de detectar ataques de este tipo, detectando la llegada de numerosas respuestas con puerto origen y TXID incorrectos para una consulta generada. No es algo que pase desapercibido.

Interesante también el saber que hay en desarrollo un RFC para reforzar la seguridad de DNS en este sentido, actualmente es un draft y su lectura es muy interesante, nos llega de la mano de Bert Hubert el autor de PowerDNS.

Vexille

Hoy he visto un anime que quería comentar. Su título es Vexille y se estrenó en Japón hace justamente un año, aunque aquí en España Aurum la ha puesto a la venta en DVD a finales del pasado abril.

La acción de desarrolla en un futuro cercano. En la primera mitad del siglo XXI la robótica avanza considerablemente. Alrededor del año 2.060 los avances en cibernética son considerables y comienza a verse  con preocupación la unión entre hombre y máquina. El rechazo hacia la cibernética va creciendo entre la población hasta que en el año 2.067 se firma un acuerdo entre todas las grandes potencias mundiales para frenar y limitar el desarrollo en este campo. Japón, y su empresa líder Daiwa, protestan ante esta resolución si bien no pueden evitar que se firme. Rechazan formar parte del acuerdo, así que se aislan del resto del mundo para poder seguir su evolución de forma independiente al resto de paises. Para ejercer este aislamiento en el pais, expulsan a todos los extranjeros, cierran las fronteras a la inmigración, y crean una barrera electromagnética alrededor del país, que evita la entrada o salida de cualquier tipo de comunicación o señal, haciendo que Japón sea una caja cerrada para el mundo.

Pasan 10 años desde el aislamiento de Japón y en el año 2.077 se produce un extraño suceso en el cual, aparentemente, se intenta asesinar a varios líderes mundiales que asistían a una cumbre secreta. Una agencia de seguridad americana, denominada “SWORD”, investiga el asunto y sospecha que Japón, en su aislamiento, ha seguido avanzando en el área de la robótica y la cibernética, a pesar del veto mundial al que fue sometida esta actividad. Con el objetivo de aclarar el misterio deciden infiltrar en Japón a un grupo de agentes.

Y una vez allí se encuentran con que la situación es más grave de lo que inicialmente se habían imaginado… y para no destriparos el argumento, no os revelo más detalles. Os animo a que la veáis y si seguís leyendo una vez que hayáis visto el trailer… ¡ojo! que mi opinión del final del post es un  spoiler en toda regla ;)

Mi opinión personal. Técnicamente Vexille me ha gustado. La animación en mi opinión es muy buena y la estética es muy atractiva. Siendo una historia de ciencia ficción, yo incluso la catalogaría de cyberpunk, ya que cumple con algunos de los rasgos típicos del género: gran corporación que se excede hasta llegar a tomar el control político y de la población, lucha de la máquina contra el hombre, nanotecnología que convierte al humano en androide, exoesqueletos de alta tecnología, etc.

La historia es buena, me gusta mucho el concepto de crear una barrera de distorsión del espectro electromagnético alrededor de Japón para aislarlo, de tal forma que interfiera completamente en las comunicaciones e incluso evite que los satélites puedan captar imágenes. La idea de que, bajo engaño, y a raíz de una epidemia forzada se inocule a la población japonesa un agente nanotecnológico que haga mutar las células me resulta también muy interesante… aunque quizás muy exagerado el pensar en una mutación de orgánico a inorgánico. En mi opinión le daría más credibilidad si hubiesen desarrollado más este punto. No me han gustado nada de nada los “jags” estos gusanos mecánicos fruto de la unión de las mutaciones fallidas, demasiado parecido a los gusanos de Dune… en ese aspecto podían haber evitado una referencia tan clara. La música me ha encantado, y encaja perfectamente con las escenas y con la estética de la película. Por último indicar que el director de Vexille es Fumihico Sori, que fue productor de Applessed.

Next Page →