S3 Ep95: vazamento do Slack, ataque do Github e criptografia pós-quântica [Áudio + Texto]

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

DOUG.  Vazamentos de folga, código malicioso do GitHub e criptografia pós-quântica.

Tudo isso e muito mais no podcast Naked Security.

[MODEM MUSICAL]

Bem-vindos ao podcast, pessoal.

Eu sou Doug Aamoth.

Comigo, como sempre, está Paul Ducklin.

Paulo, como você está hoje?

---

PATO.  Super-duper, como sempre, Doug!

---

DOUG.  Estou super-duper animado para chegar ao desta semana Histórico de tecnologia segmento, porque...

...você estava lá, cara!

Esta semana, em 11 de agosto…

---

PATO.  Ah não!

Acho que a ficha caiu…

---

DOUG.  Nem preciso dizer o ano!

11 de agosto de 2003 – o mundo tomou conhecimento do worm Blaster, afetando os sistemas Windows 2000 e Windows XP.

Blaster, também conhecido como Lovesan e MsBlast, explorou um estouro de buffer e talvez seja mais conhecido pela mensagem, “Billy Gates, por que você torna isso possível? Pare de ganhar dinheiro e conserte seu software.”

O que aconteceu, Paulo?

---

PATO.  Bem, foi a era antes, talvez, de levarmos a segurança muito a sério.

E, felizmente, esse tipo de bug seria muito, muito mais difícil de explorar hoje em dia: era um estouro de buffer baseado em pilha.

E se bem me lembro, as versões de servidor do Windows já estavam sendo construídas com o que se chama proteção de pilha.

Em outras palavras, se você estourar a pilha dentro de uma função, então, antes que a função retorne e cause o dano com a pilha corrompida, ela detectará que algo ruim aconteceu.

Então, ele tem que desligar o programa ofensivo, mas o malware não consegue ser executado.

Mas essa proteção não estava nas versões cliente do Windows naquela época.

E pelo que me lembro, era um daqueles malwares antigos que precisavam adivinhar qual versão do sistema operacional você tinha.

Você está em 2000? Você está no NT? Você está no XP?

E se errar, uma parte importante do sistema travaria e você receberia o aviso “Seu sistema está prestes a desligar”.

---

DOUG.  Ah, eu lembro desses!

---

PATO.  Então, havia aquele dano colateral que era, para muitas pessoas, o sinal de que você estava sendo atacado por infecções…

…que pode ser de fora, como se você fosse apenas um usuário doméstico e não tivesse um roteador ou firewall em casa.

Mas se você estivesse dentro de uma empresa, o ataque mais provável viria de outra pessoa dentro da empresa, espalhando pacotes em sua rede.

Então, muito parecido com o ataque CodeRed sobre o qual falamos, que foi alguns anos antes disso, em um podcast recente, era realmente a escala, o volume e a velocidade dessa coisa que era o problema.

---

DOUG.  Tudo bem, bem, isso foi há cerca de 20 anos.

E se voltarmos o relógio para cinco anos atrás, é quando Slack começou a vazar senhas com hash. [RISADA]

---

PATO.  Sim, Slack, a popular ferramenta de colaboração…

…tem um recurso onde você pode enviar um link de convite para outras pessoas participarem do seu workspace.

E você imagina: você clica em um botão que diz “Gerar um link”, e ele vai criar algum tipo de pacote de rede que provavelmente tem algum JSON dentro dele.

Se você já recebeu um convite para uma reunião do Zoom, saberá que ele tem uma data e um horário, a pessoa que está convidando você e um URL que você pode usar para a reunião, uma senha e tudo isso coisas - ele tem muitos dados lá.

Normalmente, você não investiga os dados brutos para ver o que está lá – o cliente apenas diz: “Ei, aqui está uma reunião, aqui estão os detalhes. Você quer Aceitar / Talvez / Recusar?”

Acontece que quando você fez isso com o Slack, como você disse, por mais de cinco anos, empacotado nesse convite havia dados estranhos não estritamente relevantes para o convite em si.

Então, nem um URL, nem um nome, nem uma data, nem uma hora…

…mas o *hash da senha do usuário convidativo* [RISOS]

---

DOUG.  Hmmmmm

---

PATO.  Eu não estou brincando com você!

---

DOUG.  Isso soa mal…

---

PATO.  Sim, ele realmente faz, não é?

A má notícia é, como diabos isso foi parar lá?

E, uma vez que estava lá, como diabos passou despercebido por cinco anos e três meses?

Na verdade, se você visitar o artigo sobre Naked Security e olhar para o URL completo do artigo, você notará que diz no final, blahblahblah-for-three-months.

Porque, quando li o relatório pela primeira vez, minha mente não queria ver como 2017! [RISADA]

Foi de 17 de abril a 17 de julho, então havia muitos “17” lá.

E minha mente apagou 2017 como o ano inicial – eu interpretei mal como “abril a julho *deste ano*” [2022].

Eu pensei: “Uau, *três meses* e eles não perceberam”.

E então o primeiro comentário sobre o artigo foi, “Aham [tosse]. Na verdade, era 17 de abril *2017*.”

Wow!

Mas alguém descobriu em 17 de julho [2022], e o Slack, para seu crédito, consertou no mesmo dia.

Tipo, “Oh, caramba, o que estávamos pensando?!”

Então essa é a má notícia.

A boa notícia é que, pelo menos, eram senhas *com hash*.

E eles não eram apenas hash, eles eram *salted*, que é onde você mistura dados aleatórios por usuário escolhidos de forma exclusiva com a senha.

A ideia disso é dupla.

Primeiro, se duas pessoas escolhem a mesma senha, elas não obtêm o mesmo hash, então você não pode fazer nenhuma inferência examinando o banco de dados de hash.

E dois, você não pode pré-computar um dicionário de hashes conhecidos para entradas conhecidas, porque você precisa criar um dicionário separado para cada senha *para cada sal*.

Portanto, não é um exercício trivial decifrar senhas com hash.

Dito isto, a ideia toda é que eles não deveriam ser uma questão de registro público.

Eles são misturados e salgados *no caso* de vazar, não *para que possam* vazar.

Então, ovo na cara do Slack!

O Slack diz que cerca de um em cada 200 usuários, ou 0.5%, foi afetado.

Mas se você é um usuário do Slack, suponho que, se eles não percebessem que estavam vazando senhas com hash por cinco anos, talvez também não enumerassem completamente a lista de pessoas afetadas.

Então, vá e altere sua senha de qualquer maneira… você também pode.

---

DOUG.  OK, também dizemos: se você não estiver usando um gerenciador de senhas, considere obter um; e ative o 2FA, se puder.

---

PATO.  Achei que você ia gostar disso, Doug.

---

DOUG.  Sim eu quero!

E então, se você é Slack ou empresa como ela, escolha um algoritmo de sal-hash-and-stretch respeitável ao lidar com senhas você mesmo.

---

PATO.  Sim.

O grande problema na resposta do Slack, e o que achei que estava faltando, é que eles apenas disseram: "Não se preocupe, não apenas hash as senhas, nós as salgamos também".

Meu conselho é que, se você for pego em uma violação como essa, deverá estar disposto a declarar o algoritmo ou processo usado para salgar e hash, e também, idealmente, o que é chamado alongamento, que é onde você não apenas faz o hash da senha salgada uma vez, mas talvez você faça o hash 100,000 vezes para desacelerar qualquer tipo de ataque de dicionário ou força bruta.

E se você indicar qual algoritmo está usando e com quais parâmetros... por exemplo, PBKDF2, bcrypt, scrypt, Argon2 – esses são os algoritmos de “salt-hash-stretch” de senha mais conhecidos que existem.

Se você realmente indicar qual algoritmo está usando, então: [A] você está sendo mais aberto e [B] está dando às vítimas em potencial do problema a chance de avaliar por si mesmas o quão perigoso elas acham que isso pode ter sido .

E esse tipo de abertura pode realmente ajudar muito.

O Slack não fez isso.

Eles apenas disseram: “Oh, eles foram salgados e moídos”.

Mas o que não sabemos é, eles colocaram dois bytes de sal e depois os hash uma vez com SHA-1…

…ou eles tinham algo um pouco mais resistente a ser rachado?

---

DOUG.  Aderindo ao assunto de coisas ruins, estamos percebendo uma tendência em desenvolvimento em que as pessoas são injetando coisas ruins no GitHub, só para ver o que acontece, expondo risco…

...temos mais uma dessas histórias.

---

PATO.  Sim, alguém que agora supostamente saiu no Twitter e disse: “Não se preocupem pessoal, nenhum dano foi feito. Era só para pesquisa. Vou escrever um relatório, me destacar do Blue Alert.”

Eles criaram literalmente milhares de projetos falsos do GitHub, baseados na cópia de código legítimo existente, inserindo deliberadamente alguns comandos de malware lá, como “call home para obter mais instruções” e “interpretar o corpo da resposta como código de backdoor para executar” e em breve.

Então, coisas que realmente podem causar danos se você instalar um desses pacotes.

Dando-lhes nomes legítimos…

…pegar emprestado, aparentemente, o histórico de commits de um projeto genuíno para que a coisa parecesse muito mais legítima do que você poderia esperar se aparecesse com “Ei, baixe este arquivo. Você sabe que você quer!"

Sério?! Pesquisar?? Nós não sabíamos disso já?!!?

Agora, você pode argumentar: “Bem, Microsoft, que possui o GitHub, o que eles estão fazendo para facilitar o upload desse tipo de coisa?”

E há alguma verdade nisso.

Talvez eles pudessem fazer um trabalho melhor em manter o malware fora em primeiro lugar.

Mas é um pouco exagerado dizer: “Ah, é tudo culpa da Microsoft”.

É ainda pior, na minha opinião, dizer: “Sim, esta é uma pesquisa genuína; isso é muito importante; temos que lembrar às pessoas que isso pode acontecer.”

Bem, [A] nós já sabemos disso, muito obrigado, porque muitas pessoas já fizeram isso antes; recebemos a mensagem em alto e bom som.

E [B] isso *não é* pesquisa.

Isso está deliberadamente tentando enganar as pessoas para que baixem um código que dê a um possível invasor controle remoto, em troca da capacidade de escrever um relatório.

Isso soa mais como uma “grande desculpa gorda” para mim do que um motivador legítimo para a pesquisa.

E então minha recomendação é, se você acha que isso *é* pesquisa, e se você está determinado a fazer algo assim de novo, *não espere muita simpatia* se você for pego.

---

DOUG.  Tudo bem – vamos voltar a isso e os comentários do leitor no final do show, então fique por aqui.

Mas antes, vamos falar sobre luzes de trânsito, e o que eles têm a ver com segurança cibernética.

---

PATO.  Ahhh, sim! [RISO]

Bem, há uma coisa chamada TLP, o Protocolo de semáforo.

E o TLP é o que você pode chamar de “protocolo de pesquisa de segurança cibernética humana” que ajuda a rotular documentos que você envia a outras pessoas, para dar a eles uma dica do que você espera que eles façam (e, mais importante, o que você espera que eles façam * não*) fazer com os dados.

Em particular, quão amplamente eles devem redistribuí-lo?

Isso é algo tão importante que você poderia declarar ao mundo?

Ou isso é potencialmente perigoso, ou potencialmente inclui algumas coisas que não queremos que sejam públicas ainda... então guarde para você?

E começou com: TLP:RED, que significava “Guarde para você”; TLP:AMBER, que significava “Você pode circulá-lo dentro de sua própria empresa ou para clientes seus que você acha que precisam urgentemente saber disso”; TLP:GREEN, o que significava "OK, você pode deixar isso circular amplamente na comunidade de segurança cibernética".

E TLP:WHITE, que significava: "Você pode contar a qualquer um".

Muito útil, muito simples: RED, AMBER, GREEN… uma metáfora que funciona globalmente, sem se preocupar com qual é a diferença entre “secreto” e “confidencial” e qual é a diferença entre “confidencial” e “classificado”, todas aquelas coisas complicadas que precisa de um monte de leis em torno dele.

Bem, o TLP acabou de receber algumas modificações.

Portanto, se você estiver em pesquisa de segurança cibernética, certifique-se de estar ciente disso.

TLP:WHITE foi alterado para o que considero um termo muito melhor, na verdade, porque branco tem todas essas conotações culturais desnecessárias que podemos prescindir na era moderna.

então, TLP:WHITE acaba de se tornar TLP:CLEAR, que na minha opinião é uma palavra muito melhor porque diz: "Você está certo para usar esses dados", e essa intenção é declarada, ahem, muito claramente. (Desculpe, não resisti ao trocadilho.)

E há uma camada adicional (por isso estragou um pouco a metáfora – agora é um semáforo de *cinco* cores!).

Há um nível especial chamado TLP:AMBER+STRICT, e o que isso significa é: "Você pode compartilhar isso dentro da sua empresa".

Então você pode ser convidado para uma reunião, talvez você trabalhe para uma empresa de segurança cibernética, e está bem claro que você precisará mostrar isso para programadores, talvez para sua equipe de TI, talvez para seu pessoal de garantia de qualidade, para que você possa pesquisar o problema ou resolva-o.

BUT TLP:AMBER+STRICT significa que, embora você possa circulá-lo dentro de sua organização, *por favor, não conte a seus clientes ou clientes*, ou mesmo a pessoas de fora da empresa que você acha que precisam saber.

Mantenha-o dentro da comunidade mais restrita para começar.

TLP:AMBER, como antes, significa: "OK, se você acha que precisa contar aos seus clientes, você pode".

E isso pode ser importante, porque às vezes você pode querer informar seus clientes: “Ei, temos a correção chegando. Você precisará tomar algumas medidas de precaução antes que a correção chegue. Mas porque é meio sensível, podemos pedir que você não conte ao mundo ainda?”

Às vezes, contar ao mundo cedo demais na verdade joga mais nas mãos dos bandidos do que nas mãos dos defensores.

Então, se você é um respondente de segurança cibernética, sugiro que você vá: https://www.first.org/tlp

---

DOUG.  E você pode leia mais sobre isso em nosso site, nudesecurity.sophos.com.

E se você estiver procurando por alguma outra leitura leve, esqueça a criptografia quântica… criptografia pós-quântica, Paulo!

---

PATO.  Sim, já falamos sobre isso algumas vezes antes no podcast, não é?

A ideia de um computador quântico, supondo que um computador poderoso e confiável o suficiente possa ser construído, é que certos tipos de algoritmos podem ser acelerados no estado da arte hoje, seja na raiz quadrada... *logaritmo* da escala do problema hoje.

Em outras palavras, em vez de tomar 2²⁵⁶ tenta encontrar um arquivo com um hash específico, você pode fazer isso em apenas (“apenas”!) 2¹²⁸ tentativas, que é a raiz quadrada.

Claramente muito mais rápido.

Mas há toda uma classe de problemas envolvendo produtos de fatoração de números primos que a teoria diz que podem ser quebrados no *logaritmo* do tempo que eles levam hoje, vagamente falando.

Então, em vez de tomar, digamos, 2¹²⁸ dias para rachar [MAIS DO QUE A IDADE ATUAL DO UNIVERSO], pode levar apenas 128 dias para rachar.

Ou você pode substituir “dias” por “minutos” ou qualquer outra coisa.

E, infelizmente, esse algoritmo de tempo logarítmico (chamado Algoritmo de Fatoração Quântica de Shor)… isso poderia ser, em teoria, aplicado a algumas das técnicas criptográficas atuais, notadamente aquelas usadas para criptografia de chave pública.

E, caso esses dispositivos de computação quântica se tornem viáveis ​​nos próximos anos, talvez devêssemos começar a nos preparar agora para algoritmos de criptografia que não sejam vulneráveis ​​a essas duas classes específicas de ataque?

Particularmente a do logaritmo, porque acelera tanto os ataques em potencial que as chaves criptográficas que atualmente pensamos: “Bem, ninguém nunca descobrirá isso” podem se tornar reveláveis ​​em algum estágio posterior.

De qualquer forma, o NIST, o Instituto Nacional de Padrões e Tecnologia nos EUA, vem há vários anos realizando uma competição para tentar padronizar alguns algoritmos públicos, não patenteados e bem escrutinados que serão resistentes a esses computadores quânticos mágicos, se eles aparecerem.

E recentemente eles escolheram quatro algoritmos que estão preparados para padronizar agora.

Eles têm nomes legais, Doug, então eu tenho que lê-los: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCON e SPHINCS+. [RISADA]

Então eles têm nomes legais, se nada mais.

Mas, ao mesmo tempo, o NIST pensou: “Bem, são apenas quatro algoritmos. O que faremos é escolher mais quatro como potenciais candidatos secundários e veremos se algum deles também deve ser aprovado.”

Portanto, existem quatro algoritmos padronizados agora e quatro algoritmos que podem ser padronizados no futuro.

Ou *havia* quatro em 5 de julho de 2022, e uma delas era SIKE, abreviatura de encapsulamento de chave de isogenia supersingular.

(Vamos precisar de vários podcasts para explicar as isogenias supersingulares, então não vamos nos incomodar. [RISOS])

Mas, infelizmente, este, que estava pendurado lá com uma chance de ser padronizado, parece que foi irremediavelmente quebrado, apesar de pelo menos cinco anos já ter sido aberto ao escrutínio público.

Então, felizmente, pouco antes de ser ou ser padronizado, dois criptógrafos belgas descobriram: “Quer saber? Achamos que temos uma maneira de contornar isso usando cálculos que levam cerca de uma hora, em uma CPU bastante média, usando apenas um núcleo.”

---

DOUG.  Acho que é melhor descobrir isso agora do que depois de padronizá-lo e colocá-lo na natureza?

---

PATO.  De fato!

Eu acho que se tivesse sido um dos algoritmos que já foram padronizados, eles teriam que revogar o padrão e criar um novo?

Parece estranho que isso não tenha sido notado por cinco anos.

Mas acho que essa é toda a ideia do escrutínio público: você nunca sabe quando alguém pode simplesmente acertar o crack que é necessário, ou a pequena cunha que eles podem usar para invadir e provar que o algoritmo não é tão forte quanto se pensava originalmente.

Um bom lembrete de que se você * alguma vez * pensou em tricotar sua própria criptografia…

---

DOUG.  [RISOS] Eu não!

---

PATO.  ..apesar de termos dito a você no podcast Naked Security N vezes, “Não faça isso!”

Este deve ser o lembrete final de que, mesmo quando verdadeiros especialistas lançam um algoritmo que está sujeito ao escrutínio público em uma competição global por cinco anos, isso ainda não fornece necessariamente tempo suficiente para expor falhas que acabam sendo muito ruins.

Então, certamente não parece bom para isso SIKE algoritmo.

E quem sabe, talvez seja retirado?

---

DOUG.  Vamos ficar de olho nisso.

E enquanto o sol se põe lentamente em nosso programa desta semana, é hora de ouvir um de nossos leitores sobre a história do GitHub que discutimos anteriormente.

Rob escreve:

“Há um pouco de giz e queijo nos comentários, e eu odeio dizer isso, mas eu realmente posso ver os dois lados do argumento. É perigoso, problemático, desperdiça tempo e consome recursos? Sim, claro que é. É o que os tipos com mente criminosa fariam? Sim Sim é isso. É um lembrete para qualquer um que use o GitHub, ou qualquer outro sistema de repositório de código, que viajar com segurança pela Internet requer um grau saudável de cinismo e paranóia? Sim. Como administrador de sistemas, parte de mim quer aplaudir a exposição do risco em questão. Como administrador de sistema de vários desenvolvedores, agora preciso ter certeza de que todos recentemente vasculharam qualquer pull em busca de entradas questionáveis.”

---

PATO.  Sim, obrigado, RobB, por esse comentário, porque acho que é importante ver os dois lados do argumento.

Houve comentaristas que estavam apenas dizendo: “Qual é o problema com isso? Isso é ótimo!"

Uma pessoa disse, “Não, na verdade, este teste de caneta é bom e útil. Fique feliz por eles estarem sendo expostos agora, em vez de erguer sua cabeça feia de um atacante real. ”

E minha resposta a isso é: “Bem, isso *é* um ataque, na verdade”.

É só que alguém saiu depois, dizendo “Oh, não, não. Sem danos causados! Honestamente, eu não estava sendo impertinente.”

Eu não acho que você é obrigado a comprar essa desculpa!

Mas de qualquer forma, isso não é teste de penetração.

Minha resposta foi dizer, muito simplesmente: “Os testadores de penetração responsáveis ​​só agem [A] depois de receber permissão explícita e [B] dentro dos limites comportamentais acordados explicitamente com antecedência.”

Você não apenas cria suas próprias regras, e já discutimos isso antes.

Então, como outro comentarista disse, que é, eu acho, meu comentário favorito… Ecurb disse, “Acho que alguém deveria andar de casa em casa e quebrar janelas para mostrar como as fechaduras das portas realmente são ineficazes. Isso está vencido. Alguém salte sobre isso, por favor.”

E então, caso você não tenha percebido que era uma sátira, pessoal, ele diz, "Não!"

---

PATO.  Eu tenho a ideia de que é um bom lembrete, e tenho a ideia de que se você é um usuário do GitHub, tanto como produtor quanto como consumidor, há coisas que você pode fazer.

Nós os listamos nos comentários e no artigo.

Por exemplo, coloque uma assinatura digital em todos os seus commits para que fique óbvio que as alterações vieram de você e há algum tipo de rastreabilidade.

E não consuma coisas cegamente porque você fez uma pesquisa e “parecia” que poderia ser o projeto certo.

Sim, todos nós podemos aprender com isso, mas isso realmente conta como nos ensinando, ou é apenas algo que devemos aprender de qualquer maneira?

Eu acho que isso *não* é ensinar.

É apenas *não de um padrão alto o suficiente* para contar como pesquisa.

---

DOUG.  Ótima discussão em torno deste artigo, e obrigado por enviar isso, Rob.

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 tips@sophos.com; você pode comentar qualquer um de nossos artigos; ou você pode nos bater 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, para…

---

AMBAS.  Fique seguro!

[MODEM MUSICAL]