{"id":25052,"date":"2022-07-20T13:43:29","date_gmt":"2022-07-20T19:43:29","guid":{"rendered":"https:\/\/latam.kaspersky.com\/blog\/?p=25052"},"modified":"2022-07-20T13:43:29","modified_gmt":"2022-07-20T19:43:29","slug":"hertzbleed-attack","status":"publish","type":"post","link":"https:\/\/latam.kaspersky.com\/blog\/hertzbleed-attack\/25052\/","title":{"rendered":"\u00bfQu\u00e9 es Hertzbleed y qu\u00e9 lo caracteriza?"},"content":{"rendered":"

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

Podemos clasificar este m\u00e9todo como un ataque de hardware<\/em>, ya que explota vulnerabilidades u otros puntos d\u00e9biles espec\u00edficos en el hardware<\/em>. Existen varios ataques de este tipo, pero la mayor\u00eda requieren acceso directo a la computadora de destino o solo a un chip espec\u00edfico, \u00a1pero Hertzbleed es capaz de operar a distancia!<\/p>\n

El estudio es muy interesante y, a pesar de ser complejo, puede resumirse en t\u00e9rminos m\u00e1s simples. Pero, para comprender al menos de forma b\u00e1sica sus puntos clave, es necesario un poco de conocimiento previo. Por lo que decidimos hacer ambas cosas: publicar una explicaci\u00f3n sencilla de Hertzbleed y otra un tanto m\u00e1s compleja (sin hacer uso de elaborados gr\u00e1ficos o c\u00e1lculos ininteligibles).<\/p>\n

Como es usual, Hertzbleed tiene su propia web y logotipo. El logotipo captura la esencia b\u00e1sica de la vulnerabilidad: la alteraci\u00f3n de la frecuencia del CPU provoca filtraciones. <a href=\"https:\/\/www.hertzbleed.com\/ \" target=\"_blank\">Source<\/a>.

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

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

Para ahorrar energ\u00eda, las computadoras modernas no mantienen la misma frecuencia en todo momento. En cambio, la frecuencia (de igual maneras que el voltaje de la CPU) se ajusta de forma autom\u00e1tica de acuerdo con su carga. Cuando hay pocas tareas, la frecuencia suele 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 varios n\u00facleos del CPU puede pasar 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 que la frecuencia cambie, esta puede ser menor, por ejemplo, si la computadora se sobrecalienta.<\/p>\n

Los investigadores aprovecharon dicha funcionalidad nativa para medir el estado del CPU al momento de ejecutar un programa de cifrado de datos y conseguir robar informaci\u00f3n importante. Encontraron una caracter\u00edstica en un algoritmo de cifrado moderno que \u201cobliga\u201d a la computadora a incrementar la frecuencia al procesar ciertos datos. Mientras la frecuencia aumenta, los datos se procesan de forma m\u00e1s r\u00e1pida y la computadora atacada responde a las solicitudes con mayor rapidez. Al medir el tiempo de respuesta, los investigadores pudieron reconstruir la clave secreta de cifrado. Al tener esta clave, te\u00f3ricamente pueden interceptar y descifrar los datos intercambiados entre el sistema objeto del ataque, por ejemplo, y otras computadoras en una red privada virtual. Todo esto sin que sea posible registrar el \u201crobo\u201d de la clave.<\/p>\n

Hertzbleed desarrolla la idea de los ataques de hardware<\/em> mediante canales laterales. Adem\u00e1s, introduce de forma te\u00f3rica la posibilidad de robar datos en remoto, enviando solicitudes a trav\u00e9s de la red a las potenciales v\u00edctimas. De momento esto sigue siendo un ejercicio meramente te\u00f3rico que se encuentra en la b\u00fasqueda de vulnerabilidades complejas en las computadoras modernas con CPU. No obtsnate, hay una posibilidad en el futuro de que estos ataques sean \u201csimplificados\u201d.<\/p>\n

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

Los ataques de canal lateral<\/a> se llevan a cabo observando el funcionamiento de un solo chip o de una computadora de forma indirecta. El m\u00e9todo cl\u00e1sico de ataque de canal lateral implica observar variaciones en la corriente el\u00e9ctrica consumida por el chip. Por ejemplo, si el chip se encuentra cifrando datos mediante una clave secreta, los cambios en el consumo de energ\u00eda en algunos casos pueden ser usados para reconstruir la clave.<\/p>\n

Los canales laterales pueden basarse \u200b\u200btanto en software<\/em> como en hardware<\/em>. Spectre<\/a>, el conocido estudio, usa un canal lateral de este tipo directamente en la computadora, explotando funciones de ejecuci\u00f3n especulativa para robar informaci\u00f3n secreta. Adem\u00e1s, no siempre se necesita conectar un volt\u00edmetro en la computadora para monitorizar el consumo de energ\u00eda del 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 veamos el ajuste din\u00e1mico de la frecuencia de la computadora. Esto se puede gracias a la t\u00e9cnica de escalado din\u00e1mico de voltaje y frecuencia (DVFS). De hecho, junto con la frecuencia, el voltaje del CPU tambi\u00e9n var\u00eda para garantizar condiciones de funcionamiento \u00f3ptimas (un consumo de energ\u00eda bajo, con poca carga y un funcionamiento estable a m\u00e1xima capacidad). Los investigadores describen detalladamente c\u00f3mo llevaron a cabo numerosos experimentos DVFS en procesadores Intel (una tecnolog\u00eda que la propia Intel llama Turbo Boost). Cargaron la computadora con muy poca carga (c\u00e1lculos aritm\u00e9ticos b\u00e1sicos) y observaron c\u00f3mo cambiaba la frecuencia. Observaron varios patrones: haci\u00e9ndolo muy simple, con un conjunto de datos de c\u00e1lculo, la frecuencia del CPU sol\u00eda aumentar, pero con otro no. Adem\u00e1s, una mayor frecuencia supuso c\u00e1lculos m\u00e1s r\u00e1pidos y, por ende, un resultado m\u00e1s veloz.<\/p>\n

Veamos un tercer t\u00e9rmino t\u00e9cnico que es relevante tambi\u00e9n en todo esto: la programaci\u00f3n en tiempo constante. Esto es importante cuando se trata de implementar en un programa un algoritmo de cifrado. Por ejemplo, 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. Es como si intent\u00e1ramos abrir una caja fuerte cerrada con un c\u00f3digo digital secreto, el cual se comporta de manera diferente si las secuencias de n\u00fameros que fueron introducidas son casi correctas, d\u00e1ndonos pistas de \u201ccalientes\u201d y \u201cfr\u00edas\u201d. Gran parte de los programas que implementan algoritmos de cifrado cuentan con un mecanismo protector que evita intentos de determinar la clave de esta manera, 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 del CPU rompe el principio de la programaci\u00f3n en tiempo real, es decir, la no variaci\u00f3n en el tiempo de cifrado. Los autores demuestran c\u00f3mo aprovechar esto eligiendo 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 mediante un canal lateral, es decir, la fuga de datos se produce debido a un cambio en la frecuencia de la CPU y, por ende, 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 un poco m\u00e1s compleja\u201d de Hertzbleed, descubrimos aproximadamente\u2026 un 0,05 % de la informaci\u00f3n real presentada por los investigadores. Hay matices infinitos que igual tienen relevancia para comprender su funcionamiento. Los investigadores utilizaron, de forma particular, una caracter\u00edstica del algoritmo de encapsulaci\u00f3n de claves SIKE para crear las condiciones necesarias para las fugas de datos mediante el tiempo de respuesta o el cambio de frecuencia. Esto se parece al ataque Spectre que mencionamos antes, el cual requiere crear condiciones especiales en el software<\/em> atacado para permitir el robo de datos importantes. Seg\u00fan los resultados del estudio, estrictamente hablando, es imposible decir sin equivocarse d\u00f3nde se encuentra la vulnerabilidad, si en la computadora o en el programa.<\/p>\n

Y esnecesario mencionar un aspecto evidente de la implementaci\u00f3n: a pesar de que 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 era siempre constante seg\u00fan los inputs<\/em>. Pero \u00bfqu\u00e9 pasa si la computadora ejecuta otras tareas que afectan tambi\u00e9n al tiempo de respuesta y hacen que los datos sean m\u00e1s alarmantes? Incluso en circunstancias tan id\u00f3neas, la reconstrucci\u00f3n de la clave de cifrado (en dos experimentos distintos) tard\u00f3 36 y 89 horas. Durante este tiempo, se enviaron al programa de cifrado, miles de solicitudes por segundo, 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 demasiado tiempo!<\/p>\n

Todo esto 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 era solo de las computadoras. Pero Intel<\/a> y AMD<\/a> informaron que no tienen planes de lanzar alguna 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

No obstante, este estudio es de suma importancia. Como pas\u00f3 con Spectre en 2018, este no ser\u00e1 el \u00faltimo ataque de este nuevo tipo. Si se puede mostrar un ejemplo de fuga de datos a trav\u00e9s del ajuste din\u00e1mico de la frecuencia del CPU, es seguro que otros vendr\u00e1n. De igual manera, es un campo de trabajo importante para los cript\u00f3grafos. SIKE es un algoritmo sumamente 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

Generalmente, como suele pasar en estos estudios, dicho ataque fue \u201cdescubierto\u201d pero no pudo ser implementado de forma completa ni exitosa. Los desarrolladores de CPUs 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 investigadores, u otros, localicen 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 dichas proporciones. Pero esto, y el estudio de Hertzbleed (y nuestro intento por describirlo m\u00e1s f\u00e1cilmente) 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 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, publicar\u00e1n otro informe con ligeros avances y que aclare el anterior. Y esa conclusi\u00f3n es positiva, ya que en realidad \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":25053,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2795,3539,3540],"tags":[5798,3250,647],"class_list":{"0":"post-25052","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-mx","url":"https:\/\/latam.kaspersky.com\/blog\/hertzbleed-attack\/25052\/"},{"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","url":"https:\/\/www.kaspersky.es\/blog\/hertzbleed-attack\/27390\/"},{"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:\/\/latam.kaspersky.com\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25052","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=25052"}],"version-history":[{"count":2,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25052\/revisions"}],"predecessor-version":[{"id":25056,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/25052\/revisions\/25056"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/25053"}],"wp:attachment":[{"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=25052"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=25052"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/latam.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=25052"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}