A CISA, em parceria com a MITRE, lançou a lista com as 25 vulnerabilidades de software mais perigosas de 2025 ("Top 25 Most Dangerous Software Weaknesses"), segundo a CWE. Esta lista identifica as vulnerabilidades mais críticas de software, que os adversários exploram para comprometer sistemas, roubar dados ou interromper serviços.
Essa lista é atualizada anualmente e é baseada na Common Weakness Enumeration (CWE), um padrão de nomenclatura para vulnerabilidades de software, bem extensa e completa. Ela também indica quantas vulnerabilidades conhecidas (CVEs) foram exploradas por atacantes, e estão listadas no catálogo "Known Exploited Vulnerabilities" (KEV) - um indicador importante, que mostra que essa vulnerabilidade foi explorada por atacantes.
Segue a lista:
CWE-79 - Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CVEs no KEV: 7 - Posição no ano passado: 1
CWE-89 - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') CVEs in KEV: 4 - Posição no ano passado: 3
CWE-352 - Cross-Site Request Forgery (CSRF) CVEs in KEV: 0 - Posição no ano passado: 4
CWE-862 - Missing Authorization CVEs in KEV: 0 - Posição no ano passado: 9
CWE-787 - Out-of-bounds Write CVEs in KEV: 12 - Posição no ano passado: 2
CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') CVEs in KEV: 10 - Posição no ano passado: 5
CWE-416 - Use After Free CVEs in KEV: 14 - Posição no ano passado: 8
CWE-125 - Out-of-bounds Read CVEs in KEV: 3 - Posição no ano passado: 6
CWE-78 - Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') CVEs in KEV: 20 - Posição no ano passado: 7
CWE-94 - Improper Control of Generation of Code ('Code Injection') CVEs in KEV: 7 - Posição no ano passado: 11
CWE-120 - Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') CVEs in KEV: 0 - Posição no ano passado: N/A
CWE-434 - Unrestricted Upload of File with Dangerous Type CVEs in KEV: 4 - Posição no ano passado: 10
CWE-476 - NULL Pointer Dereference CVEs in KEV: 0 - Posição no ano passado: 21
CWE-121 - Stack-based Buffer Overflow CVEs in KEV: 4 - Posição no ano passado: N/A
CWE-502 - Deserialization of Untrusted Data CVEs in KEV: 11 - Posição no ano passado: 16
CWE-122 - Heap-based Buffer Overflow CVEs in KEV: 6 - Posição no ano passado: N/A
CWE-863 - Incorrect Authorization CVEs in KEV: 4 - Posição no ano passado: 18
CWE-20 - Improper Input Validation CVEs in KEV: 2 - Posição no ano passado: 12
CWE-284 - Improper Access Control CVEs in KEV: 1 - Posição no ano passado: N/A
CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor CVEs in KEV: 1 - Posição no ano passado: 17
CWE-306 - Missing Authentication for Critical Function CVEs in KEV: 11 - Posição no ano passado: 25
CWE-918 - Server-Side Request Forgery (SSRF) CVEs in KEV: 0 - Posição no ano passado: 19
CWE-77 - Improper Neutralization of Special Elements used in a Command ('Command Injection') CVEs in KEV: 2 - Posição no ano passado: 13
CWE-639 - Authorization Bypass Through User-Controlled Key CVEs in KEV: 0 - Posição no ano passado: 30
CWE-770 - Allocation of Resources Without Limits or Throttling CVEs in KEV: 0 - Posição no ano passado: 26
Esta lista é muito útil para educar os times de desenvolvimento sobre os principais erros a serem evitados.
Pesquisadores de segurança do Threat Research Unit (TRU) da Qualys identificaram uma vulnerabilidade grave de execução remota de código não autenticado (RCE) no servidor OpenSSH (sshd) em sistemas Linux baseados em glibc. A vulnerabilidade foi batizada de regreSSHion e recebeu o CVE-2024-6387 (com score CVSS v3 8.1 - Alta).
Essa execução remota de código (RCE) não autenticado representa um grande risco de segurança, pelo seu impacto e pelo fato do SSH ser um serviço de acesso remoto seguro extremamente popular. A vulnerabilidade afeta o sshd em sua configuração padrão e não exige a interação do usuário para funcionar, o que aumenta o risco dela, permitindo acesso completo como root no equipamento vulnerável.
Esta vulnerabilidade está presente nas versões OpenSSH anteriores a 4.4p1 (se não receberam os patchs da CVE-2006-5051 e CVE-2008-4109) e as versões de 8.5p1 até, mas não incluindo, a 9.8p1, reintroduzindo um problema que foi corrigido anteriormente na CVE-2006-5051.
Segundo a Qualys, este bug marca a primeira vulnerabilidade do OpenSSH em quase duas décadas – mas tinha que ser justamente um RCE não autenticado que concede acesso root total ao equipamento?
Inclusive, o nome regreSSHion foi escolhido pelos pesquisadores da Qualys considerarem que essa vulnerabilidade é uma "regressão"- ou seja, uma atualização na ferramenta acabou trazendo de volta uma vulnerabilidade corrigida anteriormente (a tal da CVE-2006-5051). Segundo eles, esta "regressão" foi introduzida em outubro de 2020 no release do OpenSSH 8.5p1.
Segundo estimativas da Qualys, dados do Censys e do Shodan indicam que aproximadamente 14 milhões de servidores OpenSSH potencialmente vulneráveis estão expostos na Internet.
Eu fiz uma busca bem besta no Shodan e foi possível identificar 23,491,837 servidores OpenSSH expostos na Internet, dos quais 284.683 no Brasil (no caso, considerando qualquer versão do OpenSSH.
Felizmente, uma grande maioria parte desses equipamentos estão com uma versão antiga, desatualizada, mas que não possui a vulnerabilidade regreSSHion. Cerca de mais de 2/3 deles. Por exemplo, entre as "top 10" versões expostas na Internet, as duas mais presentes são de servidores desatualizados, em versões anteriores a 8.5p1 (totalizando, por si só, 7.723.494 de hosts que não são vulneráveis). Ou seja, entre as "top 10" versões de OpenSSH expostos na Internet, metade dessas versões representam equipamentos com o OpenSSH desatualizado há cerca de 4 anos, mas que representam cerca de 10 milhões entre os 15 milhões de servidores no "top 10". Estão desatualizados, mas pelo menos não estão vulneráveis ao regreSSHion. (rindo de nervoso).
Veja uma tabela que eu fiz considerando um recorte no Shodan, com as versões de servidores OpenSSH com mais de 50 mil hosts naquela versão. Cerca de 14 milhões não são vulneráveis e 6 milhões são.
Veja o infográfico que o pessoal da Qualys preparou:
Após a divulgação da vulnerabilidade regreSSHion, uma prova de conceito (PoC) já foi disponibilizada no GitHub, o que facilita muito a vida de possíveis atacantes que desejem explorar essa vulnerabilidade. Ela está disponível no repositório https://github.com/zgzhang/cve-2024-6387-poc.
Algumas recomendações para mitigar a regreSSHion:
Aplique imediatamente os patches disponíveis para o OpenSSH;
Revise os controles de acesso para limitar o acesso remoto SSH a seus equipamentos, se necessário ajustando as regras de Firewall existentes;
Mantenha uma segmentação de rede para evitar acesso não autorizado e movimentação lateral;
Acompanhe seus sistemas de detecção de intrusões para monitorar e alertar sobre atividades incomuns em acessos remotos via SSH.
A Qualys também destaca que este incidente mostra o papel crucial dos testes de regressão que devem ser realizados no processo de desenvolvimento de software, para justamente evitar a reintrodução de vulnerabilidades conhecidas no ambiente. #ficaadica
Cuidado (adicionado em 05/07): Segundo a Kaspersky, está sendo compartilhado um malware como se fosse um suposto exploit para o regreSSHion.
Recentemente, ao participar em um painel no Fórum da Internet no Brasil organizado pelo Comitê Gestor da Internet no Brasil (CGI.br), o Carlos Cabral usou uma forma muito legal para explicar o que é uma vulnerabilidade em tecnologia - isso porque ele pretendia discutir o mercado de vulnerabilidades. De forma bem didática, o Cabral associou uma exploração de vulnerabilidade a um cenário bem simples e familiar no nosso dia-a-dia: quando você vai fazer uma refeição em um restaurante de Fast Food e pede algo fora do cardápio.
Desta forma, o Cabral criou uma analogia, que ele batizou de “alegoria do balcão do McDonalds”, e compartilhou conosco:
"Imagina que a pessoa que está ali no bancão do McDonnalds, ela tem que lidar com um conjunto específico e finito de requisições, com as quais ela pode interagir, que é o cardápio. Conjunto finito e específico de requisições. E se ela receber uma requisição que não tenha nada a ver como o contexto do trabalho dela, sabe, do nada chega alguém, aparece no balcão e fala "me dá um beijo na boca", a maravilha do cérebro humano é que a gente entende o contexto. De modo que essa pessoa, ao ouvir essa requisição, ela pode falar "Olha, se liga! Eu estou trabalhando aqui no McDonalds! Olha o cardápio e pede o que está aqui". Ou ela pode falar "Me encontra daqui a 20 minutos. Eu saio, me encontra lá fora e posso te dar esse beijo na boca". Com computadores, a coisa é diferente. De modo que, se você manda uma requisição que o computador não está esperando, ele faz as coisas muito mais malucas que podem acontecer. Ele pode entregar acesso root, ou seja, acesso com privilégio administrativo na máquina. E, usando a mesma analogia, seria o mesmo que você pedir um beijo na boca para o cara do McDonalds, ele abrir a caixa registradora e te dá todo o dinheiro que tem dentro dela. Isso é uma vulnerabilidade."
OBS: eu transcrevi a fala dele literalmente, sem alterar o conteúdo.
Recentemente a HackerOne lançou uma versão nova do seu relatório anual sobre o mercado de Bug Bounty. O 4th Hacker-Powered Security Report traz várias estatísticas interessantes que traçam o perfil do mercado global e dos pesquisadores de segurança que participam dos programas de Bug Bounty organizados pela HackerOne.
Vejam alguns dados sobre o mercado de Bug Bounty em 2019, baseado nos resultados da HackerOne:
Mais de 830 mil pesquisadores cadastrados na plataforma da HackerOne.
34% no crescimento de programas na plataforma da HackerOne;
87% de crescimento no pagamento de bounties desde o ano anterior;
9 pesquisadores (de 7 países diferentes) passaram a marca de US$ 1 milhão em prêmios recebidos;
Mais de 181 mil vulnerabilidades submetidas na plataforma da HackerOne, com cerca de 1/3 delas reportadas em 2019 - das quais 37 mil foram marcadas como resolvidas;
Mais de 107 Milhões de dólares pagos em premiações, sendo 44,75 milhões pagos em 2019;
81% dos programas são privados, embora os programas públicos tenham, em média, 5x mais pesquisadores reportando vulnerabilidades.
O relatório traz também alguns dados sobre o mercado na América Latina:
Somos 1,5% dos programas de BB da HackerOne e 2% dos novos programas iniciados em 2019;
29% de crescimento da quantidade de programas. Infelizmente, esse é o menor crescimento entre todas as regiões, mostrando que o mercado local ainda não está maduro e atraindo empresas ainda para os programas de Bug Bounty;
371% de crescimento no pagamento de premiações, enquanto outras regiões cresceram em média 68%. O Brasil cresceu 1.843%, o Panamá 1.394% e Argentina 723%;
60% de crescimento no recebimento de premiações.
A HackerOne viu um impacto positivo no mercado durante a pandemia do novo Coronavírus, comparando os números do programa com os dados do mês anterior ao início dos regimes de quarentena:
59% de crescimento na adesão de novos pesquisadores ao programa da HackerOne;
28% de crescimento no número de vulnerabilidades reportadas por mês.
Atualização em 09/11: A HackerOne publicou um infográfico que resume várias informações compartilhadas durante o evento Security 2020, realizado recentemente.
Os programas de "Bug Bounty" estão ficando cada vez mais popular entre os pesquisadores e, aos poucos, quebrando a resistência das empresas!
O "Bug Bounty" (numa tradução literal, poderíamos chamar de "recompensa por bugs") é um dos canais existentes para que empresas recebam notificações sobre bugs e vulnerabilidades em suas soluções. Eles são uma evolução das políticas de "Vulnerability Disclosure", na qual as empresas aceitam que outras pessoas as notifique em caso de bugs, através de um canal de comunicação oficial. Nos programas de Bug Bounty, as empresas se comprometem a reconhecer a contribuição de quem fez o reporte, muitas vezes através de um tipo de recompensa como o pagamento de prêmios pré-estabelecidos.
Há alguns meses atrás o pessoal da Eleven Paths publicou um artigo bem interessante no blog deles explicando o que são e como surgiram os programas de Bug Bounty.
Tudo começou nos anos 90, quando a Netscape começou a oferecer bonificações financeiras para as pessoas que descobrissem bugs em seu navegador. Nas décadas seguintes, o mercado de segurança viu o amadurecimento das políticas de "Responsible Disclosure", ou "Notificação Responsável", aonde discutiu-se que as vulnerabilidades não deveriam ser tornadas públicas antes do fabricante do software ter a oportunidade de providenciar uma correção, para evitar a exploração maliciosa de uma determinada vulnerabilidade. Em 2002 surgiu a iDefense, uma empresa americana que recebia notificações sobre vulnerabilidades em troca de dinheiro, repassava essas informações para o fabricante e, ao mesmo tempo, orientava seus clientes sobre como evitar essas vulnerabilidades enquanto não eram corrigidas. Depois dela surgiram outras empresas, como a Coseinc e a ZDI (Zero Day Iniciativa), que foi comprada pela HP e depois pela Trend Micro.
Os programas de Bug Bounty representam um canal oficial aonde qualquer pessoa, incluindo um cliente ou um pesquisador independente de segurança, pode notificar a empresa sobre problemas de segurança em seus sites e aplicações.
Muito comum em empresas de tecnologia e nos EUA, o programa de "Bug Bounty" ajuda as empresas a identificar rapidamente vulnerabilidades que sejam descobertas por terceiros, e oferecem para a comunidade um meio de comunicar tais vulnerabilidade sem o risco de sofrer represálias.
"Bug bounty programs have been proved effective in attracting external hackers to find and disclose potential flaws in a responsible way". MIT
Segundo um paper do MIT, "A política de divulgação responsável de vulnerabilidades ("Responsible vulnerability disclosure policy") foi criada como uma maneira eficaz de melhorar a segurança em geral. Considerando a eficácia do uso de especialistas externos para a descoberta responsável de vulnerabilidades, programas de recompensas de bugs ("bug bounties") foram lançados por muitas empresas, incluindo Google, Facebook, Microsoft e Mozilla, para encorajar os hackers externos a compartilhar as vulnerabilidades descobertas antes da divulgação pública."
Do ponto de vista do pesquisador independente e da comunidade de segurança, os programas de bug bounty trazem várias vantagens:
Um canal seguro para reportar vulnerabilidades em softwares, sem correr o risco de ser ameaçado ou ignorado pela empresa;
Uma forma de ajudar a sociedade de forma ética, auxiliando as empresas a corrigir bugs em suas aplicações e reduzindo o impacto nocivo desses bugs em seus clientes;
Um meio de ganhar uma recompensa financeira, como se fosse um trabalho "free lance";
Uma forma de testar seu conhecimento e aprender mais.
O melhor de tudo é que o Bug Bounty permite que pesquisadores tenham um canal oficial para reportar os problemas. Quando isso não existe, é muito comum que os reportes sejam ignorados ou, pior ainda, que os pesquisadores sejam mal tratados pelas empresas. Sentindo-se ameaçadas ao ver uma denuncia de que seu software, site ou app tem bugs, algumas empresas acabam tentando silenciar os pesquisadores através de ameaças e processo legal. Essa dificuldade em reportar um bug de forma estruturada faz com que muitos pesquisadores acabem não reportando o bug para a empresa ou fabricante, e apenas compartilhem a descoberta entre seu círculo de amizade.
""Antigamente, as empresas não eram tão próximas com hackers que descobriam suas falhas, não havia essas revelações com o hoje, como Bug Bounty. E isso hoje é ótimo". Joe Grand (Kingpin), no RoadsecSP 2018
Para as empresas, as vantagens também são várias:
Um canal de relacionamento com a comunidade de segurança, para receber denúncias;
Permitir que bugs sejam descobertos e corrigidos antes que possam ser explorados para fins maliciosos, evitando prejuízos para a empresa. Um ciber criminoso não vai pensar 2 vezes antes de testar seu site e explorar uma vulnerabilidade;
Uma forma de complementar sua estratégia de segurança, usando o Bug Bounty como um meio adicional para identificar bugs, além dos testes tradicionais, auditoria de código e penteastes.
Para estabelecer um programas de bug bounty, as empresas devem estabelecer uma política de análise de vulnerabilidades que contemple esse canal de report, processos para tratamento rápido e correção desses bugs e os recursos necessários para operar o programa, desde funcionários até mesmo ferramentas para ter um portal de report.
Além do que já disse acima, os benefícios para a empresa também incluem:
Minimizar o risco de divulgação de uma vulnerabilidade (pois o pesquisador é incentivado a notificar a empresa sobre o bug);
Demonstra a maturidade da empresa e de sua área de segurança;
Estabelece e promove uma cooperação mais positiva entre a empresa e o público externo (clientes, pesquisadores, etc);
Maior diversidade de testes, pois a empresa abre a possibilidade de dezenas de pessoas testarem a sua segurança, cada uma com um ponto de vista ou especialização diferente. Alguns podem ser especialistas em testes específicos, como SQL injection ou cross-site script, ou especializados em linguagens e frameworks distintos;
Melhor uso dos recursos financeiros, pois no Bug Bounty a empresa só remunera quando um bug é identificado. Quando a empresa decide por contratar uma consultoria, ela paga um preço fixo independente da quantidade de bugs que foram encontrados, ou não.
Um grupo de pesquisadores de Berkeley publicou um estudo em 2013 aonde apontaram as principais vantagens de um programa de report de vulnerabilidades:
Offering adequate incentives entices security re- searchers to look for vulnerabilities, and this increased attention improves the likelihood of finding latent vulner- abilities. Second, coordinating with security researchers allows vendors to more effectively manage vulnerability disclosures, reducing the likelihood of unexpected and costly zero-day disclosures. Monetary rewards provide an incentive for security researchers not to sell their research results to malicious actors in the underground economy or the gray world of vulnerability markets. Third, VRPs may make it more difficult for black hats to find vulnera- bilities to exploit. Patching vulnerabilities found through a VRP increases the difficulty and therefore cost for malicious actors to find zero-days because the pool of latent vulnerabilities has been diminished. Additionally, experience gained from VRPs (and exploit bounties) can yield improvements to mitigation techniques and help identify other related vulnerabilities and sources of bugs. Finally, VRPs often engender goodwill amongst the community of security researchers.
it is in the interests of the software vendor to encourage more people to participate in the search for bugs.
An increase in the number of researchers looking for vulnerabilities yields an increase in the diversity of vulnerabilities discovered.
Uma das conclusões que eles chegaram foi de que um programa de Bug Bounty tem o custo equivalente a contratar um analista de pentest, mas os resultados são muito maiores (em termos de quantidade e qualidade) do que este mesmo analista conseguiria produzir em um mesmo período.
Ma minha apresentação abaixo eu explico como o programa de Bug Bounty se encaixa na estratégia de análise e correção de vulnerabilidades no ciclo de desenvolvimento seguro de software:
A Hackerone tem um vídeo curto, mas bem legal, sobre os programas de Bug Bounty:
Aqui no Brasil, o pessoal da Flipside está aproveitando o expertise deles com o campeonato de CTF HackaFlag, para transformar essa experiência na primeira plataforma nacional de Bug Bounty.
Embora sejam muito populares nos EUA, aos poucos o mercado Brasileiro vai se interessar pelos programas de Bug Bounty. eu conheço alguns bancos nacionais que estão planejando adotar um programa desses, o que deve dar uma boa incentivada no mercado e ajudar a quebrar a resistência das empresas.
Notícia "UK gets first millionaire ethical hacker" - fala sobre os 5 pesquisadores da HackerOne que já atingiram a marca de US$ 1 milhão recebidos em recompensas, além de citar estatísticas recentes das vulnerabilidades reportadas através da HackerOne (adicionada em 11/09/19)
O site da HackerOne tem algumas páginas explicando como enviar um relatório de vulnerabilidades. Vale a pena dar uma olhada. (adicionado em 26/06)
O ano começou com uma bomba na área de segurança: uma vulnerabilidade grave no kernel dos processadores Intel, AMD e ARM, que tornaram praticamente todo mundo vulneráveis a ataques!
O conjunto de 3 falhas, batizadas de Meltdown (CVE-2017-5754) e Spectre (CVE-2017-5753 e CVE-2017-5715), permitem o acesso a áreas protegidas da memória, de forma que um programa malicioso possa acessar áreas de memória do kernel ou de outros processos. Ambos ataques aproveitam uma técnica para otimização de desempenho chamada de "execução especulativa", presente nos processadores modernos. O Meltdown consegue quebrar o isolamento entre as áreas de memória do Sistema Operacional e de outros programas, enquanto o Spectre ataca o isolamento entre diferentes programas.
Como dizem os sites oficiais:
"Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system."
Fonte: https://meltdownattack.com
"Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre."
Fonte: https://spectreattack.com
Resumindo, tanto o Meltdown quanto o Spectre permitem aos usuários comuns (de baixo privilégio) ler informações da memória do mesmo sistema explorando o recurso de Execução Especulativa. A diferença é que o Meltdown explora um problema específico de escalada de privilégios nos processadores da Intel, enquanto o Spectre usa a combinação de Execução Especulativa e Branch Prediction.
Com isso, programas maliciosos conseguiriam acessar áreas de memória de outros programas rodando no mesmo computador, e assim, ler e manipular esses dados. É possível, por exemplo, capturar uma senha que o usuário digita em outra aplicação.
Como a imprensa tem destacado, essa vulnerabilidade afeta todos os chips produzidos pela Intel nos últimos 10 anos, e espera-se que as correções existentes podem causar prejuízo na performance dos chips de até 30%.
Agora imagine o desespero de um gestor de TI que tem que aumentar o tamanho do seu datacenter em 1/3 do dia para a noite!!!
A falha foi descoberta pelo pessoal do Google Project Zero além de outros 3 grupos de pesquisadores (que trabalharam separadamente e, por coincidência, descobriram essas vulnerabilidades em um intervalo de tempo de poucos meses entre um e outro), e foi notificada aos fabricantes pela primeira vez no dia 01 de junho de 2017. Logo após a divulgação do bug, no dia 03/01, vários pesquisadores de segurança correram para criar exploits e formas de testar essas vulnerabilidades. No exemplo abaixo, criaram um programa em JavaScript com 5 linhas de código:
Embora seja, um problema na arquitetura dos processadores modernos (isto é, no hardware), o Meltdown e o Specter podem ser evitados com patches de software. Os fabricantes de sistemas operacionais (Windows, iOS, Linux, etc) trabalharam para preparar patches que pudessem mitigar essa vulnerabilidade, mas tiveram que antecipar o lançamento desses patches devido ao que parece ter sido uma divulgação imprevista do problema. Entretanto, como as vulnerabilidades estão no hardware, as únicas correções reais envolveriam trocar a CPU por uma nova, com uma arquitetura sem essas falhas. Mas como isso ainda não é possível, estamos dependendo de ajustes feitos nos SOs para evitar que essas falhas sejam exploradas.
A correção consiste em separar completamente a memória do kernel dos processos dos usuários, como no caso do recurso batizado de "Kernel Page Table Isolation" (KPTI) incorporado no Linux. O time de desenvolvedores, ao criar essa funcionalidade, pensaram em batizá-la de forma bem criativa como "Forcefully Unmap Complete Kernel With Interrupt Trampolines", ou seja, "FUCKWIT".
Algumas explicações sobre o bug e "execução expeculativa"
O Meltdown trouxe a tona uma feature das CPUs modernas que, apatentemente, ninguém estava familiarizado: a "execução especulativa". Em poucas palavras de leigo, para ganhar um pouco mais de performance e conseguir executar mais insctuções, os processadores modernos aproveitam os ciclos de processamento que a CPU deveria estar livre para adiantar a execução das próximas instruções, quando o processamento está parado esperando algum dado ou resposta. Assim, se ele "adivinhar" qual foi a resposta certa, ele ficou na vantagem porque processou algumas instruções durante um tempo que ceveria estra parado. Se errou, então basta descartar o que foi processado, e a vida segue.
OBS: Post atualizado em 05/01 as 10:20 (para incluir a informação sobre o OpenBSD). Atualizado novamente nos dias 07/01, 08/01 e 09/01. Atualizado em 10/01 e 11/01. Nova atualização em 17/01, 19/01, 23/01 e 24/01. Atualizado em 30/01. Atualizado em 15/02 e 20/02. Atualizado em 04/04/18 e 23/05/18.
Recentemente vimos notícias catastróficas de alguns ataques relacionados a protocolos ou produtos de criptografia, que foram anunciados pela mídia com uma elevada dose de sensacionalismo:
O ataque KRACK ("Key Reinstallation Attack"), que explora uma fragilidade no handshake do protocolo WPA2 (Wi-Fi Protected Access II). Pelo que podemos deduzir das notícias sobre o ataque, ele promete tornar todas as redes wireless do mundo inseguras e todo o tráfego em redes wireless poderia ser capturado;
A vulnerabilidade ROCA (Return of Coppersmith’s Attack) (CVE-2017-15361), uma falha na geração de chaves de criptografia RSA em Smart Cards, chips, tokens e Trusted Platform Modules (TPM) da empresa alemã Infineon Technologies. Tratada como devastadora, promete acabar com qualquer chave criptográfica RSA do mundo;
O ataque DUHK (Don't Use Hard-coded Keys), que é uma vulnerabilidade que afeta equipamentos usando o gerador de números aleatórios (Random Number Generator, RNG) ANSI X9.31 junto com sementes de chave gravadas no código (hard-coded). Isso faz parecer que qualquer VPN do mundo pode ser explorada, mas na verdade a falha afeta apenas 12 produtos, e o mais famoso deles é da Fortinet, o FortiOS 4.3.0 a 4.3.18 (que são versões antigas, anteriores a 2011).
Corram paras as montanhas!?
As falhas acima são preocupantes, mas em termos práticos, eu diria que o KRACK é assustador por afetar qualquer rede wireless, mas tem correção fácilmente aplicável, o ROCA parece ser direcionado a dispositivos mais específicos mas é mais difícil de ser atualizado por usuários finais (pois pode inplicar em atualizar firmwares), e o DUHK é um ataque bem restrito a poucos dispositivos.
Nota: de acordo com o artigo original dos pesquisadores da vulberabilidade DUHK, ela afeta apenas 12 produtos no total:
BeCrypt Cryptographic Library 2.0
Cisco Aironet 7.2.115.2
DeltaCrypt FIPS Module
Fortinet FortiOS v4 4.3.0 to 4.3.18
MRV Communications LX-4000T/LX-8020S v5.3.8
Neoscale Systems \CryptoStor 2.6
Neopost Technologies Postal Security Devices v28.0
Pesquisadores de segurança identificaram algumas vulnerabilidades nas lâmpadas inteligentes da Osram, mais um exemplo de como as novas tecnologias de Internet das Coisas (IoT) estão sendo criadas sem os devidos cuidados de segurança.
Segundo o relatório da Rapid7, foram identificadas 9 vulnerabilidades nas lâmpadas Osram LIGHTIFY domésticas e profissionais, que podem causar o acesso indevido a informações de configuração do dispositivo e da rede doméstica e execução de comandos na lâmpada:
Cleartext WPA2 PSK (CVE-2016-5051) - o aplicativo da lâmpada inteligente armazena a senha da rede wi-fi doméstica em texto aberto;
Lack of SSL Pinning (CVE-2016-5052 e CVE-2016-5057) - uma vulnerabilidade na validação do certificado SSL que permite reconhecer certificados falsos e, assim, facilitar ataques Man in the Middle;
Pre-Authentication Command Execution (CVE-2016-5053) - a lâmpada permite acesso de administrador, não autenticado, através da porta 4000/TCP;
ZigBee Network Command Replay (CVE-2016-5054 e CVE-2016-5058) - a lâmpada permite que um atacante intercepte comandos e os reenvie, aceitando os comandos reenviados como se fossem originais;
Web Management Console Persistent XSS (CVE-2016-5055) - OMG! A interface administrativa é vulnerável a ataques de Cross-site scripting (XSS);
Weak Default WPA2 PSKs (CVE-2016-5056) - É possível quebrar a chave do WPA2, pois eles utilizam uma senha de tamanho curto e facilmente adivinhável;
Cached Screenshot Information Leak (CVE-2016-5059) - o app para iPad armazena screenshots das telas administrativas, e assim, pode exppor telas de configuração com informações sensíveis, como senhas.
A Wired publicou a história (e vídeo) de dois pesquisadores de segurança, Runa Sandvik e Michael Auger, que conseguiram hackear uma mira eletrônica e, assim, alterar a trajetória da bala disparada pelo rifle.
O dispositivo, Tracking Point TP750 (que custa 13 mil dólares), deveria ser utilizado para aumentar a precisão do tiro, de forma que até mesmo um atirador amador pudesse acertar o alvo através da mira eletrônica. Ela reconhece o alvo emuda de cor quando ele estiver na mira. Os pesquisadores conseguiram acessar o dispositivo através de sua conexão Wi-Fi e, explorando algumas vulnerabilidades do software embarcado na mira, eles conseguiram alterar algumas das variáveis utilizadas para o cálculo da trajetória - como, por exemplo, o peso da bala. Eles também conseguem evitar que a arma dispare ou, até mesmo, desabilitar o computador da mira eletrônica.
Tudo isso começou porque o sistema de pontaria eletrônica usa um sistema Linux embarcado que tem uma conexão Wi-Fi (desabilitada originalmente) que tem uma senha default. Eles também conseguiram privilégios de administrador no sistema e, assim, conseguem "fazer a festa".
Este caso serve para nos alertar dos riscos de automatizar e conectar diversos dispositivos do dia-a-dia, uma tendência muito forte atualmente e que é representada, principalmente, pela chamada "Internet das Coisas" (IoT). Assim como nos softwares tradicionais, é comum encontrarmos aplicações embarcadas em diversos dispositivos aonde os desenvolvedores não tomaram os cuidados básicos de segurança. Com estes dispositivos eletrônicos podendo ser acessados remotamente através de conexões em fio, temos o grande risco de alguém explorar uma vulnerabilidade do software e tomar controle do dispositivo - isso vale também para carros e aviões.
Nota (adicinada dia 30/07): Esta reportagem veio em uma boa hora, no momento em que vários cientistas estão se mobilizando contra a criação de robôs autônomos para uso militar. Ela mostra que não devemos apenas nos preocupar com o problema dos robôs atuarem sem limites éticos (ou seja, como em filmes de ficção científica como O Exterminador do Futuro ou Matrix), mas também com a possibilidade de outras pessoas tomarem o controle dos robôs.
No final desta 3a feira sairam algumas notícias sobre um novo bug do SSL batizado de FREAK, que força usuários ou servidores a utilizar cifras de criptografia inseguras, possibilitando a exposição de sua comunicação.
O ataque afeta usuários de Android e Apple (iPhone e Macs) e servidores SSL/TLS que aceitam o esquema de criptografia RSA_EXPORT (que utiliza chave RSA de apenas 512 bits e é associado a algoritmos simétricos com chave de 40 bits). Os servidores podem ser vulneráveis se forem mal configurados (isto é, se aceitarem por padrão este conjunto de chaves fracas) ou se forem vulneráveis ao bug CVE-2015-0204 do OpenSSL.
Como já virou modinha na área de segurança, todo bug sério e problemático ganha um nome chamativo, um logo e um site. Nesse caso, não poderia ser muito diferente, e pelo menos o site já existe: o site https://freakattack.com permite testar se o seu browser está vulnerável, tem várias informações sobre o bug e, ainda, lista quais dos 10 mil sites mais visitados da Internet são vulneráveis ao ataque. A lista inclui sites como businessinsider.com, americanexpress.com, groupon.com, bloomberg.com, 4shared.com, instructables.com e o mit.edu.
O pior é que alguns appliances e sistemas embarcados também podem ser vulneráveis, por utilizarem o OpenSSL :( Para testar o seu browser, utilize o site https://freakattack.com; para testar se o seu site (ou da sua empresa) está vulnerável, utilize o excelente SSL Test da Qualys.
O protocolo SSL/TLS permite que o cliente (browser) e o servidor web negociem o conjunto de algoritmos criptográficos que vão utilizar para cifrar a comunicação. Dentre os diversos conjuntos de cifras existentes (como o TLS_RSA_WITH_AES_256_CBC_SHA ou o TLS_RSA_WITH_IDEA_CBC_SHA), algumas das cifras possíveis são antigas e consideradas fracas, como por exemplo as cifras que utilizam os algoritmos RC4 para criptografia e o MD5 para assinatura digital, que são considerados fracos hoje em dia (como por exemplo o caso do TLS_RSA_WITH_RC4_128_MD5), ou pior ainda o conjunto de cifras TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (pois o DES de 40 bits é um algoritmo de criptografia simétrica antigo e absurdamente fraco).
O problema da "família" RSA-EXPORT (como no caso do conjunto de cifras TLS_RSA_EXPORT_WITH_RC4_40_MD5) é que ela utiliza uma chave RSA de 512 bits, que também é considerada fraca para os dias de hoje. Esses conjuntos de algoritmos datam do final da década de 1990, quando os EUA limitavam os algoritmos criptográficos que podiam ser exportados para fora dos EUA e o tamanho das suas chaves. Naquela época, qualquer site de empresa não-americana era obrigado a usar esses conjuntos de cifras mais fracas. Hoje em dia, estes algoritmos e tamanhos de chave não deveriam ser mais utilizados, pois comunicações criptografadas com eles podem ser facilmente decifradas.
Nota (atualizado em 04/03): O site CryptographyEngineering.com tem um texto detalhado sobre o FREAK attack e a Akamai publicou um pequeno artigo em seu blog que também explica o problema, principalmente do lado dos servidores.
