{"id":19724,"date":"2022-07-20T16:38:34","date_gmt":"2022-07-20T19:38:34","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=19724"},"modified":"2022-07-20T16:38:34","modified_gmt":"2022-07-20T19:38:34","slug":"hertzbleed-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/hertzbleed-attack\/19724\/","title":{"rendered":"O que \u00e9 o Hertzbleed e qual a grande novidade por tr\u00e1s dele?"},"content":{"rendered":"

Em junho, pesquisadores de tr\u00eas universidades americanas publicaram<\/a> um artigo descrevendo um ataque real que explora as mudan\u00e7as de frequ\u00eancia da CPU e suas depend\u00eancias da carga (comportamento padr\u00e3o para CPUs modernas). A frequ\u00eancia da CPU \u00e9 medida em hertz, da\u00ed o nome Hertzbleed (ou sangramento de Hertz, em livre tradu\u00e7\u00e3o), sugerindo que uma mudan\u00e7a nessa frequ\u00eancia leva ao vazamento de dados.<\/p>\n

Este m\u00e9todo pode ser classificado como um ataque de hardware; ou seja, que explora vulnerabilidades ou outras fraquezas espec\u00edficas em componentes f\u00edsicos. Existem muitos ataques desse tipo, mas quase todos exigem acesso direto ao computador de destino \u2014 ou apenas a um chip espec\u00edfico. Mas o Hertzbleed pode operar remotamente!<\/p>\n

O estudo \u00e9 de grande interesse e, apesar de sua complexidade, pode ser resumido em termos did\u00e1ticos para leigos. Mas para pelo menos uma compreens\u00e3o b\u00e1sica de seus pontos mais sutis, \u00e9 necess\u00e1rio um pouco de conhecimento pr\u00e9vio. Ent\u00e3o decidimos fazer as duas coisas: postar uma explica\u00e7\u00e3o simples do Hertzbleed e outra um pouco mais aprofundada (mas ainda sem gr\u00e1ficos extravagantes ou c\u00e1lculos abstrusos).<\/p>\n

Seguindo a moda, o Hertzbleed tem seu pr\u00f3prio site e logotipo. O logotipo captura a ess\u00eancia b\u00e1sica da vulnerabilidade: alterar a frequ\u00eancia da CPU que leva a vazamentos. <a href=\"https:\/\/www.hertzbleed.com\/ \" target=\"_blank\">Fonte<\/a>.

Seguindo a moda, o Hertzbleed tem seu pr\u00f3prio site e logotipo. O logotipo captura a ess\u00eancia b\u00e1sica da vulnerabilidade: alterar a frequ\u00eancia da CPU que leva a vazamentos. Fonte<\/a>.<\/p><\/div>\n

A explica\u00e7\u00e3o simples<\/h2>\n

Para economizar energia, as CPUs atuais n\u00e3o mant\u00eam a mesma frequ\u00eancia o tempo todo. Em vez disso, a frequ\u00eancia (assim como a tens\u00e3o da CPU) se ajusta automaticamente de acordo com sua carga. Quando as tarefas s\u00e3o poucas, a frequ\u00eancia pode ser muito baixa \u2014 por exemplo, 900MHz em vez dos 3,2GHz nominais. Se houver muitas tarefas, a frequ\u00eancia de um ou de todos os n\u00facleos da CPU pode ser aumentada acima da linha de base. Na pr\u00e1tica, a carga (o n\u00famero e a complexidade das tarefas) n\u00e3o \u00e9 o \u00fanico crit\u00e9rio para alterar a frequ\u00eancia. Por exemplo, pode ser reduzido se a CPU apresentar superaquecimento.<\/p>\n

Os pesquisadores conseguiram aproveitar essa funcionalidade nativa para medir o estado da CPU quando ela estava executando um programa de criptografia de dados e, assim, roubar informa\u00e7\u00f5es confidenciais. Eles encontraram um recurso de um algoritmo de criptografia moderno que \u201cfor\u00e7a\u201d a CPU a aumentar a frequ\u00eancia ao processar determinados dados. \u00c0 medida que a frequ\u00eancia aumenta, os dados s\u00e3o processados \u200b\u200bmais rapidamente e o computador atacado responde \u00e0s solicita\u00e7\u00f5es mais rapidamente. Ao medir o tempo de resposta, os pesquisadores conseguiram reconstruir a chave de criptografia secreta. Armados com essa chave, eles podem teoricamente interceptar e descriptografar dados trocados pelo sistema de destino, por exemplo, com outros computadores em uma rede privada virtual. E tudo isso sem qualquer chance de registrar o \u201croubo\u201d da chave.<\/p>\n

Hertzbleed desenvolve a ideia de ataques de hardware atrav\u00e9s dos chamados canais laterais. Ao mesmo tempo, introduz a possibilidade te\u00f3rica de roubar dados remotamente \u2014 enviando solicita\u00e7\u00f5es para a v\u00edtima em potencial pela rede. Mas, por enquanto, isso continua sendo um exerc\u00edcio puramente te\u00f3rico na busca de vulnerabilidades complexas em CPUs modernas. No entanto, \u00e9 bem poss\u00edvel que no futuro esses ataques sejam \u201csimplificados\u201d.<\/p>\n

Uma explica\u00e7\u00e3o um pouco mais complexa<\/h2>\n

Os ataques de canais laterais<\/a> s\u00e3o realizados observando indiretamente a opera\u00e7\u00e3o de um \u00fanico chip ou de um computador inteiro. O m\u00e9todo cl\u00e1ssico de ataque de canal lateral envolve a observa\u00e7\u00e3o de varia\u00e7\u00f5es na corrente el\u00e9trica consumida pelo chip. Se o chip estiver ocupado criptografando dados usando uma chave secreta, por exemplo, mudan\u00e7as no consumo de energia em alguns casos podem ser usadas para reconstruir a chave.<\/p>\n

Os canais laterais podem ser baseados em software e tamb\u00e9m em hardware. O conhecido estudo Spectre<\/a> usa esse canal lateral diretamente na CPU, explorando recursos de execu\u00e7\u00e3o especulativa para roubar informa\u00e7\u00f5es confidenciais. Al\u00e9m disso, \u00e0s vezes n\u00e3o h\u00e1 necessidade de conectar um volt\u00edmetro ao computador para monitorar o consumo de energia da CPU, porque muitas vezes eles t\u00eam um embutido. Usando um sistema para monitorar o consumo m\u00e9dio de energia dos processadores Intel, um ataque relacionado ao Hertzbleed j\u00e1 foi desenvolvido.<\/p>\n

Agora vamos dar uma olhada no ajuste din\u00e2mico da frequ\u00eancia da CPU<\/em>. Isso \u00e9 poss\u00edvel pela t\u00e9cnica DVFS; na tradu\u00e7\u00e3o da sigla, significa tens\u00e3o din\u00e2mica e escala de frequ\u00eancia. De fato, juntamente com a frequ\u00eancia, a voltagem da CPU tamb\u00e9m varia para garantir condi\u00e7\u00f5es operacionais ideais (baixo consumo de energia em baixa carga, opera\u00e7\u00e3o est\u00e1vel em capacidade m\u00e1xima). Os pesquisadores descrevem com alguns detalhes como eles realizaram v\u00e1rios experimentos DVFS em processadores Intel (a pr\u00f3pria Intel chama essa tecnologia de Turbo Boost). Eles sobrecarregaram a CPU com uma carga insignificante (c\u00e1lculos aritm\u00e9ticos b\u00e1sicos) e observaram como a frequ\u00eancia mudou. V\u00e1rios padr\u00f5es surgiram: para simplificar ao m\u00e1ximo, com um determinado conjunto de dados de c\u00e1lculo, a frequ\u00eancia da CPU tendia a aumentar \u2013 mas com outro conjunto, n\u00e3o. Al\u00e9m disso, uma frequ\u00eancia aumentada levou a c\u00e1lculos mais r\u00e1pidos e, consequentemente, a um resultado mais r\u00e1pido.<\/p>\n

Precisamos entender um terceiro termo t\u00e9cnico relevante para tudo isso: programa\u00e7\u00e3o em tempo constante<\/em>. Isso \u00e9 importante quando se trata de implementar um algoritmo de criptografia em um programa. Suponha que temos um programa que recebe uma determinada frase como entrada e gera a mesma frase, mas criptografada. Podemos inserir dados, mas n\u00e3o conhecemos a chave de criptografia secreta, que, entretanto, estamos tentando estabelecer observando o tempo de execu\u00e7\u00e3o, pois o tempo de execu\u00e7\u00e3o da fun\u00e7\u00e3o depende dos dados de entrada. Isso \u00e9 compar\u00e1vel a tentar arrombar um cofre trancado com um c\u00f3digo digital secreto que reage de maneira ligeiramente diferente a sequ\u00eancias de n\u00fameros que est\u00e3o quase certos, dando-nos pistas de \u201cquente\u201d e \u201cfrio\u201d. A maioria dos programas que implementam algoritmos de criptografia apresenta um mecanismo de prote\u00e7\u00e3o para evitar tentativas de determinar a chave dessa maneira \u2014 o pr\u00f3prio princ\u00edpio da programa\u00e7\u00e3o em tempo constante.<\/p>\n

O resultado mais importante do estudo da Hertzbleed \u00e9 que o ajuste din\u00e2mico da frequ\u00eancia da CPU<\/em> quebra o princ\u00edpio da programa\u00e7\u00e3o em tempo constante<\/em> \u2013 ou seja, invari\u00e2ncia de tempo na criptografia. E os autores mostraram como tirar proveito desse fato. Eles fizeram isso pegando um sistema com software de criptografia de dados da vida real e alimentando uma sequ\u00eancia de caracteres, que o programa tentou descriptografar. As entradas foram escolhidas para criar condi\u00e7\u00f5es que permitissem a um invasor reconstruir a chave de criptografia. Al\u00e9m disso, a chave \u00e9 extra\u00edda por meio de um canal lateral<\/em> \u2014 ou seja, o vazamento de dados ocorre devido a uma altera\u00e7\u00e3o na frequ\u00eancia da CPU e, consequentemente, no tempo de execu\u00e7\u00e3o do programa e no tempo de resposta \u00e0 solicita\u00e7\u00e3o do invasor.<\/p>\n

As consequ\u00eancias<\/h2>\n

Em nossa \u201cexplica\u00e7\u00e3o um pouco mais complicada\u201d do Hertzbleed, abordamos aproximadamente\u2026 0,05% das informa\u00e7\u00f5es reais apresentadas pelos pesquisadores. Existem in\u00fameras outras nuances tamb\u00e9m relevantes para entender seu funcionamento. Em particular, eles utilizaram um recurso do algoritmo de encapsulamento de chave SIKE para criar condi\u00e7\u00f5es para possibilitar o vazamento atrav\u00e9s do tempo de resposta ou mudan\u00e7a de frequ\u00eancia. Isso \u00e9 semelhante ao ataque Spectre mencionado acima, que exige que condi\u00e7\u00f5es especiais sejam criadas no software atacado para permitir o roubo de dados importantes. A rigor, com base nos resultados do estudo, \u00e9 imposs\u00edvel dizer inequivocamente onde est\u00e1 a vulnerabilidade: na CPU ou no programa.<\/p>\n

E precisamos mencionar um aspecto gritante da implementa\u00e7\u00e3o: embora os pesquisadores tenham demonstrado um ataque real, pr\u00e1tico (n\u00e3o te\u00f3rico), eles o realizaram sob condi\u00e7\u00f5es controladas. A varia\u00e7\u00e3o do tempo de resposta conforme as entradas foi sempre constante. Mas e se a CPU estiver executando outras tarefas simultaneamente que tamb\u00e9m afetam o tempo de resposta e tornam os dados mais ruidosos? Por fim, mesmo em tais circunst\u00e2ncias ideais, a reconstru\u00e7\u00e3o da chave de criptografia (em dois experimentos diferentes) levou 36 e 89 horas! Durante esse tempo, milhares de solicita\u00e7\u00f5es por segundo foram enviadas ao programa de criptografia, que era a \u00fanica maneira de garantir que todos os recursos necess\u00e1rios de opera\u00e7\u00e3o de software e hardware estivessem alinhados para produzir o vazamento. Isso \u00e9 muito tempo!<\/p>\n

Portanto, a rea\u00e7\u00e3o ao estudo foi amb\u00edgua. Por um lado, as vulnerabilidades receberam os identificadores usuais: CVE-2022-23823 para Intel e CVE-2022-24436 para AMD. Parece que o problema est\u00e1, afinal, nas CPUs. Mas a Intel<\/a> e a AMD<\/a> relataram que n\u00e3o t\u00eam planos de lan\u00e7ar atualiza\u00e7\u00f5es para os sistemas afetados (para Intel, as CPUs da 8\u00aa \u00e0 11\u00aa gera\u00e7\u00e3o). De fato, a mudan\u00e7a no algoritmo SIKE tornou imposs\u00edvel o ataque demonstrado. A Microsoft e a Cloudflare, que usam o SIKE como um dos elementos em seus sistemas de criptografia, atualizaram seus pr\u00f3prios softwares.<\/p>\n

No entanto, o estudo \u00e9 de grande import\u00e2ncia. Como foi o caso do Spectre em 2018, n\u00e3o ser\u00e1 o \u00faltimo desta nova classe de ataques. Se um exemplo de vazamento de dados por meio do ajuste din\u00e2mico da frequ\u00eancia da CPU puder ser mostrado, outros certamente se seguir\u00e3o. \u00c9 tamb\u00e9m um importante corpo de trabalho para cript\u00f3grafos. O SIKE \u00e9 um algoritmo bastante recente, candidato ao t\u00edtulo de \u201csolu\u00e7\u00e3o de criptografia p\u00f3s-qu\u00e2ntica\u201d. Na verdade, ele foi analisado quanto \u00e0 robustez contra qualquer ataque de canal lateral e provou ser bastante resiliente. Mas o estudo da Hertzbleed mostrou que surgiram novos caminhos.<\/p>\n

Em suma, como costuma acontecer com esses estudos, esse ataque foi \u201cdescoberto\u201d, mas n\u00e3o p\u00f4de ser implementado \u2013 de forma completa e com sucesso \u2013 de verdade. Os desenvolvedores de CPUs e programas que s\u00e3o particularmente sens\u00edveis a hackers tirar\u00e3o suas pr\u00f3prias conclus\u00f5es e far\u00e3o altera\u00e7\u00f5es antes que seja poss\u00edvel roubar qualquer coisa. Mas h\u00e1 uma pequena chance de que, da pr\u00f3xima vez, esses ou outros pesquisadores encontrem algo que permita aos invasores, digamos, interceptar o tr\u00e1fego de rede criptografado ou quebrar a criptografia enquanto permanecem an\u00f4nimos. Com um pouco de imagina\u00e7\u00e3o \u00e9 poss\u00edvel inflar o esquema descrito neste estudo para tais propor\u00e7\u00f5es. Mas isso ainda precisa ser comprovado, e o estudo Hertzbleed (e o problema que tivemos para descrev\u00ea-lo em termos simples) mostra que essa n\u00e3o \u00e9 uma tarefa f\u00e1cil. Para vulnerabilidades da classe Spectre, nenhum avan\u00e7o foi demonstrado<\/a> em mais de quatro anos. Aqui, tamb\u00e9m, as coisas provavelmente continuar\u00e3o as mesmas: em mais ou menos um ano, outro relat\u00f3rio ser\u00e1 divulgado que avan\u00e7a um pouco e esclarece o anterior. E isso \u00e9 um ponto positivo. Afinal, j\u00e1 temos problemas suficientes com seguran\u00e7a da informa\u00e7\u00e3o!<\/p>\n","protected":false},"excerpt":{"rendered":"

Saiba os detalhes em um dos estudos de infosec mais complexos e f\u00e1ceis de entender dos \u00faltimos tempos.<\/p>\n","protected":false},"author":665,"featured_media":19725,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1260,1119,1655,1656],"tags":[3022,1377,267],"class_list":{"0":"post-19724","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-threats","8":"category-business","9":"category-enterprise","10":"category-smb","11":"tag-cpus","12":"tag-spectre","13":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/hertzbleed-attack\/19724\/"},{"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":"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":"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.com.br\/blog\/tag\/vulnerabilidades\/","name":"vulnerabilidades"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/19724","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/comments?post=19724"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/19724\/revisions"}],"predecessor-version":[{"id":19729,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/posts\/19724\/revisions\/19729"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media\/19725"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/media?parent=19724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/categories?post=19724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com.br\/blog\/wp-json\/wp\/v2\/tags?post=19724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}