Não é coincidência que o Halloween caia em outubro. Nós, humanos, temos uma percepção de medo maior nesta época do ano; é algum tipo de resposta vestigial ao encurtamento dos dias. Em que mês houve as quedas de mercado mais inexplicáveis em Wall Street? Outubro. Se o Halloween não tivesse sido originalmente em outubro, teríamos mudado para um lugar onde parecesse mais natural. Outubro também é o mês de conscientização sobre segurança cibernética.
Então, é duplamente perfeito que esta semana não tenhamos uma vulnerabilidade de protocolo horrível do tipo "Meu Deus, a Internet está quebrada!", mas duas vulnerabilidades do tipo "Meu Deus, a Internet está quebrada!". Lançado no mesmo dia, nada menos que segunda-feira, 16 de outubro.
O que é ainda pior é que as vulnerabilidades podem se acumular de uma forma horrível, como você verá.
O pesquisador de segurança belga Mathy Vanhoef publicou um ataque contra clientes WiFi usando o protocolo de autenticação WPA2. O cliente alvo pode ser enganado para se conectar a uma rede WiFi duplicada e então coagido a instalar uma chave de criptografia nula (em branco), permitindo que o invasor assuma uma posição de intermediário.
Vanhoef explica o ataque KRACK sucintamente no site de vulnerabilidades com logotipo e marca krackattacks.com . Recomendamos fortemente que você assista ao pequeno vídeo que Vanhoef fez demonstrando o ataque.
Depois que o invasor alcança a posição de intermediário entre o cliente e o ponto de acesso, ele pode usar a boa e velha ferramenta sslstrip para enganar o navegador do cliente e fazê-lo enviar senhas em texto simples. O exemplo usa credenciais do match.com (por diversão), então Vanhoef acabou de lhe dar tudo o que você precisa para espionar os hábitos de namoro do seu ex. Bem a tempo para o Halloween! [Estamos brincando, não faça isso.]
O leitor astuto pensará: “Ei, redes inseguras são o motivo pelo qual temos proteção SSL! Então ainda estamos seguros, certo?”
Bem, a outra vulnerabilidade assustadora lançada, coincidentemente, no mesmo dia do KRACK, tem a ver com chaves fracas geradas por dispositivos criptográficos altamente seguros. Uau!
A mais recente vulnerabilidade SSL/TLS é o ROCA – o Retorno do Ataque Coppersmith. O Ars Technica tem o melhor artigo que vimos até hoje sobre o escopo e o impacto do ROCA. O ROCA afeta a geração de chaves RSA públicas/privadas feita em condições de tempo limitado, nas quais o software Infineon tenta usar um atalho chamado “prime rápido” para aproximar dois primos grandes.
O ROCA afeta o software associado aos chipsets Infineon que são frequentemente usados em cartões inteligentes e ambientes incorporados de alta segurança (computação confiável). Como estamos em outubro, é claro que esses chipsets são encontrados em hardware com certificação FIPS 140-2 e CC EAL 5+, ambas soluções pelas quais você paga dezenas de milhares de dólares para manter suas chaves privadas, bem, privadas. O bug da Infineon faz com que a chave privada seja praticamente fatorável quando um invasor conhece a chave pública (o que quase sempre acontece porque ela é pública e está incorporada em certificados, etc.).
Custaria de US$ 20.000 a US$ 40.000 em tempo de CPU para um invasor fatorar sua chave privada de 2.048 bits. No entanto, se o atacante for um estado-nação, isso não será um grande impedimento para ele. O custo para fatorar uma chave de 1024 bits é de apenas US$ 50 — o custo de duas cervejas em um jogo dos Yankees. De acordo com a pesquisa do próprio F5 Labs, apenas 7% da Internet ainda usa chaves tão pequenas. Ataques como o ROCA são exatamente o motivo pelo qual todos nós atualizamos para 2048 bits, certo? Bom para nós. Chaves ECC não são vulneráveis.
Até agora, a grande maioria das chaves vulneráveis está associada a cartões inteligentes, mas os pesquisadores encontraram algumas chaves TLS e Github vulneráveis. Ainda não há informações sobre chaves DNSSEC vulneráveis de 1024 bits; isso seria terrível, pois os invasores poderiam assinar seus próprios dados de zona maliciosa.
Curiosamente, é basicamente gratuito e instantâneo verificar se uma chave é vulnerável ao ROCA. Se os módulos da chave pública estiverem em conformidade com 38 pequenos primos de uma certa maneira, então eles provavelmente são vulneráveis. Os pesquisadores do ROCA forneceram ferramentas online e offline para você verificar suas chaves SSL/TLS, IPSec e SSH.
Dada a facilidade de verificação da vulnerabilidade, prevemos que os navegadores em breve o alertarão se você estiver visitando um site usando uma chave vulnerável ao ROCA. Você ouviu isso de nós primeiro.
É como escrever um roteiro de filme de Halloween. Imagine que você está em um ambiente de alta segurança (escritório de gerenciamento de espionagem). Seus inimigos são os piores inimigos do mundo; pense em S.P.E.C.T.R.E. ou algo parecido.
Um de seus agentes conecta seu laptop Windows 10 à rede sem fio em seu escritório em Istambul. Ele mal sabe que um agente da S.P.E.C.T.R.E. está falsificando o Wi-Fi e enviando sinais de canal CSA para seu laptop. Em segundos, o laptop do seu agente está sendo roteado através do ponto de acesso dos contra-agentes. Seu agente ativa seu SSL/VPN (infelizmente não o do F5) para acessar alguns dados corporativos ultrassecretos na sede.
O contra-agente já usou suas capacidades de estado-nação para fatorar a chave privada do SSL/VPN da vulnerabilidade ROCA. Ele pode descriptografar tudo o que seu agente estiver baixando do servidor ultrassecreto. Além disso, o agente de balcão obtém a senha do match.com do seu agente!
Você acha que esse pior cenário não poderia acontecer? Coisas mais estranhas já aconteceram. [tosse, <stuxnet>, tosse, <azul eterno>].
Hardware e software da F5 Networks: Não vulnerável. A F5 não está no ramo sem fio. Embora seja teoricamente possível usar nossa plataforma TMOS como um ponto de acesso, felizmente ninguém faz isso. Para KRACK, veja a declaração oficial do KRACK da F5 Networks SIRT.
A F5 Networks está definitivamente no ramo de chaves SSL/TLS. Aqui, novamente, o equipamento e o software F5 não são vulneráveis. Usamos os chipsets Infineon em alguns aparelhos, mas não usamos sua geração principal. Veja a declaração oficial do ROCA da F5 Networks SIRT.
Seu equipamento (KRACK): Vulnerável, mas… KRACK ataca o lado do cliente de uma conexão WiFi. Então, em certo sentido, não importa se seus pontos de acesso estão corrigidos ou não. Vamos concordar que você deve corrigir seus pontos de acesso de qualquer maneira (boa prática de segurança), mas isso não protegerá seus usuários do KRACK. Não há necessidade de alterar suas senhas de WiFi WPA2; elas nunca fizeram parte do problema e alterá-las não afetará nada.
Seu equipamento (ROCA): O ideal é que você conheça todos os certificados SSL/TLS associados à sua empresa. Dizemos “idealmente” porque raramente é esse o caso; as unidades de negócios estão trazendo seus próprios certificados o tempo todo agora. Se você tem uma solução de gerenciamento de certificados robusta e abrangente, provavelmente já sabe tudo sobre isso. Caso contrário, o parceiro da F5 , Venafi, pode escanear sua rede em busca de chaves SSL/TLS. Se você precisar escanear certificados rapidamente, acesse o banco de dados do projeto Certificate Transparency ( crt.sh ) e procure os certificados da sua organização. Em seguida, use as ferramentas de teste do ROCA para verificar se essas chaves públicas são vulneráveis.
Seus funcionários. A Apple corrigiu o iOS e o MacOS em um patch furtivo algumas versões atrás (eles ainda não disseram qual). Clientes Android e Linux parecem ser os mais vulneráveis. Os clientes da Microsoft também são vulneráveis. Sua maior prioridade para a KRACK deve ser seus funcionários.
Para clientes F5, há duas soluções de segurança relevantes contra KRACK e ROCA. O primeiro é por meio do BIG-IP Local Traffic Manager (LTM) da F5, o módulo principal que faz a descriptografia SSL/TLS e o balanceamento de carga. As chaves LTM normalmente não são vulneráveis ao ROCA (a menos que tenham sido geradas em outro lugar e importadas para o LTM; veja abaixo as informações do teste).
O LTM pode impor o HTTP Strict Transport Security (HSTS), que instruirá todos os navegadores a sempre usar SSL/TLS ao se conectar aos seus aplicativos. É uma caixa de seleção. Confira. O HSTS sozinho atenuará os piores aspectos do KRACK.
A segunda defesa, mais em camadas, é o BIG-IP Access Policy Manager (APM) e seu produto de ponto final associado, o BIG-IP Edge Client. Juntos, eles criam uma VPN SSL/TLS segura que tem proteção de endpoint e um mecanismo de política sofisticado para garantir que seus funcionários estejam se conectando aos recursos corporativos com segurança. Ele suporta todas as plataformas populares: Android, Windows, iOS e MacOS. O APM também tem federação, então você obtém SSO gratuitamente.
Usuários em certos ambientes de alta segurança podem ter os produtos F5 WebSafe e MobileSafe. O WebSafe protege as transações na frente de um servidor. O último é uma API de kit de ferramentas móveis para criar aplicativos mais seguros que se conectam ao primeiro. A proteção mais relevante que esses dois podem fornecer é a Criptografia da Camada de Aplicação (ALE). O ALE usa chaves RSA temporárias para criptografar assimetricamente senhas de usuários antes que elas sejam enviadas pela rede. O MobileSafe também fornece um recurso de proteção contra falsificação de DNS que deve ajudar a impedir o ataque Man-in-the-Middle fornecido pelo KRACK.
Além de escolher sua fantasia de Halloween (sugestão: o Kraken pode ser a escolha certa este ano), você tem alguns itens para adicionar à sua lista de tarefas para KRACK e ROCA.
Nosso site de inteligência de ameaças, F5 Labs , e nossa comunidade de desenvolvedores, DevCentral , continuam analisando esses tópicos e disponibilizarão materiais adicionais conforme aplicável. Caso você tenha mais dúvidas sobre as duas vulnerabilidades ou qualquer uma das soluções que mencionamos acima, não hesite em entrar em contato com um representante da F5 .
Em uma nota relacionada, a equipe DevCentral da F5 postou um vídeo explicando melhor a vulnerabilidade KRACK, e comentários adicionais estão disponíveis na seguinte postagem do F5 Labs: Nova ameaça pode passar despercebida nas políticas BYOD