Metade dos sites , e seu número está aumentando constantemente. O protocolo reduz o risco de interceptação de tráfego, mas não elimina tentativas de ataques propriamente ditas. Falaremos sobre alguns deles - POODLE, BEAST, DROWN e outros - e métodos de proteção em nosso material.
/flickr/ / CC BY-SA
POODLE
Pela primeira vez sobre o ataque ficou conhecido em 2014. Uma vulnerabilidade no protocolo SSL 3.0 foi descoberta pelo especialista em segurança da informação Bodo Möller e colegas do Google.
Sua essência é a seguinte: o hacker força o cliente a se conectar via SSL 3.0, emulando quebras de conexão. Em seguida, ele pesquisa no criptografado mensagens de tags especiais do modo de tráfego. Usando uma série de solicitações forjadas, um invasor consegue reconstruir o conteúdo dos dados de interesse, como cookies.
SSL 3.0 é um protocolo desatualizado. Mas a questão da sua segurança ainda é relevante. Os clientes o utilizam para evitar problemas de compatibilidade com servidores. Segundo alguns dados, quase 7% dos 100 mil sites mais populares . Também modificações no POODLE que visam o TLS 1.0 e o TLS 1.1 mais modernos. Este ano novos ataques Zombie POODLE e GOLDENDOODLE que ignoram a proteção TLS 1.2 (eles ainda estão associados à criptografia CBC).
Como se defender. No caso do POODLE original, você precisa desabilitar o suporte SSL 3.0. No entanto, neste caso existe o risco de problemas de compatibilidade. Uma solução alternativa poderia ser o mecanismo TLS_FALLBACK_SCSV - garante que a troca de dados via SSL 3.0 só será realizada com sistemas mais antigos. Os invasores não poderão mais iniciar downgrades de protocolo. Uma forma de proteção contra Zombie POODLE e GOLDENDOODLE é desabilitar o suporte CBC em aplicativos baseados em TLS 1.2. A solução fundamental será a transição para TLS 1.3 - a nova versão do protocolo não usa criptografia CBC. Em vez disso, são usados AES e ChaCha20 mais duráveis.
BEAST
Um dos primeiros ataques a SSL e TLS 1.0, descoberto em 2011. Como POODLE, BESTA recursos da criptografia CBC. Os invasores instalam um agente JavaScript ou miniaplicativo Java na máquina cliente, que substitui mensagens ao transmitir dados por TLS ou SSL. Como os invasores conhecem o conteúdo dos pacotes “fictícios”, eles podem usá-los para descriptografar o vetor de inicialização e ler outras mensagens para o servidor, como cookies de autenticação.
A partir de hoje, as vulnerabilidades BEAST permanecem : Servidores proxy e aplicativos para proteção de gateways locais da Internet.
Como se defender. O invasor precisa enviar solicitações regulares para descriptografar os dados. Em VMware reduza a duração de SSLSessionCacheTimeout de cinco minutos (recomendação padrão) para 30 segundos. Esta abordagem tornará mais difícil para os atacantes implementarem os seus planos, embora tenha algum impacto negativo no desempenho. Além disso, você precisa entender que a vulnerabilidade BEAST poderá em breve se tornar uma coisa do passado por si só - desde 2020, os maiores navegadores suporte para TLS 1.0 e 1.1. De qualquer forma, menos de 1,5% de todos os usuários de navegadores trabalham com esses protocolos.
AFOGAR
Este é um ataque entre protocolos que explora bugs na implementação de SSLv2 com chaves RSA de 40 bits. O invasor escuta centenas de conexões TLS do alvo e envia pacotes especiais para um servidor SSLv2 usando a mesma chave privada. Usando , um hacker pode descriptografar uma das cerca de mil sessões TLS do cliente.
DROWN ficou conhecido pela primeira vez em 2016 - então acabou sendo no mundo. Hoje não perdeu sua relevância. Dos 150 mil sites mais populares, 2% ainda são SSLv2 e mecanismos de criptografia vulneráveis.
Como se defender. É necessária a instalação de patches propostos pelos desenvolvedores de bibliotecas criptográficas que desabilitam o suporte SSLv2. Por exemplo, dois desses patches foram apresentados para OpenSSL (em 2016 1.0.1s e 1.0.2g). Além disso, atualizações e instruções para desabilitar o protocolo vulnerável foram publicadas em , , .
“Um recurso pode ser vulnerável ao DROWN se suas chaves forem usadas por um servidor de terceiros com SSLv2, como um servidor de e-mail”, observa o chefe do departamento de desenvolvimento Sergei Belkin. — Esta situação ocorre se vários servidores utilizam um certificado SSL comum. Neste caso, você precisa desabilitar o suporte SSLv2 em todas as máquinas."
Você pode verificar se o seu sistema precisa ser atualizado usando um especial — foi desenvolvido por especialistas em segurança da informação que descobriram o DROWN. Você pode ler mais sobre recomendações relacionadas à proteção contra esse tipo de ataque em .
heartbleed
Uma das maiores vulnerabilidades em software é . Foi descoberto em 2014 na biblioteca OpenSSL. No momento do anúncio do bug, o número de sites vulneráveis - isto representa aproximadamente 17% dos recursos protegidos na rede.
O ataque é implementado através do pequeno módulo de extensão Heartbeat TLS. O protocolo TLS exige que os dados sejam transmitidos continuamente. Em caso de inatividade prolongada, ocorre uma interrupção e a conexão deve ser restabelecida. Para lidar com o problema, servidores e clientes “ruído” artificialmente no canal (), transmitindo um pacote de comprimento aleatório. Se fosse maior que o pacote inteiro, as versões vulneráveis do OpenSSL leriam a memória além do buffer alocado. Esta área pode conter quaisquer dados, incluindo chaves de criptografia privadas e informações sobre outras conexões.
A vulnerabilidade estava presente em todas as versões da biblioteca entre 1.0.1 e 1.0.1f inclusive, bem como em vários sistemas operacionais - Ubuntu até 12.04.4, CentOS anterior a 6.5, OpenBSD 5.3 e outros. Existe uma lista completa . Embora os patches contra esta vulnerabilidade tenham sido lançados quase imediatamente após a sua descoberta, o problema permanece relevante até hoje. De volta em 2017 , suscetível a Heartbleed.
Como se defender. Necessário até a versão 1.0.1g ou superior. Você também pode desabilitar solicitações de Heartbeat manualmente usando a opção DOPENSSL_NO_HEARTBEATS. Após a atualização, especialistas em segurança da informação reemitir certificados SSL. Uma substituição é necessária caso os dados nas chaves de criptografia acabem nas mãos de hackers.
Substituição de certificado
Um nó gerenciado com um certificado SSL legítimo é instalado entre o usuário e o servidor, interceptando ativamente o tráfego. Este nó se faz passar por um servidor legítimo apresentando um certificado válido, e torna-se possível realizar um ataque MITM.
Conforme Por equipes da Mozilla, do Google e de diversas universidades, aproximadamente 11% das conexões seguras na rede são espionadas. Este é o resultado da instalação de certificados raiz suspeitos nos computadores dos usuários.
Como se defender. Use os serviços de confiança . Você pode verificar a “qualidade” dos certificados usando o serviço (TC). Os provedores de nuvem também podem ajudar na detecção de espionagem; algumas grandes empresas já oferecem ferramentas especializadas para monitorar conexões TLS.
Outro método de proteção será um novo ACME, que automatiza o recebimento de certificados SSL. Ao mesmo tempo, adicionará mecanismos adicionais para verificar o proprietário do site. Mais sobre isso .
/flickr/ / CC POR
Perspectivas para HTTPS
Apesar de uma série de vulnerabilidades, os gigantes de TI e os especialistas em segurança da informação estão confiantes no futuro do protocolo. Para implementação ativa de HTTPS Criador da WWW, Tim Berners-Lee. Segundo ele, com o tempo o TLS se tornará mais seguro, o que melhorará significativamente a segurança das conexões. Berners-Lee até sugeriu que certificados de cliente para autenticação de identidade. Eles ajudarão a melhorar a proteção do servidor contra invasores.
Também está previsto o desenvolvimento da tecnologia SSL/TLS usando aprendizado de máquina – algoritmos inteligentes serão responsáveis por filtrar o tráfego malicioso. Com conexões HTTPS, os administradores não têm como descobrir o conteúdo das mensagens criptografadas, inclusive detectando solicitações de malware. Já hoje, as redes neurais são capazes de filtrar pacotes potencialmente perigosos com 90% de precisão. ().
Descobertas
A maioria dos ataques ao HTTPS não está relacionada a problemas com o protocolo em si, mas ao suporte a mecanismos de criptografia desatualizados. A indústria de TI está começando a abandonar gradativamente os protocolos da geração anterior e a oferecer novas ferramentas para busca de vulnerabilidades. No futuro, estas ferramentas tornar-se-ão cada vez mais inteligentes.
Links adicionais sobre o tema:
Fonte: habr.com