S3 Ep105: WONFIX! A falha de criptografia do MS Office que “não é uma falha de segurança” [Áudio + Texto]

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

DOUG.  Violações de tirar o fôlego, criptografia descriptografável e patches em abundância.

Tudo isso mais no podcast Naked Security.

[MODEM MUSICAL]

Bem-vindos ao podcast, pessoal.

Eu sou Doug Aamoth; ele é Paul Ducklin.

Paul, como você está hoje, senhor?

---

PATO.  Doug... eu sei, porque você me disse com antecedência, o que está por vir Esta semana na história da tecnologia, e é ÓTIMO!

---

DOUG.  OK!

Esta semana, em 18 de outubro de 1958, um osciloscópio e um computador construídos para simular a resistência ao vento foram combinados com controladores personalizados de alumínio, e o jogo Tênis para dois nasceu.

Exibido em uma exposição de três dias no Laboratório Nacional de Brookhaven, Tennis for Two provou ser extremamente popular, especialmente entre estudantes do ensino médio.

Se você está ouvindo isso, você deve ir à Wikipedia e procurar “Tennis for Two”.

Há um vídeo lá para algo que foi construído em 1958…

…Acho que você vai concordar comigo, Paul, foi incrível.

---

PATO.  Eu *adoraria* jogar hoje!

E, como Asteroids e Battle Zone, e aqueles jogos especialmente lembrados da década de 1980…

…porque é um osciloscópio: gráficos vetoriais!

Sem pixelização, sem diferenças dependendo se uma linha está a 90 graus, 30 graus ou 45 graus.

E o feedback sonoro dos relés nos controladores… é ótimo!

É inacreditável que isso foi em 1958.

Voltando a um anterior Esta semana na história da tecnologia, estava no auge da revolução do transistor.

Aparentemente, a metade computacional era uma mistura de válvulas termiônicas (tubos de vácuo) e relés.

E o circuito da tela era todo baseado em transistores, Doug

Então, foi a mistura de todas as tecnologias: relés, válvulas e transistores, tudo em um videogame inovador.

---

DOUG.  Muito legal.

Confira na Wikipédia: Tênis para dois.

Agora vamos para a nossa primeira história.

Paul, eu sei que você é muito hábil em escrever um grande poema...

…Eu escrevi um poema muito curto para apresentar esta primeira história, se você me permitir.

---

PATO.  Então serão duas linhas, certo? [RISOS]

---

DOUG.  Vai um pouco mais ou menos assim.

Zoom para Mac/Não obter seqüestrado.

[MUITO SILÊNCIO]

Poema final.

---

PATO.  Oh, desculpe!

Achei que esse era o título, e que você ia fazer o poema agora.

---

DOUG.  Então, esse é o poema.

---

PATO.  OK.

[SEM EMOÇÃO] Adorável, Doug.

---

DOUG.  [IRÔNICO] Obrigado.

---

PATO.  A rima foi espetacular!

Mas nem todos os poemas têm que rimar...

---

DOUG.  Isso é verdade.

---

PATO.  Vamos chamá-lo de verso livre, certo?

---

DOUG.  OK por favor.

---

PATO.  Infelizmente, este foi um backdoor gratuito no Zoom para Mac.

[SENTINDO-SE CULPADO] Desculpe, não foi uma boa sequência, Doug.

[Risos] Você pisa no território de outra pessoa, muitas vezes fica aquém…

---

DOUG.  Não, é bom!

Eu estava experimentando poemas esta semana; você está experimentando segues.

Temos que sair da nossa zona de conforto de vez em quando.

---

PATO.  Eu suponho que este era o código que deveria ser compilado quando a compilação final fosse concluída, mas acidentalmente foi deixada.

É apenas para a versão Zoom para Mac e foi corrigido, portanto, verifique se você está atualizado.

Basicamente, em algumas circunstâncias, quando um fluxo de vídeo é iniciado ou a câmera é ativada pelo próprio aplicativo, ele inadvertidamente pensa que você pode querer depurar o programa.

Porque, ei, talvez você fosse um desenvolvedor! [RISOS]

Isso não deveria acontecer em versões de lançamento, obviamente.

E isso significava que havia uma porta de depuração TCP aberta na interface de rede local.

Isso significava que qualquer um que pudesse passar pacotes para aquela porta, que poderia ser presumivelmente qualquer outro usuário conectado localmente, então não precisaria ser um administrador ou mesmo você... mesmo um usuário convidado, isso seria suficiente.

Assim, um invasor que tivesse algum tipo de malware proxy em seu computador que pudesse receber pacotes de fora e injetá-los na interface local poderia basicamente emitir comandos para as entranhas do programa.

E as coisas típicas que as interfaces de depuração permitem incluem: despejar alguma memória; extrair segredos; alterar o comportamento do programa; ajustar as definições de configuração sem passar pela interface usual para que o usuário não possa vê-lo; capturar todo o áudio sem avisar ninguém, sem aparecer o aviso de gravação; todo esse tipo de coisa.

A boa notícia é que o Zoom o encontrou sozinho e o corrigiu rapidamente.

Mas é um ótimo lembrete de que, como dizemos tantas vezes, [risos] “Há muitos deslizes entre o copo e o lábio”.

---

DOUG.  Muito bem, muito bem.

Vamos ficar a bordo do trem de remendo e entrar na próxima estação.

E essa história... talvez a parte mais interessante dessa história do Patch Tuesday mais recente foi o que a Microsoft *não* incluiu?

---

PATO.  Infelizmente, os patches que todos provavelmente esperavam - e especulamos em um podcast recente, "Bem, parece que a Microsoft vai nos fazer esperar mais uma semana até o Patch Tuesday, e não fazer um "lançamento antecipado" fora da banda ” são aqueles dois dias zero do Exchange de memória recente.

O que ficou conhecido como E00F, ou Falha de câmbio duplo zero-day na minha terminologia, ou ProxyNotShell como talvez seja um pouco confuso conhecido na Twittersphere.

Então essa foi a grande história do Patch Tuesday deste mês: esses dois bugs espetacularmente não foram corrigidos.

E então não sabemos quando isso vai acontecer.

Você precisa ter certeza de que aplicou todas as mitigações.

Como acho que já dissemos antes, a Microsoft continuou descobrindo que as mitigações anteriores que eles sugeriram... bem, talvez não fossem boas o suficiente, e continuaram mudando de tom e adaptando a história.

Então, se você estiver em dúvida, você pode voltar para nakedsecurity.sophos.com, pesquisar a frase ProxyNotShell (todas uma palavra), e então vá e leia o que temos a dizer.

E você também pode vincular à versão mais recente da correção da Microsoft…

…porque, de todas as coisas no Patch Tuesday, essa foi a mais interessante, como você diz: porque não estava lá.

---

DOUG.  OK, vamos agora mudar de marcha para um história muito frustrante.

Este é um tapa no pulso para uma grande empresa cuja segurança cibernética é tão ruim que eles nem perceberam que foram violados!

---

PATO.  Sim, esta é uma marca que a maioria das pessoas provavelmente conhecerá como SHEIN (“she-in”), escrito como uma palavra, tudo em maiúsculas. (Na época da violação, a empresa era conhecida como Zoetop.)

E são o que se chama de “fast fashion”.

Você sabe, eles empilham alto e vendem barato, e não sem controvérsia sobre de onde eles obtêm seus projetos.

E, como varejista on-line, talvez você esperasse que eles tivessem os detalhes de segurança cibernética do varejo on-line.

Mas, como você diz, eles não o fizeram!

E a Procuradoria Geral do Estado de Nova York nos EUA decidiu que não estava feliz com a forma como foram tratados os moradores de Nova York que estavam entre as vítimas dessa violação.

Então eles tomaram medidas legais contra esta empresa… e foi uma ladainha absoluta de erros, erros e, finalmente, encobrimentos – em uma palavra, Douglas, desonestidade.

Eles tinham essa brecha que eles não perceberam.

Isso, pelo menos no passado, costumava ser decepcionantemente comum: as empresas não perceberiam que foram violadas até que um administrador de cartão de crédito ou um banco entrasse em contato com elas e dissesse: de reclamações sobre fraudes de clientes este mês.”

“E quando olhamos para o que eles chamam de CPP, o ponto comum de compra, o único comerciante de quem todas as vítimas parecem ter comprado algo é você. Achamos que o vazamento veio de você.

E neste caso foi ainda pior.

Aparentemente, outro processador de pagamento apareceu e disse: “Ah, a propósito, encontramos uma parcela inteira de números de cartão de crédito à venda, oferecidos como roubados de vocês”.

Portanto, eles tinham evidências claras de que houve uma violação em massa ou uma violação pouco a pouco.

---

DOUG.  Então, certamente, quando esta empresa tomou conhecimento disso, eles agiram rapidamente para corrigir a situação, certo?

---

PATO.  Bem, isso depende de como você... [RINDO] Eu não deveria rir, Doug, como sempre.

Isso depende do que você quer dizer com "retificar".

---

DOUG.  [RINDO] Oh, Deus!

---

PATO.  Então parece que eles *lidaram* com o problema... de fato, houve partes dele que eles cobriram muito bem.

Pelo visto.

Parece que eles decidiram de repente: “Opa, é melhor nos tornarmos compatíveis com o PCI DSS”.

Claramente não estavam, porque aparentemente mantinham logs de depuração que continham detalhes de cartão de crédito de transações com falha... tudo o que você não deveria gravar em disco, eles estavam gravando.

E então eles perceberam que isso havia acontecido, mas não conseguiram encontrar onde deixaram esses dados em sua própria rede!

Então, obviamente eles sabiam que não eram compatíveis com PCI DSS.

Eles começaram a se tornar compatíveis com o PCI DSS, aparentemente, algo que alcançaram em 2019. (A violação aconteceu em 2018.)

Mas quando lhes disseram que tinham que se submeter a uma auditoria, uma investigação forense…

…de acordo com o procurador-geral de Nova York, eles deliberadamente atrapalharam o investigador.

Eles basicamente permitiram que os investigadores vissem o sistema como estava *depois* que eles o consertaram, soldaram e poliram, e disseram: "Ah, não, você não pode ver os backups", o que soa um pouco impertinente para mim .

---

DOUG.  Uh-huh

---

PATO.  E também a maneira como eles divulgaram a violação a seus clientes atraiu uma ira significativa do Estado de Nova York.

Em particular, parece que era bastante óbvio que os detalhes de 39,000,000 de usuários de alguma forma foram roubados, incluindo senhas com hash muito fracas: um sal de dois dígitos e uma rodada de MD5.

Não é bom o suficiente em 1998, muito menos em 2018!

Então eles sabiam que havia um problema para esse grande número de usuários, mas aparentemente eles só começaram a entrar em contato com os 6,000,000 desses usuários que realmente usaram suas contas e fizeram pedidos.

E então eles disseram: “Bem, pelo menos entramos em contato com todas essas pessoas”.

E *então* descobriu-se que eles não tinham realmente contatado todos os 6,000,000 milhões de usuários!

Eles tinham acabado de entrar em contato com os seis milhões que moravam no Canadá, nos Estados Unidos ou na Europa.

Então, se você é de qualquer outro lugar do mundo, azar!

Como você pode imaginar, isso não caiu bem com as autoridades, com o regulador.

E, devo admitir... para minha surpresa, Doug, eles foram multados em US$ 1.9 milhão.

O que, para uma empresa tão grande…

---

DOUG.  Sim!

---

PATO.  … e cometer erros tão flagrantes, e depois não ser totalmente decente e honesto sobre o que aconteceu, e ser repreendido por mentir sobre a violação, nessas palavras, pelo Procurador-Geral de Nova York?

Eu estava meio que imaginando que eles poderiam ter sofrido um destino mais sério.

Talvez até incluindo algo que não poderia ser pago apenas com algum dinheiro.

Ah, e a outra coisa que eles fizeram foi quando era óbvio que havia usuários cujas senhas estavam em risco… porque elas eram profundamente decifráveis ​​devido ao fato de ser um sal de dois dígitos, o que significa que você poderia construir 100 dicionários pré-computados …

---

DOUG.  Isso é comum?

Apenas um sal de dois dígitos parece muito baixo!

---

PATO.  Não, você normalmente deseja 128 bits (16 bytes) ou até 32 bytes.

Falando livremente, isso não faz uma diferença significativa na velocidade de craqueamento de qualquer maneira, porque (dependendo do tamanho do bloco do hash) você está adicionando apenas dois dígitos extras à mistura.

Portanto, não é como se a computação real dos hashes demorasse mais.

Já em 2016, as pessoas que usavam computadores de oito GPUs executando o programa “hashcat”, eu acho, podiam fazer 200 bilhões de MD5s por segundo.

Naquela época! (Esse valor é algo como cinco ou dez vezes maior agora.)

Então, muito, muito eminentemente quebrável.

Mas em vez de entrar em contato com as pessoas e dizer: “Sua senha está em risco porque vazamos o hash, e não era muito bom, você deveria alterá-la”, [RISOS] eles apenas disseram…

…elas eram palavras muito fúteis, não eram?

---

DOUG.  “Sua senha tem um baixo nível de segurança e talvez esteja em risco. Por favor, altere sua senha de acesso.”

E então eles mudaram para “Sua senha não foi atualizada por mais de 365 dias. Para sua proteção, atualize-o agora.”

---

PATO.  Sim, "Sua senha tem um nível de segurança baixo..."

---

DOUG.  "POR CAUSA DE NÓS!"

---

PATO.  Isso não é apenas paternalista, é?

Isso está na fronteira ou além da culpa da vítima, aos meus olhos.

De qualquer forma, isso não me pareceu um incentivo muito forte para empresas que não querem fazer a coisa certa.

---

DOUG.  Tudo bem, deixe o som nos comentários, nós gostaríamos de ouvir o que você pensa!

Esse artigo chama-se: Marca de moda SHEIN multada em US$ 1.9 milhão por mentir sobre violação de dados.

E vamos a outra história frustrante…

.., outro dia, outro conto de advertência sobre o processamento de entrada não confiável!

---

PATO.  Aaargh, eu sei o que vai ser, Doug.

Essa é a Texto Apache Commons bug, não é?

---

DOUG.  Isto é!

---

PATO.  Só para ficar claro, esse não é o Apache Web Server.

Apache é uma base de software que tem uma série de produtos e ferramentas gratuitas… e eles são realmente muito úteis, e são de código aberto, e são ótimos.

Mas tivemos, na parte Java de seu ecossistema (o Apache Web Server httpd não está escrito em Java, então vamos ignorar isso por enquanto – não confunda Apache com Apache Web Server)…

…no ano passado, tivemos três problemas semelhantes nas bibliotecas Java do Apache.

Nós tivemos o infame Log4Shell erro na chamada biblioteca Log4J (Logging for Java).

Então tivemos um bug semelhante, o que era?… Configuração Apache Commons, que é um kit de ferramentas para gerenciar todos os tipos de arquivos de configuração, digamos, arquivos INI e arquivos XML, tudo de forma padronizada.

E agora em uma biblioteca de nível ainda mais baixo chamada Texto Apache Commons.

O bug no que em Java é geralmente conhecido como “interpolação de strings”.

Programadores em outras linguagens… se você usa coisas como PowerShell ou Bash, você saberá como “substituição de strings”.

É onde você pode magicamente fazer uma frase cheia de caracteres se transformar em uma espécie de miniprograma.

Se você já usou o shell Bash, saberá que, se digitar o comando echo USER, ele irá ecoar ou imprimir a string USER e você verá, na tela USUÁRIO.

Mas se você executar o comando echo $USER, isso não significa ecoar um cifrão seguido de USER.

O que isso significa é: “Substitua essa string mágica pelo nome do usuário conectado no momento e imprima isso”.

Então, no meu computador, se você echo USERvocê consegue USER, mas se você echo $USER, você entende a palavra duck ao invés.

E algumas das substituições de strings Java vão muito, muito, muito além disso... corrigindo Log4Shell durante o Natal 2021 vai se lembrar!

Existem todos os tipos de miniprogramas inteligentes que você pode incorporar dentro de strings que você processa com esta biblioteca de processamento de strings.

Então tem o óbvio: para ler o nome de usuário, você coloca ${env: (para “ler o ambiente”) user}… você usa colchetes rabiscados.

É cifrão; suporte irregular; algum comando mágico; suporte squiggly que é a parte mágica.

E, infelizmente, nesta biblioteca, havia disponibilidade padrão descontrolada de comandos mágicos como: ${url:...}, que permite enganar a biblioteca de processamento de strings para acessar a Internet, baixar algo e imprimir o que recebe de volta desse servidor da Web em vez da string ${url:...}.

Portanto, embora isso não seja exatamente injeção de código, porque é apenas HTML bruto, ainda significa que você pode colocar todo tipo de lixo e coisas estranhas e maravilhosas não confiáveis ​​nos arquivos de log das pessoas ou em suas páginas da web.

Há ${dns:...}, o que significa que você pode enganar o servidor de alguém, que pode ser um servidor de lógica de negócios dentro da rede…

…você pode enganá-lo para fazer uma pesquisa de DNS para um servidor nomeado.

E se você possui esse domínio, como um bandido, também possui e opera o servidor DNS relacionado a esse domínio.

Então, quando a pesquisa de DNS acontece, adivinhem?

Essa pesquisa termina *no seu servidor* e pode ajudá-lo a mapear as entranhas da rede de negócios de alguém... não apenas seu servidor web, mas coisas mais profundas na rede.

E por último, e mais preocupante, pelo menos com versões mais antigas do Java, houve... [risos] você sabe o que está por vir, Doug!

O comando ${script:...}.

“Ei, deixe-me fornecer um pouco de JavaScript e, gentilmente, execute-o para mim.”

E você provavelmente está pensando: “O quê?! Espere, isso é um bug em Java. O que o JavaScript tem a ver com isso?”

Bem, até recentemente… e lembre-se, muitas empresas ainda usam versões mais antigas e ainda suportadas do Java Development Kit.

Até recentemente, Java… [RISOS] (de novo, eu não deveria rir)… o Java Development Kit continha, dentro de si, um mecanismo JavaScript completo e funcional, escrito em Java.

Agora, não há relação entre Java e JavaScript, exceto as quatro letras “Java”, mas você pode colocar ${script:javascript:...}e execute o código de sua escolha.

E, irritantemente, uma das coisas que você pode fazer no mecanismo JavaScript dentro do tempo de execução do Java é dizer ao mecanismo JavaScript: “Ei, eu quero executar isso via Java”.

Assim, você pode fazer com que Java chame *in* JavaScript e JavaScript essencialmente chame *out* para Java.

E então, do Java, você pode ir, “Ei, execute este comando do sistema”.

E se você for para o artigo Naked Security, você vai me ver usando um comando suspeito para [COUGHS APOLOGICAMENTE] fazer um calc, Doug!

Uma calculadora HP RPN, é claro, porque sou eu que estou fazendo a calculadora estourar…

---

DOUG.  Tem que ser, sim!

---

PATO.  …este é um HP-10.

Assim, embora o risco não seja tão ótimo como Log4Shell, você não pode descartar isso se usar esta biblioteca.

Temos algumas instruções no artigo Naked Security sobre como descobrir se você tem a biblioteca Commons Text… e você pode tê-la, como muitas pessoas fizeram com o Log4J, sem perceber, porque pode ter vindo junto com um aplicativo.

E também temos alguns códigos de amostra que você pode usar para testar se as mitigações implementadas funcionaram.

---

DOUG.  Certo, vá para a Naked Security.

Esse artigo chama-se: Buraco perigoso no Apache Commons Text - como Log4Shell novamente.

E encerramos com uma pergunta: “O que acontece quando as mensagens criptografadas são apenas meio criptografadas?”

---

PATO.  Ah, você está se referindo ao que foi, eu acho, um relatório oficial de bug arquivado por pesquisadores de segurança cibernética da empresa finlandesa WithSecure recentemente…

…sobre a criptografia integrada oferecida no Microsoft Office, ou mais precisamente, um recurso chamado Criptografia de Mensagens do Office 365 ou OME.

É bastante útil ter um pequeno recurso como esse embutido no aplicativo.

---

DOUG.  Sim, parece simples e conveniente!

---

PATO.  Sim, exceto... oh, querida!

Parece que a razão para isso é a compatibilidade com versões anteriores, Doug…

…que a Microsoft quer que esse recurso funcione até as pessoas que ainda estão usando o Office 2010, que tem habilidades de descriptografia bem antigas embutidas nele.

Basicamente, parece que esse processo OME de criptografar o arquivo usa AES, que é o mais recente e melhor algoritmo de criptografia padronizado pelo NIST.

Mas ele usa o AES no chamado modo de criptografia errado.

Ele usa o que é conhecido como ECB, ou livro de código eletrônico modo.

E essa é simplesmente a maneira como você se refere ao AES bruto.

O AES criptografa 16 bytes por vez... a propósito, ele criptografa 16 bytes se você usa AES-128, AES-192 ou AES-256.

Não confunda o tamanho do bloco e o tamanho da chave – o tamanho do bloco, o número de bytes que são alterados e criptografados cada vez que você gira a manivela no mecanismo criptográfico, é sempre 128 bis, ou 16 bytes.

De qualquer forma, no modo de livro de código eletrônico, você simplesmente pega 16 bytes de entrada, gira a manivela uma vez sob uma determinada chave de criptografia e obtém a saída, bruta e não reprocessada.

E o problema com isso é que toda vez que você obtém a mesma entrada em um documento alinhado no mesmo limite de 16 bytes…

…você obtém exatamente os mesmos dados na saída.

Assim, os padrões na entrada são revelados na saída, assim como são em um César cifra ou um Vigenère cifra:

Agora, isso não significa que você pode quebrar a cifra, porque você ainda está lidando com pedaços de 128 bits de largura por vez.

O problema com o modo de livro de código eletrônico surge precisamente porque ele vaza padrões do texto simples para o texto cifrado.

Ataques de texto simples conhecidos são possíveis quando você sabe que uma determinada string de entrada é criptografada de uma determinada maneira e, para texto repetido em um documento (como um cabeçalho ou nome de empresa), esses padrões são refletidos.

E embora isso tenha sido relatado como um bug para a Microsoft, aparentemente a empresa decidiu que não vai corrigi-lo porque “não atende aos requisitos” para uma correção de segurança.

E parece que o motivo é: “Bem, estaríamos fazendo um desserviço às pessoas que ainda estão usando o Office 2010”.

---

DOUG.  Aff!

---

PATO.  Sim!

---

DOUG.  E nessa nota, temos um comentário do leitor para esta semana sobre esta história.

O Naked Security Reader Bill comenta, em parte:

Isso me lembra os 'berços' que os decifradores de Bletchley Park usaram durante a Segunda Guerra Mundial. Os nazistas muitas vezes terminavam as mensagens com a mesma frase de fechamento e, assim, os decifradores de código poderiam trabalhar de volta a partir desse conjunto de caracteres criptografados, sabendo o que eles provavelmente representavam. É decepcionante que, 80 anos depois, pareçamos estar repetindo os mesmos erros.

---

PATO.  80 anos!

Sim, é decepcionante mesmo.

Meu entendimento é que outros berços que os decifradores de código aliados poderiam usar, particularmente para textos criptografados pelos nazistas, também lidavam com o *início* do documento.

Eu acredito que isso era uma coisa para os boletins meteorológicos alemães… havia um formato religioso que eles seguiam para garantir que eles fornecessem os boletins meteorológicos exatamente.

E os boletins meteorológicos, como você pode imaginar, durante uma guerra que envolve bombardeios aéreos noturnos, eram coisas realmente importantes!

Parece que eles seguiram um padrão muito, muito estrito que poderia, ocasionalmente, ser usado como o que você poderia chamar de um “solteiro” criptográfico, ou uma cunha que você poderia usar para quebrar em primeiro lugar.

E isso, como Bill aponta… é exatamente por isso que o AES, ou qualquer cifra, no modo de livro de código eletrônico não é satisfatório para criptografar documentos inteiros!

---

DOUG.  Muito bem, obrigado por enviar isso, Bill.

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!