S3 Ep146: Conte-nos sobre essa violação! (Se você quiser.)

S3 Ep146: Conte-nos sobre essa violação! (Se você quiser.)

Carimbo de data / hora: 3 de agosto de 2023, 1:56
S3 Ep146: Conte-nos sobre essa violação! (Se você quiser.) PlatoBlockchain Data Intelligence. Pesquisa vertical. Ai.
by Paul Ducklin

ESTRANHO MAS VERDADEIRO

Nenhum reprodutor de áudio abaixo? Ouvir diretamente no Soundcloud.

Com Doug Aamoth e Paul Ducklin. Música de introdução e final de Edith Mudge.

Você pode nos ouvir em Soundcloud, Podcasts da Apple, Google Podcasts, Spotify e em qualquer lugar que bons podcasts sejam encontrados. Ou simplesmente solte o URL do nosso feed RSS em seu podcatcher favorito.

LEIA A TRANSCRIÇÃO

DOUG.  Atualizações do Firefox, outro Bug com um nome impressionante, e a SEC exige divulgação.

Tudo isso e muito mais no podcast Naked Security.

[MODEM MUSICAL]

Bem-vindos ao podcast, pessoal.

Eu sou Doug Aamoth; ele é Paul Ducklin.

Paul, espero que você se orgulhe de mim… Sei que você é um entusiasta do ciclismo.

Eu andei de bicicleta ontem por 10 milhas americanas, que acredito serem aproximadamente 16 km, enquanto puxava uma criança pequena, mas não pesada, atrás da bicicleta em uma carruagem de duas rodas.

E ainda estou vivo para contar a história.

É um longo caminho para andar de bicicleta, Paul?

PATO.  [RISOS] Depende de quão longe você realmente precisava ir.

Tipo, se na verdade fossem 1200 metros que você tivesse que percorrer e se perdesse... [RISOS]

Meu entusiasmo pelo ciclismo é muito grande, mas isso não significa que eu pedale deliberadamente mais longe do que preciso, porque é minha principal forma de me locomover.

Mas 10 milhas está OK.

Você sabia que as milhas americanas e britânicas são, de fato, idênticas?

DOUG.  É bom saber!

PATO.  E desde 1959, quando um monte de países, incluindo, eu acho, Canadá, África do Sul, Austrália, Estados Unidos e Reino Unido se reuniram e concordaram em padronizar em uma “polegada internacional”.

Acho que a polegada imperial ficou muito, muito ligeiramente menor e a polegada americana ficou muito, muito ligeiramente mais longa, com o resultado de que a polegada (e, portanto, a jarda, o pé e a milha)...

…eles são todos definidos em termos de metro.

Uma polegada é exatamente 25.4 mm

Três algarismos significativos é tudo que você precisa.

DOUG.  Fascinante!

Bem, falando em fascinante, é hora do nosso Esta semana na história da tecnologia segmento.

Nesta semana, em 01 de agosto de 1981, a Music Television, também conhecida como MTV, foi ao ar como parte dos pacotes de televisão a cabo e satélite americanos e apresentou ao público os videoclipes.

A primeira tocou [CANTA, MUITO BEM DE FATO] “Video Killed the Radio Star” do The Buggles.

Adequado na época, embora irônico hoje em dia, já que a MTV raramente exibe videoclipes e não exibe nenhum videoclipe novo, Paul.

PATO.  Sim, é irônico, não é, que a TV a cabo (em outras palavras, onde você tinha fios passando debaixo da terra em sua casa) matou a estrela do rádio (ou do wireless), e agora parece que a TV a cabo, MTV… isso meio que morreu porque todo mundo tem redes móveis que funcionam sem fio.

O que vai, volta, Douglas.

DOUG.  Tudo bem, vamos falar sobre essas atualizações do Firefox.

Recebemos uma dose dupla de atualizações do Firefox este mês, porque elas estão em um ciclo de 28 dias:

Firefox corrige uma enxurrada de falhas no primeiro dos dois lançamentos deste mês

Não há dias zero nesta primeira rodada fora do portão, mas alguns momentos de aprendizado.

Listamos talvez metade deles em seu artigo, e um que realmente se destacou para mim foi: Ignorar possíveis solicitações de permissão por meio de clickjacking.

PATO.  Sim, o bom e velho clickjacking novamente.

Eu gosto desse termo porque descreve muito bem o que é.

Você clica em algum lugar, pensando que está clicando em um botão ou em um link inocente, mas está inadvertidamente autorizando que algo aconteça que não é óbvio pelo que a tela está mostrando sob o cursor do mouse.

O problema aqui parece ser que, em algumas circunstâncias, quando uma caixa de diálogo de permissões estava prestes a aparecer no Firefox, por exemplo, diga: “Tem certeza de que deseja permitir que este site use sua câmera? tem acesso à sua localização? usar seu microfone?”…

…todas essas coisas que, sim, você quer que perguntem.

Aparentemente, se você conseguir levar o navegador a um ponto de desempenho (novamente, desempenho versus segurança) em que ele está lutando para acompanhar, poderá atrasar o aparecimento do pop-up de permissões.

Mas tendo um botão no local onde o pop-up apareceria e induzindo o usuário a clicar nele, você poderia atrair o clique, mas o clique seria enviado para a caixa de diálogo de permissões que você ainda não tinha visto.

Uma espécie de condição visual de corrida, se preferir.

DOUG.  OK, e o outro era: A tela fora da tela pode ter contornado as restrições de origem cruzada.

Você continua dizendo que uma página da web pode espiar imagens exibidas em outra página de um site diferente.

PATO.  Isso não deveria acontecer, não é?

DOUG.  Não!

PATO.  O jargão para isso é a “política da mesma origem”.

Se você estiver executando o site X e me enviar um monte de JavaScript que define uma carga inteira de cookies, tudo isso será armazenado no navegador.

Mas apenas mais JavaScript do site X pode ler esses dados de volta.

O fato de você estar navegando no site X em uma guia e no site Y na outra guia não permite que eles vejam o que o outro está fazendo, e o navegador deve manter todas essas coisas separadas.

Isso é obviamente muito importante.

E parece aqui que, pelo que entendi, se você estivesse renderizando uma página que ainda não estava sendo exibida…

…uma tela fora da tela, que é onde você cria, se quiser, uma página da web virtual e, em algum momento futuro, você diz: “Agora estou pronto para exibi-la” e, bingo, a página aparece toda em uma vez.

O problema vem com a tentativa de garantir que o material que você está renderizando de forma invisível não vaze dados inadvertidamente, mesmo que nunca seja exibido para o usuário.

Eles perceberam isso, ou foi divulgado com responsabilidade e foi corrigido.

E esses dois, eu acho, foram incluídos nas chamadas vulnerabilidades de nível “alto”.

A maioria dos outros eram “Moderados”, com exceção do tradicional da Mozilla, “Encontramos muitos bugs por fuzzing e por meio de técnicas automatizadas; não as sondamos para descobrir se poderiam ser exploradas, mas estamos dispostos a assumir que alguém que se esforçou o suficiente poderia fazê-lo.

Essa é uma admissão de que nós dois gostamos muito, Doug... porque vale a pena eliminar bugs em potencial, mesmo que você tenha certeza de que ninguém jamais descobrirá como explorá-los.

Porque na cibersegurança vale a pena nunca dizer nunca!

DOUG.  Tudo bem, você está procurando o Firefox 116 ou, se estiver em uma versão estendida, 115.1.

O mesmo com o Thunderbird.

E vamos passar para… oh, cara!

Paulo, isso é emocionante!

Temos um novo BWAIN após um BWAIN duplo na semana passada: um bug com um nome impressionante.

Este é chamado Colidir+Força:

Desempenho e segurança se chocam mais uma vez no ataque “Collide+Power”

PATO.  [RISOS] Sim, é intrigante, não é, que eles escolheram um nome que tem um sinal de mais nele?

DOUG.  Sim, isso torna difícil dizer.

PATO.  Você não pode ter um sinal de mais em seu nome de domínio, então o nome de domínio é collidepower.com.

DOUG.  Tudo bem, deixe-me ler os próprios pesquisadores e cito:

A raiz do problema é que os componentes compartilhados da CPU, como o sistema de memória interna, combinam dados do invasor e dados de qualquer outro aplicativo, resultando em um sinal de vazamento combinado no consumo de energia.

Assim, conhecendo seus próprios dados, o invasor pode determinar os valores exatos dos dados usados ​​em outras aplicações.

PATO.  [RISOS] Sim, isso faz muito sentido se você já sabe do que eles estão falando!

Para tentar explicar isso em inglês simples (espero ter entendido corretamente)…

Isso se resume aos problemas de desempenho versus segurança sobre os quais falamos antes, incluindo podcast da semana passada com isso Sangramento Zen bug (que é muito mais sério, a propósito):

Zenbleed: como a busca pelo desempenho da CPU pode colocar suas senhas em risco

Há toda uma carga de dados que é mantida dentro da CPU (“em cache” é o termo técnico para isso) para que a CPU não precise buscá-los mais tarde.

Portanto, há muitas coisas internas que você realmente não consegue gerenciar; a CPU cuida disso para você.

E o cerne desse ataque parece ser mais ou menos assim…

O que o invasor faz é acessar vários locais de memória de forma que o armazenamento em cache interno lembre-se desses locais de memória, para que não precise lê-los da RAM novamente se forem reutilizados rapidamente.

Portanto, o invasor de alguma forma obtém esses valores de cache preenchidos com padrões conhecidos de bits, valores de dados conhecidos.

E então, se a vítima tiver memória que *ela* está usando com frequência (por exemplo, os bytes em uma chave de descriptografia), se seu valor for repentinamente julgado pela CPU como mais provável de ser reutilizado do que um dos valores dos invasores, ele chuta o valor do invasor para fora desse local de cache super-rápido interno e coloca o novo valor, o valor da vítima, lá.

E o que esses pesquisadores descobriram (e tão improvável quanto o ataque soa na teoria e na prática, isso é uma coisa incrível de se descobrir)…

O número de bits que são diferentes entre o valor antigo no cache e o novo valor *altera a quantidade de energia necessária para executar a operação de atualização do cache*.

Portanto, se você puder medir o consumo de energia da CPU com precisão suficiente, poderá fazer inferências sobre quais valores de dados foram gravados na memória cache interna, oculta e invisível dentro da CPU que a CPU pensou que não era da sua conta.

Bastante intrigante, Doug!

DOUG.  Excelente.

OK, existem algumas mitigações.

Essa seção começa: “Em primeiro lugar, você não precisa se preocupar”, mas também quase todas as CPUs são afetadas.

PATO.  Sim, isso é interessante, não é?

Diz “antes de tudo” (texto normal) “Você" (em itálico) "não precisa se preocupar" (em negrito). [RISOS]

Então, basicamente, ninguém vai atacá-lo com isso, mas talvez os projetistas de CPU queiram pensar sobre isso no futuro, se houver alguma maneira de contornar isso. [RISOS]

Eu pensei que era uma maneira interessante de colocar isso.

DOUG.  OK, então a mitigação é basicamente desligar o hyperthreading.

É assim que funciona?

PATO.  Hyperthreading torna isso muito pior, até onde posso ver.

Já sabemos que o hyperthreading é um problema de segurança porque já houve várias vulnerabilidades que dependiam dele antes.

É onde uma CPU, digamos, com oito núcleos finge ter 16 núcleos, mas na verdade eles não estão em partes separadas do chip.

Na verdade, são pares de pseudo-núcleos que compartilham mais componentes eletrônicos, mais transistores, mais capacitores, o que talvez seja uma boa ideia por motivos de segurança.

Se você estiver executando o bom e velho OpenBSD, acho que eles decidiram que o hyperthreading é muito difícil de proteger com mitigações; pode muito bem simplesmente desligá-lo.

No momento em que você tiver atingido o desempenho exigido pelas mitigações, é melhor não tê-lo.

Então eu acho que desligando hyperthreading irá imunizá-lo muito contra este ataque.

A segunda coisa que você pode fazer é, como dizem os autores em negrito: não se preocupe. [RISADA]

DOUG.  Isso é uma grande mitigação! [RISOS]

PATO.   Há uma grande parte (vou ter que ler isso, Doug)…

Há uma grande parte em que os próprios pesquisadores descobriram que, para obter qualquer tipo de informação confiável, eles estavam obtendo taxas de dados entre 10 e 100 bits por hora fora do sistema.

Acredito que pelo menos as CPUs Intel tenham uma mitigação que imagino que ajudaria contra isso.

E isso nos traz de volta aos MSRs, aqueles registros específicos do modelo sobre os quais falamos na semana passada com o Zenbleed, onde havia uma parte mágica que você poderia ativar que dizia: "Não faça coisas arriscadas".

Há um recurso que você pode definir chamado filtragem RAPL, e RAPL é a abreviação de limite de potência média em execução.

É usado por programas que desejam ver o desempenho de uma CPU para fins de gerenciamento de energia, para que você não precise invadir a sala do servidor e colocar um monitor de energia em um fio com uma pequena sonda na placa-mãe. [RISOS]

Você pode realmente fazer com que a CPU diga quanta energia está usando.

A Intel pelo menos tem esse modo chamado filtragem RAPL, que introduz deliberadamente jitter ou erro.

Assim, você obterá resultados que, em média, são precisos, mas onde cada leitura individual estará errada.

DOUG.  Vamos agora voltar nossa atenção para este novo acordo com a SEC.

A Security and Exchange Commission está exigindo limites de divulgação de quatro dias sobre violações de segurança cibernética:

SEC exige limite de divulgação de quatro dias para violações de segurança cibernética

Mas (A) você decide se um ataque é sério o suficiente para relatar e (B) o limite de quatro dias não começa até que você decida que algo é importante o suficiente para relatar, Paul.

Então, um bom primeiro começo, mas talvez não tão agressivo quanto gostaríamos?

PATO.  Concordo com sua avaliação, Doug.

Parecia ótimo quando olhei pela primeira vez: “Ei, você tem essa divulgação de quatro dias se tiver uma violação de dados ou um problema de segurança cibernética”.

Mas então havia algo sobre: ​​“Bem, isso deve ser considerado um problema material”, um termo legal que significa que realmente importa o suficiente para valer a pena ser divulgado em primeiro lugar.

E então cheguei a essa parte (e não é um comunicado de imprensa muito longo da SEC) que meio que dizia: “Assim que você decidir que realmente deve relatar isso, ainda terá quatro dias para denunciá-lo”.

Agora, imagino que, legalmente, não é bem assim que vai funcionar. Doug

Talvez estejamos sendo um pouco duros no artigo?

DOUG.  Você amplia os ataques de ransomware, dizendo que existem alguns tipos diferentes, então vamos falar sobre isso... é importante determinar se esse é um ataque material que você precisa relatar.

Então, que tipo de ransomware estamos vendo?

PATO.  Sim, só para explicar, pensei que era uma parte importante disso.

Não quero apontar o dedo para a SEC, mas isso é algo que não parece ter saído na lavagem em muitos ou em nenhum país ainda…

…se apenas sofrer um ataque de ransomware é inevitavelmente o suficiente para ser uma violação de dados materiais.

Este documento da SEC na verdade não menciona a “palavra R”.

Não há menção a coisas específicas de ransomware.

E o ransomware é um problema, não é?

No artigo, queria deixar claro que a palavra “ransomware”, que ainda usamos amplamente, não é mais a palavra certa, não é?

Provavelmente deveríamos chamá-lo de “chantagem” ou simplesmente “ciberextorsão”.

Identifico três tipos principais de ataque de ransomware.

Tipo A é onde os bandidos não roubam seus dados, eles apenas embaralham seus dados in situ.

Portanto, eles não precisam fazer upload de nada.

Eles embaralham tudo de forma que possam fornecer a chave de descriptografia, mas você não verá um único byte de dados deixando sua rede como um sinal revelador de que algo ruim está acontecendo.

Depois, há um ataque de ransomware Tipo B, onde os bandidos dizem: “Sabe de uma coisa, não vamos arriscar gravar em todos os arquivos, sendo pegos fazendo isso. Vamos apenas roubar todos os dados e, em vez de pagar o dinheiro para recuperar seus dados, você está pagando pelo nosso silêncio.”

E então, é claro, há o ataque de ransomware Tipo C, que é: “Ambos A e B”.

É aí que os bandidos roubam seus dados *e* eles os embaralham e dizem: "Ei, se não é uma coisa que vai te causar problemas, é a outra."

E seria bom saber onde o que eu acredito que a profissão jurídica chama de materialidade (em outras palavras, o significado legal ou a relevância legal para uma determinada regulamentação)…

…onde isso entra em ação, no caso de ataques de ransomware.

DOUG.  Bem, este é um bom momento para trazer nosso comentarista da semana, Adam, nesta história.

Adam dá sua opinião sobre os vários tipos de ataque de ransomware.

Então, começando com o Tipo A, onde é apenas um ataque direto de ransomware, onde eles bloqueiam os arquivos e deixam uma nota de resgate para desbloqueá-los…

Adão diz:

Se uma empresa for atingida por ransomware, não encontrar evidências de exfiltração de dados após uma investigação completa e recuperar seus dados sem pagar o resgate, eu estaria inclinado a dizer: “Não [divulgação necessária]”.

PATO.  Você já fez o suficiente?

DOUG.  Sim.

PATO.  Você não evitou exatamente isso, mas fez a próxima melhor coisa, então não precisa contar a seus investidores….

A ironia é, Doug, se você tivesse feito isso como empresa, talvez quisesse dizer a seus investidores: “Ei, adivinhem? Tivemos um ataque de ransomware como todo mundo, mas saímos dele sem pagar o dinheiro, sem nos envolver com os bandidos e sem perder nenhum dado. Então, embora não fôssemos perfeitos, éramos a segunda melhor coisa.”

E, na verdade, pode ter muito peso divulgar isso voluntariamente, mesmo que a lei diga que você não precisa.

DOUG.  E então, para o Tipo B, o ângulo da chantagem, Adam diz:

Essa é uma situação complicada.

Teoricamente, eu diria: “Sim”.

Mas isso provavelmente levará a muitas divulgações e prejudicará a reputação dos negócios.

Então, se você tem um monte de empresas saindo e dizendo: “Olha, fomos atingidos por ransomware; achamos que nada de ruim aconteceu; pagamos os bandidos para mantê-los quietos; e estamos confiantes de que eles não vão derramar o feijão”, por assim dizer…

…isso cria uma situação complicada, porque pode prejudicar a reputação de uma empresa, mas se eles não tivessem divulgado, ninguém saberia.

PATO.  E vejo que Adam se sentiu da mesma maneira que você e eu sobre o assunto: “Você tem quatro dias, e não mais do que quatro dias… a partir do momento em que você acha que os quatro dias devem começar”.

Ele também disse isso, não foi?

Ele disse:

Algumas empresas provavelmente adotarão táticas para atrasar bastante a decisão sobre se há um impacto material.

Então, não sabemos bem como isso vai acontecer, e tenho certeza que a SEC também não sabe.

Pode levar alguns casos de teste para que eles descubram qual é a quantidade certa de burocracia para garantir que todos nós aprendamos o que precisamos saber, sem forçar as empresas a divulgar cada pequena falha de TI que já aconteceu e enterrar todos nós em um carga de papelada.

O que leva essencialmente à fadiga da violação, não é?

Se você tem tantas más notícias que não são muito importantes, apenas lavando você...

… de alguma forma, é fácil perder as coisas realmente importantes que estão entre todos os “eu realmente precisava ouvir sobre isso?”

O tempo dirá, Douglas.

DOUG.  Sim, complicado!

E eu sei que digo isso o tempo todo, mas vamos ficar de olho nisso, porque será fascinante ver isso se desenrolar.

Então, obrigado, Adam, por enviar esse comentário.

PATO.  Sim, de fato!

DOUG.  Se você tem uma história, comentário ou pergunta interessante que gostaria de enviar, adoraríamos ler no podcast.

Você pode enviar um e-mail para tips@sophos.com, comentar em qualquer um de nossos artigos ou entrar em contato conosco nas redes sociais: @nakedsecurity.

Esse é o nosso show de hoje; muito obrigado por ouvir.

Para Paul Ducklin, sou Doug Aamoth, lembrando você até a próxima…

AMBAS.  Fique seguro.

[MODEM MUSICAL]

Carimbo de hora:

Mais de Segurança nua