Select Page
NetCAT: otro side-channel de Intel

NetCAT: otro side-channel de Intel

by | Sep 16, 2019 | CiberSeguridad, Actualidad, Canales Laterales, Keystroke Dynamics, Noticias, Vulnerabilidades

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.
Malboard: Replicando patrones de tipeo

Malboard: Replicando patrones de tipeo

by | Jul 22, 2019 | CiberSeguridad, Actualidad, Canales Laterales, Ciberprotección

Encuentran la forma de engañar a los sistemas de autenticación por reconocimiento de patrones de tipeo.

 

El Si6:

Fue allá por el 2003 en el Si6 donde iniciamos un conjunto de proyectos relacionados con la identificación de comportamiento de intrusos. Uno de los temas de investigación sobre el que trabajamos durante años, fue el de Keystroke Patterns o Patrones de Tipeo. El objetivo era el de poder identificar a un intruso, que se logueaba de forma interactiva a una shell, analizando su comportamiento de tipeo.

Aprovecho esta nota para nombrar a todos los investigadores que formaron parte del Si6, equipo al que me enorgullezco de haber pertenecido: Sebastián García, Flavio Fernández, Georgina Halladjian, Alejandro Benaben, Maximiliano Bertacchini, Luciano Bello, Verónica Estrada, Pablo Fierens y Carlos Benitez.

El Si6 no existe más, pero como los que estamos en este negocio sabemos que los rastros no se borran nunca en Internet, por si a alguien le interesa:

Como parte de nuestro trabajo, publicamos varios trabajos relacionados con la dinámica de tipeo, como por ejemplo:

Keystroke Dynamics:

Respecto a Keystroke Dynamics, el concepto es sencillo. Todas las personas utilizan sus dedos para oprimir teclas en un teclado. Del mismo modo que cada una de nosotros camina, sonríe o habla de forma diferente, también tipeamos de forma diferente. Por este motivo es posible identificar personas determinando lo que se denomina su “patrón de tipeo” o keystroke pattern.
Además de los trabajos de investigación, también desarrollamos una aplicación para detectar estos patrones en aplicaciones la web. La aplicación se denominaba k-profiler y los resultados de la investigación fue publicada en el paper: User Clustering Based on Keystroke Dynamics

 

El concepto consiste en medir los tiempos de latencia entre diferentes acciones realizada en el teclado (como apretar o soltar una tecla). La medición suele realizarse sobre el tiempo entre dos teclas sucesivas o “digrafos”.

En esa época, habíamos imaginado una némesis para el concepto. Consistía en la posibilidad de que un intruso alterara artificialmente su patrón de tipeo. De esta forma sería identificado como otro atacante y no como él mismo.

 

Malboard:

Pasaron 16 años y nuestro némesis se volvió realidad. Un grupo de investigadores de la universidad Ben-Gurion, descubrió una forma de engañar a los sistemas que autentican a las personas usando sus patrones de tipeo. El ataque, denominado Malboard, fue publicado en mayo pasado. En este caso, no es un usuario que se impersona en otro para falsear su patrón de tipeo. Sino que se utilizan dispositivos USB que se reconocen como teclados para inyectar comandos desde un teclado. Existen varios dispositivos de este tipo en el mercado, tal como el RubberDucky. Lo novedoso de este ataque es que los comandos se inyectan tal como lo haría el usuario al que se trata de impersonar.

Para el ataque, se evaluaron los patrones de tipeo de 30 personas realizando 3 acciones diferentes. A partir de la copia del patrón de tipeo, se inyectaron comandos maliciosos mientras se era monitoreado por diferentes sistemas de detección como TypingDNA o KeyTrac. El resultado fue que se logró evadir los sistemas de detección más del 83% de los casos.
Pero el grupo no se quedó sólo en el ataque. Desarrolló además un sistema que permite su detección. Con esto lograron un 100% de efectividad en la detección, al menos en las pruebas realizadas por ellos.

El método de identificación por patrones de tipeo se utilizó por primera vez con el telégrafo durante la guerra de secesión de Estados Unidos allá por 1860. Es interesante ver cómo técnicas como estas no mueren, sino que se reciclan constantemente evolucionando una y otra vez.

 

Nota por Carlos Benitez

Carlos Benitez es un reconocido experto en seguridad de la información.
Cuando el hardware grita…

Cuando el hardware grita…

by | Mar 28, 2018 | Actualidad, Argentina, Canales Laterales, CiberDefensa, CiberSeguridad, Machine Learning, Meltdown, Spectre, Vulnerabilidades

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