Um arquivo pode ser mal-intencionado alterado de forma a manter seu hash SHA-1 original?

Question

De acordo com este artigo, e muitos outros, SHA-1 não é seguro.

No meu caso, não estou preocupado com senhas ou certificados digitais. Estou preocupado com a integridade dos arquivos.

É razoavelmente possível que um arquivo (por exemplo, uma imagem ISO ou arquivo executável) seja alterado de maneira mal-intencionada de forma que:

• Mantém o hash SHA-1 do arquivo original e
• Mantém o conteúdo geral e a operação do arquivo (mas, é claro, agora inclui conteúdo mal-intencionado que não existia originalmente)

Do jeito que eu vejo, alterar um arquivo de uma maneira que produza uma colisão SHA-1 tornaria o arquivo totalmente inútil. O ISO seria totalmente corrompido, ou o arquivo executável seria tão embaralhado que nem seria mais um arquivo executável.

Mas a maneira como vejo isso pode estar errado. Até agora não encontrei nada nas pesquisas do Google em relação à adequação contínua do SHA-1 para verificação de arquivos. Alguma ideia?

    

Answer 1

Ninguém ainda realizou isso para o SHA-1. É possível em teoria, mas ainda não é prático. Os relatórios sobre insegurança no SHA-1 significam apenas que o nível de segurança não é tão alto quanto gostaríamos que fosse e isso significa que não temos tantos anos antes que tenhamos que nos preocupar com isso como pensamos que fizemos. / p>

É mais difícil produzir um arquivo com o mesmo hash SHA-1 de um determinado arquivo do que criar dois arquivos com o mesmo hash SHA-1. E, até onde sabemos, ninguém em qualquer parte do mundo ainda realizou essa tarefa tão fácil. Isso não significa que não possa acontecer amanhã.

    

Answer 2

É teoricamente possível, mas ainda não foi feito.

O que você está procurando é chamado de "hash collision": dois arquivos com o mesmo hash. Os códigos hash criptográficos como o SHA-1 são geralmente projetados para dificultar isso. Como o SHA-1 é um código de 160 bits, serão necessárias, em média, 2 ^ 159 tentativas de força bruta para encontrar uma duplicata. Se for encontrado um algoritmo que faça melhor do que aquele contra um hash criptográfico, o hash é considerado "quebrado".

O MD-5 é um exemplo de um hash muito quebrado. Era suposto ter uma força de 128 bits, exigindo em média 2 ^ 127 tentativas. Assim como, abusando de vulnerabilidades conhecidas, o número real de tentativas necessárias pode ser tão baixo quanto 2 ^ 47. Isso é muito menor que 2 ^ 127. Na verdade, isso foi feito em menos de um dia em um cluster de computação moderno.

Eu dou esse exemplo porque está mais próximo de como você está usando o SHA-1. No entanto, essa não é a abordagem mais comum usada na análise criptoanalítica para garantir que os hashes não sejam quebrados. Eles geralmente permitem uma colisão entre dois arquivos, escolhidos pelo invasor, em vez de você escolher um arquivo e o invasor tentar combiná-lo. Esse tipo de ataque tem a vantagem de ser mais fácil de avaliar. Se eu achar que é "difícil" decifrar seu arquivo, isso significa que outro arquivo é igualmente strong? Esse ataque em que o invasor escolhe os dois arquivos garante que capturemos o pior dos piores.

Esse tipo de ataque permite um truque interessante conhecido como " ataque de aniversário ." Para encurtar a história, usar o ataque de aniversário reduz à metade a força do algoritmo, portanto, o SHA-1 requer 2 ^ 80 tentativas (em média) e o MD5 requer 2 ^ 64 tentativas (em média). Estes são metade de 160 e 128, respectivamente.

O SHA-1 tem ataques conhecidos que diminuem sua força de 2 ^ 80 para 2 ^ 69. Isso não vai importar muito para você. 2 ^ 69 tentativas é um tempo longo .

No entanto, da história, descobrimos que os algoritmos de hash não são quebrados espontaneamente, mas sim quebrados com o tempo. Ninguém quebra um algoritmo como o MD-5 levando-o de 2 ^ 64 para 2 ^ 47 durante a noite. Isso acontece ao longo do tempo, já que muitos indivíduos publicam artigos sobre a matemática que estão usando contra ele. Geralmente, é possível observar a complexidade dos ataques diminuir lentamente desde o início do algoritmo (em que o melhor ataque geralmente é o ataque de aniversário).

O fato de que estamos vendo algumas mudanças nas colisões sugere que o SHA-1 está vendo a luz no fim do túnel. Ainda é strong, mas pode haver um desejo de ir até o mais novo SHA-3, que é atualmente muito mais seguro.

Você deve realmente tomar essas decisões de uma perspectiva de modelo de ameaça. Quanto dano pode ser causado por um invasor se ele sofrer uma dessas colisões. Seus atacantes são crianças de script com acesso a alguns laptops ou governos com clusters de supercomputação inteiros à sua disposição? O tamanho de uma janela de tempo que um atacante tem para quebrar o hash antes que ele não seja usado (muitos usos da criptografia envolvem uma "mudança de guarda", como rotação de senha). Tudo isso afetará a seriedade com que você deve considerar colisões.

    

Answer 3

As falhas no SHA-1 discutidas nesse artigo são muito específicas: elas permitem que os atacantes criem duas coisas com o mesmo valor (isso é chamado de "ataque de colisão"). No entanto, um ataque de colisão requer que o invasor controle ambos os arquivos envolvidos. Se o invasor não controlar o arquivo original, um ataque de colisão não permitirá que ele encontre outro arquivo com o mesmo valor de hash.

O motivo que isso importa para o TLS / SSL (e assinaturas em geral) é que, com esses, um invasor geralmente pode controlar os dois arquivos. Um certificado TLS é criado principalmente pela pessoa que o solicita (os bits que eles não controlam costumam ser previsíveis), portanto as colisões permitem que eles criem um certificado legítimo e um certificado ilegítimo, obtenham o certificado legítimo assinado e transfiram a assinatura.

Para arquivos, a mesma situação nem sempre se aplica. Se a sua preocupação é que a pessoa que está fazendo o arquivo é o atacante (por exemplo, ele verifica se algo foi verificado independentemente como bom e envia a carga maligna com o mesmo hash), o ataque SHA-1 se aplica e você deve procurar para a eliminação gradual (embora ainda não seja crítico, como David Schwartz mencionou). Se o arquivo original é confiável, então um invasor não pode aplicar os ataques SHA-1 atualmente conhecidos, embora você ainda deva pensar em eliminá-lo se puder (se tiver uma opção, use um hash sem ataques conhecidos como SHA- 2).

Em resposta a "a colisão não será útil" - embora um ataque não exija que um invasor consiga uma colisão útil , geralmente não é tão difícil transformar "colisão" em "colisão útil". Muitos formatos de arquivo têm uma quantidade razoável de espaço em que você pode ter o que quiser sem afetar a funcionalidade do arquivo; um atacante pode tipicamente modificá-lo para obter uma colisão (se as colisões forem praticamente localizáveis), mantendo a parte funcional como quer que ela seja. A diferença entre "ataque acadêmico" e "ataque prático" pode ser grande; o intervalo entre "qualquer colisão" e "colisão útil" é geralmente muito menor.

O problema mais sério, que não está relacionado à escolha do algoritmo, é como você está obtendo o hash. Tudo o que um hash faz é mudar o problema de "pegar o arquivo real" para "obter o valor real do hash"; um valor de hash enviado do mesmo servidor e sobre o mesmo tipo de conexão que o arquivo é completamente inútil contra modificações maliciosas (qualquer invasor que possa mexer no arquivo pode adulterar o hash). Os hashes são úteis apenas para isso, se você puder confiar mais no hash do que em confiar no arquivo; enquanto isso às vezes é o caso (torrents, espelhos), eles são freqüentemente usados quando não é o caso. Portanto, você deve ter muito cuidado com isso sempre que usar hashes para verificação de integridade.

    

Answer 4

Você precisa diferenciar entre um ataque de colisão e um ataque de pré-imagem . Encontrar quaisquer duas mensagens com o mesmo valor é um ataque de colisão.
Substituir uma mensagem específica dada (aqui: um executável) por outra mensagem que tenha o mesmo hash é um (segundo) ataque de pré-imagem.

O SHA-1 é quebrado na medida em que um ataque de colisão pode ser feito em 2 ⁵² operações de acordo com um artigo da Wikipedia que não fornece uma citação para esse número (o melhor ataque que eu conheço o que é realmente credível é o de Marc Stevens, que leva 2 ⁶⁰ operações). Mas vamos assumir o caso pessimista de 2 ⁵² .

Isso é preocupante porque um ataque nessa escala não só é teoricamente concebível, mas na verdade perfeitamente factível em menos de um dia em uma plataforma multi-GPU. É claro que isso é um problema para aplicativos em que as mensagens "any two" servem. Mesmo o número 2 ⁶⁰ dado por Stevens (que é 256 vezes mais trabalho) é perfeitamente viável se o seu atacante está disposto a jogar algum dinheiro extra no problema, ou está disposto a gastar um ano.
Qual é exatamente o tipo de coisa que não impede que alguém envolvido em espionagem ou crime cibernético forjem certificados.

Agora, um ataque de pré-imagem tem um expoente que é duas vezes maior, então assumindo 2 ⁵² para o ataque de colisão, isso seria 2 ¹⁰⁴ operações, o que é um estádio totalmente diferente.

Isso não é apenas impraticável (uma máquina que é um bilhão de vezes mais rápida que a mencionada no parágrafo anterior ainda levaria cerca de 6 milhões de anos), mas dado nosso meio insignificante de gerar energia isso é totalmente impossível. / p>

Fazer um cálculo tão massivo exigiria uma fonte de energia que é muito maior do que qualquer coisa que possamos dedicar a uma única operação. Não, não é bem uma fonte de energia do tamanho do sol, mas ainda é muito grande .

Você pode esperar obter de 10 a 50 GFLOPS de um Watt. Assumindo que algum tipo de milagre acontece e os processadores obtêm cerca de milhares de vezes mais energia eficiente durante a noite, pode-se assumir 1 SHA ≈ 1 FLOP (bastante otimista!). Isso significaria que, para realizar cálculos de hash de 2 ¹⁰⁴ dentro de 10 anos, você precisa de uma usina elétrica de 10 ¹² W. Para executar o ataque dentro de um ano, você precisa de uma usina elétrica de 10 ¹³ W. Isso é cerca de 50 vezes o que todas as usinas nucleares dos EUA, França e Japão podem produzir juntas, apenas para forjar um único hash.

Isto não vai acontecer , existem maneiras muito mais fáceis de atingir o mesmo objetivo (explorar o servidor que armazena o hash original e substituí-lo, chantageando alguém, etc.).

    

Answer 5

O ponto geral do artigo mencionado na pergunta é: SHA1 está obsoleto e deve ser descontinuado enquanto você ainda tem tempo para fazê-lo sem problemas. Em algumas áreas, o tempo está se esgotando desde que o Google e a Microsoft impõem prazos.

Regra geral da tecnologia obsoleta :

• Se você criar um novo design ou adicionar recursos, não o use (SHA1).
• Se você mantiver algo antigo, faça um plano quando substituí-lo (SHA1).

Resumo da citação do post de 2012 de Bruce Schneier:   "A questão é que nós, da comunidade, precisamos iniciar a migração para longe do SHA-1 e para o SHA -2 / SHA-3 agora. "

    

Answer 6

Para a parte de colisão de hash SHA-1 da sua pergunta, isso foi resolvido por algumas das respostas.

No entanto, uma grande parte disso depende do tipo de arquivo com o qual estamos trabalhando:

Maintains the file's overall content and operation (but of course now includes malicious content that was not originally there changed contents)

O que isso significa varia muito sobre o que está detectando as alterações:

• Se for um executável assinado, não uma chance (razoável): você precisaria obter duas colisões de hash de alguma forma: o SHA-1 do arquivo e a assinatura .exe interna.
• Se for um executável não assinado, .com, .dll não assinado ou semelhante, os garfos de recursos podem ser adicionados de forma a não alterar sua operação e, assim, você poderá (eventualmente) obter uma colisão de hash que não é detectável por operação 'normal'.
• Se for um arquivo de código-fonte ou uma estrutura semelhante (.cs, .c, .h, .cpp, .rb, .yml, .config, .xml, .pl, .bat, .ini), as adições, modificações ou remoções podem ser restritas a uma sintaxe válida de comentários, de modo que a alteração não seja perceptível pela maioria dos usos (compilando ou executando-a, não abrindo-a com um editor de texto).
• Se for um formato .iso ou .zip ou outro formato de contêiner, também é mais improvável, pois a maioria das alterações aleatórias corromperá o contêiner. É possível fazer: adicionar uma entrada de arquivo falsa ou alterar um conteúdo dentro do contêiner e verificá-lo novamente, mas você está adicionando uma camada de complexidade e adicionando mais tempo para verificar o resultado, além de ter graus limitados de liberdade com respeito como e quais conteúdos podem ser alterados.
• Se for um formato de texto ou de texto, eles podem ser alterados da maneira que você desejar, mesmo sendo um arquivo 'válido', embora o conteúdo provavelmente seja perceptível.
• Com muitos formatos como .rtf, .doc, .html, .xslx e outros formatos de marcação, eles podem ser adicionados ou modificados de maneiras que não serão detectadas por analisadores, portanto, além do tamanho (ou até mesmo com um comprimento restrito, menos liberdade) os arquivos podem ser alterados para (eventualmente) obter uma colisão de hash, continuando sendo não apenas um arquivo válido, mas não visivelmente alterado de alguma forma que seria visível para os aplicativos típicos com os quais eles seriam usados.

Então, o que resta é como obter colisões em qualquer estrutura que não seja corruptiva e algum grau de indetectável, talvez:

1. Faça as alterações funcionais desejadas (talvez a inserção de conteúdo malicioso) e faça alterações adicionais para manter a validade específica do formato de arquivo
2. Adicione uma seção que não funcionará (entre os blocos de comentário, no final de um arquivo de texto com retornos de carro 3k acima dele, isole um bloco de comentário atual)
3. Adicione ou selecione um caractere / ponto de código / byte para modificação e tente todas as combinações válidas possíveis (nem todas as combinações de bytes são válidas para diferentes codificações, por exemplo).
4. Recompute o hash, veja se a colisão corresponde.
5. se isso não acontecer, vá para 3.

Digamos que você tenha um computador super rápido e um arquivo pequeno, de modo que a modificação com uma sequência de bytes válida e o recálculo do hash leve 1 milissegundo (provavelmente exigindo algum hardware dedicado). Se a distribuição hash é perfeitamente aleatória e distribuída em todo o intervalo, você terá uma colisão com o SHA-1 a cada 2^160 tentativas (brute forçando-o).

2^160/1000/60/60/24/365.24 
= 4.63x10^37 years 
= 46,300,000,000,000,000,000,000,000,000,000,000,000 years 
= 46 undecillion years.

Mas, ei, vamos tentar as versões 2^60 e 2^52 , e fingir que elas nos permitem modificar o arquivo da maneira que quisermos (elas não) e que elas também podem ser feitas em 1ms cada tente:

2^52 yields 142,714 years 
/*humans might still be around to care, but not about these antiquated formats*/
2^60 yields 3.65x10^7 years = 36,500,000 years 
/*machines will probably have taken over anyway*/

Mas ei, você pode ter sorte. Realmente, realmente, mais um milagre do que qualquer coisa que as pessoas chamam milagres de sorte.

    

Answer 7

Não é verdade, você pode satisfazer uma dessas condições de cada vez, mas não ambas. É possível obter o mesmo hash para dois arquivos diferentes, mas para alguém alterar um arquivo e tentar obter o mesmo hash é bastante muito impossível, tanto quanto eu sei

    

Answer 8

Sim, é possível. Pense em como os vírus funcionam em EXEs. A carga de malware é anexada ao EXE original, de modo que o programa ainda faz o que originalmente fez, mas também se espalha como um vírus. Agora, para manter o mesmo hash, você precisaria de preenchimento específico adicional

.

Isso significa que o arquivo seria maior. Mas, no caso de um EXE, talvez você possa remover alguns dos códigos menos utilizados, para que o programa pareça funcionar inicialmente. No caso de um JPEG, você pode comprimir a imagem ou usar uma imagem diferente. Para um ISO, você pode remover conjuntos de arquivos. Os cálculos necessários para replicar o hash seriam mais difíceis, e talvez matematicamente impossíveis para casos específicos, mas ainda assim seriam possíveis em geral.