S3 Ep94: Este tipo de criptografia (grafia) e o outro tipo de criptografia (moeda!) [Áudio + Texto]

Republicado por Platão

seguidores: 0

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. A bug crítico do Samba, Ainda outra roubo de criptografia e Feliz Dia do SysAdmin.

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… Paul, como você está hoje?

PATO. Excelente, obrigado, Douglas.

DOUG. Gostamos de começar o show com um pouco da história da tecnologia.

E esta semana, Paul, vamos voltar a 1858!

Esta semana, em 1858, o primeiro cabo telegráfico transatlântico foi concluído.

Foi liderado pelo comerciante americano Cyrus Westfield, e o cabo ia de Trinity Bay, Newfoundland, até Valência, Irlanda, com cerca de 2000 quilômetros de diâmetro e mais de 2 quilômetros de profundidade.

Esta seria a quinta tentativa e, infelizmente, o cabo só funcionou por cerca de um mês.

Mas funcionou o tempo suficiente para que o então presidente James Buchanan e a rainha Vitória trocassem gentilezas.

PATO. Sim, acredito que foi, como posso dizer... desmaio. [RISADA]

1858!

O que Deus fez?, Douglas! [PALAVRAS ENVIADAS NA PRIMEIRA MENSAGEM TELÉGRÁFICA]

DOUG. [RISOS] Falando em coisas que foram forjadas, há uma bug crítico do Samba que já foi corrigido.

Não sou um especialista de forma alguma, mas esse bug permitiria que qualquer um se tornasse um administrador de domínio… isso parece ruim.

PATO. Bem, parece ruim, Doug, principalmente porque *é* bastante ruim!

DOUG. Ai está!

PATO. Samba… só para deixar claro, antes de começarmos, vamos ver as versões que você deseja.

Se você estiver na versão 4.16, precisará da versão 4.16.4 ou posterior; se você estiver no 4.15, precisará do 4.15.9 ou posterior; e se você estiver no 4.14, precisará do 4.14.14 ou posterior.

Essas correções de bugs, no total, corrigiram seis bugs diferentes que foram considerados sérios o suficiente para obter números CVE – designadores oficiais.

Quem se destacou foi CVE-2022-32744.

E o título do bug diz tudo: Os usuários do Samba Active Directory podem falsificar solicitações de alteração de senha para qualquer usuário.

DOUG. Sim, isso parece ruim.

PATO. Então, como o relatório completo do bug no comunicado de segurança, o log de alterações diz, de uma forma bastante exagerada:

“Um usuário poderia alterar a senha da conta de administrador e obter controle total sobre o domínio. Seria possível a perda total de confidencialidade e integridade, bem como de disponibilidade, ao negar aos usuários o acesso às suas contas.”

E como os nossos ouvintes provavelmente sabem, a chamada “santíssima trindade” (aspas no ar) da segurança informática é: disponibilidade, confidencialidade e integridade.

Você deveria ter todos eles, não apenas um deles.

então, integridade significa que ninguém mais pode entrar e mexer nas suas coisas sem você perceber.

Disponibilidade diz que você sempre pode pegar suas coisas – eles não podem impedir que você faça isso quando quiser.

E confidencialidade significa que eles não podem olhar para ele, a menos que seja permitido.

Qualquer um desses, ou dois deles, não tem muita utilidade por si só.

Então isso realmente foi uma trifeta, Doug!

E, irritantemente, é exatamente na parte do Samba que você pode usar não apenas se estiver tentando conectar um computador Unix a um domínio do Windows, mas se estiver tentando configurar um domínio do Active Directory para computadores Windows usarem. um monte de computadores Linux ou Unix.

DOUG. Isso é marcar todas as caixas de todas as maneiras erradas!

Mas há uma correção – e sempre dizemos: “Atualize cedo, atualize com frequência”.

Existe algum tipo de solução alternativa que as pessoas possam usar se não conseguirem corrigir imediatamente por algum motivo, ou isso é algo do tipo "faça apenas".

PATO. Bem, meu entendimento é que esse bug está no serviço de autenticação de senha chamado kpasswd.

Essencialmente, o que esse serviço faz é procurar uma solicitação de alteração de senha e verificar se ela está assinada ou autorizada por algum tipo de parte confiável.

E, infelizmente, após uma certa série de condições de erro, essa parte confiável pode incluir você mesmo.

Então é como um Imprima seu próprio passaporte bug, se você quiser.

Você tem que apresentar um passaporte… pode ser um passaporte real emitido pelo seu próprio governo, ou pode ser um que você conseguiu em casa na sua impressora jato de tinta, e ambos seriam aprovados. [RISADA]

O truque é que, se você realmente não depende desse serviço de autenticação de senha ao usar o Samba, você pode evitar isso. kpasswd serviço seja executado.

Claro, se você realmente depende de todo o sistema Samba para fornecer autenticação do Active Directory e alterações de senha, a solução alternativa quebraria seu próprio sistema.

Então a melhor defesa, claro, é de fato o patch que *remove* o bug em vez de simplesmente *evitá-lo.

DOUG. Muito bom.

Você pode leia mais sobre isso no site: nakedscurity.sophos.com.

E avançamos para a época mais maravilhosa do ano!

Acabamos de comemorar Dia do administrador do sistema, Paul, e não vou telegrafar a piada aqui ... mas você teve bastante escrito.

PATO. Bem, uma vez por ano, não é pedir muito que vámos ao departamento de TI e sorrimos para todos que fizeram todo esse trabalho oculto de segundo plano…

…para manter [CADA VEZ MAIS RÁPIDO] nossos computadores, e nossos servidores, e nossos serviços em nuvem, e nossos laptops, e nossos telefones, e nossos switches de rede [DOUG LAUGHS], e nossas conexões DSL, e nosso kit Wi-Fi em bom estado de funcionamento.

Disponível! Confidencial! Cheio de integridade, o ano todo!

Se você não fez isso na última sexta-feira de julho, que é S.Dia de Valorização do ysAdmin, então por que não fazer isso hoje?

E mesmo que você tenha feito isso, não há nada que diga que você não pode valorizar seus SysAdmins todos os dias do ano.

Você não precisa fazer isso apenas em julho, Doug.

DOUG. Bom ponto!

PATO. Então aqui está o que fazer, Doug.

Vou chamar isso de “poema” ou “verso”… Acho que tecnicamente é doggerel [RISOS], mas vou fingir que tem toda a alegria e calor de um soneto de Shakespeare.

*Não* é um soneto, mas terá que servir.

DOUG. Perfeito.

PATO. Aqui está, Douglas.

Se o seu mouse estiver sem bateria
Ou a luz da sua webcam não brilhará

Se você não consegue lembrar sua senha
Ou seu e-mail simplesmente não será exibido

Se você perdeu sua unidade USB
Ou sua reunião não começará

Se você não consegue produzir um histograma
Ou desenhe um belo gráfico redondo

Se você clicar em [Excluir] acidentalmente
Ou formatou seu disco

Se você pretendia fazer um backup
Mas em vez disso apenas assumi um risco

Se você sabe que o culpado é óbvio
E a culpa aponta para você

Não perca a esperança e fique abatido
Resta uma coisa a fazer!
  
Leve chocolates, vinho, um pouco de alegria, um sorriso
E seja sincero quando você diz:
  
"Acabei de passar para desejar a todos vocês
Um ótimo dia do SysAdmin!"

DOUG. [PALMAS] Muito bom! Um dos seus melhores!

PATO. Muito do que os SysAdmins fazem é invisível, e muito do que é surpreendentemente difícil de fazer bem e de forma confiável…

…e fazer sem consertar uma coisa e quebrar outra.

Esse sorriso é o mínimo que eles merecem, Doug.

DOUG. O mínimo!

PATO. Então, para todos os SysAdmins de todo o mundo, espero que tenham gostado da última sexta-feira.

E se você não conseguiu sorrisos suficientes, tire um agora.

DOUG. Feliz Dia do SysAdmin a todos, e leia esse poema, o que é ótimo… está no site.

Tudo bem, passando para algo não tão bom: um bug de mau gerenciamento de memória no GnuTLS.

PATO. Sim, achei que valia a pena escrever sobre Naked Security, porque quando as pessoas pensam em criptografia de código aberto, elas tendem a pensar em OpenSSL.

Porque (A) é aquele de que todo mundo já ouviu falar, e (B) é o que provavelmente teve mais publicidade nos últimos anos sobre bugs, por causa de heartbleed.

Mesmo que você não estivesse lá na época (foi há oito anos), provavelmente já ouviu falar do Heartbleed, que era uma espécie de vazamento de dados e bug de vazamento de memória no OpenSSL.

Estava no código há muito tempo e ninguém percebeu.

E então alguém percebeu, e deu a ele um nome chique, e deu um logotipo ao bug, e deu ao bug um site, e eles fizeram uma enorme coisa de relações públicas com isso.

DOUG. [RISOS] É assim que você sabe que é real…

PATO. OK, eles estavam fazendo isso porque queriam chamar a atenção para o fato de terem descoberto e estavam muito orgulhosos disso.

E o outro lado foi que as pessoas saíram e consertaram esse bug que de outra forma não teriam feito… porque, bem, é apenas um bug.

Não parece muito dramático – não é uma execução remota de código. então eles não podem simplesmente entrar e assumir instantaneamente o controle de todos os meus sites, etc.

Mas tornou o OpenSSL um nome familiar, não necessariamente pelos motivos certos.

No entanto, existem muitas bibliotecas criptográficas de código aberto, não apenas OpenSSL, e pelo menos duas delas são surpreendentemente amplamente utilizadas, mesmo que você nunca tenha ouvido falar delas.

Existe NSS, abreviação de Serviço de segurança de rede, que é a biblioteca criptográfica da própria Mozilla.

Você pode baixá-lo e usá-lo independentemente de qualquer projeto específico da Mozilla, mas você o encontrará, principalmente, no Firefox e no Thunderbird, fazendo toda a criptografia lá – eles não usam OpenSSL.

E tem gnuTLS, que é uma biblioteca de código aberto do projeto GNU, que essencialmente, se você preferir, é um concorrente ou uma alternativa ao OpenSSL, e que é usada (mesmo que você não perceba) por um número surpreendente de usuários abertos. projetos e produtos de origem…

…inclusive por código, seja qual for a plataforma em que você esteja, que provavelmente tenha em seu sistema.

Então isso inclui qualquer coisa relacionada, digamos: FFmpeg; Mencodificador; GnuPGP (a ferramenta de gerenciamento de chaves GNU); QEMU, Rdesktop; Samba, do qual acabamos de falar no bug anterior; Wget, que muitas pessoas usam para download na web; Ferramentas de detecção de rede do Wireshark; Zlib.

Existem muitas e muitas ferramentas por aí que precisam de uma biblioteca criptográfica e decidiram usar GnuTLS *em vez* de OpenSSL, ou talvez até *bem como*, dependendo dos problemas da cadeia de suprimentos de quais subpacotes eles extraíram em.

Você pode ter um projeto em que algumas partes usam GnuTLS para criptografia e outras partes usam OpenSSL, e é difícil escolher um em vez do outro.

Então você acaba, para o bem ou para o mal, com os dois.

E infelizmente, o GnuTLS (a versão que você deseja é 3.7.7 ou posterior) tinha um tipo de bug conhecido como duplamente grátis… acredite ou não, na parte do código que faz a validação do certificado TLS.

Então, no tipo de ironia que já vimos em bibliotecas criptográficas antes, código que usa TLS para transmissões criptografadas, mas não se preocupa em verificar o outro lado… código que diz: “Validação de certificado, quem precisa dele?”

Isso geralmente é considerado uma ideia extremamente ruim, um tanto ruim do ponto de vista da segurança... mas qualquer código que faça isso não será vulnerável a esse bug, porque ele não chama o código com erros.

Então, infelizmente, o código que está tentando fazer a coisa *certa* pode ser enganado por um certificado não autorizado.

E só para explicar de forma simples, um duplamente grátis é o tipo de bug em que você pergunta ao sistema operacional ou ao sistema: “Ei, me dê um pouco de memória. Preciso de um pouco de memória temporariamente. Nesse caso, tenho todos esses dados do certificado, quero armazená-los temporariamente, validá-los e, quando terminar, devolvo a memória para que possa ser usada por outra parte do programa. ”

Se você é um programador C, estará familiarizado com as funções malloc(), abreviação de “alocar memória” e free(), que é “devolva”.

E sabemos que existe um tipo de bug chamado usar depois de livre, que é onde você devolve os dados, mas continua usando esse bloco de memória de qualquer maneira, esquecendo que desistiu.

Mas uma liberação dupla é um pouco diferente - é onde você devolve a memória e evita usá-la novamente, mas, em um estágio posterior, você diz: “Espere aí, tenho certeza de que não entreguei isso memória de volta ainda. É melhor devolvê-lo, por precaução.

E então você diz ao sistema operacional: “OK, libere esta memória novamente”.

Portanto, parece que é uma solicitação legítima para liberar os dados *dos quais alguma outra parte do programa pode realmente estar confiando*.

E como você pode imaginar, coisas ruins podem acontecer, porque isso significa que você pode obter duas partes do programa que, sem saber, dependem do mesmo pedaço de memória ao mesmo tempo.

A boa notícia é que não acredito que tenha sido encontrada uma exploração funcional para esse bug e, portanto, se você corrigir, estará à frente dos criminosos, em vez de simplesmente alcançá-los.

Mas, claro, a má notícia é que, quando correções de bugs como essa são lançadas, geralmente há muitas pessoas olhando para elas, tentando analisar o que deu errado, na esperança de entender rapidamente o que podem fazer para explorar. o bug contra todas aquelas pessoas que demoraram a corrigir.

Em outras palavras: não demore. Faça hoje.

DOUG. Tudo bem, a versão mais recente do GnuTLS é 3.7.7… atualize.

Você pode leia mais sobre isso no site.

PATO. Ah, e Doug, aparentemente o bug foi introduzido no GnuTLS 3.6.0.

DOUG. OK.

PATO. Então, em teoria, se você tem uma versão anterior a essa, você não está vulnerável a esse bug…

…mas por favor, não use isso como desculpa para dizer: “Não preciso atualizar ainda”.

Você também pode avançar com todas as outras atualizações lançadas, para todos os outros problemas de segurança, entre 3.6.0 e 3.7.6.

Portanto, o fato de você não se enquadrar na categoria desse bug – não use isso como desculpa para não fazer nada.

Use isso como um impulso para chegar aos dias de hoje... esse é o meu conselho.

DOUG. OK!

E nossa última história da semana: estamos falando de outro roubo de criptografia.

Desta vez, apenas US $ 200 milhões, porém, Paulo.

Esta é uma mudança estúpida em comparação com algumas das outras sobre as quais falamos.

PATO. Quase não quero dizer isso, Doug, mas uma das razões pelas quais escrevi isso é que olhei para ele e me peguei pensando: “Oh, apenas 200 milhões? Isso é um pouco… O QUE ESTOU PENSANDO!?” [RISADA]

200 milhões de dólares, basicamente… bem, não “jogados pela sanita”, mas sim “fora do cofre do banco”.

Este serviço Nomad é de uma empresa chamada Illusory Systems Incorporated.

E penso que concordará que, certamente do ponto de vista da segurança, a palavra “ilusório” é talvez o tipo certo de metáfora.

É um serviço que essencialmente permite que você faça o que está no jargão conhecido como ponte.

Basicamente, você está negociando ativamente uma criptomoeda por outra.

Então você coloca sua própria criptomoeda em um balde gigante junto com um monte de outras pessoas… e então podemos fazer todos esses contratos inteligentes automatizados sofisticados de “finanças descentralizadas”.

Podemos trocar Bitcoin por Ether ou Ether por Monero, ou qualquer outra coisa.

Infelizmente, durante uma recente atualização de código, parece que eles caíram no mesmo tipo de buraco que talvez os caras do Samba tenham caído com o bug de que falamos no Samba.

Há basicamente um Imprima seu próprio passaporte, Ou uma Autorize sua própria transação bug que eles introduziram.

Há um ponto no código em que um hash criptográfico, um hash criptográfico de 256 bits, deve ser validado... algo que ninguém, exceto um aprovador autorizado, poderia inventar.

Exceto que se você usasse o valor zero, você seria aprovado.

Você poderia basicamente pegar a transação existente de qualquer outra pessoa, reescrever o nome do destinatário com o seu (“Ei, pague *minha* carteira de criptomoeda”) e apenas reproduzir a transação.

E o sistema irá, “OK”.

Você só precisa obter os dados no formato correto, esse é o meu entendimento.

E a maneira mais fácil de criar uma transação que seria aprovada é simplesmente pegar a transação pré-concluída e existente de outra pessoa, reproduzi-la, mas riscar o nome ou o número da conta e inserir o seu próprio.

Então, como analista de criptomoeda @samczsun disse no Twitter, “Os invasores abusaram disso para copiar e colar transações e rapidamente drenaram a ponte em um vale-tudo frenético.”

Em outras palavras, as pessoas enlouqueceram ao sacar dinheiro no caixa eletrônico que aceitaria o cartão bancário de qualquer pessoa, desde que você inserisse um PIN zero.

E não apenas até o caixa eletrônico ser esvaziado... o caixa eletrônico estava basicamente conectado diretamente à lateral do cofre do banco, e o dinheiro simplesmente estava saindo.

DOUG. Arrrgh!

PATO. Como você disse, aparentemente eles perderam algo em torno de US$ 200 milhões em pouco tempo.

Oh céus.

DOUG. Bem, temos alguns conselhos e são bastante simples…

PATO. O único conselho que você realmente pode dar é: “Não tenha muita pressa em participar desta revolução financeira descentralizada”.

Como já dissemos antes, certifique-se de que se você *entrar* nessa “negociação on-line; empreste-nos criptomoeda e pagaremos juros; coloque suas coisas em uma carteira quente para que você possa agir em segundos; entre em todo o cenário do contrato inteligente; compre meus tokens não fungíveis [NFTs]” – todas essas coisas…

…se você decidir que o mercado *é* para você, certifique-se de entrar com os olhos bem abertos, não com os olhos bem fechados!

E a simples razão é que em casos como este, não é apenas como se os bandidos pudessem drenar *alguns* dos caixas eletrônicos do banco.

Neste caso, em primeiro lugar, parece que drenaram quase tudo e, em segundo lugar, ao contrário dos bancos convencionais, simplesmente não existem as protecções regulamentares de que desfrutaríamos se um banco na vida real falisse.

No caso das finanças descentralizadas, toda a ideia de ser descentralizado, e ser novo, e legal, e algo em que você quer se apressar…

…é que *não* tem essas irritantes proteções regulatórias.

Você poderia, e possivelmente poderia – porque já falamos sobre isso com mais frequência do que me sinto confortável em fazer, na verdade – você pode perder *tudo*.

E o outro lado disso é que, se você perdeu coisas em algumas finanças descentralizadas ou na implosão do “novo site de supernegociação da Web 3.0” como esta, então tome muito cuidado com as pessoas que chegam dizendo: “Ei, não se preocupe. Apesar da falta de regulamentação, existem empresas especializadas que podem reaver o seu dinheiro. Tudo o que você precisa fazer é entrar em contato com a empresa X, o indivíduo Y ou a conta da mídia social Z”.

Porque, sempre que ocorre um desastre desse tipo, os golpistas secundários aparecem rapidamente, oferecendo-se para “encontrar uma maneira” de recuperar seu dinheiro.

Existem muitos golpistas por aí, então tenha muito cuidado.

Se você perdeu dinheiro, não se esforce para jogar dinheiro bom atrás de dinheiro ruim (ou dinheiro ruim atrás de dinheiro bom, seja qual for a solução).

DOUG. OK, você pode ler mais sobre isso: Cryptocoin “token swapper” Nomad perde US $ 200 milhões em erro de codificação.

E se ouvirmos de um de nossos leitores sobre esta história, um comentarista anônimo escreve, e eu concordo… não entendo como isso funciona:

“O que é surpreendente é que uma startup online tinha muito a perder em primeiro lugar. US$ 200,000 mil, você pode imaginar. Mas US$ 200 milhões parecem inacreditáveis.”

E acho que respondemos a essa pergunta, mas de onde vem todo esse dinheiro, para pegar apenas US$ 200 milhões?

PATO. Não posso responder a isso, Doug.

DOUG. Não.

PATO. Será que o mundo está mais crédulo do que costumava ser?

Será que há muitos ganhos ilícitos circulando pela comunidade das criptomoedas?

Portanto, há pessoas que não investiram seu próprio dinheiro nisso, mas acabaram com um monte de criptomoedas por meios ilícitos, e não justos. (Sabemos que os pagamentos de ransomware geralmente vêm como criptomoedas, não é?)

Então é como dinheiro fictício… a pessoa que está perdendo o “dinheiro” talvez não tenha colocado dinheiro adiantado?

É apenas um zelo quase religioso por parte das pessoas que dizem: “Não, não, *esta* é a maneira de fazer isso. Precisamos quebrar o modo estrangulador como as organizações financeiras da velha escola, confusas e altamente regulamentadas fazem as coisas. Precisamos nos libertar do Homem”?

Não sei, talvez US$ 200 milhões não sejam mais muito dinheiro, Doug?

DOUG. [RISOS] Bem, é claro!

PATO. Suspeito que haja apenas pessoas entrando com os olhos bem fechados.

Eles dizem: “Estou *preparado* para correr esse risco porque é muito legal”.

E o problema é que se você vai perder US$ 200, ou US$ 2000, e pode se dar ao luxo de perdê-los, isso é uma coisa.

Mas se você apostou $ 2000 e pensa: “Quer saber. Talvez eu deva apostar US$ 20,000 mil? E então você pensa: “Quer saber. Talvez eu deva apostar $ 200,000? Talvez eu deva apostar tudo?

Então, acho que você precisa ter muito cuidado mesmo!

Precisamente pelas razões que você pode achar que tem pelas proteções regulatórias, como quando algo ruim acontece no seu cartão de crédito e você simplesmente liga, contesta e eles vão embora. “OK”, e eles cortam esses $ 52.23 da conta…

…isso não vai acontecer neste caso.

E é improvável que seja US$ 52, provavelmente será muito mais do que isso.

Então se cuidem, pessoal!

DOUG. Tome cuidado, de fato.

Tudo bem, obrigado pelo comentário.

E se você tiver uma história interessante, comentário ou pergunta 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; você pode nos contatar 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…

AMBAS. Fique seguro!

[MODEM MUSICAL]

Carimbo de hora: 4 de agosto de 20224 de agosto de 2022