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?
- O servidor tem um conjunto de criptografia configurados que ele aceita.
- 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 ).
- O servidor escolhe entre eles o pacote mais favorável para começar a criptografar os dados (também conhecido como ServerHello ).
- O servidor envia seu certificado.
- 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.
- O cliente envia uma mensagem criptografada ao servidor.
- O servidor verifica se o MAC (Message Authentication Code , usado para autenticação) está correto e se a mensagem pode ser descriptografada corretamente.
- 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.
- Link de referência de vulnerabilidade: https://censys.io/blog/freak
- Recomendação: desative RSA_EXPORT e versões inferiores a TLS1.2
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.
- Link de referência de vulnerabilidade: http://heartbleed.com/
- Recomendação: Desative SSL no servidor.
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 🙂
Mundo Tecnológico 