{"id":27390,"date":"2022-07-18T16:27:18","date_gmt":"2022-07-18T14:27:18","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=27390"},"modified":"2022-07-18T16:27:18","modified_gmt":"2022-07-18T14:27:18","slug":"hertzbleed-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/hertzbleed-attack\/27390\/","title":{"rendered":"\u00bfQu\u00e9 es Hertzbleed y en qu\u00e9 se caracteriza?"},"content":{"rendered":"

En junio, los investigadores de tres universidades estadounidenses publicaron<\/a> un art\u00edculo que describe un ataque real que aprovecha que los cambios de frecuencia de la CPU dependen de la carga (un comportamiento est\u00e1ndar de las CPU modernas). La frecuencia de la CPU se mide en hercios, de ah\u00ed viene el nombre de Hertzbleed que sugiere que un cambio en esta frecuencia conduce a la fuga de datos.<\/p>\n

Este m\u00e9todo se puede clasificar como un ataque de hardware<\/em>, ya que explota vulnerabilidades u otros puntos d\u00e9biles espec\u00edficos en el hardware<\/em>. Hay muchos ataques de este tipo, pero casi todos requieren acceso directo al ordenador de destino o solo a un chip espec\u00edfico, \u00a1pero Hertzbleed puede operar de forma remota!<\/p>\n

El estudio es muy interesante y, a pesar de su complejidad, se puede resumir en t\u00e9rminos m\u00e1s sencillos. Pero, para comprender al menos de forma b\u00e1sica sus puntos clave, se requiere un poco de conocimiento previo. As\u00ed que decidimos hacer ambas cosas: publicar una explicaci\u00f3n simple de Hertzbleed y otra un poco m\u00e1s compleja (aunque tambi\u00e9n sin hacer uso de elaborados gr\u00e1ficos o c\u00e1lculos ininteligibles).<\/p>\n

\"Como

Como ya es habitual, Hertzbleed tiene su propia web y logotipo. El logotipo captura la esencia b\u00e1sica de la vulnerabilidad: la alteraci\u00f3n de la frecuencia de la CPU provoca filtraciones. Fuente<\/a><\/p><\/div>\n

La explicaci\u00f3n sencilla<\/h2>\n

Para ahorrar energ\u00eda, las CPU modernas no mantienen la misma frecuencia en todo momento. En cambio, la frecuencia (as\u00ed como el voltaje de la CPU) se ajusta autom\u00e1ticamente seg\u00fan su carga. Cuando hay pocas tareas, la frecuencia puede ser muy baja, por ejemplo, de 900 MHz en lugar de los 3,2 GHz nominales. Si hay muchas tareas, la frecuencia de uno o todos los n\u00facleos de la CPU se puede elevar por encima de la frecuencia est\u00e1ndar. En la pr\u00e1ctica, la carga (el n\u00famero y la complejidad de las tareas) no es el \u00fanico criterio para cambiar la frecuencia, esta puede ser menor, por ejemplo, si la CPU se sobrecalienta.<\/p>\n

Los investigadores lograron aprovechar esta funcionalidad nativa para medir el estado de la CPU en el momento de ejecutar un programa de cifrado de datos y conseguir robar informaci\u00f3n sensible. Encontraron una caracter\u00edstica de un algoritmo de cifrado moderno que \u201cobliga\u201d a la CPU a aumentar la frecuencia al procesar ciertos datos. A medida que aumenta la frecuencia, los datos se procesan m\u00e1s r\u00e1pidamente y el ordenador atacado responde a las solicitudes con mayor rapidez. Al medir el tiempo de respuesta, los investigadores pudieron reconstruir la clave secreta de cifrado. Con esta clave en su poder, en teor\u00eda pueden interceptar y descifrar los datos intercambiados entre el sistema objeto del ataque, por ejemplo, y otros ordenadores en una red privada virtual. Y todo ello sin ninguna posibilidad de registrar el \u201crobo\u201d de la clave.<\/p>\n

Hertzbleed desarrolla la idea de los ataques de hardware<\/em> a trav\u00e9s de los llamados canales laterales. Adem\u00e1s, tambi\u00e9n introduce de forma te\u00f3rica la posibilidad de robar datos en remoto, enviando solicitudes a las v\u00edctimas potenciales a trav\u00e9s de la red. De momento esto sigue siendo un ejercicio puramente te\u00f3rico que se encuentra en la b\u00fasqueda de vulnerabilidades complejas en las CPU modernas. Sin embargo, es muy posible que en el futuro estos ataques sean \u201csimplificados\u201d.<\/p>\n

Una explicaci\u00f3n algo m\u00e1s compleja<\/h2>\n

Los ataques de canal lateral<\/a> se realizan observando indirectamente el funcionamiento de un solo chip o de un ordenador completo. El m\u00e9todo cl\u00e1sico de ataque de canal lateral implica observar variaciones en la corriente el\u00e9ctrica consumida por el chip. Si el chip est\u00e1 ocupado cifrando datos mediante una clave secreta, por ejemplo, los cambios en el consumo de energ\u00eda en algunos casos pueden usarse para reconstruir la clave.<\/p>\n

Los canales laterales pueden basarse \u200b\u200btanto en software<\/em> como en hardware<\/em>. El conocido estudio de Spectre<\/a> utiliza un canal lateral de este tipo directamente en la CPU, explotando funciones de ejecuci\u00f3n especulativa para robar informaci\u00f3n confidencial. Adem\u00e1s, a veces no es necesario conectar un volt\u00edmetro en el ordenador para monitorizar el consumo de energ\u00eda de la CPU, ya que suele tener uno incorporado. Ya se ha desarrollado un ataque relacionado con Hertzbleed usando un sistema para monitorizar el consumo de energ\u00eda promedio de los procesadores Intel.<\/p>\n

Ahora echemos un vistazo al ajuste din\u00e1mico de la frecuencia de la CPU. Esto es posible gracias a la t\u00e9cnica de escalado din\u00e1mico de voltaje y frecuencia (DVFS). De hecho, junto con la frecuencia, el voltaje de la CPU tambi\u00e9n var\u00eda para garantizar condiciones \u00f3ptimas de funcionamiento (un bajo consumo de energ\u00eda con poca carga y un funcionamiento estable a m\u00e1xima capacidad). Los investigadores describen con cierto detalle c\u00f3mo llevaron a cabo numerosos experimentos DVFS en procesadores Intel (una tecnolog\u00eda que la propia Intel llama Turbo Boost). Cargaron la CPU con una carga insignificante (c\u00e1lculos aritm\u00e9ticos b\u00e1sicos) y observaron c\u00f3mo cambiaba la frecuencia. Surgieron varios patrones: simplific\u00e1ndolo mucho, con un conjunto de datos de c\u00e1lculo, la frecuencia de la CPU tend\u00eda a aumentar, pero no con otro. Adem\u00e1s, una mayor frecuencia supuso c\u00e1lculos m\u00e1s r\u00e1pidos y, por lo tanto, un resultado m\u00e1s r\u00e1pido.<\/p>\n

Veamos un tercer t\u00e9rmino t\u00e9cnico que tambi\u00e9n es relevante en todo esto: la programaci\u00f3n en tiempo constante. Esto es importante cuando se trata de implementar en un programa un algoritmo de cifrado. Supongamos que tenemos un programa que recibe un mensaje determinado y genera el mismo mensaje, pero cifrado. Podemos introducir datos, pero no conocemos la clave secreta de cifrado, que, mientras, estamos tratando de establecer observando el tiempo de ejecuci\u00f3n, ya que el tiempo de ejecuci\u00f3n de la funci\u00f3n depende de los datos de entrada. Esto podr\u00eda ser como intentar abrir una caja fuerte cerrada con un c\u00f3digo digital secreto que se comporta de manera ligeramente diferente si las secuencias de n\u00fameros que se han introducido son casi correctas, d\u00e1ndonos pistas de \u201ccalientes\u201d y \u201cfr\u00edas\u201d. La mayor\u00eda de los programas que implementan algoritmos de cifrado cuentan con un mecanismo de protecci\u00f3n para evitar intentos de determinar la clave de esta forma, lo que es el mismo principio de la programaci\u00f3n en tiempo constante.<\/p>\n

El resultado m\u00e1s importante del estudio de Hertzbleed es que el ajuste din\u00e1mico de la frecuencia de la CPU rompe el principio de la programaci\u00f3n en tiempo constante, es decir, la no variaci\u00f3n en el tiempo de cifrado. Los autores mostraron c\u00f3mo aprovechar este hecho cogiendo un sistema con un software <\/em>de cifrado de datos real e introduciendo una secuencia de caracteres que el programa trat\u00f3 de descifrar. Los mensajes se eligieron para crear condiciones que permitieran a un atacante reconstruir la clave de cifrado. Adem\u00e1s, la clave se extrae a trav\u00e9s de un canal lateral, es decir, la fuga de datos se produce debido a un cambio en la frecuencia de la CPU y, por lo tanto, en el tiempo de ejecuci\u00f3n del programa y el tiempo de respuesta a la solicitud del atacante.<\/p>\n

Faltan consecuencias<\/h2>\n

En nuestra \u201cexplicaci\u00f3n algo m\u00e1s compleja\u201d de Hertzbleed, hemos cubierto aproximadamente\u2026 un 0,05 % de la informaci\u00f3n real presentada por los investigadores. Hay innumerables matices que tambi\u00e9n son relevantes para comprender c\u00f3mo funciona. En particular, los investigadores utilizaron una caracter\u00edstica del algoritmo de encapsulaci\u00f3n de claves SIKE para crear las condiciones en las que fueran posibles las fugas de datos mediante el tiempo de respuesta o el cambio de frecuencia. Esto es similar al ataque Spectre mencionado anteriormente, que requiere crear condiciones especiales en el software<\/em> atacado para permitir el robo de datos importantes. Estrictamente hablando, seg\u00fan los resultados del estudio, es imposible decir de manera inequ\u00edvoca d\u00f3nde se encuentra la vulnerabilidad, si en la CPU o en el programa.<\/p>\n

Y debemos mencionar un aspecto evidente de la implementaci\u00f3n: aunque los investigadores demostraron un ataque real, pr\u00e1ctico (no te\u00f3rico), lo llevaron a cabo en condiciones controladas. La variaci\u00f3n en el tiempo de respuesta seg\u00fan los inputs<\/em> era siempre constante. Pero \u00bfqu\u00e9 pasa si la CPU est\u00e1 ejecutando otras tareas simult\u00e1neas que afectan tambi\u00e9n al tiempo de respuesta y hacen que los datos sean m\u00e1s escandalosos? Por \u00faltimo, incluso en circunstancias tan id\u00f3neas, la reconstrucci\u00f3n de la clave de cifrado (en dos experimentos diferentes) tard\u00f3 36 y 89 horas. Durante este tiempo, se enviaron miles de solicitudes por segundo al programa de cifrado, siendo la \u00fanica forma de garantizar que todas las funciones necesarias para el funcionamiento del software<\/em> y el hardware<\/em> estuvieran alineadas para producir la fuga de datos. \u00a1Eso es much\u00edsimo tiempo!<\/p>\n

Todo ello hizo que la reacci\u00f3n al estudio fuera ambigua. Por un lado, a las vulnerabilidades se les asignaron los identificadores habituales: CVE-2022-23823 para Intel y CVE-2022-24436 para AMD. Parecer\u00eda que el problema estaba finalmente en las CPU. Pero Intel<\/a> y AMD<\/a> han informado de que no tienen planes de lanzar ninguna actualizaci\u00f3n para los sistemas afectados (para Intel, las CPU de 8\u00aa a 11\u00aa generaci\u00f3n). De hecho, el cambio en el algoritmo SIKE hizo imposible el ataque demostrado. Microsoft y Cloudflare, que utilizan SIKE como uno de los elementos de sus sistemas de cifrado, actualizaron su propio software<\/em>.<\/p>\n

Sin embargo, este estudio tiene una gran importancia. Como ocurri\u00f3 con Spectre en 2018, este no ser\u00e1 el \u00faltimo de esta nueva clase de ataques. Si se puede mostrar un ejemplo de fuga de datos a trav\u00e9s del ajuste din\u00e1mico de la frecuencia de la CPU, seguramente vendr\u00e1n otros. Tambi\u00e9n es un importante campo de trabajo para los cript\u00f3grafos. SIKE es un algoritmo bastante reciente, candidato al t\u00edtulo de \u201csoluci\u00f3n de cifrado poscu\u00e1ntica\u201d. De hecho, se analiz\u00f3 su robustez contra cualquier ataque de canal lateral y demostr\u00f3 ser bastante resistente. Pero el estudio de Hertzbleed muestra que han aparecido nuevas opciones.<\/p>\n

En general, como suele suceder con este tipo de estudios, este ataque fue \u201cdescubierto\u201d pero realmente no pudo implementarse de forma completa y exitosa. Los desarrolladores de CPU y de programas que son particularmente sensibles a los hackeos sacar\u00e1n sus propias conclusiones y realizar\u00e1n cambios antes de que sea posible efectuar un robo. Pero existe una peque\u00f1a posibilidad de que la pr\u00f3xima vez estos u otros investigadores encuentren algo que permita a los atacantes, por ejemplo, interceptar el tr\u00e1fico de red cifrado o descifrar el cifrado permaneciendo en el anonimato. Con un poco de imaginaci\u00f3n es posible llevar el esquema representado en este estudio a tales proporciones. Pero esto est\u00e1 por demostrar, y el estudio de Hertzbleed (y nuestro intento por describirlo de forma sencilla) muestra que no se trata de una tarea f\u00e1cil. Para las vulnerabilidades de la clase Spectre, no se ha demostrado este avance<\/a> en un periodo de m\u00e1s de cuatro a\u00f1os. Aqu\u00ed, tambi\u00e9n, lo m\u00e1s probable es que las cosas sigan igual: dentro de un a\u00f1o m\u00e1s o menos, se publicar\u00e1 otro informe con ligeros avances y que aclare el anterior. Y esa es una conclusi\u00f3n positiva ya que realmente \u00a1ya tenemos suficientes problemas con la seguridad de la informaci\u00f3n!<\/p>\n","protected":false},"excerpt":{"rendered":"

Uno de los estudios de seguridad de la informaci\u00f3n m\u00e1s complejos de los \u00faltimos tiempos, pero f\u00e1ciles de entender.<\/p>\n","protected":false},"author":665,"featured_media":27392,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2202,2754,2755],"tags":[435,2500,784],"class_list":{"0":"post-27390","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-cpu","11":"tag-spectre","12":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/hertzbleed-attack\/27390\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/hertzbleed-attack\/24346\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/hertzbleed-attack\/19812\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/hertzbleed-attack\/26719\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/hertzbleed-attack\/25052\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/hertzbleed-attack\/33493\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/hertzbleed-attack\/10883\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/hertzbleed-attack\/44824\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/hertzbleed-attack\/19160\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/hertzbleed-attack\/19724\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/hertzbleed-attack\/29043\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/hertzbleed-attack\/25222\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/hertzbleed-attack\/30710\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/hertzbleed-attack\/30458\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/27390","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=27390"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/27390\/revisions"}],"predecessor-version":[{"id":27394,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/27390\/revisions\/27394"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/27392"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=27390"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=27390"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=27390"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}