S3 Ep113: Dominando o kernel do Windows – os criminosos que enganaram a Microsoft [Áudio + Texto] PlatoBlockchain Data Intelligence. Pesquisa vertical. Ai.

S3 Ep113: Pwning the Windows kernel – os bandidos que enganaram a Microsoft [Audio + Text]

PWNING O KERNEL DO WINDOWS

Clique e arraste nas ondas sonoras abaixo para pular para qualquer ponto. Você também pode ouça 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, Costureiro 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.  Spyware sem fio, clonagem de cartão de crédito e patches em abundância.

Tudo isso e muito mais no podcast Naked Security.

[MODEM MUSICAL]

Bem-vindos ao podcast, pessoal.

Eu sou Doug Aamoth; ele é Paul Ducklin.

Paulo, como vai?


PATO.  Estou muito bem, Doug.

Frio, mas bem.


DOUG.  Está congelando aqui também, e todo mundo está doente... mas é dezembro para você.

Falando em dezembro, gostamos de começar o show com nosso Esta semana na história da tecnologia segmento.

Temos uma entrada empolgante esta semana – em 16 de dezembro de 2003, a Lei CAN-SPAM foi sancionada pelo então presidente dos Estados Unidos, George W. Bush.

Um backronym para controlando o ataque de pornografia não solicitada e marketing, CAN-SPAM era considerado relativamente inútil por motivos como não exigir o consentimento dos destinatários para receber e-mails de marketing e não permitir que indivíduos processassem spammers.

Acreditava-se que, em 2004, menos de 1% do spam estava realmente em conformidade com a lei.


PATO.  Sim, é fácil dizer isso em retrospectiva…

…mas como alguns de nós brincamos na época, achamos que eles chamaram isso de CAN-SPAM porque isso é *exatamente* o que você poderia fazer. [RISADA]


DOUG.  “Você PODE enviar spam!”


PATO.  Acho que a ideia era: "Vamos começar com uma abordagem muito suave".

[TOM IRRITANTE] Então foi o começo, reconhecidamente, não tanto assim.


DOUG.  [RISOS] Nós vamos chegar lá eventualmente.

Falando em mal e pior…

…Microsoft Patch Tuesday – nada para ver aqui, a menos que você conte um driver de kernel malicioso assinado?!

O malware de driver assinado sobe na cadeia de confiança de software


PATO.  Bem, vários na verdade – a equipe Sophos Rapid Response encontrou esses artefatos em compromissos que eles fizeram.

Não apenas a Sophos – pelo menos dois outros grupos de pesquisa de segurança cibernética são listados pela Microsoft como tendo encontrado essas coisas recentemente: drivers de kernel que receberam efetivamente um selo digital de aprovação da Microsoft.

A Microsoft agora tem um comunicado que está culpando parceiros desonestos.

Se eles realmente criaram uma empresa que fingia fabricar hardware, especialmente para ingressar no programa de driver com a intenção de fornecer drivers de kernel duvidosos?

Ou se subornaram uma empresa que já fazia parte do programa para jogar bola com eles?

Ou se eles invadiram uma empresa que nem percebeu que estava sendo usada como um veículo para dizer à Microsoft: “Ei, precisamos produzir esse driver de kernel – você pode certificá-lo?”…

O problema com os drivers de kernel certificados, é claro, é porque eles precisam ser assinados pela Microsoft e, como a assinatura do driver é obrigatória no Windows, isso significa que, se você conseguir assinar o driver do kernel, não precisará de hacks ou vulnerabilidades ou exploits para poder carregar um como parte de um ataque cibernético.

Você pode simplesmente instalar o driver e o sistema dirá: “Bem, está assinado. Portanto, é permitido carregá-lo.”

E, claro, você pode causar muito mais danos quando estiver dentro do kernel do que quando for “meramente” Administrador.

Notavelmente, você obtém acesso interno ao gerenciamento de processos.

Como administrador, você pode executar um programa que diz: “Quero matar o programa XYZ”, que pode ser, digamos, um antivírus ou uma ferramenta de caça a ameaças.

E esse programa pode resistir a ser encerrado, porque, supondo que também seja de nível administrativo, nenhum processo pode absolutamente reivindicar primazia sobre o outro.

Mas se você estiver dentro do sistema operacional, é o sistema operacional que lida com os processos de início e finalização, então você obtém muito mais poder para matar coisas como software de segurança…

…e aparentemente é exatamente isso que esses bandidos estavam fazendo.

Na “história se repetindo”, eu me lembro, anos e anos atrás, quando investigávamos software que bandidos usavam para encerrar programas de segurança, eles normalmente tinham listas de 100 a 200 processos que estavam interessados ​​em eliminar: sistema operacional processos, programas antivírus de 20 fornecedores diferentes, todo esse tipo de coisa.

E desta vez, acho que havia 186 programas que o driver deles estava lá para matar.

Então, um pouco de vergonha para a Microsoft.

Felizmente, eles expulsaram esses codificadores desonestos de seu programa de desenvolvimento e colocaram na lista de bloqueio pelo menos todos os drivers duvidosos conhecidos.


DOUG.  Então isso não é tudo o que foi revelado no Patch Tuesday.

Houve também alguns dias zero, alguns bugs RCE e outras coisas dessa natureza:

Patch Tuesday: 0 dias, bugs RCE e um curioso conto de malware assinado


PATO.  Sim.

Felizmente, os bugs de dia zero corrigidos este mês não eram conhecidos como RCEs, ou execução remota de código buracos.

Portanto, eles não forneceram uma rota direta para invasores externos apenas entrarem em sua rede e executarem o que quisessem.

Mas havia um bug de driver de kernel no DirectX que permitiria que alguém que já estivesse em seu computador basicamente se promovesse para ter poderes no nível do kernel.

Isso é um pouco como trazer seu próprio driver assinado – você *sabe* que pode carregá-lo.

Nesse caso, você explora um bug em um driver confiável e que permite fazer coisas dentro do kernel.

Obviamente, esse é o tipo de coisa que transforma um ataque cibernético que já é uma má notícia em algo muito, muito pior.

Então você definitivamente quer corrigir isso.

Curiosamente, parece que isso se aplica apenas à versão mais recente, ou seja, 2022H2 (segundo semestre do ano é o que significa H2) do Windows 11.

Você definitivamente quer ter certeza de que tem isso.

E havia um bug intrigante no Windows SmartScreen, que é basicamente a ferramenta de filtragem do Windows que, quando você tenta baixar algo que pode ser ou é perigoso, avisa.

Então, obviamente, se os bandidos descobriram: “Oh, não! Recebemos esse ataque de malware e estava funcionando muito bem, mas agora o Smart Screen está bloqueando, o que vamos fazer?”…

…ou eles podem fugir e criar um ataque totalmente novo, ou podem encontrar uma vulnerabilidade que os permita contornar a Tela Inteligente para que o aviso não apareça.

E foi exatamente isso que aconteceu no CVE-2022-44698, Douglas.

Então, esses são os dias zero.

Como você disse, existem alguns bugs de execução remota de código na mistura, mas nenhum deles é conhecido por estar em estado selvagem.

Se você fizer um patch contra eles, ficará à frente dos bandidos, em vez de apenas alcançá-los.


DOUG.  OK, vamos continuar no assunto de patches…

… e eu amo a primeira parte disso manchete.

Apenas diz: “A Apple conserta tudo”:

Apple corrige tudo e finalmente revela mistério do iOS 16.1.2


PATO.  Sim, não consegui pensar em uma maneira de listar todos os sistemas operacionais em 70 caracteres ou menos. [RISADA]

Então pensei: “Bem, isso é literalmente tudo”.

E o problema é que da última vez que escrevemos sobre uma atualização da Apple, foi apenas iOS (iPhones) e apenas iOS 16.1.2:

Apple lança atualização de segurança do iOS mais discreta do que nunca

Então, se você tivesse o iOS 15, o que faria?

Você estava em risco?

Você ia receber a atualização mais tarde?

Desta vez, as notícias sobre a última atualização finalmente saíram na lavagem.

Parece, Doug, que a razão pela qual obtivemos a atualização do iOS 16.1.2 é que havia um exploit in-the-wild, agora conhecido como CVE-2022-42856, e que era um bug no WebKit, o mecanismo de renderização da web. dentro dos sistemas operacionais da Apple.

E, aparentemente, esse bug pode ser acionado simplesmente atraindo você para ver algum conteúdo armadilhado - o que é conhecido no comércio como um instalação automática, onde você apenas olha para uma página e, “Oh, dear”, no fundo, o malware é instalado.

Agora, aparentemente, o exploit encontrado só funcionava no iOS.

Presumivelmente, é por isso que a Apple não lançou atualizações para todas as outras plataformas, embora macOS (todas as três versões suportadas), tvOS, iPadOS… todos eles realmente continham esse bug.

O único sistema que não o fez, aparentemente, foi o watchOS.

Portanto, esse bug estava em praticamente todos os softwares da Apple, mas aparentemente só era explorável, até onde eles sabiam, por meio de uma exploração in-the-wild, no iOS.

Mas agora, estranhamente, eles estão dizendo: “Apenas em iOSes anteriores ao 15.1”, o que faz você se perguntar: “Por que eles não lançaram uma atualização para o iOS 15, nesse caso?”

Nós simplesmente não sabemos!

Talvez eles estivessem esperando que, se lançassem o iOS 16.1.2, algumas pessoas no iOS 15 atualizariam de qualquer maneira e isso resolveria o problema para eles?

Ou talvez eles ainda não tivessem certeza de que o iOS 16 não era vulnerável e era mais rápido e fácil lançar a atualização (para a qual eles têm um processo bem definido) do que fazer testes suficientes para determinar que o bug não poderia t ser explorado no iOS 16 facilmente.

Provavelmente nunca saberemos, Doug, mas é uma história fascinante em tudo isso!

Mas, de fato, como você disse, há uma atualização para todos com um produto com o logotipo da Apple.

Portanto: Não demore/Faça hoje.


DOUG.  Passemos aos nossos amigos da Universidade Ben-Gurion... eles estão de volta.

Eles desenvolveram algum spyware sem fio - um pequeno truque de spyware sem fio:

COVID-bit: o truque do spyware sem fio com um nome infeliz


PATO.  Sim… não tenho certeza do nome; Eu não sei o que eles estavam pensando lá.

Eles chamaram isso COVID-bit.


DOUG.  Um pouco estranho.


PATO.  Acho que todos nós fomos mordidos pelo COVID de uma forma ou de outra…


DOUG.  Talvez seja isso?


PATO.  A COV destina-se a representar encoberto, e eles não dizem o que ID-bit apoia.

Eu imaginei que poderia ser “divulgação de informações pouco a pouco”, mas ainda assim é uma história fascinante.

Adoramos escrever sobre a pesquisa que este Departamento faz porque, embora para a maioria de nós seja um pouco hipotético…

…eles estão procurando como violar airgaps de rede, que é onde você executa uma rede segura que você deliberadamente mantém separada de todo o resto.

Então, para a maioria de nós, isso não é um grande problema, pelo menos em casa.

Mas o que eles estão vendo é que *mesmo que você isole uma rede da outra fisicamente*, e hoje em dia você arranca todos os cartões sem fio, os cartões Bluetooth, os cartões Near Field Communications ou corta os fios e quebra traços de circuito na placa de circuito para impedir que qualquer conectividade sem fio funcione…

…ainda existe uma maneira de um invasor que obtém acesso único à área segura, ou um interno corrupto, vazar dados de maneira não rastreável?

Infelizmente, isolar totalmente uma rede de equipamentos de computador de outra é muito mais difícil do que você pensa.

Os leitores regulares saberão que escrevemos sobre muitas coisas que esses caras inventaram antes.

Eles tiveram GAIROSCOPE, que é onde você realmente reaproveita a função de um telefone celular chip de bússola como um microfone de baixa fidelidade.


DOUG.  [RISOS] Eu me lembro dessa:

Quebrando a segurança do airgap: usando o giroscópio do seu telefone como microfone


PATO.  Porque esses chips podem sentir vibrações muito bem.

Eles tinham LANTENNA, que é onde você coloca sinais em uma rede com fio que está dentro da área segura, e os cabos de rede realmente agem como estações de rádio em miniatura.

Eles vazam apenas radiação eletromagnética suficiente para que você possa captá-la fora da área segura, então eles estão usando uma rede com fio como transmissor sem fio.

E eles tinham uma coisa que chamavam de brincadeira de FANSMITTER, que é onde você vai, “Bem, podemos fazer sinalização de áudio? Obviamente, se apenas tocarmos músicas pelo alto-falante, como [ruídos de discagem] bip-bip-bip-bip-bip, será bastante óbvio.”

Mas e se variarmos a carga da CPU, para que a ventoinha acelere e desacelere - poderíamos usar o mudança na velocidade do ventilador quase como uma espécie de sinal de semáforo?

O ventilador do seu computador pode ser usado para espioná-lo?

E neste último ataque, eles pensaram: “De que outra forma podemos transformar algo dentro de quase todos os computadores do mundo, algo que parece bastante inocente... como podemos transformá-lo em uma estação de rádio de baixíssima potência?”

E neste caso, eles conseguiram fazer isso usando a fonte de alimentação.

Eles conseguiram fazer isso em um Raspberry Pi, em um laptop Dell e em uma variedade de PCs de mesa.

Eles estão usando a própria fonte de alimentação do computador, que basicamente faz uma comutação CC de alta frequência para cortar uma tensão CC, geralmente para reduzi-la, centenas de milhares ou milhões de vezes por segundo.

Eles encontraram uma maneira de fazer com que isso vazasse radiação eletromagnética – ondas de rádio que eles podiam captar a até 2 metros de distância em um telefone celular…

…mesmo que aquele telefone celular tenha todos os seus recursos sem fio desligados ou mesmo removidos do dispositivo.

O truque que eles inventaram é: você muda a velocidade na qual está comutando e detecta as mudanças na frequência de comutação.

Imagine, se você quiser uma tensão mais baixa (se quiser, digamos, cortar 12V para 4V), a onda quadrada estará ligada por um terço do tempo e desligada por dois terços do tempo.

Se você quiser 2V, precisará alterar a proporção de acordo.

E acontece que as CPUs modernas variam tanto a frequência quanto a voltagem para gerenciar a energia e o superaquecimento.

Portanto, alterando a carga da CPU em um ou mais núcleos da CPU – apenas aumentando e diminuindo as tarefas em uma frequência comparativamente baixa, entre 5000 e 8000 vezes por segundo – eles conseguiram obter o modo comutado fonte de alimentação para *alternar seus modos de comutação* nessas baixas frequências.

E isso gerou emanações de rádio de baixíssima frequência a partir de circuitos ou qualquer fio de cobre na fonte de alimentação.

E eles foram capazes de detectar essas emanações usando uma antena de rádio que não era mais sofisticada do que um simples loop de fio!

Então, o que você faz com um loop de arame?

Bem, você finge, Doug, que é um cabo de microfone ou de fone de ouvido.

Você o conecta a um conector de áudio de 3.5 mm e o conecta ao seu celular como se fosse um conjunto de fones de ouvido…


DOUG.  Uau.


PATO.  Você grava o sinal de áudio gerado pelo loop de fio – porque o sinal de áudio é basicamente uma representação digital do sinal de rádio de frequência muito baixa que você captou.

Eles conseguiram extrair dados a uma taxa entre 100 bits por segundo quando estavam usando o laptop, 200 bits por segundo com o Raspberry Pi e até 1000 bits por segundo, com uma taxa de erro muito baixa, de os computadores desktop.

Você pode obter coisas como chaves AES, chaves RSA e até mesmo pequenos arquivos de dados nesse tipo de velocidade.

Eu pensei que era uma história fascinante.

Se você administra uma área segura, com certeza deseja acompanhar essas coisas, porque, como diz o velho ditado, “os ataques só ficam melhores ou mais inteligentes”.


DOUG.  E tecnologia inferior. [RISADA]

Tudo é digital, exceto que temos esse vazamento analógico que está sendo usado para roubar chaves AES.

É fascinante!


PATO.  Apenas um lembrete de que você precisa pensar sobre o que está do outro lado da parede segura, porque “fora da vista definitivamente não é necessariamente fora da mente”.


DOUG.  Bem, isso se encaixa perfeitamente em nosso história final – algo que está fora da vista, mas não fora da mente:

Skimming de cartão de crédito – a longa e sinuosa estrada da falha na cadeia de suprimentos

Se você já construiu uma página da web, sabe que pode colocar código de análise – uma pequena linha de JavaScript – lá para o Google Analytics, ou empresas semelhantes, para ver como estão suas estatísticas.

Havia uma empresa de análise gratuita chamada Cockpit no início de 2010, então as pessoas estavam colocando esse código do Cockpit – essa pequena linha de JavaScript – em suas páginas da web.

Mas o Cockpit fechou em 2014 e deixou o nome de domínio expirar.

E então, em 2021, os cibercriminosos pensaram: “Alguns sites de comércio eletrônico ainda permitem que esse código seja executado; eles ainda estão chamando esse JavaScript. Por que simplesmente não compramos o nome de domínio e então podemos injetar o que quisermos nesses sites que ainda não removeram essa linha de JavaScript?”


PATO.  Sim.

O que poderia dar certo, Doug?


DOUG.  [RISOS] Exatamente!


PATO.  Sete anos!

Eles teriam uma entrada em todos os seus logs de teste dizendo: Could not source the file cockpit.js (ou o que quer que fosse) from site cockpit.jp, Eu acho que foi.

Então, como você disse, quando os bandidos incendiaram o domínio novamente e começaram a colocar arquivos lá para ver o que aconteceria…

…eles perceberam que vários sites de comércio eletrônico estavam consumindo e executando cegamente e alegremente o código JavaScript dos criminosos dentro dos navegadores da web de seus clientes.


DOUG.  [LUAGHING] “Ei, meu site não está mais dando erro, está funcionando.”


PATO.  [INCRÉDULO] “Eles devem ter consertado”… para alguma compreensão especial da palavra “consertado”, Doug.

Obviamente, se você pode injetar JavaScript arbitrário na página da Web de alguém, pode fazer com que essa página da Web faça o que quiser.

E se, em particular, você estiver visando sites de comércio eletrônico, poderá definir o que é essencialmente um código de spyware para procurar páginas específicas que tenham formulários da web específicos com determinados campos nomeados neles…

…como número do passaporte, número do cartão de crédito, CVV, seja o que for.

E você pode basicamente sugar todos os dados confidenciais não criptografados, os dados pessoais, que o usuário está inserindo.

Ele ainda não entrou no processo de criptografia HTTPS, então você o extrai do navegador, criptografa-o por HTTPS *você mesmo* e o envia para um banco de dados executado por bandidos.

E, claro, a outra coisa que você pode fazer é alterar ativamente as páginas da web quando elas chegarem.

Assim, você pode atrair alguém para um site – aquele que é o site *certo*; é um site que eles visitaram antes, no qual sabem que podem confiar (ou acham que podem confiar).

Se houver um formulário da Web nesse site que, digamos, geralmente solicite o nome e o número de referência da conta, bem, basta inserir alguns campos extras e, considerando que a pessoa já confia no site…

… se você disser nome, ID e [adicionar] data de nascimento?

É muito provável que eles apenas coloquem a data de nascimento porque imaginam: "Suponho que seja parte da verificação de identidade".


DOUG.  Isso é evitável.

Você poderia começar por revisando seus links da cadeia de suprimentos baseados na web.


PATO.  Sim.

Talvez uma vez a cada sete anos seja um começo? [RISADA]

Se você não está olhando, então você realmente faz parte do problema, não da solução.


DOUG.  Você também poderia, ah, não sei... verifique seus logs?


PATO.  Sim.

Novamente, uma vez a cada sete anos pode ser iniciado?

Deixe-me apenas dizer o que dissemos antes no podcast, Doug…

…se você vai coletar logs que você nunca olha, *apenas não se incomode em coletá-los*.

Pare de se enganar e não colete os dados.

Porque, na verdade, a melhor coisa que pode acontecer com os dados se você os coletar e não olhar para eles é que as pessoas erradas não os pegarão por engano.


DOUG.  Então, é claro, execute transações de teste regularmente.


PATO.  Devo dizer: “Uma vez a cada sete anos seria um começo”? [RISADA]


DOUG.  Claro, sim ... [WRY] isso pode ser regular o suficiente, suponho.


PATO.  Se você é uma empresa de comércio eletrônico e espera que seus usuários visitem seu site, acostume-se com uma aparência específica e confie nela…

…então você deve isso a eles para testar se a aparência está correta.

Com regularidade e frequência.

Fácil assim.


DOUG.  Ok, muito bom.

E enquanto o show começa a diminuir, vamos ouvir um de nossos leitores sobre esta história.

Larry comenta:

Revise seus links da cadeia de suprimentos baseados na web?

Gostaria que a Epic Software tivesse feito isso antes de enviar o bug de rastreamento Meta para todos os seus clientes.

Estou convencido de que há uma nova geração de desenvolvedores que pensa que o desenvolvimento é encontrar fragmentos de código em qualquer lugar da Internet e colá-los acriticamente em seu produto de trabalho.


PATO.  Se ao menos não desenvolvêssemos códigos assim...

… onde você vai, “Eu sei, vou usar esta biblioteca; Vou baixá-lo desta fantástica página do GitHub que encontrei.

Oh, precisa de um monte de outras coisas!?

Oh, veja, ele pode satisfazer os requisitos automaticamente... bem, vamos fazer isso então!”

Infelizmente, você precisa *ser dono de sua cadeia de suprimentos*, e isso significa entender tudo o que está envolvido nela.

Se você está pensando na lista de materiais de software [SBoM], roadway, onde pensa: “Sim, vou listar tudo o que uso”, não basta apenas listar o primeiro nível de coisas que você usa.

Você também precisa saber, ser capaz de documentar e saber que pode confiar em todas as coisas das quais essas coisas dependem e assim por diante:

Pulgas pequenas têm pulgas menores
   Nas costas deles para mordê-los
E pulgas menores têm pulgas menores
   E assim, ad infinitum.

*É assim* que você deve perseguir sua cadeia de suprimentos!


DOUG.  Bem dito!

Tudo bem, muito obrigado, Larry, por enviar esse comentário.

Se você tiver uma história, comentário ou pergunta interessante que gostaria de enviar, adoraríamos lê-la 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 a vocês, até a próxima, para…


AMBAS.  Fique seguro!

[MODEM MUSICAL]


Carimbo de hora:

Mais de Segurança nua