SHA1, ShellShock e Poodle, Ameaças da Web
Ao longo deste último trimestre surgiram muitas novidades sobre segurança digital. Em concreto, há três grandes ameaças que merecem atenção: a Google e a Mozilla Foundation querem que se deixe já de usar o SHA-1; o problema de segurança de 1989 chamado ShellShock e o cãozinho do SSL v3 (Poodle).
SHA-1
Comecemos por explicar o que é a Hash SHA-1. Quando se utilizam certificados digitais, por exemplo, para assinar um documento/ficheiro, é necessário criar um valor único que o identifique, para posteriormente aplicar uma assinatura digital. Esse mecanismo chama-se função de Hash. Já existiram várias anteriormente e, com o passar do tempo, foram deixando de ser consideradas seguras, como se verificou em 2008 com o MD5. Isto acontece com o aumento da capacidade computacional das máquinas e pelo trabalho de vários cérebros.
O ano de 2021 é considerado como o limite temporal onde será computacionalmente possível forçar dois ficheiros a ter a mesma Hash SHA-1. Por esta razão, e para dar algum tempo para nos prepararmos para umupgrade ao nível do algoritmo de Hash, a Microsoft publicou a política de obsolescência para 2017, que foi considerada aceitável pela comunidade. No entanto, a 5 de Setembro deste ano foi publicado pela Google um intervalo de tempo muito mais escasso, que se iniciou em Novembro. Com a versão 40 do Chrome, sites com certificados que expiram após Junho de 2016 e que utilizem algoritmo SHA-1, irão obter um aviso como o seguinte:
E, sites cujos certificados expirem após 2017 irão obter um aviso de falta de segurança:
É importante referir ainda duas situações:
- Houve uma tentativa de mudança por parte da Mozilla/Firefox para migrar os seus sistemas para SHA-2. No entanto, a Mozilla voltou atrás porque teve uma significativa redução nos acessos, ou seja, menos clientes;
- 93% dos sites com certificado na Internet usam SHA-1, isto porque 20% a 30% dos utilizadores da Internet ainda usam o Windows XP (SP1 e SP2), ou telemóveis Windows antigos, que não permitem aceder a sites com SHA-2.
ShellShock
Para falarmos sobre o ShellShock, primeiro há que explicar o que é uma Shell. Os sistemas operativos baseados em Unix são compostos por um conjunto de aplicações que foram sendo criadas ao longo dos tempos. No início, estes Sistemas Operativos tinham poucas funcionalidades e foram sendo criados como Legos, em que as peças encaixam umas nas outras. A informação é concatenada entre aplicações através de pipes “|”.
Foram criadas Shells com várias características e a mais usada é a “Bash”, que é a afetada por este problema. Quando a “Bash” foi criada, foram desenvolvidas funcionalidades que na altura faziam sentido, porque tinham um objetivo simples e limitado, visto que a Internet que existia era limitada (alguns servidores) e não como a de hoje, acessível nos nossos relógios de pulso ou até nas lâmpadas lá de casa. Estes Legos foram sendo usados, por serem simples e porque já eram usados desde “sempre”. No entanto, a possibilidade de passar variáveis de ambiente de 1989, passou a ser, nos dias de hoje, um problema de segurança, cuja descoberta desencadeou vários incidentes que levaram à criação de BotNets por todo o mundo.
É importante relembrar que, por exemplo, a maioria das Webcam IP utiliza versões da Bash na sua CGI-BIN (local dos binários da “Common Gateway Interface”), por serem baseados em sistemas operativos Unix. Isto poderá significar que a NSA funciona mais como “Big Brother” do que pensamos.
SSL v3
A terceira grande ameaça de que se tem falado recentemente é o SSL v3 (Poodle). Uma análise a este tema requer, primeiro, uma explicação do que são o SSL e o TLS.
SSL – Secure Socket Layer, criada pela Netscape, serve para estabelecer uma ligação segura entre sockets (abstracção para endereços de comunicação através dos quais os processos comunicam) do servidor e do cliente. Existem três versões: 1.0, 2.0 e 3.0, sendo que as primeiras duas são consideradas inseguras e apenas a 3.0 ainda é utilizada.
TLS – Transport Layer Security pode ser considerada a versão actualizada do SSL. A versão 1.0 foi apresentada em 1999 e, desde então, foi melhorada para a versão 1.1 e a 1.2. Esta última, por ser muito recente, ainda é pouco utilizada.
Como funciona a ligação de um cliente a um servidor?
Como existem várias versões destas camadas de segurança, os Browsers permitem ligar, por exemplo, a um servidor que conhece SSL V3, ou até ao TLS 1.2 a partir da versão 8 do Internet Explorer (entre outros browsers). Para que isto seja possível, é perguntado pelo Browser qual a lista de protocolos que aceita (Cypher Suite List) e, por regra, escolhe o mais seguro que é conhecido pelos dois.
Como o SSL v3 é o protocolo mais antigo em uso, é também considerado o mais inseguro, visto que a segurança está limitada no tempo. Foi recentemente apresentada, a 14 de Outubro, por funcionários (Bodo Möller) de segurança da Google, uma vulnerabilidade do protocolo SSLv3 chamada de Poodle (Padding Oracle On Downgraded Legacy Encryption).
Para explicar esta vulnerabilidade, primeiro é importante esclarecer o que é o ataque man-in-the-middle.
Este problema acontece quando, num sistema inseguro, um atacante intercepta os dados trocados entre duas partes, por exemplo uma pessoa e o seu banco. Essa comunicação é de alguma forma interceptada, registada e possivelmente alterada pelo atacante sem que a vítima se aperceba.
O Poodle attack, um problema de man-in-the-middle, permite que um atacante que explore esta vulnerabilidade consiga obter um byte da comunicação através da realização de 256 pedidos. Isto deve-se a um problema no protocolo que define que no final do processo da criação do pacote, primeiro se gera o MAC (Message Authentication Code) e só depois se cifra a mensagem.
Está definido que, por questões de segurança, a primeira análise de uma mensagem (pacote) deve ser ao MAC, para validar se houve alterações do género do man-in-the-middle. No entanto, neste caso, será necessário decifrar primeiro e só depois validar o MAC, o que permite exactamente uma “trinca” deste Poodle, paddding oracle attack. À medida que o atacante vai obtendo mais informação (vários ataques/vários bytes) pode conseguir, por exemplo, obter a totalidade de um cookie de sessão, que por sua vez irá permitir fazer-se passar pelo cliente.
Já existem pelo menos três soluções para este problema:
- A mais simples passa por desligar esta versão do sistema (SSL v3), quer no lado do cliente (Browser) quer no lado do servidor (sites, servidores de email, ftp, etc);
- A segunda será usar o SCSV – TLS Fallback Signaling Cipher Suite Value. Desta forma, ambas as partes estão sempre cientes do protocolo mais seguro que a outra conhece e, mesmo que na listagem não apareça, por exemplo o TLS 1.2, ambos sabem que há um problema de segurança, um inappropriate fallback. O problema com esta solução é que ambas as partes têm que dispor desta funcionalidade e o Internet Explorer, por exemplo, não dispõe.
- A terceira solução varia mediante o fornecedor da solução ter ou não alterado a aplicação de forma a evitar este Bug. No entanto, implica ter ido contra o que está escrito nas especificações definidas anteriormente porque, como indicado, é um problema do core e não da implementação.
Este problema no SSL v3 vem, muito provavelmente, colocar um ponto final na sua utilização. De resto, a Mozilla Foundation já desactivou esta funcionalidade na versão 34 do Firefox e a Google indicou que o iria fazer na versão 39, no entanto ainda está activo.
Existem algumas implementações de versões do TLS 1.0 que utilizam a função de padding do SSL v3, ou seja, incorrem no mesmo problema. As versões do TLS 1.1 e 1.2 são bastante rigorosas na forma como o padding é formatado (validação obrigatória), no entanto, há algumas implementações do 1.0 que simplesmente não verificam o resultado após a desencriptação, como por exemplo nos balanceadores da F5 ou em versões do módulo NSS da Mozilla anteriores a 2010.
Todos os creditos para Pedro Tarrinho.
Postado em: Pplware
- Metasploit Framework de cabo a rabo – Parte 6 - 4 de junho de 2018
- Metasploit Framework de cabo a rabo – Parte 5 - 28 de maio de 2018
- CEH – Scanning Networks – Parte 2 - 24 de maio de 2018
