Select Page
NetCAT: otro side-channel de Intel

NetCAT: otro side-channel de Intel

Otra vulnerabilidad de side-channel en procesadores Intel, permite reconstruir sesiones SSH usando Keystroke Dynamics.

Ya habíamos hablado hace tiempo de las vulnerabilidades de side-channels (o Canales laterales). Meltdown y Spectre son los más resonantes ejemplos de dichas vulnerabilidades que afectan a los procesadores Intel.
En ese sentido, investigadores de la universidad de Vrije de Amsterdan publicaron un paper donde presentan un nuevo ataque a procesadores Intel modernos explotando canales laterales.

A partir del descubrimiento, el grupo inició un proceso de publicación de la vulnerabilidad acordado con Intel y el CERT Alemán el 23 de Junio pasado. A la vulnerabilidad se le asignó el código CVE-2019-11184 y además Intel, le asignó el suyo propio: INTEL-SA-00290.

 

Fundamentos:

El grupo de 5 investigadores del Departamento de Ciencias de la Computación de la universidad, señala la dificultad que poseen los procesadores modernos para sostener la alta tasa de transferencia de placas de red modernas. En lugar de transferir esos datos desde y hacia la DRAM, los procesadores Intel modernos realizan operaciones de E/S directamente en la LLC. Esta función se denomina DCA (Direct Cache Access) y se utiliza en lugar de acceder a la memoria vía DMA (Direct Memory Access). La función para acelerar la transferencia de datos con esta técnica se denomina Data-Direct I/O (DDIO).

El problema de utilizar LLC es que esta memoria caché se comparte entre la CPU y el resto de los periféricos, y está implementada por diseño sin medidas de seguridad. Los investigadores de Vrije hicieron foco en uno de los dispositivos, las interfaces de red. De esta forma crearon un ataque denominado NetCAT (abreviatura de Network Cache ATtack) mediante el que explotan información sensible de tiempos en comunicaciones de redes. Particularmente, detectan las teclas oprimidas por otro usuario que comparta la misma CPU en una sesión SSH.

¿Pero cómo hacen para saber qué teclas oprimió un usuario? Esto sería imposible teniendo en cuenta que la vulnerabilidad descubierta es sobre el contenido de información de red (que quedan en la LLC) y a nivel de red, los paquetes SSH viajan cifrados. La forma de obtener esa información es adivinando las teclas que oprimen los usuarios. Y eso lo hacen mediante Keystroke Dynamics.

 

Prueba de concepto

Los investigadores publicaron el detalle de como construyeron el ataque. Éste empieza conectándose a un dispositivo que esté utilizando un procesador intel con DDIO y RDMA habilitados. Si hay un usuario que se conecta al mismo servidor y establece una sesión SSH, es posible registrar la llegada de cada paquete de dicha sesión. Dado que en SSH los caracteres que el usuario tipea se envían de a uno por vez, es posible adivinar los caracteres enviados por la latencia entre ellos. Esta técnica es bastante antigua. Esto ya lo hacía el viejo Chaosreader hace unos 15 años. El que, a su vez, había tomado el concepto de Song en su paper de 2001.
Podemos ver lo que hacía Chaosreader ya que milagrosamente ¡la página de Brendan Gregg sigue viva! La diferencia con NetCAT es que Chaosreader capturaba paquetes de red y trabajaba con ellos para obtener información diversa. Una de las funciones de la herramienta era “adivinar” el contenido de sesiones SSH mediante una herramienta denominada sshkeydata.
En esta página se pueden ver los resultados de procesar paquetes de sesiones SSH. Aquí se puede ver cómo se analizan los paquetes para tratar de reconstruir la sesión.

La gente de Vrije utilizó además que el de Song, otros trabajos más modernos que le permitieron aumentar la precisión. Por otro lado, leer los tiempos de llegada de los paquetes via DDIO es más preciso que usando libpcap por la red. Sin embargo, se enfrentaron con los mismos problemas que todos los que hicimos esto alguna vez: extraer las teclas tipeadas por usuarios no enrolados*. Teniendo en cuenta que todas las personas escriben sobre un teclado con patrones de tipeo diferentes, esta tarea es la más difícil de realizar.

 

Conclusiones

Por un lado, en la eterna pelea performance y usabilidad vs. seguridad, a veces ganan unos y a veces otros. Habilitar DDIO y RDMA sabemos que es poner a los procesadores en modo turbo. Pero el efecto secundario es que se pierde seguridad. En este caso, poder leer datos de la caché de los dispositivos va mucho más allá que reconstruir sesiones SSH. Hay mucha información sensible que puede estar siendo transferida entre dispositivos por un usuario y vista por otro que no tiene privilegios y sólo por estar en el mismo procesador.

Por el otro, ciberseguridad ya tiene tantos años que dejó de ser nueva. Otra vez side-channel attacks… otra vez Intel… otra vez keystroke dynamics.
Los problemas que se encuentran hoy ya no son nuevos, sino viejos que se reciclan.

 

 

*Usuarios no enrolados: usuarios de los cuales no se tiene la información de su patrón de tipeo.

 Usuarios enrolados: usuarios que se los somete a varias pruebas repetitivas, para que tipeen textos conocidos y controlados, y así se puede obtener su patrón de tipeo.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Cómo entrenar a tu dragón

Cómo entrenar a tu dragón

Y ya están entre nosotros.


A pesar de las predicciones y especulaciones de su inminencia tanto en la literatura fantástica como en el cine de ciencia ficción, le tomó unos 30 años a la Inteligencia Artificial (IA) salir de los laboratorios y llegar a nuestro mundo cotidiano. Pasó por Redes Semánticas, Procesamiento de Lenguaje Natural, Sistemas Expertos, Sistemas Cognitivos, Agentes Inteligentes y, finalmente, Inteligencia Artificial. A medida que fue creciendo, algunos logros nos asombraron como cuando a fines del siglo pasado Deep Blue
 le ganaba varias partidas a Kasparov. Aunque eso ni se compara con la forma en la que DeepMind de Google viene destrozando a varios jugadores expertos y campeones mundiales de Go en los últimos años. Estos resultados espectaculares por ahora siguen siendo de laboratorio. Aunque Siri, Google Now y Cortana no lo son.

Cada vez que consultamos a nuestros smartphones y les preguntamos cómo llegar a cierta dirección, o si nos puede dar la mejor receta de la Musaka griega o si le pedimos que cante, quien nos está respondiendo es el sistema de IA que Apple, Google y Microsoft desarrollaron para sus productos.
Al consultar el pronóstico del tiempo en el Weather Channel, ir de compras virtuales por Macey’s o hacer consultas de salud en el sitio de la American Cancer Society, veremos el logo de “With Watson” que significa que esas organizaciones están usando el sistema de IA de IBM: Watson para analizar sus datos. El mismísimo Elon Musk, a pesar de mostrar públicamente su preocupación por el desarrollo de la IA, formó la compañía OpenAI para fomentar su desarrollo.

Antes de la IA, usábamos nuestros programas, aplicaciones y sistemas para que nos agilicen nuestros procesos de negocio, aunque las decisiones intermedias las seguían tomando los expertos que interpretaban los resultados.  ¿Pero qué pasa si entrenamos a un sistema de IA para que tenga las mismas habilidades del experto? Eso es lo que están haciendo hoy los sistemas de IA. Reemplazan la intervención humana en la toma de decisiones de forma mucho más rápida, eficiente y con menor tasa de error. Y esto se logra por medio de dos claves: la primera es la elección correcta del tipo de herramienta de IA (hoy en día la más difundida por su eficiencia es la de Deep Learning); la segunda es cómo la entrenamos. En particular con Deep Learning, se deben usar millones de datos tomados de expertos, pre-procesarlos adecuadamente para alimentar al sistema para que aprenda y se entrene.

Vayamos a un ejemplo concreto en el ámbito de la ciber-seguridad. Un sistema SIEM (Administrador de Eventos e Información de Ciberseguridad) es un sistema extremadamente complejo. Su misión es la de recolectar información de sensores a través de las redes y sistemas, correlacionarlos y dar alertas ante la evidencia de un ciberataque.
Blog – Como entrenar a tu dragón

Si bien algunos fabricantes prometen que con un “Next> Next> Next>” es posible tener un SIEM activo y funcionando en minutos, la realidad es que estos sistemas son muy complejos que requieren de la intervención de un experto. Inicialmente para el diseño mismo del sistema, analizando la red, los nodos, los sistemas instalados, las comunicaciones, los activos críticos, los puntos de entrada y de salida. Y posteriormente para  analizar enormes cantidades de datos que permitan dar como resultado información realmente útil.
Si bien las herramientas SIEM actuales son bastante completas y funcionan para la mayoría de las instalaciones de forma convencional, en redes muy grandes esto es casi imposible. Por esto algunos vendors están empezando a agregar componentes de IA para reemplazar la intervención humana y hasta para generar acciones por sí mismos, como bloquear conexiones o borrar archivos potencialmente peligrosos.

Ahora bien, una herramienta es sólo una herramienta. Dependiendo de en qué manos caiga, es lo que se va a hacer con ella. Resulta que un ciberataque también es un proceso muy complejo y de varios ciclos de análisis, toma de decisiones y acciones para llegar a un objetivo. Y también es necesario un experto para llevarlo a cabo; ¿o lo era? ¿Se podrá entrenar un sistema de IA para generar ciber-ataques? La respuesta es sí. El mismísimo DARPA (Defense Advanced Research Projects Agency) está fomentando esta actividad. Pero además, las herramientas que están a disposición de la comunidad ya se están entrenando para planificar cómo causar daños en el ciberespacio.

Pero hay un problema extra. Dijimos que especialmente en Deep Learning se necesitan muchísimos datos (muy bien pre-procesados) para que los sistemas de IA aprendan correctamente. Si hacemos esto incorrectamente o a las apuradas o con datos insuficientes, podemos hacer que los sistemas de IA aprendan, pero mal. Que por ejemplo en el caso del SIEM, no sólo no detecten los ataques, sino que abran puertas a los atacantes o borren archivos válidos e importantes o bloqueen un sistema por haber errado en un análisis. Y en ese caso, ¿qué tipo de error sería? ¿Un error humano producido por una máquina?

Los sistemas de IA serán lo que hagamos de ellos. Si los entrenamos bien, podrían convertirse en nuestros aliados como tantas otras tecnologías que utilizamos a diario en nuestras vidas; pero si los entrenamos mal, por error o con malas intenciones, sin que lleguen necesariamente a convertirse en Skynet, pueden llegar a causarnos a los humanos que quedemos, serios dolores de cabeza…

 
Nota por Carlos Benitez
Un golpe de suerte, o de cómo Mark Zuckerberg creó conciencia para la implementación de GDPR

Un golpe de suerte, o de cómo Mark Zuckerberg creó conciencia para la implementación de GDPR

En una nota anterior, contamos cómo la Unión Europea está trabajando fuertemente desde hace 4 años en una nueva normativa de protección de datos personales, la hoy ya famosa GDPR o Reglamentación General de Protección de Datos de la Unión Europea. Esta iniciativa se crea dadas las enormes falencias que existen en las empresas de la Unión, en las que se fueron detectando faltas inaceptables en las capacidades de ciberprotección.
La norma será de aplicación obligatoria para todas las empresas de la UE a partir del 25 de mayo de este año. Sin embargo, el hecho de la obligatoriedad, no necesariamente implica que la curva de implementación de las contramedidas sea rápida o eficiente. La misma motivación que hace que las empresas a veces tengan áreas enteras dedicadas a analizar de qué forma pueden pagar menos impuestos, es probable que las hagan analizar de qué forma cumplir con GDPR con el menor esfuerzo e inversión posibles. 
¿Por qué se da esto? Por la misma razón por la que hoy en día sus medidas de ciberprotección son inaceptables: la falta de conciencia.
El convencimiento de que lo que uno está haciendo es importante o necesario es lo que dispara los procesos para que efectivamente se lleve a cabo. Y en este caso, muchas empresas de la UE no están convencidas ni creen que es importante – o por lo menos no lo estaban.
El vuelco que dio en la aceptación sobre la implementación de la nueva norma, se dio gracias al escándalo de Facebook y Cambridge Analytica. La comisionada por los asuntos de los consumidores de la UE, Vera Jourlova, quien se reunió con Mark Zuckerberg a raiz del escándalo, le dió a Zuckerberg las gracias públicamente por haber aceptado cumplir con GDPR ni bien esté en vigencia. Es difícil saber si la declaración del CEO de Facebookaceptando sin objeciones las nuevas contramedidas de seguridad para preservar la privacidad de los datos de los usuarios, hubiese sido la misma sin el escándalo de Cambridge Analytica. Pero la verdad es que a los promotores de la medida les vino como anillo al dedo, y justo antes de la entrada en vigencia de la medida.
Veremos el 26 de mayo cuáles habrán sido finalmente los resultados.
 
Nota por Carlos Benitez

 

Cuando el hardware grita…

Cuando el hardware grita…

En el ámbito de la ciber-seguridad, ¿qué es un canal lateral? Imaginemos que una persona se encuentra dentro de una habitación, sentada en un escritorio con una computadora delante. Imaginemos también que pretende loguearse a una aplicación y que, además, va a escribir un mensaje confidencial. Supongamos que la aplicación no tiene bugs de seguridad, que la comunicación viaja cifrada por un canal seguro y utilizando certificados digitales con el mayor grado de seguridad posible. Imaginemos también que no hay nadie en la habitación más que esa persona y ningún otro objeto más que el escritorio, la silla y la computadora. Seguro, ¿no? Todo prolijamente construido y configurado para darle un altísimo grado de seguridad.
La persona comienza a trabajar, pero hace algo más: cada tecla que oprime o cada función o botón sobre los que hace clic en la pantalla, los grita, fuertemente.
Parafraseando el famoso Koan del Budismo Zen: “¿qué es lo que grita si no hay nadie para escuchar?”. Sin embargo, supongamos que sí hay alguien cerca, fuera de la habitación. Y, aunque con dificultad, logra escuchar, entender y anotar todo lo que grita el usuario. ¿Cuál sería el resultado? Que al cabo de un tiempo, alguien ajeno a la comunicación logra obtener el mensaje secreto, o parte de él.
¿Y cómo es posible romper ese secreto? ¿Infiltrando un malware en la computadora? ¿Interceptando la comunicación? ¿Robando las credenciales? No, de ninguna de esas formas. El mensaje secreto se filtra porque algo en el proceso falla, y revela la información de una forma inesperada. El intruso logró hacerse del mensaje mediante la explotación de un “canal lateral”, en este caso, el sonido producido por el mismo usuario.
A muchos lectores esta figura les podrá parecer absurda, grotesca o hasta burda. Sin embargo es exactamente lo que pasa. Cuando se utilizan los dispositivos electrónicos para interactuar con aplicaciones y con la red, esos dispositivos (aunque no lo percibamos) “gritan”, todo el tiempo. Cambian sus patrones de consumo de energía, emiten sonidos, utilizan librerías o zonas de memoria accesibles por otros usuarios de forma totalmente diferente en función de las acciones que está realizando el usuario. Es por esto que, sabiendo “escuchar”, es posible descifrar el contenido de esos “gritos”.
El concepto de atacar canales laterales no es nuevo, solo que, como siempre ocurre, cuando estas ideas aparecen la tecnología no está suficientemente madura. Pero pasa el tiempo, la tecnología evoluciona, y el bíblico “nihil novum sub sole” (nada nuevo bajo el sol) se materializa.
Si bien hoy en día son muchos más los trabajos de investigación académica que los exploits concretos, éstos existen y se van sumando. Incluso existen varias pruebas de concepto públicas cuya utilidad es muy limitada, pero muestran que el camino a que cada vez aparezcan más ataques de este tipo es irreversible.
Una de las primeras muestras de ataques graves de Canales Laterales se pudieron ver muy a principio de este año con dos vulnerabilidades conocidas como Meltdown y Spectre. La primera permite “derretir” los límites de seguridad entre áreas de memoria del procesador, mientras que la otra permite engañar a los programas a que revelen sus datos. De esta forma, es posible obtener datos sensibles de otros programas que se están ejecutando en el mismo equipo, no importa a qué usuario correspondan.
Estos ataques de Canales Laterales ni siquiera utilizan sofisticados algoritmos de Machine Learning (ML), y sin embargo comprometen seriamente la seguridad de casi cualquier sistema.
El mayor peligro de estas técnicas, consiste en su principal ámbito de aplicación: la nube. Las técnicas de canales laterales se pueden utilizar en muchos ambientes, pero las mayores posibilidades se obtienen cuando el atacante está compartiendo el mismo hardware que la víctima, por extensión, cuando muchos usuarios sin relación ni conocimiento entre ellos utilizan las mismas plataformas. Esto es exactamente la nube. Los sistemas “IaaS” (infraestructure as a service) y “PaaS” (Platform as a service) son los más susceptibles. Este tipo de ataque se denomina Inter-Máquinas Virtuales o Cross-VM.
Estos ataques no son fáciles de llevar a cabo para los atacantes. Se deben hacer muchas pruebas, recolectar muchos datos y analizar esos datos con herramientas de clasificación muy sofisticadas para obtener resultados útiles. La tecnología que permite hacer esto es la de ML. Y no es necesario contar con el software de nombre del asistente de Sherlock Holmes desarrollado por la compañía de tres letras… cada vez más existen componentes y frameworks de ML open source que los usuarios pueden descargar y probar. Si se desean realizar algunas pruebas, se puede utilizar el framework de Deep Learning Kerashttps://keras.io/ basado en python, que se monta sobre las liberías Theano o el poderoso desarrollo de Google, Tensorflow que permite la realización de cálculos tensoriales complejos con unas pocas líneas de Python.
Tampoco es fácil detectar estos ataques, ya que estas técnicas no son invasivas como los ciber-ataques habituales. De hecho, hoy en día, podríamos tener nuestra infraestructura implementada en la nube, un atacante podría haber alquilado servidores o contenedores en el mismo servicio que nosotros, y estar tratando de atacarnos sin que podamos darnos cuenta. Todavía no existen herramientas de software que nos permitan esta detección. La única solución de defensa hasta el momento consiste en la utilización de dos estrategias tanto en forma individual como combinada. Una de ellas es monitorear en nuestros propios sistemas las mismas variables que monitorearía el atacante para ver si se comportan de manera anómala y pudiese significar un posible ataque (por favor, notar la cantidad de veces que utilicé el potencial). La otra es la de generar “ruido” aleatorio que tape los gritos. Es decir hacer que el hardware se comporte de forma lo más aleatoria (o también rítmica) posible para que a los sistemas de inteligencia artificial que utilice un atacante no les sea posible distinguir entre un comportamiento y otro de nuestros sistemas.
Una vieja idea que de pronto se convierte en una nueva ciber-amenaza, silenciosa, casi imperceptible, y muy peligrosa. Una vez más, nos toca prepararnos.
Nota por Carlos Benitez
El #1 de las infraestructuras críticas: las centrales eléctricas

El #1 de las infraestructuras críticas: las centrales eléctricas

Las infraestructuras críticas (aquellas que proveen servicios a la sociedad que, de ser interrumpidos, causarían graves daños a la población) vienen siendo blanco de ciber-ataques desde hace muchos años. El equipamiento industrial involucrado en la prestación de este tipo de servicios, se controla con sistemas informáticos interconectados muy antiguos que hacen que sean susceptibles de ser alcanzados por malware.
Cuando el sistema de control más popular, el SCADA, nació allá por los ’60, era absolutamente impensado que alguien pudiese conectarse a él remotamente desde la otra mitad del mundo y abrir de la exclusa de una represa, o la válvula de un circuito de provisión de gas, o el interceptor de un transformador de alta tensión que provee energía eléctrica a toda una ciudad.
Sin embargo, con el paso del tiempo, al abuelo SCADA, a sus derivados y a los sistemas que controla, se le fueron agregando componentes de IT cada vez más complejos y con cada vez más conexión a la red: sensores, interfaces gráficas, nodos de red, dispositivos IoT, etc.
Esto hizo que fuera blanco cada vez más fácilmente de pruebas de concepto y ciber-ataques cada vez más sofisticados, más frecuentes y más peligrosos. El caso que cambió radicalmente la visión sobre este tipo de ataques fue el descubrimiento en el año 2010 del gusano Stuxnet cuyo efecto fue el considerable retraso en el programa de desarrollo nuclear de Irán. Es entonces cuando se dispara la carrera de medidas y contramedidas tratando por un lado de atacar estos sistemas (los unos) y por otro de defenderlos (los otros).
Si bien los sistemas SCADA controlan casi el 90% de los procesos industriales automatizados del planeta, el foco de los atacantes desde hace aproximadamente un año son las centrales eléctricas.
Cada vez más son probadas y atacadas con mayor virulencia, sofisticación y frecuencia. Una gran parte de esos ataques son exploratorios, es decir que se realizan con el propósito de probar tanto las herramientas propias, como las capacidades de defensa de las centrales. La sofisticación se incrementa exponencialmente a tal punto que existen grupos como “Dragonfly“, cuyo propósito específico es atacar centrales eléctricas.
Estas amenazas han hecho que los países más desarrollados hayan tomado en serio las medidas de protección que eviten un desastre en el caso de un ciber-ataque masivo a este tipo de instalaciones.
El gobierno de Estados Unidos, por ejemplo, envió recientemente una orden ejecutiva por la cual se obliga a las redes del estado y de las infraestructuras críticas a utilizar el Marco de Ciber-seguridad del NIST (National Institute of Standards and Technology’s Cybersecurity Framework) que, si bien existe desde hace varios años, hasta el momento de la orden ejecutiva, su aplicación era voluntaria.
Uno de los resultados de esta escalada hizo que por ejemplo, algunas organizaciones que se dedican a la generación y distribución de energía eléctrica para millones de usuarios en Estados Unidos, cambiaran sus estrategias de ciberdefensa de reactivas a proactivas. Esto lo hicieron instalando miles de sensores en diferentes niveles de la arquitectura, recolectando datos de todos ellos y explotando esa Big Data de modo de prever posibles ataques a partir de comportamientos anómalos antes de que ocurran, y estar preparados para defenderse.
Y otra vez, como en varias de las notas anteriores, nos toca preguntarnos: ¿y por casa? ¿Cómo está la situación? Nuestras empresas generadoras y distribuidoras de energía eléctrica, ¿están adoptando las medidas necesarias para prevenir ataques de estas características? ¿Estamos siquiera en la etapa de estrategia reactiva, o todavía ni siquiera empezamos?
Las herramientas, tanto metodológicas, como normativas y técnicas están disponibles. Sólo falta tomar conciencia y darse cuenta de la situación en la que estamos junto con el resto del mundo, y empezar a trabajar.
 
Nota por Carlos Benitez

 

Otra vez los Juegos

Otra vez los Juegos

 
Existe una extraña tendencia histórica, que muestra que cada vez que se produce un evento deportivo mundial de gran magnitud, las redes, las aplicaciones, los sitios relacionados con el evento, son blancos de ciber-ataques.
Hace años que sucede esto y en algunos casos hasta ha tenido consecuencias positivas. Antes del mundial de fútbol Brasil 2014, se sabía de amenazas a la organización del evento sobre la posibilidad de interrupciones en sus sistemas. Dos años más tarde, lo mismo sucedía con los juegosolímpicos de Rio 2016.
Como consecuencia de estas amenazas, Brasil se preparó tan fuertemente para defenderse que hasta casi significó la creación misma del área de Ciberdefensa, el ComDCiber que hoy está activo, funciona plenamente y sigue invirtiendo en cada vez más en medidas de ciber-protección a nivel nacional.
Esto ocurre desde hace años juego tras juego, por lo que los Juegos Olímpicos de Invierno que se llevan a cabo en este momento en PyeongChang, Corea del Sur tampoco son ajenos. Y esta vez las contramedidas parecen no haber sido suficientes. Durante el mismo momento en que se producía la ceremonia inaugural el pasado 9 de febrero, un grupo hasta ahora no identificado (aunque hay fuentes que aseveran que fueron hackers rusos), bloqueó el acceso a Internet y algunas transmisiones, hizo aterrizar los drones con las cámaras, bajó el sitio web oficial e impidió que los espectadores imprimieran sus reservas. El ataque fue denominado “Olympic Destroyer” y el malware involucrado tenía por objetivo destruir los recursos compartidos de red a los que se tuviera acceso desde el equipo infectado. El malware, al parecer, estaba diseñado para producir el mayor daño en el menor tiempo posible.
Si bien este ataque se produjo el 9 de febrero, comenzó en realidad tiempo antes. En diciembre del año pasado, los miembros de la organización de los Juegos fueron blanco de phishing, cuyo objetivo fue el de obtener información interna de los sistemas asociados a los Juegos para hacer mucho más eficiente el ataque final. Lo interesante de este ataque, fue que esta vez se utilizó un método novedoso en la que se envía adjunto al email falso, un documento de Word que contiene un script malicioso. Lo que realmente llama la atención por su novedad, es que el código malicioso se esconde dentro de los pixels de imágenes adjuntas lo que lo hace indetectable a los antivirus. Es por esto que probablemente muchos de estos ataques hayan sido exitosos y logrando la interrupción de servicios del primer día del evento. Es obvio que fallaron los antivirus por no estar preparados para este tipo de ataques, pero falló algo más; la concientización, los usuarios que a pesar de todos los cursos, charlas y avisos que suponemos tuvieron, abrieron un adjunto de un email falso.
Pero, ¿por qué atacar a los Juegos? Existen varias teorías al respecto así como análisis más serios y profundos que indican que el momento de un evento de estas características posee gran atractivo para convertirlo en blanco de ciber-ataques. A pesar de la organización, la realidad es que, como indica el informe de Berkeley, en estos eventos la ciber-superficie de ataque es infinita. Es imposible mitigar el riesgo de todos los dispositivos interconectados, el volumen, la variedad, la heterogeneidad; la distribución geográfica es tal que los hace incontrolables. Sistemas de puntuación, dispositivos que miden el estado de salud de los competidores, control de entradas, dispositivos de transmisión de los medios de prensa, medios de transporte, sin contar con los sistemas de control propios de los estadios y los dispositivos personales de cada participante, organizador o visitante; todo esto conectado de una forma u otra a la misma red.
Por otra parte, la cantidad de tecnología involucrada en estos eventos no sólo es inmensa, sino que además es crucial para el desarrollo del evento que no podrían realizarse sin ésta. Esto lo vuelve un verdadero desafío para los organizadores que tratan de extremar las medidas de ciber-protección, así como para los atacantes que ven terreno propicio para introducirse en los sistemas del próximo evento y demostrar que las medidas de protección no alcanzan.
Veremos qué pasa en el mundial de Rusia. Y Buenos Aires, ¿cuán preparada está para los Juegos Olímpicos de la Juventud de Octubre, ¿quién ganará la partida?
 
Nota por Carlos Benitez