Segurança séria: Microsoft Office 365 atacado por criptografia fraca

Não sabemos ao certo como chamá-lo agora, então nos referimos a ele no título pelo nome híbrido Microsoft Office 365.

(O nome “Office” como substantivo coletivo para os aplicativos de processamento de texto, planilha, apresentação e colaboração da Microsoft está sendo morto no próximo mês ou dois, para se tornar simplesmente "Microsoft 365".)

Temos certeza de que as pessoas continuarão usando os nomes de aplicativos individuais (Word, Excel, PowerPoint e amigos) e o apelido da suíte Office por muitos anos, embora os recém-chegados ao software provavelmente acabem conhecendo-o como 365, depois de descartar o prefixo onipresente da Microsoft.

Como você deve saber, os aplicativos autônomos do Office (aqueles que você realmente instala localmente para não precisar ficar online para trabalhar em suas coisas) incluem sua própria opção para criptografar documentos salvos.

Isso deve adicionar uma camada extra de segurança caso você compartilhe algum desses arquivos, por acidente ou design, com alguém que não deveria recebê-los – algo surpreendentemente fácil de fazer por engano ao compartilhar anexos por e-mail.

A menos e até que você também dê ao destinatário a senha que eles precisam para desbloquear o arquivo, é apenas repolho picado para eles.

É claro que, se você incluir a senha no corpo do e-mail, você não ganhará nada, mas se for um pouco cauteloso ao compartilhar a senha por meio de um canal diferente, você terá segurança extra contra invasores. , bisbilhoteiros e malfeitores obtendo acesso fácil a conteúdo confidencial.

OME sob os holofotes

Ou você tem?

De acordo com o pesquisadores na empresa finlandesa de segurança cibernética WithSecure, seus dados podem estar desfrutando de muito menos proteção do que você poderia esperar.

O recurso que os testadores usaram é o que eles chamam de Criptografia de mensagens do Office 365ou OME abreviado.

Não reproduzimos seus experimentos aqui, pelo simples motivo de que os produtos principais do Office, desculpe, 365 produtos não rodam nativamente no Linux, que usamos para trabalhar. As versões baseadas na Web das ferramentas do Office não têm o mesmo conjunto de recursos que os aplicativos completos, portanto, é improvável que os resultados que possamos obter se alinhem com a forma como a maioria dos usuários corporativos do Office, ah, 365 configurou o Word, Excel, Outlook e amigos em seus laptops Windows.

Como os pesquisadores descrevem:

Esse recurso é anunciado para permitir que as organizações enviem e recebam mensagens de email criptografadas entre pessoas dentro e fora de sua organização de maneira segura.

Mas também apontam que:

Infelizmente, as mensagens OME são criptografadas no modo de operação inseguro Electronic Codebook (ECB).

BCE explicou

Explicar.

Muitos algoritmos de criptografia, notadamente o Advanced Encryption Standard ou AES, que o OME usa, são o que é conhecido como cifras de bloco, que embaralham grandes blocos de dados por vez, em vez de processar bits ou bytes individuais em sequência.

De um modo geral, isso deve ajudar tanto na eficiência quanto na segurança, porque a cifra tem mais dados de entrada para misturar-picar-triturar-e-liquidar a cada volta da manivela criptográfica que aciona o algoritmo, e cada volta leva você mais longe através dos dados que você deseja criptografar.

O algoritmo AES principal, por exemplo, consome 16 bytes de texto simples de entrada (128 bits) por vez e embaralha esses dados em uma chave de criptografia para produzir 16 bytes de saída de texto cifrado criptografado.

(Não confunda tamanho do bloco de tamanho da chave – As chaves de criptografia AES podem ter 128 bits, 192 bits ou 256 bits, dependendo de quão improvável você deseja que elas sejam adivinhadas, mas todos os três tamanhos de chave funcionam em blocos de 128 bits cada vez que o algoritmo é “acionado”.)

O que isso significa é que, se você escolher uma chave AES (independentemente do tamanho) e usar a cifra AES diretamente em um bloco de dados…

…então toda vez que você obtém o mesmo pedaço de entrada, você obtém o mesmo pedaço de saída.

Como um livro de códigos verdadeiramente enorme

É por isso que este modo direto de operação é chamado BCE, abreviatura de livro de código eletrônico, porque é como ter um enorme livro de códigos que poderia ser usado como uma tabela de consulta para criptografar e descriptografar.

(Um “livro de códigos” completo nunca poderia ser construído na vida real, porque seria necessário armazenar um banco de dados composto por 2¹²⁸ Entradas de 16 bytes para cada chave possível.)

Infelizmente, especialmente em dados formatados por computador, a repetição de certos blocos de dados geralmente é inevitável, graças ao formato de arquivo usado.

Por exemplo, arquivos que rotineiramente preenchem seções de dados para que se alinhem em limites de 512 bytes (um tamanho de setor comum ao gravar em disco) ou em limites de 4096 bytes (um tamanho de unidade de alocação comum ao reservar memória) geralmente produzirão arquivos com execuções longas de zero bytes.

Da mesma forma, documentos de texto que contenham muitos clichês, como cabeçalhos e rodapés em todas as páginas, ou menções repetidas ao nome completo da empresa, conterão muitas repetições.

Toda vez que um trecho de texto simples repetido se alinha em um limite de 16 bytes no processo de criptografia AES-ECB, ele emergirá na saída criptografada como exatamente o mesmo texto cifrado.

Portanto, mesmo que você não consiga descriptografar formalmente o arquivo de texto cifrado, você poderá fazer inferências imediatas e que destruam a segurança a partir dele, graças ao fato de que os padrões na entrada (que você pode conhecer ou ser capaz de inferir) ou adivinhar) são preservados na saída.

Aqui está um exemplo baseado em um artigo que publicamos há quase nove anos, quando explicamos por que o agora notório uso da criptografia no modo ECB pela Adobe para “hash” as senhas de seus usuários foi Não é uma boa ideia:

Observe como os pixels que são brancos sólidos na entrada produzem de forma confiável um padrão repetitivo na saída, e as partes azuis permanecem um tanto regulares, de modo que a estrutura dos dados originais é óbvia.

Neste exemplo, cada pixel no arquivo original ocupa exatamente 4 bytes, de modo que cada execução de 4 pixels da esquerda para a direita nos dados de entrada tem 16 bytes de comprimento, o que se alinha exatamente com cada bloco de criptografia AES de 16 bytes, acentuando assim o “efeito BCE”.

---

Padrões de texto cifrado correspondentes

Pior ainda, se você tiver dois documentos que você sabe que estão criptografados com a mesma chave, e você tiver o texto simples de um deles, então você pode olhar através do texto cifrado que você não pode descriptografar e tentar combinar seções dele com padrões no texto cifrado que você pode descriptografar.

Lembre-se de que você não precisa da chave para “descriptografar” o primeiro documento se já o tiver na forma descriptografada – isso é conhecido, sem surpresa, como ataque de texto simples conhecido.

Mesmo que existam apenas algumas correspondências de texto aparentemente inocente que não sejam dados secretos, o conhecimento que um adversário pode extrair desta forma pode ser uma mina de ouro para espiões de propriedade intelectual, engenheiros sociais, investigadores forenses e muito mais.

Por exemplo, mesmo que você não tenha ideia do que os detalhes de um documento se referem, combinando pedaços de texto simples conhecidos em vários arquivos, você pode determinar que uma coleção aparentemente aleatória de documentos:

• Foram todos enviados para o mesmo destinatário, se houver uma saudação comum no topo de cada um.
• Consulte o mesmo projeto, se houver uma string de texto de identificação exclusiva que continua aparecendo.
• Têm a mesma classificação de segurança, se você deseja se concentrar em coisas que claramente devem ser “mais secretas” do que o resto.

O que fazer?

Não use o modo BCE!

Se você estiver usando uma cifra de bloco, escolha um modo de operação de cifra de bloco que:

• Inclui o que é conhecido como IV, ou vetor de inicialização, escolhidos aleatoriamente e exclusivamente para cada mensagem.
• Organiza deliberadamente o processo de criptografia para que entradas repetidas saiam de forma diferente a cada vez.

Se você estiver usando o AES, o modo que você provavelmente deseja escolher atualmente é AES-GCM (Galois Counter Mode), que não apenas usa um IV para criar um fluxo de dados de criptografia diferente a cada vez, mesmo que a chave permaneça a mesma, mas também calcula o que é conhecido como Código de autenticação de mensagem (MAC), ou soma de verificação criptográfica, ao mesmo tempo em que embaralha ou desembaralha os dados.

AES-GCM significa não apenas que você evita padrões repetidos de texto cifrado, mas também que sempre acaba com uma “soma de verificação” que lhe dirá se os dados que você acabou de descriptografar foram adulterados ao longo do caminho.

Lembre-se de que um bandido que não sabe o que o texto cifrado realmente significa pode, no entanto, ser capaz de enganá-lo a confiar em uma descriptografia inexata sem nunca saber (ou se importar) com o tipo de saída incorreta que você obtém.

Um MAC calculado durante o processo de descriptografia, com base na mesma chave e IV, ajudará a garantir que você saiba que o texto cifrado recebido é válido e, portanto, que quase certamente descriptografou o que foi originalmente colocado na outra extremidade.

Alternativamente, use um dedicado cifra de fluxo que produz um fluxo de chaves pseudo-aleatório byte por byte que permite criptografar dados sem ter que processar 16 bytes (ou qualquer que seja o tamanho do bloco) por vez.

O AES-GCM essencialmente converte AES em uma cifra de fluxo e adiciona autenticação na forma de MAC, mas se você estiver procurando por uma cifra de fluxo dedicada projetada especificamente para funcionar dessa maneira, sugerimos o de Daniel Bernstein. ChaCha20-Poly1305 (a parte Poly1305 é o MAC), conforme detalhado em RFC 8439.

Abaixo, mostramos o que obtivemos usando AES-128-GCM e ChaCha20-Poly1305 (descartamos os códigos MAC aqui), junto com uma “imagem” consistindo de 95,040 bytes RGBA (330×72 a 4 bytes por pixel) do Gerador pseudo-aleatório do kernel Linux.

Lembre-se de que só porque os dados parecem não estruturados não significa que sejam verdadeiramente aleatórios, mas se não parecerem aleatórios, mas alegarem estar criptografados, você também pode assumir que há alguma estrutura deixada para trás e que a criptografia é suspeito:

O que acontece depois?

De acordo com WithSecure, a Microsoft não planeja corrigir essa “vulnerabilidade”, aparentemente por motivos de retrocompatibilidade com o Office 2010…

As versões herdadas do Office (2010) exigem AES 128 ECB, e os documentos do Office ainda são protegidos dessa maneira pelos aplicativos do Office.

…e…

O relatório [dos pesquisadores da WithSecure] não foi considerado como atendendo aos requisitos de serviço de segurança, nem é considerado uma violação. Nenhuma alteração de código foi feita e, portanto, nenhum CVE foi emitido para este relatório.

Em resumo, se você está confiando no OME, considere substituí-lo por uma ferramenta de criptografia de terceiros para mensagens confidenciais que criptografam seus dados independentemente dos aplicativos que criaram essas mensagens e, portanto, funcionam independentemente da criptografia interna código na gama Office.

Dessa forma, você pode escolher uma cifra moderna e um modo moderno de operação de cifra, sem ter que voltar para o código de descriptografia antigo integrado ao Office 2010.

---

COMO CRIAMOS AS IMAGENS DO ARTIGO Comece com sop330.png, que você pode criar cortando o logotipo SOPHOS limpo da imagem superior, removendo o limite azul de 2 pixels e salvando no formato PNG.  A imagem deve terminar em 330x72 pixels de tamanho.
 Converta para RGBA usando ImageMagick: $ convert sop330.png sop.rgba A saída é 330x72 pixels x 4 bytes/pixel = 95,040 bytes.
 === Criptografe usando Lua e a biblioteca LuaOSSL (Python tem uma ligação OpenSSL muito semelhante): -- load data > fdat = misc.filetostr('sop.rgba') > fdat:len() 95040 -- cria objetos de cifra > aes = openssl.cipher.new('AES-128-ECB') > gcm = openssl.cipher.new('AES-128-GCM') > cha = openssl.cipher.new('ChaCha20-Poly1305') -- inicializar senhas e IVs -- AES-128-ECB precisa de uma senha de 128 bits, mas não IV -- AES-128-GCM precisa de uma senha de 128 bits e um IV de 12 bytes -- ChaCha20 precisa de uma senha de 256 bits e a 12 bytes IV > aes:encrypt('THEPASSWORDIS123') > gcm:encrypt('THEPASSWORDIS123','andkrokeutiv') > cha:encrypt('THEPASSWORDIS123THEPASSWORDIS123','qlxmtosh476g') -- criptografa os dados do arquivo com as três cifras > aesout = aes:final(fdat) > gcmout = gcm:final(fdat) > chaout = cha:final(fdat) -- uma cifra de fluxo produz saída byte a byte, -- então o texto cifrado deve ter o mesmo comprimento que o texto simples > gcmout:len() 95040 > chaout:len() 95040 -- não usaremos os códigos MAC do GCM e Poly1305 aqui, -- mas cada cifra produz uma "soma de verificação" de 128 bits (16 bytes) -- usada para autenticar a descriptografia após o término, -- para detectar se o texto cifrado de entrada é corrompido ou hackeado -- (o MAC depende da chave, então um atacante não pode forjar) > base.hex(gcm:getTag(16)) a70f204605cd5bd18c9e4da36cbc9e74 > base.hex(cha:getTag(16)) a55b97d5e9f3cb9a3be2fa4f040b56ef -- cria uma "imagem" 95040 diretamente de /dev/random > rndout = misc.filetostr('/dev/random',#fdat) -- salve-os todos - observe que truncamos explicitamente o AES-ECB -- a saída da cifra de bloco para o comprimento exato da imagem necessária, porque -- o ECB precisa de preenchimento para corresponder ao tamanho de entrada com o tamanho do bloco > misc.strtofile(aesout:sub(1,#fdat),'aes.rgba') > misc.strtofile(gcmout,'gcm.rgba') > misc.strtofile(chaout,'cha. rgba') > misc.strtofile(rndoout,'rnd.rgba') === Para carregar os arquivos em um visualizador de imagens normal, pode ser necessário convertê-los sem perdas de volta ao formato PNG: $ convert -depth 8 -size 330x72 aes .rgba aes.png $ convert -depth 8 -size 330x72 gcm.rgba gcm.png $ convert -depth 8 -size 330x72 cha.rgba cha.png $ convert -depth 8 -size 330x72 rnd.rgba rnd.png === Dado que o processo de criptografia embaralha todos os quatro bytes em cada pixel RGBA , a imagem resultante tem transparência variável (A = alfa, abreviação de transparência).
 Seu visualizador de imagens pode decidir exibir esse tipo de imagem com um fundo quadriculado, que confusamente parece parte da imagem, mas não é.  Portanto, usamos o azul Sophos da imagem original como plano de fundo para os arquivos criptografados para facilitar a visualização.  A tonalidade azul geral, portanto, não faz parte dos dados da imagem.