Muitos Servidores Ainda Estão Vulneráveis ao Heartbleed
Na opinião do executivo Felipe Peñaranda, líder de segurança da informação da IBM para a América Latina, o problema pode ser permanente. Ele afirmou que cerca de metade dos servidores potencialmente vulneráveis, ainda está sem correções específicas para o Heartbleed, o que o torna uma ameaça crítica permanente. Mesmo com o alto número de ataques, a IBM registrou mais de 3.000 vulnerabilidades durante o primeiro semestre. Segundo as projeções da empresa, é possível pensar que, se mantiver este ritmo até o final do ano, o ano de 2014 terá menos de oito mil vulnerabilidades identificadas, número este que não é alcançado desde o ano de 2011.
Implementação de Estratégias Contra Ataques
Outra ação importante para o combate ao Heartbleed, foi a compreensão das estratégias de detecção e defesa contra ataques. As técnicas de bloqueio provocaram um adiamento curto e temporário da atividade de ataque, o que favoreceu o surgimento de um tempo valioso para que os sistemas críticos possam passar pelas devidas correções. Além do mais, os firewalls também tiveram papel importante neste cenário. De acordo com o "Estudo Trimestral IBM X-Force de Inteligência contra Ameaças" referente ao primeiro semestre de 2014, os dispositivos são cruciais como "arma" de defesa, quando um pequeno subconjunto de hosts gera os ataques.
Common Vulnerability Scoring System (CVSS)
Vale observar que o relatório revela que 67% das falhas foram consideradas de nível médio pela equipe, enquanto 24% delas caracterizou situações críticas ou graves, seguindo o padrão internacional 2 do Common Vulnerability Scoring System (CVSS). As vulnerabilidades nos Sistemas de Gerenciamento de Conteúdo (CMS, em inglês), continuam como as mais frequentes.
Afinal, o que Realmente é o Heartbleed?
O bug do OpenSSL não apareceu recentemente. Ele não é algo proveniente de uma atualização recente. De acordo com informação oficial da desenvolvedora do software, essa falha já existe há mais de dois anos, mas ninguém sabia que ela estava lá. Nem mesmo os próprios desenvolvedores sabiam disso, afinal, se alguém soubesse, já teriam tomado as devidas providências e aplicado a correção.
O responsável pela descoberta desse erro de programação foi Neel Mehta, pesquisador do Google. Ele verificou que a falha poderia garantir, plenamente, que houvesse acesso a dados privados. Dessa forma, os cybercriminosos que saibam como explorar a falha podem interceptar o tráfego de dados, fingindo ser o servidor e dificultando que qualquer um saiba que existe algum problema no meio do caminho. Além do mais, o cybercriminoso que conseguir tirar proveito do bug pode puxar até 64 k de informações da memória do servidor.
Vale ressaltar que o cybercriminoso, de forma habitual, não tem como saber o que virá nesses dados, mas que em algumas situações, é possível coletar alguns dados privados. Também é importante ressaltar, que é possível repetir esse processo inúmeras vezes.
Facilidade para Exploração do Bug
Falando de uma forma bem franca, é preciso ter muito conhecimento para conseguir explorar esse tipo de vulnerabilidade. Mesmo os crackers mais habilidosos, certamente, levariam um bom tempo para conseguir entrar no servidor e roubar alguma informação importante. Até algum tempo atrás, algumas empresas, como é o caso da Cloudflare, estavam dizendo que era tão difícil que dava para dizer que era impossível, de modo que a falha não representava uma ameaça real.
Neste cenário, não demorou nem 24 horas para que alguns crackers conseguissem adquirir chaves SSL em servidores. Em algumas máquinas que executavam o Apache, houve a possibilidade de conseguir os dados já na primeira requisição. Este fato apenas deixa claro que a falha é fácil de ser explorada, e pode ser utilizada em quase todos os servidores que ainda não aplicaram os patches necessários.
Conforme informações da Bloomberg, a NSA já sabia da existência dessa falha e vem explorando isso já faz muito tempo. A Agência, logicamente, negou qualquer envolvimento e conhecimento sobre essa questão. Diante de tantos problemas passados, as declarações da NSA passaram a ter caráter duvidoso.
Sites Desprotegidos
Em abril, a maioria dos grandes sites que tinham algum problema já haviam corrigido as falhas. Quando houve o estopim do confronto e o caso tornou-se público, quase todos eles continham a falha no OpenSSL. Sendo assim, é possível incluir na lista grandes nomes como Twitter, Google (e seus respectivos sites), Facebook (e quaisquer sites desenvolvidos pela empresa), Yahoo!, Amazon, Dropbox, SoundCloud, Flickr, Foursquare e outros tantos. Mas é lógico, assim que a correção foi liberada, todos os sites corrigiram o defeito de imediato, evitando que seus usuários fossem prejudicados.
A interrogação que fica é se algum cybercriminoso já não havia descoberto a falha e explorado dados privados anteriormente. Além disso, é muito válido ressaltar que há muitos sites menores que ainda não corrigiram o problema, sendo que as pessoas que o frequentam ainda podem estar correndo perigo. Normalmente, as empresas e servidores que efetuaram a atualização do OpenSSL estão enviando e-mails comunicando seus usuários, mas você mesmo pode verificar se aquele site que só você acessa já está dentro de todos os parâmetros da segurança.
Melhores Formas de Proteção
Sem levar em consideração qual site ou serviço você utiliza, é fortemente recomendado que você modifique suas senhas para evitar que os criminosos online usem suas credenciais. Afinal de contas, não há como saber se alguém conseguiu se apropriar de seus dados, portanto, é bom tomar alguma atitude e evitar que elas sejam usadas indevidamente. Vale ressaltar ainda que a falha do Heartbleed também pode ter afetado os aparelhos que executam o sistema Android. Toda essa história de Heartbleed apenas deixa muito claro, que a Web não é um lugar tão seguro quanto muitas pessoas pensam.
As vulnerabilidades estão por aí, em sistemas, em software e as equipes de segurança das empresas mais renomadas em todo o mundo, fazem todos os dias, um grande esforço para detectar e identificar essas falhas, com a intenção de evitar violações de dados. Portanto, ninguém deve esquecer que esta é apenas uma falha que aconteceu com um tipo de protocolo, mas não há certeza da inexistência de outros tantos bugs em outros tipos de servidores.
Saiba Mais:
[1] Convergência Digital http://convergenciadigital.uol.com.b...8#.VCkwNfldWpx
[2] TecMundo http://www.tecmundo.com.br/internet/...a-internet.htm