Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Já se passou cerca de uma década desde a descoberta do Heartbleed, uma vulnerabilidade perigosa do OpenSSL que afetou milhões de sistemas — e que ganhou destaque na grande mídia.
Isso já é história, né? A tecnologia avança rápido… dez anos é muito tempo… e essa vulnerabilidade já não existe mais, certo?
Errado.
Estamos publicando mais um artigo sobre o Heartbleed porque, adivinhem só, ele ainda está entre nós. Sim, considerando a rapidez com que uma correção foi lançada e levando em conta o ritmo acelerado do desenvolvimento tecnológico, o Heartbleed já deveria ter ficado para trás a esta altura.
E, se você tiver aplicado as atualizações nos seus sistemas sempre dentro do prazo, não tem com o que se preocupar.
Mas e se você tiver deixado de instalar uma atualização em algum lugar? E se sua empresa tiver se fundido recentemente com outra empresa em que a aplicação de atualizações não estava em dia? Ou e se essa solução tecnológica novinha em folha contiver uma parte de código desatualizado?
Acontece que ainda é comum que os sistemas estejam vulneráveis ao Heartbleed. Neste artigo, apresentamos uma breve visão geral do Heartbleed e de sua história. Também indicaremos pesquisas recentes que mostram que inúmeros sistemas ainda correm o risco de sofrer um ataque viabilizado por uma exploração do Heartbleed.
Também explicamos como você pode verificar facilmente se possui bibliotecas do OpenSSL vulneráveis ao Heartbleed e o que pode fazer para garantir uma proteção infalível contra essa vulnerabilidade perigosa.
O que é exatamente o “Heartbleed Bug”? Uma visão geral rápida
Em 2014, pesquisadores descobriram que as versões 1.0.1 a 1.0.1f do OpenSSL continham um tipo de falha no gerenciamento de memória chamada falha na verificação de limites. Em outras palavras, o código do OpenSSL não verificava se os dados inseridos na memória excediam o tamanho do buffer alocado.
Um invasor pode, portanto, induzir o serviço OpenSSL a alocar um buffer de 64 KB, para depois enviar dados que excedam o tamanho desse buffer. Ao fazer isso, o invasor pode vazar (ou extrair) dados da máquina da vítima em incrementos de 64 KB. Essa é apenas uma breve descrição — para obter detalhes sobre a exploração, você pode ler o aqui.
A falha foi batizada de Heartbleed devido à necessidade de “sangrar” dados pouco a pouco e porque o ataque ocorre durante o que é chamado de “heartbeat” – a mensagem de pulso enviada entre dois servidores para confirmar se o servidor conectado ainda está ativo.
As oportunidades para explorar a vulnerabilidade Heartbleed eram amplas e graves. Os invasores podem roubar desde chaves criptográficas e credenciais de usuários até documentos e comunicações privadas. Um invasor pode fazer tudo isso sem precisar ter credenciais de acesso — e sem deixar nenhum rastro.
Embora 64 KB não pareça muito, isso abre as portas para grandes violações. Em um exemplo alarmante de um ataque do Heartbleed, um invasor conseguiu roubar 4,5 milhões de registros de pacientes da Community Health Systems em 2014.
A vulnerabilidade Heartbleed continua exposta
Tudo bem, isso foi em 2014. Por que ainda vale a pena escrever sobre o Heartbleed? Simplesmente por causa do grande número de aplicativos e servidores que dependem do OpenSSL, o que, somado à tendência de aplicar correções de forma inconsistente, nos deixa com um grande número de serviços que ainda estão vulneráveis.
Na época em que o Heartbeat foi descoberto, a Netcraft informou que cerca de 17% dos servidores web seguros estavam vulneráveis, incluindo alguns dos serviços mais populares do mundo. É um número enorme de servidores.
Correções para o OpenSSL foram lançadas assim que a vulnerabilidade foi divulgada, mas isso não significa que o Heartbleed tenha sido definitivamente resolvido.
Pesquisadores de segurança continuam apontando riscos relacionados ao Heartbleed. Recentemente, a gigante japonesa de tecnologia NTT destacou em um relatório de pesquisa que o Heartbleed é uma das principais razões pelas quais o OpenSSL continua sendo um dos serviços mais frequentemente visados por hackers.
Da mesma forma, em novembro de 2020, um pesquisador do SANS Internet Storm Center utilizou o mecanismo de busca Shodan para descobrir que mais de 200 mil máquinas ainda estão vulneráveis à CVE-2014-0160, o identificador oficial da vulnerabilidade Heartbleed. Por meio de um processo de validação, o pesquisador constatou que o Shodan estava, em grande parte, correto em suas avaliações.
É claro que, embora já existam medidas de mitigação, o Heartbleed ainda é um problema. Se você estiver usando o serviço de correção de bibliotecas da TuxCare, o LibraryCare, você não precisa se preocupar muito, pois suas bibliotecas estarão sempre atualizadas. No entanto, na ausência de uma solução automatizada de aplicação de patches em bibliotecas que não exija reinicialização, você deve avaliar como suas operações ainda podem estar vulneráveis ao Heartbleed devido a uma vulnerabilidade na biblioteca OpenSSL.
Você também pode ler nosso guia completo para descobrir maneiras estratégicas de evitar o tempo de inatividade dos servidores em toda a sua infraestrutura.
A aplicação de patches é a solução… mas também o problema
A razão pela qual o Heartbleed ainda está em circulação não se deve, de forma alguma, à falta de patches. A maioria dos serviços que utilizam o OpenSSL já dispõe de um patch para eliminar a ameaça do Heartbleed. Basta aplicar o patch e a ameaça do Heartbleed desaparece; é simples assim, segundo a teoria.
No entanto, não é bem assim tão simples, por várias razões. No ambiente corporativo, a aplicação de patches não se resume a simplesmente executar um patch e reiniciar um serviço ou dispositivo. A aplicação de patches exige um tempo de inatividade planejado e recursos significativos, envolvendo o tempo de diversos especialistas, incluindo administradores de sistemas, administradores de bancos de dados e administradores de Linux. Muitos problemas surgem nesse processo:
- Incerteza sobre quais bibliotecas foram atualizadas: Ao executar um processo de aplicação de patches, geralmente há um certo grau de automação, o que pode deixar os administradores de sistemas sem saber ao certo quais bibliotecas foram atualizadas durante o processo. Isso pode levar a reinicializações extensas e desnecessárias, além de tempo de inatividade adicional — o que pode impedir a aplicação abrangente de patches.
- Falta de consistência na aplicação de patches: Outro risco é que algumas bibliotecas possam não receber as atualizações simplesmente porque os administradores não estão cientes de que elas precisam ser atualizadas. Pode ser difícil estabelecer um catálogo completo e abrangente das bibliotecas, e basta uma única biblioteca sem atualização para que ocorra uma violação. A aplicação manual de atualizações também pode levar rapidamente à omissão de algumas bibliotecas.
- Janela de vulnerabilidade: Os patches costumam ser lançados rapidamente – mas aplicados com menos rapidez. A razão para isso é a dificuldade em planejar o tempo de inatividade e os desafios de organizar todos os aspectos técnicos necessários para aplicar um patch. Isso deixa uma janela entre o momento em que uma vulnerabilidade é relatada e o momento em que ela é corrigida pelo usuário final. Durante essa janela, os sistemas da sua organização ficarão vulneráveis a ataques.
É evidente que a aplicação de patches pode rapidamente se tornar uma questão de sorte. Anos após a descoberta do Heartbleed, ainda não é de forma alguma impossível que sua organização tenha deixado de aplicar os patches de forma completa para se proteger contra ele.
Também é possível que, nesse meio tempo, você tenha adquirido uma tecnologia que ainda apresente a falha crítica do OpenSSL.
Verificação de bibliotecas sem patch com o Uchecker
Se você é um administrador de sistemas e está se perguntando se suas bibliotecas estão sempre atualizadas, uma das ferramentas que você deve considerar usar é o uChecker – uma ferramenta gratuita, licenciada sob a licença GNU, desenvolvida pela equipe responsável pelo TuxCare.
O uChecker ajuda você a verificar se suas bibliotecas receberam o patch contra a vulnerabilidade Heartbleed, gerando um relatório de fácil compreensão que detalha quais bibliotecas não estão atualizadas. O uChecker pode verificar tanto as bibliotecas na memória quanto as armazenadas no disco.
Essa é uma vantagem em relação a outros scanners, que não conseguem detectar bibliotecas sem patch na memória. É fácil instalar o uChecker – basta acessar a página do GitHub aqui.
$ curl -s -L https://kernelcare.com/uchecker | sudo python
Depois de realizar uma verificação com o uChecker, você pode aplicar as correções em quaisquer serviços do OpenSSL que ainda estejam vulneráveis ao Heartbleed.
Por uma questão de segurança, você deve verificar minuciosamente o código baixado da internet antes de executá-lo em seus sistemas. O comando acima pode, e deve, ser dividido em dois: um para baixar o código, que você verificaria, e outro para executá-lo de fato. O que foi mostrado acima é apenas uma maneira prática de executar o uChecker, não a melhor prática de segurança.
Vale a pena verificar novamente se há vulnerabilidade do Heartbleed
Anos após o surgimento do Heartbleed, vale, sem dúvida, a pena verificar se seus servidores estão totalmente protegidos contra essa ameaça perigosa. Apresentamos dois exemplos de como pesquisas recentes destacam que as organizações ainda apresentam lacunas em sua resposta ao Heartbleed.
Caso você ainda não utilize uma ferramenta automatizada de aplicação de patches em tempo real, recomendamos que execute o uChecker — trata-se de uma ferramenta gratuita e fácil de usar que identificará rapidamente se você possui servidores que ainda estejam vulneráveis à falha Heartbleed.
De qualquer forma, é fundamental ficar de olho no OpenSSL. Trata-se de uma importante camada de segurança, mas, ao mesmo tempo, tem sido um dos softwares mais vulneráveis, com 202 vulnerabilidades descobertas desde seu lançamento até o momento da redação deste artigo — das quais o Heartbleed foi apenas uma.
E não se esqueça: o LibCare, da TuxCare, manterá suas bibliotecas, incluindo o OpenSSL, atualizadas — sem complicações. Saiba mais sobre o LibCare aqui.
