sslscan

Detalhando as suites de cifras SSL/TLS

Diego Piffaretti1 comentário

Olá galera, resolvi trazer um post bem completo que pode ajudar bastante a galera que se confundi com o emaranhado de sopa de letrinhas das cifras SSL/TLS e também ter um material bem completo sobre o tema.

INTRODUÇÃO

Primeiramente eu ínicio esse post dizendo que vejo muita gente, até mesmo profissionais de segurança, que confundem protocolo SSL com certificado SSL. São coisas destintas! Umas coisa é o certificado SSL, que é o famoso HTTPS que o site utiliza. Esse certificado naturalmente possui uma chave de assinatura (normalmente sha256) e uma chave publica (normalmente RSA 2048).

Aqui o foco é assunto é protocolo, que é como sua aplicação se comunica com o servidor.

TEORIA

Existem basicamente 2 tipos de protocolos utilizados, um é o SSL e o outro é o TLS.

SSL está depreciado, seja ele em qualquer versão (a ultima versão é a SSL 3). Inclusive ele aparece a algum tempo em ferramentas de scan, como o Nessus, como vulnerabilidade alta.

O protocolo SSL/TLS utilizam um pacote de criptografia. Este pacote é um conjunto de algoritmos de criptografia, cada um com uma função específica, e que juntos permitem comunicações criptografadas entre um cliente e um servidor. E como essa comunicação ocorre?

  1. O servidor tem um conjunto de criptografia configurados que ele aceita.
  2. O cliente envia ao servidor as versões de TLS / SSL, conjuntos de criptografia e métodos de compactação que ele suporta, em ordem de preferência (também conhecido como ClientHello ).
  3. O servidor escolhe entre eles o pacote mais favorável para começar a criptografar os dados (também conhecido como ServerHello ).
  4. O servidor envia seu certificado.
  5. Com a verificação do certificado (e, portanto, da identidade do servidor), uma chave secreta denominada Master Secret é negociada , levando em consideração o conjunto de cifras escolhido.
  6. O cliente envia uma mensagem criptografada ao servidor.
  7. O servidor verifica se o MAC (Message Authentication Code , usado para autenticação) está correto e se a mensagem pode ser descriptografada corretamente. 
  8. O servidor responde à mensagem, que também é verificada pelo cliente.

FERRAMENTA

Bom, já aprendemos de forma sucinta como é feito a comunicação entre cliente/servidor. E como eu verifico que cifras um servidor está aceitando negociar?

Uma das ferramentas que eu mais gosto é o SSLCAN, que vem por padrão no Kali Linux. Se for um site externo e você não for um profissional com tanto conhecimento ou acesso a um kali ou linux qualquer, pode utilizar uma ferramenta totalmente online, chamada SSL LABS.

ENTENDENDO RESULTADO DO SSLSCAN (PACOTE DE CRIPTOGRAFIA)

Ao executar o sslscan (Ex: sslscan target -p 443) o resultado visto é algo parecido com isso:

Vamos entender agora o que é cada pedaço da suite de cifras:

  • Protocolo . Indica o tipo de protocolo a utilizar, como já comentei pode ser o SSL (já obsoleto) ou TLS, com as respectivas versões.
  • Algoritmo de troca de chave (Key Exchange) . Algoritmo a ser usado para compartilhar as chaves simétricas com as quais as comunicações serão criptografadas.
  • Assinatura digital . Verifica as identidades do cliente e do servidor durante a sessão. Neste ponto, deve ser mencionado que o algoritmo RSA pode funcionar como um algoritmo de troca de chave e uma assinatura digital.
  • Algoritmo de criptografia e o comprimento da chave . Algoritmos simétricos usados ​​para criptografar a comunicação (com o comprimento correspondente de cada algoritmo).
  • Modo de criptografia . Estas são cifras de bloco. Seu uso depende do algoritmo de criptografia usado anteriormente.
  • Hash . Algoritmo de criptografia irreversível que verifica a integridade das mensagens.
  • Tamanho da curva elíptica . Esta opção não é obrigatória e depende do algoritmo de troca de chaves previamente escolhido. No exemplo acima eu coloquei 3 pontinhos pois essa cifra que escolhi de exemplo não tinha.

Agora segue uma tabela com os tipos possíveis para cada bloco desse que expliquei, pintei em amarelo o que está depreciado:

EXPLORAÇÕES – RISCO NA PRÁTICA

Abaixo vou elencar falhas divulgas que podem reforçar os problemas de se utilizar qualquer elemento desses que estão depreciados:

BEAST (Exploração do navegador contra SSL / TLS) – CVE-2011-3389

  • Descrição:
    • Permite que ataques MiTM obtenham informações de uma sessão usando SSL / TLS1.0.
    • Esta vulnerabilidade é muito complexa de explorar, pois requer força bruta para obter informações úteis.
    • É causado pelos vetores de inicialização TLS1.0 nas cifras CBC e RC4.
  • Recomendação: desative SSLv3, TLS1.0 e TLS1.1 no servidor.

CRIME (vazamento de informações de taxa de compressão facilitado) – CVE-2012-4929

  • Descrição:
    • É baseado no sequestro de sessões nos protocolos HTTPS e SPDY através do roubo de cookies de sessão, explorando a compressão HTTP com força bruta. Esta exploração é possível porque SSL / TLS e SPDY usam um algoritmo de compressão denominado DEFLATE, que elimina strings duplicadas durante a conexão entre o cliente e o servidor.
    • Apesar disso, a compactação TLS está atualmente desativada nos navegadores Chrome, Mozilla, Opera Safari e Internet Explorer, portanto, desativá-la no servidor ajudaria a proteger os usuários que usam navegadores desatualizados.
  • Recomendação: desative a compactação em TLS e HTTP no servidor.

BREACH (reconhecimento de navegador e exfiltração via compressão adaptativa de hipertexto) – CVE-2013-3587

  • Descrição:
    • É uma variante do ataque CRIME, que difere deste porque o BREACH se concentra no ataque a respostas HTTP, que usam compactação no nível HTTP (em vez de no nível TLS, como é o caso do CRIME). , que por sua vez é mais comum.
  • Link de referência de vulnerabilidade: http://breachattack.com/
  • Recomendação: desative a compactação em TLS e HTTP no servidor.

FREAK (Factoring RSA Export Keys) – CVE-2015-0204

  • Descrição:
    • É especialmente focado em servidores que aceitam RSA_EXPORT em seus conjuntos de criptografia.
    • Consiste em interceptar as comunicações HTTPS entre o cliente e o servidor e forçar o servidor a usar criptografia obsoleta ou vulnerável (ou seja, fazer downgrade) para quebrar as chaves.

Heartbleed – CVE-2014-0160

  • Descrição:
    • Permite que um atacante leia a memória de um cliente ou servidor, podendo obter as chaves privadas de um servidor SSL e comprometendo a integridade do servidor e dos usuários que se conectam a ele, além de sua confidencialidade.

Bar Mitzvah – CVE-2015-2808

  • Descrição:
    • Ele explora a geração pseudo-aleatória de chaves que o algoritmo RC4 usa e, com ela, consegue obter os primeiros 100 bytes de uma conexão TLS / SSL. 
  • Recomendação: Desative o uso do RC4.

LOGJAM – CVE-2015-4000

  • Descrição:
    • Possui uma lógica semelhante à vulnerabilidade FREAK já que ambos buscam downgrade do servidor, mas com a diferença que neste caso viola aqueles servidores que suportam DHE_EXPORT (devido a uma falha no protocolo TLS) obrigando-os a utilizar um grau menor de exportação. em conexões de 512 bits, que podem ser descriptografadas com relativa facilidade. 
  • Link de referência de vulnerabilidade: https://weakdh.org/
  • Recomendação: desative DHE_EXPORT e implemente Diffie-Hellman 2048 bits.


Lucky13 – CVE-2013-0169

  • Descrição:
    • Este ataque é mais teórico devido às condições que devem ser estabelecidas na configuração do servidor e ao grande número de requisições que devem ser feitas, explorando o uso de CBC (Cipher-Block-Chainning) e o cálculo de MAC.
  • Recomendação: Desative o uso de CBC.

POODLE – CVE-2014-3566

  • Descrição:
    • Parte disso, quando uma tentativa de conexão segura falha, ele tenta fazer a conexão novamente, mas com um protocolo de comunicação mais antigo. Dessa forma, um invasor pode causar intencionalmente erros de conexão em protocolos seguros como TLS 1.2, TLS1.1 e TLS1.0 e, assim, forçar o uso de SSL 3.0 para explorar a vulnerabilidade.
  • Recomendação: desative SSLv3, TLS1.0 e TLS1.1 no servidor.

SWEET32 – CVE-2016-2183

  • Descrição:
    • Isso tornaria mais fácil para um invasor remoto obter informações confidenciais devido a uma falha de criptografia DES / 3DES.
    • Um invasor pode realizar ataques MiTM capturando grandes quantidades de tráfego criptografado entre o servidor SSL / TLS e o cliente e recuperando os dados em texto não criptografado. 
  • Link de referência de vulnerabilidade: https://sweet32.info/
  • Recomendação: desative SSLv3, TLS1.0 e TLS1.1 no servidor.

RACCOON – CVE-2020-1968

  • Descrição:
    • Ele faz uso da troca de chaves Diffie-Hellman durante o handshake em TLS1.2 (e versões anteriores), para que ele descriptografe a conexão entre um cliente e o servidor.
    • A vulnerabilidade é encontrada na chave Premaster Secret usada na geração das chaves de criptografia na comunicação, que é usada como uma variável de entrada no KDF (Key Derivation Function). O KDF é baseado em hashes com diferentes perfis de tempo, de forma que essas medidas de tempo podem ajudar um invasor a gerar novas chaves secretas pré-mestre, encaminhando essa chave para o servidor para personificar um cliente em uma nova conexão.
    • Esse ataque é complexo de explorar, pois um grande número de solicitações deve ser feito para construir uma nova chave e, por sua vez, depende da configuração do comportamento de temporização do servidor .
  • Link de referência de vulnerabilidade: https://raccoon-attack.com/
  • Recomendação: Desative o uso de Diffie-Hellman para troca de chave (troca de chave DH) em TLS1.2 e versões anteriores.

Bom, acredito que aqui tenha um material bem completo. Gostaria de citar aqui o pessoal do Flu Project que me inspirou a construir este material, baseado em um post deles, 90% do mérito é deles 🙂