S3 Ep108: Você escondeu TRÊS BILHÕES de dólares em uma lata de pipoca?

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

DOUG.  Golpes do Twitter, Patch Tuesday e criminosos hackeando criminosos.

Tudo isso e muito mais no podcast Naked Security.

[MODEM MUSICAL]

Bem-vindos ao podcast, pessoal.

Eu sou Doug.

Ele é Paul Ducklin.

Paulo, como você está hoje?

---

PATO.  Muito bem, Doug.

Não tivemos o eclipse lunar aqui na Inglaterra, mas tive um breve vislumbre da lua cheia *cheia* através de uma pequena abertura nas nuvens que emergiu como o único buraco em toda a camada de nuvens no momento em que saí para dar uma olhada!

Mas não tínhamos aquela lua laranja como vocês tinham em Massachusetts.

---

DOUG.  Vamos começar o show com Esta semana na história da tecnologia… isso remonta.

Esta semana, em 08 de novembro de 1895, o professor de física alemão Wilhelm Röntgen se deparou com uma forma ainda não descoberta de radiação que o levou a se referir a essa radiação simplesmente como “X”.

Como no raio-X.

Que tal... a descoberta acidental de raios-X?

---

PATO.  Bastante surpreendente.

Lembro-me da minha mãe me dizendo: na década de 1950 (deve ter sido a mesma coisa nos Estados Unidos), aparentemente, em sapatarias…

---

DOUG.  [SABE O QUE ESTÁ POR VIR] Sim! [RISOS]

---

PATO.  As pessoas levavam seus filhos… você ficava nessa máquina, calçava os sapatos e, em vez de apenas dizer: “Ande por aí, eles são apertados? Eles beliscam?”, você estava em uma máquina de raios X, que basicamente o banhava em radiação de raios X, tirava uma foto ao vivo e dizia: “Ah, sim, eles são do tamanho certo”.

---

DOUG.  Sim, tempos mais simples. Um pouco perigoso, mas…

---

PATO.  UM POUCO PERIGOSO?

Você consegue imaginar as pessoas que trabalhavam nas sapatarias?

Eles devem ter se banhado em raios-X o tempo todo.

---

DOUG.  Com certeza... bem, estamos um pouco mais seguros hoje.

E no assunto de segurança, a primeira terça-feira do mês é o Patch Tuesday da Microsoft.

So o que aprendemos esta Patch Tuesday aqui em novembro de 2022?

Troca de 0 dias corrigido (finalmente) – mais 4 novos Patch Tuesday 0 dias!

---

PATO.  Bem, o mais empolgante, Doug, é que tecnicamente o Patch Tuesday fixou não um, nem dois, nem três… mas *quatro* dias zero.

Mas, na verdade, os patches que você pode obter para os produtos da Microsoft na terça-feira fixaram *seis* dias zero.

Lembre-se daqueles dias zero do Exchange que notoriamente não foram corrigidos na última Patch Tuesday: CVE-2002-41040 e CVE-2022-41082, que ficou conhecido como ProxyNotShell?

S3 Ep102.5: “ProxyNotShell” Troca bugs – um especialista fala [Áudio + Texto]

Bem, eles foram corrigidos, mas essencialmente em uma “linha lateral” separada para o Patch Tuesday: o Exchange November 2022 SU, ou Software Update, que apenas diz:

As atualizações de software do Exchange de novembro de 2022 contêm correções para as vulnerabilidades de dia zero relatadas publicamente em 29 de setembro de 2022.

Tudo o que você precisa fazer é atualizar o Exchange.

Puxa, obrigado Microsoft… Acho que sabíamos que era isso que teríamos que fazer quando os patches finalmente saíssem!

Então, eles *estão* fora e há dois dias zero fixos, mas não são novos e não estão tecnicamente na parte do “Patch Tuesday”.

Lá, temos outros quatro dias zero fixos.

E se você acredita em priorizar patches, então, obviamente, esses são aqueles com os quais você deseja lidar primeiro, porque alguém já sabe como fazer coisas ruins com eles.

Eles variam de um bypass de segurança a duas elevações de privilégio e uma execução remota de código.

Mas há mais de 60 patches no total, e se você olhar para a lista geral de produtos e componentes do Windows afetados, há uma lista enorme, como sempre, que abrange todos os componentes/produtos do Windows de que você já ouviu falar e muitos dos quais provavelmente não.

A Microsoft corrige 62 vulnerabilidades, incluindo Kerberos, Mark of the Web e Exchange…

Então, como sempre: Não demore/Faça hoje, Douglas!

---

DOUG.  Muito bom.

Vamos agora falar sobre um grande atraso…

Você tem uma história muito interessante sobre o Mercado de drogas da Rota da Seda, e um lembrete de que criminosos roubando criminosos ainda é um crime, mesmo que dez anos depois você realmente seja pego por isso.

Hacker do mercado de drogas do Silk Road se declara culpado e pode pegar 20 anos de prisão

---

PATO.  Sim, mesmo as pessoas que são muito novas na segurança cibernética ou no acesso à Internet provavelmente já ouviram falar do “Silk Road”, talvez o primeiro mercado da dark web conhecido, importante, amplamente utilizado e amplamente utilizado, onde basicamente vale tudo.

Então, tudo pegou fogo em 2013.

Porque o fundador, originalmente conhecido apenas como Terror Pirata Roberts, mas finalmente revelou ser Ross Ulbricht… sua pobre segurança operacional era suficiente para amarrar as atividades a ele.

O fundador do Silk Road, Ross Ulbricht, pega prisão perpétua sem liberdade condicional

Não só a segurança operacional dele não era muito boa, como parece que no final de 2012, eles tiveram (dá pra acreditar, Doug?) um erro no processamento de pagamento com criptomoeda…

---

DOUG.  [GASPS EM FALTA DE HORROR]

---

PATO.  …do tipo que a gente tem visto repetido muitas vezes desde então, que andava sem fazer uma contabilidade de partidas dobradas bem feita, onde para cada débito, tem um crédito correspondente e vice-versa.

E esse invasor descobriu que, se você colocasse algum dinheiro em sua conta e pagasse muito rapidamente para outras contas, poderia pagar cinco vezes (ou até mais) os mesmos bitcoins antes que o sistema percebesse que o primeiro débito havia desaparecido Através dos.

Então, basicamente, você poderia colocar algum dinheiro e depois retirá-lo repetidamente e obter um estoque maior…

…e então você pode voltar para o que você pode chamar de “ciclo de ordenha de criptomoeda”.

E estima-se... os investigadores não tinham certeza, que ele começou com entre 200 e 2000 bitcoins de sua autoria (se ele os comprou ou os minerou, não sabemos), e ele muito, muito rapidamente os transformou em, espere, Doug: 50,0000 bitcoins!

---

DOUG.  Wow!

---

PATO.  Mais de 50,000 bitcoins, simples assim.

E então, obviamente imaginando que alguém iria notar, ele cortou e correu enquanto estava à frente com 50,000 bitcoins…

…cada um valendo incríveis $ 12, acima das frações de um centavo apenas alguns anos antes. [RISOS]

Então ele fugiu com $ 600,000, assim, Doug.

[PAUSA DRAMÁTICA]

Nove anos depois…

[RISO]

…quase *exatamente* nove anos depois, quando ele foi preso e sua casa invadida sob um mandado, os policiais foram revistar e encontraram uma pilha de cobertores em seu armário, sob os quais estava escondida uma lata de pipoca.

Lugar estranho para guardar sua pipoca.

Dentro da qual havia uma espécie de carteira fria computadorizada.

Dentro do qual havia uma grande proporção dos referidos bitcoins!

Na época em que ele foi preso, os bitcoins valiam algo ao norte de US$ 65,535 (ou 2¹⁶-1 cada.

Eles subiram bem mais de mil vezes nesse ínterim.

Então, na época, foi a maior apreensão de criptomoedas de todos os tempos!

Nove anos depois, aparentemente incapaz de se desfazer de seus ganhos ilícitos, talvez com medo de que, mesmo que tentasse enfiá-los em um copo, todos os dedos apontassem para ele…

…ele tem todos esses $ 3 bilhões em bitcoins que estão parados em uma lata de pipoca há nove anos!

---

DOUG.  Minha nossa.

---

PATO.  Então, tendo sentado neste tesouro assustador por todos esses anos, imaginando se ele seria pego, agora ele fica se perguntando: “Quanto tempo vou ficar na prisão?”

E a pena máxima para a acusação que ele enfrenta?

20 anos, Douglas.

---

DOUG.  Outra história interessante acontecendo agora. Se você esteve no Twitter ultimamente, sabe que há muita atividade. dizê-lo diplomaticamente...

---

PATO.  [IMPERSONAÇÃO DE BOB DYLAN DE BAIXA A MÉDIA QUALIDADE] Bem, os tempos estão mudando.

---

DOUG.  …incluindo a certa altura a ideia de cobrar $ 20 por um cheque azul verificado, o que, é claro, quase imediatamente provocou alguns golpes.

Golpes de e-mail do Twitter Blue Badge – Não caia neles!

---

PATO.  É apenas um lembrete, Doug, de que sempre que houver algo que atraia muito interesse, os bandidos certamente o seguirão.

E a premissa disso era: “Ei, por que não chegar cedo? Se você já tem uma marca azul, adivinhe? Você não terá que pagar $ 19.99 por mês se fizer o pré-registro. Vamos deixar você ficar com ele.

Sabemos que não foi ideia de Elon Musk, como ele afirmou, mas é o tipo de coisa que muitas empresas fazem, não é?

Muitas empresas vão te dar algum tipo de benefício se você continuar com o serviço.

Portanto, não é totalmente inacreditável.

Como você diz... o que você deu?

B-menos, foi?

---

DOUG.  Dou ao e-mail inicial um B-menos... talvez você possa ser enganado se o ler rapidamente, mas há alguns problemas gramaticais; as coisas não parecem certas.

E então, quando você clicar, eu daria C-menos às páginas de destino.

Isso fica ainda mais difícil.

---

PATO.  Isso é algo entre 5/10 e 6/10?

---

DOUG.  Sim, digamos isso.

E temos alguns conselhos, de modo que, mesmo que seja um golpe A-plus, não importa, porque você poderá impedi-lo de qualquer maneira!

Começando com o meu favorito pessoal: Use um gerenciador de senhas.

Um gerenciador de senhas resolve muitos problemas quando se trata de golpes.

---

PATO.  Isso acontece.

Um gerenciador de senhas não possui nenhuma inteligência semelhante à humana que possa ser enganada pelo fato de que a imagem bonita está correta, ou o logotipo é perfeito, ou o formulário da web está exatamente na posição correta na tela com exatamente a mesma fonte , então você o reconhece.

Tudo o que sabe é: “Nunca ouvi falar deste site antes.”

---

DOUG.  E claro, ative o 2FA se puder.

Sempre adicione um segundo fator de autenticação, se possível.

---

PATO.  Claro, isso não necessariamente protege você de si mesmo.

Se você for a um site falso e decidir: “Ei, é pixel perfeito, deve ser o negócio real”, e estiver determinado a fazer login e já tiver inserido seu nome de usuário e sua senha, e então ele pede para você passar pelo processo 2FA…

…é muito provável que você faça isso.

No entanto, dá a você aquele tempinho para fazer o “Pare. Acho. Conectar." coisa e diga a si mesmo: "Espere, o que estou fazendo aqui?"

Portanto, de certa forma, o pequeno atraso que o 2FA introduz pode, na verdade, não ser apenas um incômodo muito pequeno, mas também uma maneira de realmente melhorar seu fluxo de trabalho de segurança cibernética... um pouco mais a sério.

Portanto, não vejo qual é a desvantagem, realmente.

---

DOUG.  E, claro, outra estratégia que é difícil para muitas pessoas seguirem, mas é muito eficaz, é evite links de login e botões de ação no e-mail.

Portanto, se você receber um e-mail, não basta clicar no botão… vá para o próprio site e você poderá dizer rapidamente se esse e-mail é legítimo ou não.

---

PATO.  Basicamente, se você não pode confiar totalmente na correspondência inicial, não pode confiar em nenhum detalhe dela, seja o link em que vai clicar, o número de telefone para o qual vai ligar, o endereço de e-mail para o qual vai entrar em contato com eles, a conta do Instagram para a qual você vai enviar DMs, seja lá o que for.

Não use o que está no e-mail... encontre seu próprio caminho e você causará um curto-circuito em muitos golpes desse tipo.

---

DOUG.  E por último, mas não menos importante… isso deveria ser senso comum, mas não é: Nunca pergunte ao remetente de uma mensagem incerta se ela é legítima.

Não responda e diga: “Ei, você é mesmo o Twitter?”

---

PATO.  Sim, você está certo.

Porque meu conselho anterior, “Não confie nas informações do e-mail”, como não ligar para o número de telefone... algumas pessoas ficam tentadas a dizer: “Bem, vou ligar para o número de telefone e ver se realmente são eles. [IRONIC] Porque, obviamente, se o cozinheiro responder, eles vão dar seus nomes verdadeiros.”

---

DOUG.  Como sempre dizemos: Em caso de dúvida/Não divulgue.

E este é um bom conto de advertência, esta próxima história: quando verificações de segurança, que são ferramentas de segurança legítimas, revelar mais do que deveriam, O que acontece depois?

Ferramentas de verificação de URL pública – quando a segurança leva à insegurança

---

PATO.  Este é um pesquisador conhecido chamado Fabian Bräunlein na Alemanha… já o apresentamos algumas vezes antes.

Ele está de volta com um relatório detalhado intitulado urlscan.io's spot SOAR: ferramentas de segurança tagarelas vazando dados privados.

E neste caso é urlscan.io, um site que você pode usar gratuitamente (ou como um serviço pago) onde você pode enviar uma URL, ou um nome de domínio, ou um número de IP, ou o que quer que seja, e você pode pesquisar: “O que a comunidade sabe sobre isso?"

E revelará o URL completo sobre o qual outras pessoas perguntaram.

E não se trata apenas de coisas que as pessoas copiam e colam por sua própria escolha.

Às vezes, o e-mail deles, por exemplo, pode estar passando por uma ferramenta de filtragem de terceiros que extrai URLs, liga para urlscan.io, faz a pesquisa, obtém o resultado e usa isso para decidir se deseja enviar lixo eletrônico, bloquear spam ou repassar a mensagem.

E isso significa que, às vezes, se a URL incluísse dados secretos ou semi-secretos, informações de identificação pessoal, outras pessoas que simplesmente procurassem o nome de domínio certo em um curto período de tempo veriam todas as URLs pesquisadas, incluindo coisas que podem estar no URL.

você sabe, como blahblah?username=doug&passwordresetcode= seguido por uma longa string de caracteres hexadecimais e assim por diante.

E Bräunlein apresentou uma lista fascinante do tipo de URLs, particularmente aqueles que podem aparecer em e-mails, que podem ser rotineiramente enviados a terceiros para filtragem e, em seguida, indexados para pesquisa.

O tipo de e-mail que ele considerou definitivamente explorável incluía, mas não se limitava a: links de criação de conta; Links de entrega de presentes da Amazon; chaves de API; Solicitações de assinatura DocuSign; transferências de arquivos dropbox; rastreamento de pacotes; redefinições de senha; faturas do PayPal; Compartilhamento de documentos do Google Drive; Convites do SharePoint; e links de cancelamento de assinatura do boletim informativo.

Não apontar dedos lá no SharePoint, Google Drive, PayPal, etc.

Esses foram apenas exemplos de URLs que ele encontrou que eram potencialmente exploráveis ​​dessa maneira.

---

DOUG.  Temos alguns conselhos no final desse artigo, que se resumem a: leia o relatório de Bräunlein; ler urlscan.iopostagem no blog de; faça uma revisão de código por conta própria; se você tiver um código que faça pesquisas de segurança online; saiba quais recursos de privacidade existem para envios online; e, mais importante, aprenda como relatar dados não autorizados a um serviço online, se você os vir.

Percebi que há três... tipos de limericks?

Mini-poemas muito criativos no final deste artigo…

---

PATO.  [MOCK HORROR] Não, eles não são limericks! Limericks têm uma estrutura de cinco linhas muito formal…

---

DOUG.  [Risos] Sinto muito. Isso é verdade!

---

PATO.  …tanto para a métrica quanto para a rima.

Muito estruturado, Doug!

---

DOUG.  Sinto muito, é verdade. [RISOS]

---

PATO.  Isso é apenas doggerel. [RISADA]

De novo: Em caso de dúvida/Não divulgue.

E se você estiver coletando dados: Se não deveria estar dentro/Coloque direto na lixeira.

E se você estiver escrevendo um código que chama APIs públicas que podem revelar dados do cliente: Nunca faça seus usuários chorarem/pela forma como você chama a API.

---

DOUG.  [RISOS] Isso é novo para mim, e eu gosto muito dele!

E por último, mas certamente não menos importante em nossa lista aqui, temos falado semana após semana sobre esse bug de segurança do OpenSSL.

A grande questão agora é: “Como você sabe o que precisa ser consertado?”

A história da atualização de segurança do OpenSSL – como você pode dizer o que precisa ser corrigido?

---

PATO.  De fato, Doug, como sabemos qual versão do OpenSSL temos?

E, obviamente, no Linux, basta abrir um prompt de comando e digitar openssl version, e informa a versão que você tem.

Mas o OpenSSL é uma biblioteca de programação e não há nenhuma regra que diga que o software não pode ter sua própria versão.

Sua distro pode usar o OpenSSL 3.0 e, no entanto, há um aplicativo que diz: “Ah, não, não atualizamos para a nova versão. Preferimos o OpenSSL 1.1.1, porque ele ainda é suportado e, caso você não o tenha, estamos trazendo nossa própria versão.”

E então, infelizmente, assim como naquele infame caso Log4Shell, você teve que procurar os três? 12? 154? sabe-se lá quantos lugares na sua rede onde você pode ter um programa Log4J desatualizado.

O mesmo para OpenSSL.

Em teoria, as ferramentas XDR ou EDR podem ser capazes de lhe dizer, mas algumas não oferecem suporte a isso e muitas desencorajam: na verdade, executar o programa para descobrir qual é a versão.

Porque, afinal, se for o bugado ou errado, e você realmente tiver que rodar o programa para que ele reporte a sua própria versão…

…é como colocar a carroça na frente dos bois, não é?

Então, publicamos um artigo para aqueles casos especiais em que você realmente deseja carregar a DLL ou a biblioteca compartilhada e deseja chamar sua própria TellMeThyVersion() código de software.

Em outras palavras, você confia no programa o suficiente para carregá-lo na memória, executá-lo e executar algum componente dele.

Mostramos como fazer isso para que você tenha certeza absoluta de que todos os arquivos OpenSSL periféricos que você possui em sua rede estão atualizados.

Porque embora isso tenha sido rebaixado de CRITICAL para HIGH, ainda é um bug que você precisa e deseja corrigir!

---

DOUG.  Sobre o assunto da gravidade deste bug, recebemos um pergunta interessante do leitor de segurança Naked Svet, que escreve, em parte:

Como é que um bug de enorme complexidade para exploração, e que só pode ser usado para ataques de negação de serviço, continua sendo classificado como ALTO?

---

PATO.  Sim, acho que ele disse algo sobre: ​​“Ah, a equipe do OpenSL não ouviu falar do CVSS?”, que é um padrão do governo dos EUA, se preferir, para codificar o risco e o nível de complexidade dos bugs de uma forma que pode ser filtrados automaticamente por scripts.

Portanto, se ele tiver uma pontuação CVSS baixa (que é a Sistema de pontuação comum de vulnerabilidades), por que as pessoas estão ficando animadas com isso?

Por que deveria ser ALTO?

E então minha resposta foi: "Por que *não deveria* ser ALTO?"

É um bug em um mecanismo criptográfico; pode travar um programa, digamos, que está tentando obter uma atualização... então ele travará repetidamente, o que é um pouco mais do que apenas uma negação de serviço, porque na verdade está impedindo você de fazer sua segurança corretamente.

Há um elemento de desvio de segurança.

E acho que a outra parte da resposta é, quando se trata de vulnerabilidades transformadas em exploits: “Nunca diga nunca!”

Quando você tem algo como um estouro de buffer de pilha, onde você pode manipular outras variáveis ​​na pilha, possivelmente incluindo endereços de memória, sempre haverá a chance de alguém descobrir uma exploração viável.

E o problema, Doug, é que uma vez que eles descobriram, não importa o quão complicado foi descobrir...

…uma vez que você sabe como explorá-lo, *qualquer um* pode fazer isso, porque você pode vender o código para fazer isso.

Acho que você sabe o que vou dizer: “Não que eu tenha uma forte opinião sobre isso.”

[RISO]

É, mais uma vez, uma daquelas coisas do tipo “dane-se se fizerem, dane-se se não fizerem”.

---

DOUG.  Muito bem, muito obrigado, Svet, por escrever esse comentário e enviá-lo.

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 você até a próxima…

---

AMBAS.  Fique seguro!