Segurança séria: o bug de logon do Samba causado por criptografia desatualizada

Samba, em poucas palavras, é uma reimplementação de código aberto super útil e megapopular dos protocolos de rede usados ​​no Microsoft Windows, e sua importância histórica na interconexão de redes (conectando dois tipos diferentes de rede) não pode ser subestimada.

No final da década de 1990, a rede da Microsoft abandonou sua natureza opaca e proprietária e tornou-se um padrão aberto conhecido como CIFS, abreviação de sistema de arquivos comum da internet.

Mas não havia nada de “comum” ou “aberto” nisso no início dos anos 1990, quando o acadêmico australiano Andrew Tridgell decidiu corrigir isso implementando um sistema compatível que permitisse conectar seu computador Unix a uma rede Windows e vice-versa.

Naquela época, o protocolo era oficialmente conhecido como SMB, abreviação de bloco de mensagem do servidor (um nome que você ainda ouve com muito mais frequência do que CIFS), então Tridge, como Andrew Tridgell é conhecido, compreensivelmente chamou seu projeto de “SMBserver”, porque era isso.

Mas um produto comercial com esse nome já existia, então um novo apelido era necessário.

Foi quando o projeto ficou conhecido como Samba, um nome deliciosamente memorável que resultou de uma busca no dicionário por palavras da forma S?M?B?.

Na verdade, samba ainda é a primeira palavra fora do portão em ordem alfabética no dict arquivo comumente encontrado em computadores Unix, seguido pela palavra bastante inadequada scramble e o totalmente inapropriado scumbag:

Alguns bugs você faz, mas alguns bugs você pega

Ao longo dos anos, o projeto Samba não apenas introduziu e corrigiu seus próprios bugs exclusivos, como geralmente faz qualquer projeto de software complexo, mas também herdou bugs e deficiências no protocolo subjacente, já que seu objetivo sempre foi trabalhar perfeitamente com redes Windows.

(Infelizmente, os chamados compatibilidade de bugs geralmente é uma parte inevitável da construção de um novo sistema que funcione com um existente.)

No final de 2022, uma dessas “vulnerabilidades herdadas” foi encontrada e relatada à Microsoft, dado o identificador CVE-2022-38023e corrigido na atualização Patch Tuesday de novembro de 2022.

Este bug pode ter permitido que um invasor alterasse o conteúdo de alguns pacotes de dados de rede sem ser detectado, apesar do uso de MACs criptográficos (códigos de autenticação de mensagem) destinado a evitar falsificação e adulteração.

Notavelmente, ao manipular dados no momento do logon, cibercriminosos astutos podem realizar um ataque de elevação de privilégio (EoP).

Eles poderiam, pelo menos em teoria, induzir um servidor a pensar que eles passaram no teste "você tem credenciais de administrador?" teste, mesmo que eles não tivessem essas credenciais e seus dados falsos devessem ter falhado em sua verificação criptográfica.

Agilidade criptográfica

Decidimos escrever sobre esse bug bastante esotérico não porque achamos que você provavelmente será explorado por ele (embora, quando se trata de segurança cibernética, tomamos a atitude Nunca diga nunca), mas porque é um mais um lembrete por que agilidade criptográfica é importante.

---

---

Coletivamente, precisamos tanto da habilidade quanto da vontade de deixar para trás algoritmos antigos para sempre assim que forem encontrados defeitos, e não deixá-los por aí indefinidamente até que se transformem em problema de outra pessoa. (Esse “alguém” pode acabar sendo nós, daqui a dez anos.)

Surpreendentemente, a vulnerabilidade CVE-2022-38023 existia em primeiro lugar porque o Windows e o Samba ainda suportavam um estilo de proteção de integridade baseado no algoritmo de hash MD5, há muito obsoleto.

Simplificando, a autenticação de rede usando a versão da Microsoft do protocolo Kerberos ainda permitia que os dados fossem protegidos por integridade (ou soma de verificação, para usar o termo de jargão casual, mas não estritamente preciso) usando criptografia defeituosa.

Você não deveria mais usar o MD5 porque é considerado quebrado: um invasor determinado pode facilmente criar duas entradas diferentes que acabam com o mesmo hash MD5.

Como você provavelmente já sabe, no entanto, um dos requisitos de qualquer hash que reivindica qualidade criptográfica é que isso simplesmente não deveria ser possível.

No jargão, duas entradas que possuem o mesmo hash são conhecidas como colisão, e não deve haver nenhum truque ou atalho programático para ajudá-lo a encontrar um rapidamente.

Não deve haver nenhuma maneira de encontrar uma colisão que seja melhor do que uma simples boa sorte - tentando repetidamente com arquivos de entrada em constante mudança até você acertar o jackpot.

O verdadeiro custo de uma colisão

Assumindo um algoritmo confiável, sem fraquezas exploráveis, você esperaria que um hash com X bits de saída precisasse de cerca de 2^X-1 tenta encontrar uma segunda entrada que colidiu com o hash de um arquivo existente.

Mesmo que tudo o que você quisesse fazer fosse encontrar quaisquer duas entradas (duas entradas arbitrárias, independentemente do conteúdo, tamanho ou estrutura) que tivessem o mesmo hash, você esperaria precisar de um pouco mais de 2^{X / 2} tenta antes de bater em uma colisão.

Qualquer algoritmo de hash que possa ser “quebrado” de forma confiável mais rápido do que isso não é criptograficamente seguro, porque você mostrou que seu processo interno para triturar-cortar-e-agitar os dados que são alimentados nele não produz um resultado verdadeiramente pseudo-aleatório.

Observe que qualquer procedimento de cracking melhor do que o acaso, mesmo que apenas acelere ligeiramente o processo de geração de colisão e, portanto, não seja atualmente um risco explorável na vida real, destrói a fé no algoritmo criptográfico subjacente ao minar suas reivindicações de correção criptográfica .

Se houver 2^X diferentes saídas de hash possíveis, você espera atingir uma chance de 50:50 de encontrar uma entrada com um hash específico e pré-determinado após cerca de metade das tentativas e 2^X/ 2 = 2^X-1. Encontrar quaisquer dois arquivos que colidem é mais fácil, porque toda vez que você tenta uma nova entrada, você ganha se seu novo hash colidir com qualquer das entradas anteriores você já tentou, porque qualquer par de entradas é permitido. Para uma colisão do tipo “quaisquer dois arquivos neste balde gigante servirão”, você atinge a chance de 50:50 de sucesso em apenas um pouco mais do que a raiz quadrada do número de hashes possíveis e √2^X = 2^{X / 2}. Portanto, para um hash de 128 bits como MD5, você esperaria, em média, cerca de 2¹²⁷ blocos para corresponder a um valor de saída específico e 2⁶⁴ blocos para encontrar qualquer par de entradas em colisão.

Colisões MD5 rápidas facilitadas

Acontece que você não pode gerar facilmente duas entradas pseudo-aleatórias completamente diferentes e não relacionadas que tenham o mesmo hash MD5.

E você não pode retroceder facilmente de um hash MD5 para descobrir qualquer coisa sobre a entrada específica que o produziu, que é outra promessa criptográfica que um hash confiável precisa manter.

Mas se você começar com duas entradas idênticas e inserir cuidadosamente um par calculado deliberadamente de pedaços de “construção de colisão” no mesmo ponto em cada fluxo de entrada, poderá criar colisões MD5 de forma confiável em segundos, mesmo em um laptop modesto.

Por exemplo, aqui está um programa Lua que escrevemos que pode ser convenientemente dividido em três seções distintas, cada uma com 128 bytes.

Há um prefixo de código que termina com uma linha de texto que inicia um comentário Lua (a string que começa --[== na linha 8), há 128 bytes de texto de comentário que pode ser substituído por qualquer coisa que quisermos, porque é ignorado quando o arquivo é executado (linhas 9 a 11) e há um sufixo de código de 128 bytes que fecha o comentário (o string começando --]== na linha 12) e finaliza o programa.

Mesmo que você não seja um programador, provavelmente poderá ver que o código ativo lê o conteúdo [linha 14] do próprio arquivo de código-fonte (em Lua, o valor arg[0] na linha 5 é o nome do arquivo de script que você está executando atualmente), então o imprime como um dump hexadecimal [linha 15] , seguido por seu hash MD5 [linha 17]:

A execução do arquivo é essencialmente autodescritiva e torna os três blocos de 128 bytes óbvios:

Usando um MD5 ferramenta de pesquisa chamado md5_fastcoll, originalmente criado pelo matemático Marc Stevens como parte de seu mestrado em criptografia em 2007, produzimos rapidamente dois pedaços de 128 bytes “criação de colisão MD5” que usamos para substituir o texto do comentário mostrado no arquivo acima.

Isso criou dois arquivos que ainda funcionam como antes, porque as alterações estão confinadas ao comentário, o que não afeta o código executável em nenhum dos arquivos.

Mas eles são visivelmente diferentes em vários bytes e, portanto, devem ter valores de hash completamente diferentes, como o seguinte código diff (jargão para despejo de diferenças detectadas) revela.

Convertemos os pedaços de criação de colisão de 128 bytes, que não fazem sentido como texto imprimível, em hexadecimal para maior clareza:

A execução de ambos, no entanto, mostra claramente que eles representam uma colisão de hash, porque eles têm a mesma saída MD5:

Complexidade de colisão explorada

MD5 é um hash de 128 bits, como as strings de saída acima deixam claro.

Então, como mencionado antes, esperamos precisar de cerca de 2^128/2Ou 2⁶⁴ tenta, em média, produzir uma colisão MD5 de qualquer tipo.

Isso significa processar um mínimo de cerca de 18 quintilhões de blocos de hash MD5, porque 2⁶⁴ = 18,446,744,073,709,551,616.

Em uma taxa de hash MD5 de pico estimada de cerca de 50,000,000 de blocos/segundo em nosso laptop, isso significa que teríamos que esperar mais de 10,000 anos e, embora invasores bem financiados possam facilmente ir de 10,000 a 100,000 vezes mais rápido do que isso, mesmo eles espere semanas ou meses apenas para que uma única colisão aleatória (e não necessariamente útil) apareça.

No entanto, o par de arquivos Lua de duas faces acima, que têm exatamente o mesmo hash MD5, apesar de claramente não serem idênticos, levou apenas alguns segundos para ser preparado.

De fato, gerar 10 colisões diferentes para 10 arquivos, usando 10 prefixos iniciais diferentes que nós mesmos escolhemos, nos levou: 14.9 seg, 4.7 seg, 2.6 seg, 2.1 seg, 10.5 seg, 2.4 seg, 2.0 seg, 0.14 seg, 8.4 seg, e 0.43 seg.

Claramente, a promessa criptográfica do MD5 de fornecer o que é conhecido como resistência a colisão está fundamentalmente quebrado…

…aparentemente por um fator de pelo menos 25 bilhões, com base na divisão do tempo médio que esperamos esperar para encontrar uma colisão (milhares de anos, conforme estimado acima) pelo pior tempo que realmente medimos (14.9 segundos) durante a agitação dez colisões diferentes apenas para este artigo.

A falha de autenticação explicada

Mas e quanto ao uso inseguro de MD5 em CVE-2022-38023?

No pseudocódigo estilo Lua, o código de autenticação de mensagem defeituoso usado durante os logons era calculado assim:

Para explicar: o código de autenticação usado é calculado pelo hmac.md5() chamada de função na linha 15, usando o que é conhecido como hash com chave, neste caso HMAC-MD5.

O nome HMAC é a abreviação de construção criptográfica para gerar códigos de autenticação de mensagens baseados em hash, e o sufixo -MD5 denota o algoritmo de hash que está usando internamente.

O HMAC usa uma chave secreta, combinada com duas invocações do hash subjacente, em vez de apenas uma, para produzir seu código de autenticação de mensagem:

A chave tem alguns de seus bits invertidos primeiro e é anexada aos dados fornecidos antes do início do primeiro hash.

Isso reduz muito o controle que os crackers criptográficos têm, quando tentam provocar uma colisão ou outro comportamento não aleatório no processo de hash, sobre o estado interno da função hash quando os primeiros bytes dos dados de entrada são alcançados.

Notavelmente, a chave secreta impede que os invasores comecem com um prefixo de mensagem de sua própria escolha, como fizemos no twohash.lua exemplo acima.

Então, uma vez que o primeiro hash é calculado, a chave tem um conjunto diferente de bits invertido, é anexado ao primeiro valor de hash e esses novos dados de entrada são hash uma segunda vez.

Isso também evita que os invasores manipulem a parte final do cálculo do HMAC, impedindo-os de anexar um sufixo de sua própria escolha ao último estágio do processo de hash.

De fato, mesmo que você não deva usar o MD5, não temos conhecimento de nenhum ataque atual que possa quebrar o algoritmo quando ele é usado no formato HMAC-MD5 com uma chave escolhida aleatoriamente.

O buraco está no meio

A lacuna explorável no pseudocódigo acima, portanto, não está em nenhuma das linhas onde o hmac.md5() função é usada.

Em vez disso, o coração do bug é a linha 11, onde os dados que você deseja autenticar são compactados em uma string de tamanho fixo…

.. empurrando-o através de uma única invocação do velho e simples MD5.

Em outras palavras, não importa qual função HMAC você escolha na linha 15, e não importa o quão forte e resistente a colisão essa etapa final possa ser, você ainda tem a chance de causar uma colisão de hash na linha 11.

Simplificando, se você conhece os dados que devem entrar no chksum() função a ser autenticada e você pode usar um gerador de colisão para encontrar um bloco de dados diferente com o mesmo hash MD5…

…linha 11 significa que você acabará com exatamente o mesmo valor de entrada (a variável signdat no pseudocódigo) sendo empurrado para a etapa HMAC tão segura quanto você gosta.

Portanto, mesmo que você esteja usando uma função de resumo de mensagem com chave forte no final, você pode estar autenticando um hash MD5 derivado de dados do impostor.

Menos teria sido mais

como o samba boletim de segurança descreve de forma compacta o problema:

A fraqueza […] é que a soma de verificação segura é calculada como HMAC-MD5(MD5(DATA),KEY), o que significa que um invasor ativo conhecendo os dados de texto sem formatação pode criar um diferente escolhido DATA, com a mesma soma de verificação MD5 e substitua-o no fluxo de dados sem ser detectado.

Ironicamente, deixando de lado o MD5(DATA) parte da fórmula HMAC acima, que parece à primeira vista aumentar o processo geral de “mistura”, melhoraria a resistência à colisão.

Sem essa compactação MD5 no meio, você precisaria encontrar uma colisão no próprio HMAC-MD5, o que provavelmente não será possível em 2023, mesmo com financiamento quase ilimitado do governo, pelo menos não durante o tempo de vida da sessão de rede que você estava tentando comprometer.

O que demorou tanto?

A essa altura, você provavelmente está se perguntando, como nós, por que esse bug permaneceu sem ser descoberto, ou pelo menos sem correção, por tanto tempo.

Afinal, RFC 6151, que remonta a 2011 e tem o título significativo Considerações de segurança atualizadas para o MD5 Message-Digest e os algoritmos HMAC-MD5, aconselha o seguinte (grifo nosso, mais de uma década depois):

Os ataques ao HMAC-MD5 não parecem indicar uma vulnerabilidade prática quando usado como código de autenticação de mensagem. Portanto, pode não ser urgente remover o HMAC-MD5 dos protocolos existentes. No entanto, desde MD5 não deve ser usado para assinaturas digitais, para um novo projeto de protocolo, um ciphersuite com HMAC-MD5 não deve ser incluído.

Parece, no entanto, como a grande maioria das plataformas de servidor SMB recentes tem a autenticação HMAC-MD5 desativada quando os usuários tentam fazer logon, que os clientes SMB que ainda suportam esse modo inseguro geralmente nunca o usaram (e teriam falhado de qualquer maneira se tivessem tentou).

Os clientes implicitamente pareciam estar “protegidos” e o código inseguro parecia ser tão bom quanto inofensivo, porque a autenticação fraca não era necessária nem usada.

Portanto, o problema em potencial simplesmente nunca recebeu a atenção que merecia.

Infelizmente, esse tipo de “segurança por suposição” falha completamente se você encontrar (ou for atraído para) um servidor que aceita essa insegurança chksum() algoritmo durante o logon.

Esse tipo de “problema de downgrade” não é novo: em 2015, pesquisadores criaram o notório FREAK e CONJUNTO ataques, que deliberadamente induziram os clientes da rede a usar as chamadas cifras EXPORT, que eram os modos de criptografia deliberadamente enfraquecidos que o governo dos EUA bizarramente insistiu por lei no século passado.

Como escrevemos na época:

Os comprimentos das chaves EXPORT foram escolhidos para serem quase quebráveis ​​na década de 1990, mas nunca estendidos para acompanhar os avanços na velocidade do processador.

Isso porque as cifras de exportação foram abandonadas pelos EUA por volta de 2000.

Eles eram uma ideia tola desde o início: as empresas americanas apenas importavam software criptográfico que não tinha restrições de exportação e prejudicavam sua própria indústria de software.

Claro, uma vez que os legisladores cederam, os ciphersuites EXPORT tornaram-se supérfluos, então todos pararam de usá-los.

Infelizmente, muitos kits de ferramentas criptográficas, incluindo OpenSSL e SChannel da Microsoft, mantiveram o código para suportá-los, então você (ou, mais preocupante, bandidos bem informados) não foi impedido de usá-los.

Desta vez, o principal culpado entre os servidores que ainda usam esse processo quebrado de MD5-mais-HMAC-MD5 parece ser a linha NetApp, na qual alguns produtos aparentemente continuam (ou continuaram até recentemente) a confiar nesse algoritmo arriscado.

Portanto, às vezes você ainda pode estar passando por um processo de logon de rede vulnerável e corre o risco de CVE-2022-38023, talvez mesmo sem perceber.

O que fazer?

Este bug foi finalmente tratado com, pelo menos por padrão, na versão mais recente do Samba.

Simplificando, Samba versão 4.17.5 agora força as duas opções reject md5 clients = yes e reject md5 servers = yes.

Isso significa que quaisquer componentes criptográficos nos vários protocolos de rede SMB que envolvem o algoritmo MD5 (mesmo que sejam teoricamente seguros, como HMAC-MD5), são proibido por padrão.

Se realmente precisar, você pode ativá-los novamente para acessar servidores específicos em sua rede.

Apenas certifique-se, se você criar exceções que os padrões da Internet já desaconselharam oficialmente por mais de uma década…

…que você defina uma data em que finalmente aposentará essas opções não padrão para sempre!

Os ataques criptográficos ficam cada vez mais inteligentes e rápidos, portanto, nunca confie em protocolos e algoritmos desatualizados simplesmente “não sendo mais usados”.

Retire-os completamente do seu código, porque se eles não estiverem lá, você NÃO PODE usá-los e não pode ser enganado para usá-los por alguém que está tentando atraí-lo para a insegurança.

---

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• Platoblockchain. Inteligência Metaverso Web3. Conhecimento Ampliado. Acesse aqui.
• Fonte: https://nakedsecurity.sophos.com/2023/01/30/serious-security-the-samba-logon-bug-caused-by-outdated-crypto/