Clique e arraste nas ondas sonoras abaixo para pular para qualquer ponto. Você também pode ouça diretamente no Soundcloud.

---

DOUG.   Patches, correções e crimelords - oh meu!

Ah, e mais um gerenciador de senhas nas notícias.

Tudo isso e muito mais no podcast Naked Security.

[MODEM MUSICAL]

Bem-vindos ao podcast, pessoal.

Eu sou Paul Ducklin; ele é Doug Aamoth...

..acho que entendi isso ao contrário, Paul: *Eu* sou Doug Aamoth; *ele* é Paul Ducklin.

Paul, nós gostamos de começar o show com um Esta semana na história da tecnologia segmento.

E eu gostaria de apresentar algo da história muito recente.

Esta semana, em 06 de fevereiro de 2023, nosso próprio Paul Ducklin…

---

PATO.   [ENCANTADO] Uau!

---

DOUG.   ...publicou uma entrevista com jornalista de tecnologia Andy Greenberg sobre seu novo livro, "Tracers in the Dark - the Global Hunt for the Crime Lords of Cryptocurrency".

Vamos ouvir um clipe rápido…

[STING MUSICAL]

---

---

[STING MUSICAL]

PATO.   Eu sei que diria isso, Doug, mas recomendo fortemente ouvir isso Podcast.

Ou, se preferir ler, veja a transcrição, porque…

…como eu disse a Andy no final, foi tão fascinante falar com ele quanto ler o livro em primeiro lugar.

Eu recomendo totalmente o livro, e ele tem alguns insights incríveis sobre coisas como backdoors criptográficos que vêm não apenas da opinião, mas de como a aplicação da lei lidou, aparentemente de maneira muito eficaz, com crimes cibernéticos, sem precisar atropelar nossa privacidade, talvez como tanto quanto algumas pessoas acham que é necessário.

Então, alguns insights fascinantes, Doug:

Rastreadores no escuro: a caçada global aos senhores do crime da criptografia

---

DOUG.   Dá uma olhada... está no padrão Feed de podcast Naked Security.

Se você está recebendo nosso podcast, esse deve ser o anterior a este.

E vamos agora passar para uma rodada relâmpago de correções e atualizações.

Temos OpenSSL. temos o VMware e temos o OpenSSH.

Vamos começar com VMware. Paulo:

Usuário VMware? Preocupado com o “ESXi ransomware”? Verifique seus patches agora!

---

PATO.   Isso se tornou uma grande história, eu acho, por causa de um boletim que foi divulgado pelo francês CERT (Computer Emergency Response Team) na sexta-feira da semana passada.

Então. isso seria 03 de fevereiro de 2023.

Eles simplesmente contaram como era: “Ei, existem essas vulnerabilidades antigas no VMware ESXi que você poderia ter corrigido em 2000 e 2021, mas algumas pessoas não o fizeram e agora os bandidos estão abusando delas. Surpresa, surpresa: o resultado final é igual a ransomware.”

Eles não colocaram bem assim... mas esse era o propósito do boletim.

Isso meio que se transformou em uma tempestade de notícias de [VOZ SURPREENDIDA], “Oh, não! Bug gigante no VMware!”

Parece que as pessoas estão inferindo: “Oh, não! Há um novo dia zero! É melhor eu jogar tudo fora e ir dar uma olhada!

E, de certa forma, é pior do que um dia zero, porque se você corre o risco de um ataque específico de uma gangue cibernética de butique, terminando em ransomware…

…você está vulnerável há dois anos.

---

DOUG.   Um dia de 730, na verdade…

---

PATO.   Exatamente!

Então eu escrevi o artigo para explicar qual era o problema.

Também descompilei e analisei o malware que eles estavam usando no final.

Porque acho que o que muitas pessoas leram nessa história é: “Uau, há um grande bug no VMware e está levando ao ransomware. Portanto, se eu for corrigido, não preciso fazer nada e o ransomware não acontecerá.”

E os problemas são que esses buracos podem ser usados, essencialmente, para obter acesso root em caixas ESXi, onde os bandidos não precisam usar ransomware.

Eles podem roubar dados, enviar spam, keylogging, criptomineração, {insira aqui o cibercrime menos favorito}.

E a ferramenta de ransomware que esses bandidos estão usando, que é semiautomática, mas pode ser usada manualmente, é um embaralhador de arquivos autônomo projetado para embaralhar arquivos realmente grandes rapidamente.

Portanto, eles não estão totalmente criptografados – eles o configuraram para criptografar um megabyte, pular 99 MB, criptografar um megabyte, pular 99 MB…

…portanto, ele passará por um VMDK (arquivo de imagem de máquina virtual) de vários gigabytes ou até terabytes muito, muito rapidamente.

E eles têm um script que executa essa ferramenta de criptografia para cada imagem VMware que encontrar, tudo em paralelo.

Obviamente, qualquer pessoa pode implantar essa ferramenta específica *sem invadir a vulnerabilidade do VMware*.

Portanto, se você não for corrigido, isso não terminará necessariamente em ransomware.

E se você for corrigido, essa não é a única maneira de os bandidos entrarem.

Portanto, é útil se informar sobre os riscos desse ransomware e como você pode se defender contra ele.

---

DOUG.   Ok, muito bom.

Então nós temos um pokeable bug de memória duplamente livre em OpenSSH.

É divertido dizer isso…

OpenSSH corrige bug de memória duplamente livre que pode ser acessado pela rede

---

PATO.   É, Doug.

E pensei: “É muito divertido de entender”, então escrevi isso no Naked Security como uma forma de ajudá-lo a entender um pouco desse jargão de bug relacionado à memória.

É um problema bastante esotérico (provavelmente não afetará você se você usar o OpenSSH), mas ainda acho que é uma história interessante, porque [A] porque a equipe do OpenSSH decidiu que iria divulgá-lo em suas notas de lançamento, “É não tem um número CVE, mas é assim que funciona de qualquer maneira,” e [B] é um ótimo lembrete de que bugs de gerenciamento de memória, especialmente quando você está codificando em C, podem acontecer até mesmo para programadores experientes.

Este é um double-free, que é o caso em que você termina com um bloco de memória, então o devolve ao sistema e diz: “Você pode passar isso para outra parte do meu programa. Para mim chega."

E então, mais tarde, em vez de usar o mesmo bloco novamente depois de desistir (o que seria obviamente ruim), você devolve a memória novamente.

E soa como: “Bem, qual é o mal feito? Você só está se certificando.

É como voltar correndo do estacionamento para o seu apartamento e subir e verificar: “Eu realmente desliguei o forno?”

Não importa se você voltar e ele estiver desligado; só importa se você voltar e descobrir que não o desligou.

Então, qual é o problema de um double-free?

O problema, é claro, é que isso pode confundir o sistema subjacente, e isso pode fazer com que a memória de outra pessoa seja mal administrada ou mal administrada de uma forma que os criminosos possam explorar.

Portanto, se você não entende como tudo isso funciona, acho que esta é uma leitura interessante, talvez até importante…

…mesmo que o bug seja razoavelmente esotérico e, até onde sabemos, ninguém descobriu uma maneira de explorá-lo ainda.

---

DOUG.   Por último, mas certamente não menos importante, há uma alta gravidade bug de roubo de dados no OpenSSL isso foi corrigido.

E eu gostaria de encorajar as pessoas, se você for como eu, razoavelmente técnico, mas avesso ao jargão…

…as notas oficiais estão repletas de jargões, mas, Paul, você faz um trabalho magistral de traduzir esse jargão para o inglês simples.

Incluindo um explicador dinamite de como os bugs de memória funcionam, incluindo: cancelamento de referência NULL, cancelamento de referência de ponteiro inválido, estouro de buffer de leitura, use-after-free, double-free (sobre o qual acabamos de falar) e mais:

OpenSSL corrige bug de roubo de dados de alta gravidade – corrija agora!

---

PATO.   [PAUSA] Bem, você me deixou um pouco sem palavras, Doug.

Muito obrigado por suas amáveis ​​palavras.

Escrevi este por... Eu ia dizer duas razões, mas meio que três razões.

A primeira é que OpenSSH e OpenSSL são duas coisas completamente diferentes – são dois projetos de código aberto completamente diferentes executados por equipes diferentes – mas ambos são amplamente usados.

Portanto, o bug do OpenSSL em particular provavelmente se aplica a você em algum lugar de sua propriedade de TI, porque algum produto que você possui em algum lugar quase certamente o inclui.

E se você tem uma distribuição Linux, a distribuição provavelmente também fornece sua própria versão - meu Linux foi atualizado no mesmo dia, então você deve verificar por si mesmo.

Então, eu queria conscientizar as pessoas sobre os novos números de versão.

E, como dissemos, havia uma carga vertiginosa de jargão que achei que valia a pena explicar… por que até as pequenas coisas importam.

E há um bug de alta gravidade. (não vou explicar confusão de tipos aqui – vá para o artigo se quiser algumas analogias sobre como isso funciona.)

E este é um caso em que um invasor, talvez, seja capaz de acionar o que parecem ser comparações de memória perfeitamente inocentes, onde eles estão apenas comparando esse buffer de memória com aquele buffer de memória…

…mas eles direcionam mal um dos buffers e, vejam só, eles podem descobrir o que está no *seu* buffer comparando-o com coisas conhecidas que eles colocaram no *deles*.

Em teoria, você poderia abusar de um bug como esse no que você pode chamar de meio Heartbleed.

Tenho certeza de que todos nos lembramos disso, se nossas carreiras de TI remontam a 2014 ou antes - o Bug do OpenSSL Heartbleed, onde um cliente poderia fazer ping em um servidor e dizer: “Você ainda está vivo?”

“Heartbleed heartache” – você deveria REALMENTE mudar todas as suas senhas imediatamente?

E enviaria uma mensagem de volta que incluía até 64 kilobytes de dados extras que possivelmente incluíam os segredos de outras pessoas por engano.

E esse é o problema com bugs de vazamento de memória, ou possíveis bugs de vazamento de memória, em produtos criptográficos.

Eles, por definição, geralmente têm muito mais a esconder do que os programas tradicionais!

Então, vá e leia isso e definitivamente corrija assim que puder.

---

DOUG.   Não acredito que Heartbleed foi em 2014.

Isso parece... Eu só tinha um filho quando isso saiu e ele era um bebê, e agora tenho mais dois.

---

PATO.   E mesmo assim ainda falamos sobre isso...

---

DOUG.   Falando Sério!

---

PATO.   …como um lembrete definidor de por que um simples estouro de buffer de leitura pode ser bastante catastrófico.

Porque muitas pessoas tendem a pensar: "Oh, bem, certamente isso é muito menos prejudicial do que um estouro de buffer de *gravação*, onde posso injetar shellcode ou desviar o comportamento de um programa?"

Certamente, se eu puder apenas ler as coisas, bem, posso descobrir seus segredos ... isso é ruim, mas não me permite obter acesso root e controlar sua rede.

Mas, como muitas violações de dados recentes provaram, às vezes, ser capaz de ler coisas de um servidor pode revelar segredos que permitem que você faça login em vários outros servidores e faça coisas muito mais travessas!

---

DOUG.   Bem, essa é uma ótima continuação sobre segredos e coisas perversas.

Temos uma atualização para uma história de Passado de Segurança Nua.

Você deve se lembrar da história do final do ano passado sobre alguém invadindo uma empresa de psicoterapia e roubando um monte de transcrições de sessões de terapia, usando essas informações para extorquir os pacientes dessa empresa.

Bem, ele fugiu... e estava apenas recentemente preso na França:

Suspeito finlandês de extorsão por psicoterapia é preso na França

---

PATO.   Este foi um crime verdadeiramente feio.

Ele não apenas invadiu uma empresa e roubou um monte de dados.

Ele invadiu uma empresa de *psicoterapia* e, duplamente, infelizmente, essa empresa foi totalmente negligente, ao que parece, em sua segurança de dados.

Na verdade, seu ex-CEO está com problemas com as autoridades sob acusações de que eles próprios poderiam resultar em uma sentença de prisão, porque eles simplesmente tinham todas essas informações de dinamite que realmente deviam proteger seus pacientes, e não o fizeram.

Eles o colocaram em um servidor de nuvem com uma senha padrão, aparentemente, onde o bandido o encontrou.

Mas é a natureza de como a violação se desenrolou que foi realmente terrível.

Ele chantageou a empresa... Acho que ele disse: “Quero € 450,000 ou vou derramar todos os dados”.

E, claro, a empresa estava mantendo o schtumm sobre isso - é por isso que os reguladores decidiram ir atrás da empresa também.

Eles ficaram quietos sobre isso, esperando que ninguém descobrisse, e aí vem esse cara dizendo: “Pague-nos o dinheiro, ou então.”

Bem, eles não iriam pagá-lo.

Não adiantava: ele já tinha a data e já estava fazendo coisas ruins com ela.

E então, como você disse, os bandidos decidiram: “Bem, se não consigo tirar € 450,000 da empresa, por que não tento atingir cada pessoa que fez psicoterapia por € 200 cada?”

De acordo com o conhecido jornalista ciberdetetive Brian Krebs, sua nota de extorsão dizia: “Você tem 24 horas para me pagar 200 euros. Então dou-lhe 48 horas para pagar 500€. E se eu não tiver notícias suas depois de 72 horas, contarei a seus amigos e familiares e a qualquer um que queira saber as coisas que você disse.

Porque esses dados incluíam transcrições, Doug.

Por que diabos eles estavam armazenando essas coisas por padrão em primeiro lugar?

Eu nunca vou entender isso.

Como você disse, ele fugiu do país e foi preso “à revelia” pelos finlandeses; que lhes permitiu emitir um mandado de prisão internacional.

De qualquer forma, agora ele está enfrentando a música na França, onde, é claro, os franceses estão tentando extraditá-lo para a Finlândia, e os finlandeses estão tentando colocá-lo no tribunal.

Aparentemente, ele tem forma [equivalente nos EUA: priores] por esta. Doug.

Ele já foi condenado por crimes cibernéticos antes, mas naquela época ele era menor de idade.

Ele agora tem 25 anos, eu acredito; naquela época ele tinha 17 anos, então ele teve uma segunda chance.

Ele recebeu uma pena suspensa e uma pequena multa.

Mas se essas alegações estiverem corretas, acho que muitos de nós suspeitamos que ele não se safará tão facilmente desta vez, se for condenado.

---

DOUG.   Portanto, este é um bom lembrete de que você pode ser – se você for como esta empresa – a vítima *e* o culpado.

E mais um lembrete de que você precisa ter um plano em prática.

Então, temos alguns conselhos no final do artigo, começando por: Ensaie o que você fará se sofrer uma violação.

Você tem que ter um plano!

---

PATO.   Absolutamente.

Você não pode compensar à medida que avança, porque simplesmente não haverá tempo.

---

DOUG.   E também, se você é uma pessoa afetada por algo assim: Considere preencher um relatório, porque isso ajuda na investigação.

---

PATO.   Na verdade, ele faz.

Meu entendimento é que, neste caso, muitas pessoas que receberam essas demandas de extorsão *foram* às autoridades e disseram: “Isso veio do nada. Isso é como ser agredido na rua! O que você vai fazer sobre isso?

As autoridades disseram: “Ótimo, vamos coletar os relatórios”, e isso significa que eles podem construir um caso melhor e fazer um caso mais forte para algo como a extradição.

---

DOUG.   Tudo bem, muito bom.

Terminaremos nosso show com: “Outra semana, outro gerenciador de senhas na berlinda.”

Desta vez é KeePass.

Mas essa confusão em particular não é tão direta, Paul:

“Vulnerabilidade” de roubo de senha relatada no KeePass – bug ou recurso?

---

PATO.   Na verdade, Doug, acho que você poderia dizer que é muito direto... e imensamente complicado ao mesmo tempo. [RISOS]

---

DOUG.   [RISOS] OK, vamos falar sobre como isso realmente funciona.

O recurso em si é uma espécie de recurso de automação, um tipo de script…

---

PATO.   “Gatilho” é o termo a ser pesquisado – é assim que eles chamam.

Então, por exemplo, quando você salva o arquivo de banco de dados [KeePass], por exemplo (talvez você tenha atualizado uma senha ou gerado uma nova conta e aperte o botão salvar), não seria bom se você pudesse chamar um script personalizado próprio que sincroniza esses dados com algum backup na nuvem?

Em vez de tentar escrever código no KeePass para lidar com todos os sistemas de upload em nuvem possíveis no mundo, por que não fornecer um mecanismo onde as pessoas possam personalizá-lo, se quiserem?

Exatamente o mesmo quando você tenta usar uma senha... você diz: “Quero copiar essa senha e usá-la”.

Não seria bom se você pudesse chamar um script que obtém uma cópia da senha em texto sem formatação, para que possa usá-la para fazer login em contas que não são tão simples quanto apenas colocar os dados em um formulário da web que está em sua tela?

Isso pode ser algo como sua conta do GitHub, ou sua conta de Integração Contínua, ou o que quer que seja.

Essas coisas são chamadas de “gatilhos” porque são projetadas para serem acionadas quando o produto faz certas coisas.

E algumas dessas coisas – inevitavelmente, porque é um gerenciador de senhas – lidam com o manuseio de suas senhas.

Os pessimistas acham que, “Bem, esses gatilhos, eles são muito fáceis de configurar, e adicionar um gatilho não é protegido por uma senha de proteção contra violação”.

Você precisa inserir uma senha mestra para obter acesso às suas senhas, mas não precisa inserir a senha mestra para obter acesso ao arquivo de configuração para obter acesso às senhas.

Acho que é daí que vêm os pessimistas.

E outras pessoas estão dizendo: “Sabe de uma coisa? Eles precisam obter acesso ao arquivo de configuração. Se eles conseguiram isso, você já está em apuros!

---

DOUG.   “As pessoas” incluem KeePass, que está dizendo: “Este programa não está configurado para se defender contra alguém [RISOS] que está sentado em sua cadeira quando você já fez login em sua máquina e no aplicativo”.

---

PATO.   De fato.

E acho que a verdade provavelmente está em algum lugar no meio.

Eu posso ver o argumento porque, se você vai ter as senhas protegidas com a senha mestra... por que você não protege o arquivo de configuração também?

Mas também concordo com as pessoas que dizem: “Sabe de uma coisa? Se eles fizeram login na sua conta e estão no seu computador, e já são você, você meio que já ficou em segundo lugar na corrida.

Então não faça isso!

---

DOUG.   [Risos] OK, então se diminuirmos um pouco essa história…

…Leitor do Naked Security, Richard pergunta:

Um gerenciador de senhas, não importa qual, é um ponto único de falha? Por design, é um alvo de alto valor para um hacker. E a presença de qualquer vulnerabilidade permite que um invasor acumule cada senha no sistema, independentemente da força fictícia dessas senhas.

Acho que essa é uma pergunta que muitas pessoas estão fazendo agora.

---

PATO.   De certa forma, Doug, essa é uma pergunta sem resposta.

Um pouco como esse “gatilho” no arquivo de configuração do KeePass.

É um bug, ou é um recurso, ou temos que aceitar que é um pouco dos dois?

Acho que, como outro comentarista disse no mesmo artigo, há um problema em dizer: “Um gerenciador de senhas é um ponto único de falha, então não vou usar um. O que vou fazer é pensar em *uma* senha muito, muito complicada e vou usá-la em todos os meus sites.”

Que é o que muitas pessoas fazem se não estiverem usando um gerenciador de senhas… e em vez de ser um *potencial* ponto único de falha, isso cria algo que é exatamente, absolutamente *e já* um único ponto de falha.

Portanto, um gerenciador de senhas é certamente o menor de dois males.

E acho que há muita verdade nisso.

---

DOUG.   Sim, eu diria que acho que *pode* ser um ponto único de falha, dependendo dos tipos de contas que você mantém.

Mas para muitos serviços, não é e não deve ser um ponto único de falha *total*.

Por exemplo, se minha senha bancária for roubada e alguém acessar minha conta bancária, meu banco verá que está acessando do outro lado do mundo e dirá: “Uau! Espere um segundo! Isso parece estranho.

E eles me fazem uma pergunta de segurança ou me enviam por e-mail um código secundário que devo inserir, mesmo que não esteja configurado para 2FA.

A maioria das minhas contas importantes... Não me preocupo muito com essas credenciais, porque haveria um segundo fator automático que eu teria que ignorar porque o login pareceria suspeito.

E espero que a tecnologia seja tão fácil de implementar que qualquer site que mantenha qualquer tipo de dados tenha isso embutido: “Por que essa pessoa está fazendo login da Romênia no meio da noite, quando normalmente está em Boston?”

Muitos desses mecanismos de segurança existem para coisas importantes que você pode manter online, então espero que não seja um ponto único de falha nesse sentido.

---

PATO.   Esse é um ótimo ponto, Doug, e acho que meio que ilustra que há, se você preferir, uma questão candente por trás da pergunta, que é: “Por que precisamos de tantas senhas em primeiro lugar?”

E talvez uma maneira de seguir em direção a um futuro sem senha seja simplesmente permitir que as pessoas usem sites onde possam escolher *não* ter a (aspas aéreas) “gigantesca conveniência” de precisar criar uma conta em primeiro lugar.

---

DOUG.   [Risos tristes] Como discutimos, fui afetado pela violação do LastPass e olhei para minha lista gigante de senhas e disse: "Oh, meu Deus, tenho que mudar todas essas senhas!"

Acontece que tive que *mudar* metade dessas senhas e, pior, tive que *cancelar* a outra metade dessas contas, porque eu tinha tantas contas lá…

…só pelo que você disse; “Tenho que criar uma conta apenas para acessar algo neste site.”

E eles não são apenas clicar e cancelar.

Alguns, você tem que ligar.

Alguns, você tem que falar com alguém no chat ao vivo.

Foi muito mais árduo do que apenas alterar um monte de senhas.

Mas eu gostaria de pedir às pessoas, quer você esteja usando um gerenciador de senhas ou não, dê uma olhada apenas no número de contas que você possui e exclua aquelas que você não está mais usando!

---

PATO.   Sim.

Em três palavras, “menos é mais”.

---

DOUG.   Sem dúvida que sim!

Tudo bem, muito obrigado, Richard, por enviar isso.

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 email [email protegido], você pode comentar 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]