0 
0 As organizações têm cinco dias para se preparar para o que o Projeto OpenSSL em 26 de outubro descreveu como uma vulnerabilidade “crítica” nas versões 3.0 e superiores da biblioteca criptográfica quase onipresente para criptografar comunicações na Internet.
Na terça-feira, 1º de novembro, o projeto lançará uma nova versão do OpenSSL (versão 3.0.7) que corrigirá uma falha ainda não divulgada nas versões atuais da tecnologia. As características da vulnerabilidade e a facilidade com que ela pode ser explorada determinarão a velocidade com que as organizações precisarão resolver o problema.
Implicações Potencialmente Enormes
Os principais fornecedores de sistemas operacionais, editores de software, provedores de e-mail e empresas de tecnologia que integraram o OpenSSL em seus produtos e serviços provavelmente terão versões atualizadas de suas tecnologias programadas para lançamento com a divulgação da falha do Projeto OpenSSL na próxima terça-feira. Mas isso ainda deixará potencialmente milhões de outros – incluindo agências federais, empresas privadas, provedores de serviços, fabricantes de dispositivos de rede e inúmeros operadores de sites – com um prazo iminente para encontrar e corrigir a vulnerabilidade antes que os invasores comecem a explorá-la.
Se a nova vulnerabilidade for outro bug do Heartbleed – a última vulnerabilidade crítica a impactar o OpenSSL – as organizações e, de fato, todo o setor estarão sob a mira para resolver o problema o mais rápido possível.
A vulnerabilidade Heartbleed (CVE-2014-0160), divulgada em 2014, basicamente deu aos invasores uma maneira de espionar as comunicações da Internet, roubar dados de serviços e usuários, personificar serviços e fazer tudo isso com poucos vestígios de terem feito qualquer disso. O bug existia nas versões do OpenSSL a partir de março de 2012 e afetou uma gama estonteante de tecnologias, incluindo servidores Web amplamente usados, como Nginx, Apache e IIS; organizações como Google, Akamai, CloudFlare e Facebook ; servidores de e-mail e chat; aparelhos de rede de empresas como a Cisco; e VPN.
A divulgação do bug desencadeou um frenesi de atividades corretivas em todo o setor e despertou preocupações de grandes comprometimentos. Como o site Heartbleed.com da Synopsys observou, Apache e Nginx sozinhos representavam uma participação de mercado de mais de 66% dos sites ativos na Internet no momento em que o Heartbleed foi divulgado.
Não há como dizer, pelo menos até terça-feira, se a nova falha será algo como Heartbleed. Mas dado o uso quase de infraestrutura crítica do OpenSSL para criptografia na Internet, as organizações fariam bem em não subestimar a ameaça, disseram especialistas em segurança nesta semana.
As organizações de segurança devem se preparar para o impacto
“É um pouco difícil especular sobre o impacto, mas a experiência passada mostrou que o OpenSSL não usa o rótulo ‘crítico’ levianamente”, diz Johannes Ullrich, reitor de pesquisa do SANS Institute.
O próprio OpenSSL define uma falha crítica como aquela que permite a divulgação significativa do conteúdo da memória do servidor e detalhes do usuário em potencial, vulnerabilidades que podem ser exploradas facilmente e remotamente para comprometer as chaves privadas do servidor.
A versão 3.0, a versão atual do OpenSSL, é usada em muitos sistemas operacionais atuais, como Ubuntu 22.04 LTS e MacOS Mavericks e Ventura, observa Ullrich. As organizações podem esperar receber patches do Linux rapidamente e provavelmente ao mesmo tempo que o boletim OpenSSL na terça-feira. Mas as organizações devem se preparar agora, descobrindo quais sistemas usam o OpenSSL 3.0, diz Ullrich. “Depois do Heartbleed, o OpenSSL introduziu esses pré-anúncios de patches de segurança”, diz ele. “Eles devem ajudar as organizações a se prepararem. Portanto, use esse tempo para descobrir o que precisará ser corrigido.”
Brian Fox, cofundador e CTO da Sonatype, diz que quando o OpenSSL Project divulgar o bug na terça-feira, as organizações precisam identificar se estão usando uma versão vulnerável em qualquer lugar de seu portfólio de tecnologia, quais aplicativos estão usando e por quanto tempo seria necessário para eles para remediar o problema.
“O alcance potencial é sempre a parte mais importante de qualquer grande falha”, observa Fox. “Neste caso, o maior desafio com a atualização do OpenSSL é que muitas vezes esse uso é incorporado em outros dispositivos.” Nesses casos, pode ser difícil avaliar a exposição sem perguntar ao fornecedor upstream da tecnologia, acrescenta.
Qualquer coisa que se comunique com a Internet de forma segura pode ter o OpenSSL embutido. E não é apenas o software que pode ser afetado, mas também o hardware. O aviso prévio fornecido pelo Projeto OpenSSL deve dar às organizações tempo para se prepararem. “Encontrar quais peças de software ou dispositivos é o primeiro passo. As organizações devem fazer isso agora e, em seguida, corrigir ou fornecer atualizações dos fornecedores upstream seguirão”, diz Fox. “Tudo o que você pode fazer no momento é o inventário.”
Um ecossistema inteiro pode precisar ser atualizado
Muito também dependerá de como os fornecedores de produtos com versões vulneráveis do OpenSSL embutidos neles responderão à divulgação. O lançamento da nova versão do OpenSSL Project na terça-feira é apenas o primeiro passo. “Todo um ecossistema de aplicativos construídos com OpenSSL também terá que atualizar seu código, lançar suas próprias atualizações, e as organizações precisarão aplicá-las”, diz John Bambenek, principal caçador de ameaças da Netenrich.
Idealmente, as organizações que lidaram com o Heartbleed terão uma ideia de onde estão suas instalações OpenSSL e quais produtos de seus fornecedores também exigirão uma atualização. “É por isso que as listas de materiais de software podem ser importantes”, diz Bambenek. “Eles podem aproveitar esse tempo para entrar em contato e entender os planos de seus fornecedores e fornecedores para atualizações para garantir que essas atualizações também sejam aplicadas”. Uma questão provável para a qual as organizações precisam estar preparadas é como lidar com produtos em fim de vida para os quais não há atualizações disponíveis, acrescenta ele.
Mike Parkin, engenheiro técnico sênior da Vulcan Cyber, diz que, sem evidências de atividade de exploração e indicadores associados de comprometimento, é melhor que as organizações sigam seu processo normal de gerenciamento de mudanças para quando uma atualização conhecida estiver a caminho. “No lado da segurança, vale a pena colocar um foco adicional em sistemas que podem ser afetados se uma exploração surgir antes que a nova versão seja lançada”, aconselha ele.
Não há informações suficientes no anúncio do OpenSSL Project para dizer quanto trabalho será envolvido na atualização, “mas, a menos que exija a atualização de certificados, a atualização provavelmente será direta”, prevê Parkin.
Também em 1º de novembro, o projeto OpenSSL lançará o OpenSSL versão 1.1.1s, que descreveu como um “lançamento de correção de bugs”. A versão 1.1.1, que substitui, não é suscetível ao CVE que está sendo corrigido na 3.0, observou o projeto.
FONTE: DARK READING