S3 Ep112: Violações de dados podem assombrá-lo mais de uma vez! [Áudio + Texto]

Nó Fonte: 1769637

VIOLAÇÕES DE DADOS - A FERIDA NA CAUDA

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.  Troca de SIM, dia zero, a [voz dramática] Ping of DEATH e LastPass… de novo.

Tudo isso e muito mais no podcast Naked Security.

[MODEM MUSICAL]

Sejam todos bem-vindos ao podcast.

Eu sou Doug Aamoth.

Comigo, como sempre, está Paul Ducklin.

Paulo, como vai?


PATO.  Muito bem, Doug.

Você colocou um som dramático nessa introdução, fico feliz em ver!


DOUG.  Bem, como você diz “Ping of Death” sem dizer [doom metal growl] “Ping of DEATH”?

Você não pode simplesmente dizer [voz gentil] “Ping of Death”.

Tem que socar um pouco...


PATO.  Eu suponho que sim.

É diferente na escrita – o que você tem?

Negrito e itálico.

Acabei de usar texto normal, mas usei letras maiúsculas, o que ajuda.


DOUG.  Sim, acho que colocaria em negrito e itálico a palavra “morte”, então [doom metal novamente] “The Ping of DEATH”.


PATO.  E use várias cores!

Farei isso da próxima vez, Doug.


DOUG.  Quebre o velho tag em HTML, fazê-la piscar um pouco? [RISOS]


PATO.  Doug, por um momento, fiquei preocupado que você fosse usar a palavra [risos] .


DOUG.  [RISOS] Nós amamos coisas antigas aqui!

E isso se encaixa muito bem com o nosso Esta semana na história da tecnologia segmento – Estou empolgado com este porque não tinha ouvido falar dele, mas me deparei com ele.

Esta semana, em 04 de dezembro de 2001, o worm Goner vasculhou a internet em um ritmo que só perde para o vírus Love Bug.

Goner se espalhou pelo Microsoft Outlook e prometeu às vítimas inocentes um divertido protetor de tela quando executado.


PATO.  Caso perdido…

Acho que ganhou esse nome porque tinha um pop-up no final, não tinha, que mencionava o Pentágono?

Mas era para ser um trocadilho – era “Penta/Gone”.

Esse certamente foi o worm que lembrou às pessoas que, na verdade, os protetores de tela do Windows são apenas programas executáveis.

Então, se você estava procurando especialmente por .EXE arquivos, bem, eles podem ser agrupados em .SCR (protetor de tela) arquivos também.

Se você confiasse apenas em nomes de arquivos, poderia ser facilmente enganado.

E muitas pessoas foram, infelizmente.


DOUG.  Tudo bem, vamos da velha escola para a nova escola.

Estamos falando do LastPass: houve uma violação; a violação em si não foi terrível; mas essa violação agora levou a outra violação.

Ou talvez seja apenas uma continuação da violação original?

LastPass admite violação de dados de clientes causada por violação anterior


PATO.  Sim, o LastPass escreveu sobre isso essencialmente como uma continuação da violação anterior, que acho que foi em agosto de 2022, não foi?

E como dissemos na época, foi um visual muito embaraçoso para o LastPass.

Mas, no que diz respeito às violações, provavelmente foi pior para suas relações públicas, marketing e (eu acho) para seus departamentos de propriedade intelectual, porque parece que a principal coisa que os bandidos conseguiram foi o código-fonte de seu sistema de desenvolvimento.

E o LastPass foi rápido em tranquilizar as pessoas…

Em primeiro lugar, suas investigações sugeriram que, enquanto estavam lá, os bandidos não foram capazes de fazer nenhuma alteração não autorizada que pudesse posteriormente se infiltrar no código real.

Em segundo lugar, o acesso ao sistema de desenvolvimento não dá acesso ao sistema de produção, onde o código real é criado.

E em terceiro lugar, eles puderam dizer que parecia que nenhum cofre de senha criptografada foi roubado, então o armazenamento em nuvem de suas senhas criptografadas não foi acessado.

E mesmo que tivesse sido acessado, só você saberia a senha, porque a descriptografia (o que você chamou de “trabalho pesado” quando falamos sobre isso no podcast) é realmente feita na memória de seus dispositivos – o LastPass nunca vê seu senha.

E então, em quarto lugar, eles disseram, tanto quanto podemos dizer, como resultado dessa violação, algumas das coisas que estavam no ambiente de desenvolvimento agora deram o mesmo… ou possivelmente uma carga completamente diferente de bandidos que compraram o dados roubados do lote anterior, quem sabe?

Isso permitiu que eles entrassem em algum serviço de nuvem onde algum conjunto aparentemente desconhecido de dados do cliente foi roubado.

Eu não acho que eles saibam ainda, porque pode demorar um pouco para descobrir o que realmente foi acessado depois que uma violação aconteceu.

Portanto, acho justo dizer que esse é o lado B da violação original.


DOUG.  Tudo bem, sugerimos que se você for cliente LastPass, fique atento ao relatório de incidentes de segurança da empresa.

Vamos ficar de olho nessa história, pois ela ainda está em desenvolvimento.

E se você, como Paul e eu, luta contra o cibercrime para viver, há algumas lições excelentes a serem aprendidas com a violação do Uber.

Então, esse é um episódio de podcast – um “minisódio” – com Chester Wisniewski que Paul incorporou na parte inferior do artigo do LastPass:

S3 Ep100.5: violação Uber – um especialista fala [Áudio + Texto]

Muito a aprender nessa frente!


PATO.  Como você disse, é uma ótima escuta, porque é, acredito, o que é conhecido na América como “conselho acionável” ou “notícias que você pode usar”.


DOUG.  [RISOS] Maravilhoso.

Falando em notícias que você realmente não pode usar, a Apple geralmente não fala sobre suas atualizações de segurança… e houve uma atualização de segurança:

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


PATO.  Oh, Doug, esse é um dos seus melhores… Eu gosto dessa sequência.


DOUG.  [RISOS] Obrigado; Muito obrigado.


PATO.  Sim, isso me surpreendeu.

Pensei: “Bem, vou pegar a atualização porque parece sério”.

E eu me dei o motivo: “Deixe-me fazer isso pelos leitores do Naked Security”.

Porque se eu fizer isso e não houver efeitos colaterais, posso pelo menos dizer a outras pessoas: “Olha, eu fiz isso cegamente e nenhum mal me aconteceu. Então talvez você possa fazer isso também.

De repente, percebi que havia uma atualização do iOS 16.1.2 disponível, embora eu não tivesse recebido nenhum e-mail de aviso de segurança da Apple.

Sem e-mail?!

Isso é estranho .. então eu fui para o HT201222 página do portal que a Apple tem para seus boletins de segurança, e lá estava: iOS 16.1.2.

E o que diz, Doug, “Detalhes seguirão em breve”?


DOUG.  E eles seguiram logo?


PATO.  Bem, isso foi há mais de uma semana, e eles ainda não chegaram lá.

Então, estamos falando de “em breve” significando horas, dias, semanas ou meses?

No momento, parece semanas.

E, como sempre acontece com a Apple, não há indicação de nada a ver com nenhum outro sistema operacional.

Eles foram esquecidos?

Eles não precisam da atualização?

Eles também precisavam da atualização, mas ainda não está pronta?

Eles foram retirados do suporte?

Mas parecia, como eu disse na manchete, ainda mais discreto do que o normal para a Apple, e não necessariamente a coisa mais útil do mundo.


DOUG.  OK, muito bem… ainda algumas perguntas, o que nos leva à nossa próxima história.

Uma pergunta muito interessante!

Às vezes, quando você se inscreve em um serviço e ele aplica a autenticação de dois fatores, ele diz: “Você deseja ser notificado por mensagem de texto ou deseja usar um aplicativo de autenticação?”

E esta história é um alerta para não usar seu telefone – use um aplicativo de autenticação, mesmo que seja um pouco mais complicado.

Esta é uma história muito interessante:

SIM swapper enviado para a prisão por roubo de criptomoeda 2FA de mais de $ 20 milhões


PATO.  É, Doug!

Se você já perdeu um celular ou bloqueou seu cartão SIM digitando o PIN incorretamente muitas vezes, você sabe que pode entrar na loja de celulares…

… e geralmente eles pedem uma identidade ou algo assim, e você diz: “Ei, preciso de um novo cartão SIM.”

E eles vão gerar um para você.

Quando você o coloca em seu telefone, bingo!... tem seu antigo número nele.

Então, o que isso significa é que, se um bandido pode passar pelo mesmo exercício que você faria para convencer a empresa de telefonia móvel de que ele “perdeu” ou “quebrou” seu cartão SIM (ou seja, *seu cartão SIM*), e eles podem obter aquele cartão entregue, ou enviado, ou dado a eles de alguma forma...

…então, quando eles o conectam ao telefone, eles começam a receber seus códigos de autenticação de dois fatores por SMS, *e* seu telefone para de funcionar.

Essa é a má notícia.

A boa notícia neste artigo é que este foi o caso de um sujeito que foi preso por isso.

Ele foi enviado para a prisão nos EUA por 18 meses.

Ele, com um bando de cúmplices – ou, nas palavras do Ministério da Justiça, o Participantes do Esquema… [RISOS]

…eles fugiram com a criptomoeda de uma vítima em particular, aparentemente no valor de $ 20 milhões, se você não se importa.


DOUG.  Aff!


PATO.  Então ele concordou em se declarar culpado, pegar uma sentença de prisão e imediatamente perder... a quantia era [lendo com atenção] $ 983,010.72... apenas para perder isso imediatamente.

Então, presumivelmente, ele tinha isso por aí.

E ele aparentemente também tem algum tipo de obrigação legal de reembolsar mais de US$ 20 milhões.


DOUG.  Boa sorte com isso, pessoal! Boa sorte.

Seu outro [itálico vocal] Participantes do Esquema pode causar alguns problemas lá! [RISOS]


PATO.  Sim, não sei o que acontece se eles também se recusarem a cooperar.

Tipo, se eles apenas o pendurarem para secar, o que acontece?

Mas temos algumas dicas e alguns conselhos sobre como reforçar a segurança (em mais maneiras do que apenas o 2FA que você usa) no artigo.

Então vá e leia isso ... cada pedacinho ajuda.


DOUG.  OK, falando em “pequenos pedaços”…

…esta foi outra história fascinante, como os humildes ping pode ser usado para acionar a execução remota de código:

Pingo da morte! FreeBSD corrige bug crashtastic na ferramenta de rede


PATO.  [Gostando da continuação de novo] Acho que você se superou, Doug!


DOUG.  [RISOS] Estou em alta hoje...


PATO.  Da Apple à [tentativa fraca de vocais doom] Ping of DEATH!

Sim, este foi um bug intrigante.

Eu não acho que isso realmente causará muito dano a muitas pessoas, e ele *está* corrigido, então consertar é fácil.

Mas há um ótimo artigo no FreeBSD assessoria de segurança...

… e é uma história divertida e, se assim posso dizer, muito informativa para a atual geração de programadores que podem ter confiado em “Bibliotecas de terceiros farão isso por mim. Lidando com pacotes de rede de baixo nível? Eu nunca tenho que pensar sobre isso...”

Há algumas grandes lições a serem aprendidas aqui.

A ping O utilitário, que é a única ferramenta de rede que quase todo mundo conhece, recebe o nome de SONAR.

Você vai [faz barulho de filme submarino] ping, e então o eco volta do servidor na outra extremidade.

E este é um recurso embutido no Protocolo de Internet, IP, usando algo chamado ICMP, que é o Protocolo de Mensagem de Controle da Internet.

É um protocolo especial de baixo nível, muito inferior ao UDP ou TCP com o qual as pessoas provavelmente estão acostumadas, que é projetado exatamente para esse tipo de coisa: “Você está realmente vivo do outro lado, antes que eu me preocupe com o porquê seu servidor web não está funcionando?”

Existe um tipo especial de pacote que você pode enviar chamado “ICMP Echo”.

Então, você envia este pequeno pacote com uma mensagem curta (a mensagem pode ser o que você quiser), e ele simplesmente envia a mesma mensagem de volta para você.

É apenas uma maneira básica de dizer: “Se essa mensagem não retornar, a rede ou o servidor inteiro está inoperante”, em vez de dizer que há algum problema de software no computador.

Por analogia com o SONAR, o programa que envia essas requisições de eco é chamado... [pausa] Vou fazer o efeito sonoro, Doug... [falso ruído de filme submarino de novo] ping. [RISADA]

E a ideia é, você vai, digamos, ping -c3 (isso significa verificar três vezes) nakedsecurity.sophos.com.

Você pode fazer isso agora e deve obter três respostas, cada uma delas com um segundo de intervalo, dos servidores WordPress que hospedam nosso site.

E está dizendo que o site está ativo.

Não está dizendo que o servidor da web está ativo; não está dizendo que o WordPress está funcionando; não está dizendo que Naked Security está realmente disponível para leitura.

Mas pelo menos confirma que você pode ver o servidor e o servidor pode alcançá-lo.

E quem teria pensado que aquela pequena resposta de ping poderia atrapalhar o FreeBSD ping programa de tal forma que um servidor desonesto poderia enviar de volta uma mensagem armadilhada "Sim, estou vivo" que poderia, em teoria (apenas em teoria; acho que ninguém fez isso na prática) acionar a execução remota de código em seu computador.


DOUG.  Sim, isso é incrível; essa é a parte incrível.

Mesmo que seja uma prova de conceito, é uma coisa tão pequena!


PATO.  A ping O próprio programa recupera todo o pacote IP e deve dividi-lo em duas partes.

Normalmente, o kernel cuidaria disso para você, então você veria apenas a parte dos dados.

Mas quando você está lidando com o que é chamado soquetes crus, o que você recebe de volta é o cabeçalho do Protocolo da Internet, que diz apenas: “Ei, esses bytes vieram de tal e tal servidor.”

E então você recebe uma coisa chamada “ICMP Echo Reply”, que é a segunda metade do pacote que você recebe de volta.

Agora, esses pacotes normalmente têm apenas 100 bytes ou mais, e se for IPv4, os primeiros 20 bytes são o cabeçalho IP e o restante, seja o que for, é a resposta de eco.

Isso tem alguns bytes para dizer: “Esta é uma resposta de eco” e, em seguida, a mensagem original que saiu voltando.

E então a coisa óbvia a fazer, Doug, quando você conseguir, é dividi-lo em...

…o cabeçalho IP, que tem 20 bytes de comprimento, e o resto.

Adivinha onde está o problema?


DOUG.  Diga!


PATO.  O problema é que os cabeçalhos IP têm *quase sempre* 20 bytes de comprimento – na verdade, acho que nunca vi um que não tivesse.

E você pode dizer que eles têm 20 bytes porque o primeiro byte será hexadecimal 0x45.

O “4”” significa IPv4, e o “5”… “Ah, vamos usar isso para dizer o tamanho do cabeçalho.”

Você pega esse número 5 e o multiplica por 4 (para valores de 32 bits) e obtém 20 bytes.

…e esse é o tamanho de provavelmente seis sigmas de cabeçalhos IP que você verá em todo o mundo, Doug. [RISADA]

Mas eles *podem* ir até 60 bytes.

Se você colocar 0x4F em vez de 0x45, que diz que há 0xF (ou 15 em decimal) × 4 = 60 bytes no cabeçalho.

E o código do FreeBSD simplesmente pegou esse cabeçalho e o copiou em um buffer na pilha que tinha 20 bytes de tamanho.

Um estouro de buffer de pilha simples e antigo.

É o caso de uma venerável ferramenta de solução de problemas de rede com um venerável tipo de bug. (Bem, não mais.)

Portanto, quando você estiver programando e tiver que lidar com coisas de baixo nível nas quais ninguém realmente pensa há anos, não siga apenas a sabedoria recebida que diz: “Oh, sempre serão 20 bytes; você nunca verá nada maior.”

Porque um dia você pode.

E quando esse dia chegar, pode estar lá deliberadamente porque um vigarista o fez de propósito.

Então o diabo, como sempre, está nos detalhes da programação, Doug.


DOUG.  OK, muito interessante; boa história.

E continuaremos no assunto do código com esta história final sobre o Chrome.

Outro dia zero, que eleva o total de 2022 para nove vezes:

Número nove! O Chrome corrige outro dia zero de 2022, o Edge corrigido também


PATO.  [Voz formal, soando como uma gravação] “Número 9. Número 9. Número 9, número 9,” Douglas.


DOUG.  [RISOS] É Yoko Ono?


PATO.  É isso que o Revolução 9 do “Álbum Branco” dos Beatles.

Yoko pode ser ouvido fazendo riffs naquela música - aquela paisagem sonora, eu acredito que eles chamam isso - mas aparentemente a parte no começo onde há alguém dizendo “Número 9, número 9” repetidamente, era, na verdade, uma fita de teste que eles encontraram por aí.


DOUG.  Ah, muito legal.


PATO.  Um engenheiro da EMI dizendo algo como: “Esta é a fita de teste número 9 da EMI” [RISOS] e, aparentemente, acho que ninguém sabe de quem é a voz.

Isso não tem *nada* a ver com o Chrome, Doug.

Mas dado que alguém comentou no Facebook outro dia: “Aquele tal de Paul está começando a parecer um Beatle”… [interrogatório] o que achei um pouco estranho.


DOUG.  [RISOS] Sim, como você deve encarar isso?


PATO.  …Achei que poderia jantar fora no “Número 9”.

É o nono dia zero do ano até agora, Doug.

E é uma correção de um bug, com o bug identificado como CVE 2022-4282.

Como o Microsoft Edge usa o núcleo de código aberto Chromium, ele também estava vulnerável e, alguns dias depois, a Microsoft lançou uma atualização para o Edge.

Portanto, este é um problema do Chrome e do Edge.

Embora esses navegadores devam ser atualizados sozinhos, recomendo verificar de qualquer maneira – mostramos como fazer isso no artigo – apenas por precaução.

Não vou ler os números de versão aqui porque eles são diferentes para Mac, Linux e Windows no Chrome, e são diferentes novamente para o Edge.

Como a Apple, o Google está um pouco calado sobre isso.

Foi encontrado por um de sua equipe de caçadores de ameaças, eu acredito.

Então, imagino que eles o encontraram enquanto investigavam um incidente que aconteceu na selva e, portanto, provavelmente querem mantê-lo sob o chapéu, embora o Google geralmente tenha muito a dizer sobre “abertura” quando se trata de correção de bugs.

Você pode ver por que, em um caso como este, você pode querer um pouco de tempo para se aprofundar um pouco mais antes de dizer a todos exatamente como funciona.


DOUG.  Excelente… e temos uma pergunta do leitor que provavelmente é uma pergunta que muitas pessoas estão pensando.

Cassandra pergunta: “Os localizadores de bugs estão apenas tendo sorte em encontrar bugs? Ou eles encontraram uma 'costura' cheia de insetos? Ou o Chromium está emitindo um novo código com mais bugs do que o normal? Ou algo mais está acontecendo?”


PATO.  Sim, essa é uma ótima pergunta, na verdade, e temo que só poderia respondê-la de uma forma meio jocosa, Doug.

Como Cassandra havia dado as opções A), B) e C), eu disse: “Bem, talvez seja D) Todas as anteriores."

Sabemos que, quando um bug de um determinado tipo aparece no código, é razoável supor que o mesmo programador pode ter feito bugs semelhantes em outras partes do software.

Ou outros programadores da mesma empresa podem ter usado o que era considerado sabedoria recebida ou prática padrão na época e podem ter seguido o exemplo.

E um ótimo exemplo é, se você olhar para o Log4J… houve uma correção para corrigir o problema.

E então, quando eles foram procurar, “Oh, na verdade, existem outros lugares onde erros semelhantes foram cometidos”.

Então havia uma correção para a correção e, em seguida, havia uma correção para a correção para a correção, se bem me lembro.

É claro que também há o problema de que, ao adicionar um novo código, você pode obter bugs exclusivos desse novo código e surgir devido à adição de recursos.

E é por isso que muitos navegadores, incluindo o Chrome, têm uma versão “um pouco mais antiga” que você pode usar.

E a ideia é que esses lançamentos “antigos”… eles não tenham nenhum dos novos recursos, mas todas as correções de segurança relevantes.

Portanto, se você quiser ser conservador em relação aos novos recursos, pode ser.

Mas certamente sabemos que, às vezes, quando você adiciona novos recursos a um produto, novos bugs vêm com os novos recursos.

E você pode dizer isso, por exemplo, quando há uma atualização, digamos, para o seu iPhone, e você obtém atualizações, digamos, para iOS 15 e iOS 16.

Então, quando você olha para as listas de bugs, há alguns bugs que se aplicam apenas ao iOS 16.

E você pensa: “Olá, devem ser bugs no código que não existiam antes”.

Então, sim, é uma possibilidade.

E acho que as outras coisas que estão acontecendo podem ser consideradas boas.

A primeira é que eu acho que, particularmente para coisas como navegadores, os fabricantes de navegadores estão ficando muito melhores em lançar reconstruções completas muito, muito rapidamente.


DOUG.  Interessante.


PATO.  E acho que a outra coisa que mudou é que, no passado, você poderia argumentar que para muitos fornecedores... eles tinham várias correções de dia zero neles.

Eu acho que talvez seja também uma resposta ao fato de que cada vez mais de nós estamos cada vez mais propensos não apenas a aceitar, mas na verdade a *esperar* uma atualização automática que seja realmente rápida.

Então, acho que você pode ler algumas coisas boas nisso.

O fato não apenas de que o Google pode lançar uma única correção de dia zero quase instantaneamente, mas também de que as pessoas estão dispostas a aceitar isso e até exigi-lo.

Então eu gosto de ver aquela questão de “nossa, nove dias-zero no ano corrigidos individualmente!”…

…Gosto de pensar nisso mais como “copo meio cheio e cheio” do que “copo meio vazio e escorrendo por um pequeno orifício no fundo”. [RISADA]

Essa é a minha opinião.


DOUG.  Tudo bem, muito bom.

Obrigado pela pergunta, Cassandra.

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: Até a próxima…


AMBAS.  Fique seguro!

[MODEM MUSICAL]


Carimbo de hora:

Mais de Segurança nua