Qué nos enseñan los ataques de canal lateral

Las infraestructuras en la nube nos han proporcionado plataformas en las que diseñar aplicaciones. Esto, a su vez, ha puesto a disposición de los desarrolladores componentes del stack con los que hacerlo efectivo. Sin embargo, esta gran ventaja trae consigo un dilema: ¿cuántas aplicaciones diseñamos desde cero con las plataformas, y a cuántas nos suscribimos y usamos como SaaS? Es importante garantizar la integración completa de la plataforma en la fase de diseño para decidir en qué casos optamos por una u otra opción.

En el mundo de la seguridad, circula una frase muy manida: «No crees tus propios criptoactivos». Aunque como consejo sigue siendo totalmente válido, debería seguir con «…ni crees tu propia plataforma». Diseñar una plataforma supone manejar tantas combinaciones posibles que las áreas de superficie que formarían son un caramelo demasiado goloso para los atacantes, que son muy astutos al tratar de aprovecharlas. Personalizar una plataforma es una tarea en constante evolución. En ese sentido, la plataforma de Fastly, que preintegra servicios de computación, de almacenamiento y de redes, está bien equipada para defenderse de este tipo de ataques actuales y futuros. 

En este artículo analizaremos qué aspectos pueden fallar. Como hemos visto, los ataques de canal lateral son la debilidad más extendida en el diseño de seguridad. Son, además, difíciles de prever: aparecen cuando un algoritmo, a pesar de ser seguro de puertas para adentro, interactúa con su entorno de un modo extraño que permite a los atacantes inferir secciones secretas.

Creo que puede ser tan divertido como instructivo analizar algunas de las vulnerabilidades de canal lateral más básicas y raras que llevan años dando quebraderos de cabeza a los responsables de seguridad. Intentaré que el análisis sea general para que queden claras las ideas principales, pero te invito a consultar los enlaces del artículo si prefieres entrar en detalle y tener una visión más completa.

Una introducción de ciencia ficción

Empecemos echando la vista atrás, hasta la década de los 80. Aunque ha despertado el interés general ahora, la interferencia de Van Eck ilustra a la perfección qué son los ataques de canal lateral. La clave en este ataque concreto es que los monitores de ordenador generan campos electromagnéticos de forma predecible al representar una imagen en el monitor. La mayoría de las personas entendería que son interferencias en el espectro de radio, pero un atacante decidido puede recomponerlas y lograr una reproducción bastante aceptable del contenido de la pantalla. De hecho, un ordenador sin conexión a internet ubicado en una habitación sin ventanas sigue siendo un canal lateral vulnerable porque se pueden aprovechar los efectos laterales de los rayos de luz emitidos por el monitor. Por tonto que pueda parecer este ejemplo, ayuda a entender de verdad la complejidad del problema.

Estos efectos laterales son extremadamente difíciles de predecir y la técnica ha ido mejorando con el tiempo. Una de las que más me gusta —que tiene que ver más con la seguridad física que con la informática— trascendió este verano. Unos investigadores lograron imprimir en 3D una llave que abría la cerradura en la que se había insertado otra llave grabando el sonido que hacía la otra llave al abrir la puerta. El canal lateral era... ¡el mismo sonido! Menos mal que no llevamos micrófonos en los bolsillos ni vivimos en casas llenas de dispositivos capaces de grabar cualquier sonido...

El tiempo es oro

Los relojes son otro de los candidatos ideales a canal lateral. Está claro que podrían divulgar información por accidente sin que el algoritmo de seguridad lo hubiera previsto. El ataque Raccoon es ejemplo reciente en este sentido, pero hay muchos otros. 

Este ataque aprovecha una deficiencia localizada en una sección bastante profunda de TLS 1.2 y versiones anteriores, en la cual la especificación correspondiente a una variante común exige descartar los ceros a la izquierda de un valor secreto antes de ejecutar un hash. Se trata de suprimir cualquier cero que esté a la izquierda de un número (como 00314159) para mostrarlo en pantalla. Los ataques de tiempos se explican porque calcular el hash es más fácil (y rápido) cuanto más simple sea el número. Así, el atacante puede calcular los ceros a la izquierda y conocer detalles de la entrada secreta simplemente observando el reloj y midiendo la velocidad de TLS.

En los últimos años, cachés de todo tipo han sido el foco de deficiencias de canal lateral en forma de análisis de tiempos. La memoria caché almacena el resultado de cálculos realizados con el objetivo de acelerar los que se hagan en el futuro. De ahí que, por desgracia, se puedan producir fugas de historiales entre entidades que no deberían conocer el historial de otras. 

Fijémonos ahora en la memoria caché de los navegadores web. Una sus funciones principales es mantener los sitios web aislados entre sí: el historial de navegación del sitio A no debe ser accesible por el sitio B. Sin embargo, es posible que el sitio B deduzca si el sitio A está en tu caché cargando un subrecurso del sitio A y observando cuánto tarda en cargar. Si la carga es rápida, el sitio estaba en tu caché, porque ya lo habías visitado antes. Aquí el canal lateral son los tiempos de almacenamiento en caché. Por eso no para de aumentar la lista de tipos de caché a los que las primeras entidades (los sitios que desencadenan la carga) exigen una clave doble. Si bien esto mejora el nivel de privacidad, también reduce la eficacia de la memoria caché.

La idea de que las entradas de caché van dejando un rastro de huellas se asocia a distintas capas; las cachés son dispositivos de implementación útiles que proporcionan incrementos de rendimiento transparentes. No obstante, esa misma transparencia está detrás de la filtración de datos; un problema que no afecta solo a las aplicaciones del lado del cliente, como los navegadores; también a las arquitecturas multiinquilino del lado del servidor. Por ejemplo, Pythia aprovecha la vulnerabilidad creada por el almacenamiento transparente en caché de tablas de página en hardware RDMA, que se utiliza para acceder con rapidez a las unidades de almacenamiento en centros de datos y sistemas informáticos dispuestos en clústeres. El funcionamiento de este ataque es el habitual: dos servicios que deberían estar aislados logran sondear los historiales respectivos sincronizando las respuestas a sus propias peticiones y, así, inferir si las acciones de la otra parte provocan el almacenamiento en caché de algún tipo de información.

La regresión infinita como causa última

Como dije antes, la mayoría de estos problemas se dan por las abstracciones necesarias para dar vida a las tecnologías. Quizá para los diseñadores de sistemas sea tranquilizador llegar al fondo del stack y encontrarse con hardware que se puede tocar, como CPU, chips, memoria RAM o las clásicas arquitecturas de Von Neumann. Sin embargo, todo es un espejismo: lo más probable es que ese hardware lo integren máquinas virtuales con procesadores secundarios propios y microcódigo editable, o que incluso contenga abstracciones importantes para desmenuzar su propia complejidad en partes más manejables. O sea, que nos topamos con la regresión infinita y sus tortugas y el problema de la integración sigue sin resolverse; pero centrémonos en los elementos clave: la CPU, la RAM y la red.

Quizá imaginabas que íbamos a hablar del tristemente célebre desastre de los ataques de ejecución temporal de Spectre. Muchos aspectos te resultarán familiares a estas alturas, ya que en esencia se trata de una vulnerabilidad basada en huellas dejadas en la memoria caché y en el análisis de tiempos. Sin embargo, Spectre eleva el nivel de sofisticación al vincular estos elementos y el comportamiento interno de la CPU. Los defectos en la lógica principal del procesador nunca defraudan, son un regalo caído del cielo para los atacantes. La caché muta en ataque de tipo Spectre cuando se realizan ejecuciones especulativas con fallos. En la práctica, eso significa que la CPU se dedicaría a hacer los cálculos de lo que habría pasado si hubiera ocurrido algo distinto a lo que en realidad sucedió. 

Es una confusión digna del gato de Schrödinger. Sin embargo, el problema es que estas conjeturas de la CPU dejan rastro en la caché del procesador, de manera que cualquier código malicioso podría usarlo mediante ataques de tiempos semejantes a otros ataques de caché que hemos descrito. No se trata de un ataque aislado, sino de una clase de problemas que no para de evolucionar. Para mitigarlos es preciso adoptar un enfoque razonado, holístico y profundo.

En su mayoría, los canales laterales guardan relación con atacantes que logran obtener datos cuya lectura no deberían poder realizar, aunque algunas estrategias parecidas también les permiten escribirlos. Rowhammer es un ejemplo típico de esa variante: un atacante pone en funcionamiento de manera intencionada una parte de la RAM con tanta potencia que los impulsos eléctricos afectan a las partes de la RAM adyacentes; todo ello sin que el sistema operativo o la aplicación pregunte si este procedimiento es seguro. Este tipo de ataque se suele categorizar como ataque por fallos en el que el factor que hace las veces de canal lateral es el acceso a la RAM adyacente.

Veamos un ataque más, por ingenioso y complejo. Me recuerda lo importante que es mantener en todo momento la mente abierta respecto a lo que creemos saber. El ataque no se apoya en algo tan trivial como una caché compartida entre atacante y víctima, sino que se centra en la ruta compartida de acceso a la red que ambos quizás utilicen a través del enrutador inalámbrico que hay en el hogar de la víctima. 

Muchos creen que TCP no es seguro frente a los ataques que están canalizados en la ruta de acceso, pero sí frente a ataques canalizados fuera de dicha ruta. Si el atacante no puede ver el tráfico que hay entre el cliente y el servidor (o sea, si está fuera de la ruta de transporte), en teoría no puede manipular la conexión. El secreto que no está disponible fuera de la ruta de acceso son los 48 bits que componen el número de puerto de cliente y el número de secuencia de TCP. Con esta información, los atacantes pueden inyectar los datos que quieran sin dificultad alguna e incluso terminar una conexión canalizada fuera de la ruta de acceso. 

La clave del ataque es que la víctima reaccione poniendo en marcha respuestas de distinta intensidad contra los sondeos con los que el atacante trata de averiguar el secreto. Estos sondeos determinan si el ataque ha sido preciso, muy impreciso o aproximado. En condiciones normales, eso no tendría importancia, porque los atacantes no pueden ver las respuestas si están fuera de la ruta de acceso. Sin embargo, si crean una conexión separada con la víctima de manera simultánea a los ataques, pueden observar el impacto de los mensajes ocultos en los recursos compartidos, como el enrutador wifi. Los mensajes más pesados que circulan por el canal externo a la ruta de acceso ralentizan de forma observable los mensajes del canal ubicado dentro de la ruta. Así se obtiene suficiente información para inferir a qué categoría corresponde la suposición, lo que permite a los atacantes localizar el espacio secreto rápidamente por ensayo y error. ¡Qué ingenioso! Ni siquiera hace falta explorar todo el espacio buscando una correspondencia exacta.

Conclusión

Los ejemplos anteriores ilustran algunos de los aspectos que quizás no estén claros cuando iniciamos un proyecto por cuenta propia. Todos —y solo son una muestra de la infinidad de posibilidades— son sumamente ingeniosos, no puedo más que expresar mi admiración. Sin embargo, me gustaría poner en valor el lado creativo del diseño de aplicaciones e invitarte a sacar el máximo partido de una plataforma de edge cloud integrada que está pensada, escalada y mantenida para respaldar ese estilo de aplicación del modo más sencillo posible. 

Proteger a las aplicaciones frente a estas deficiencias y otras vulnerabilidades similares es un proceso, no una acción aislada. Es necesario reflexionar con detenimiento sobre el contexto íntegro de la aplicación; documentar las exposiciones; implementar mitigaciones donde sea posible; definir interfaces binarias de aplicaciones (ABI) que tengan en cuenta el tiempo y el espacio, así como definiciones de datos; y corregir y repasar sin descanso. Si solo te centras en el lanzamiento, acabarás sufriendo vulnerabilidades. Estar alerta tampoco es suficiente: incluso aunque apliques parches de seguridad, puedes pasar por alto combinaciones ambientales que puedan dar paso a las vulnerabilidades. Además, sabemos que si desarrollamos solo componentes concretos, no vemos más que una parte del problema. Por todos estos motivos, personalizar una plataforma es un trabajo a jornada completa.