Patch Madness: Os avisos de bug do fornecedor estão quebrados, tão quebrados

BLACK HAT EUA – Las Vegas – Acompanhar a correção de vulnerabilidades de segurança é, na melhor das hipóteses, um desafio, mas priorizar quais bugs focar tornou-se mais difícil do que nunca, graças às pontuações CVSS sem contexto, aos avisos confusos dos fornecedores e às correções incompletas que deixe os administradores com uma falsa sensação de segurança.

Esse é o argumento que Brian Gorenc e Dustin Childs, ambos da Zero Day Initiative (ZDI) da Trend Micro, apresentaram no palco da Black Hat USA durante sua sessão: “Calculando o risco na era da obscuridade: lendo nas entrelinhas dos avisos de segurança. "

A ZDI divulgou mais de 10,000 vulnerabilidades para fornecedores em todo o setor desde 2005. Ao longo desse tempo, Childs, gerente de comunicações da ZDI, disse que percebeu uma tendência perturbadora, que é uma diminuição na qualidade dos patches e uma redução nas comunicações em torno das atualizações de segurança.

“O verdadeiro problema surge quando os fornecedores lançam patches defeituosos ou informações imprecisas e incompletas sobre esses patches que podem fazer com que as empresas calculem mal o seu risco”, observou ele. “Patchs defeituosos também podem ser uma vantagem para explorar os gravadores, já que os ‘n-days’ são muito mais fáceis de usar do que os zero-days.”

O problema com pontuações CVSS e prioridade de patch

A maioria das equipes de segurança cibernética tem falta de pessoal e está sob pressão, e o mantra “manter sempre todas as versões de software atualizadas” nem sempre faz sentido para departamentos que simplesmente não têm recursos para cobrir a zona portuária. É por isso que priorizar quais patches aplicar de acordo com sua classificação de gravidade na Escala Comum de Gravidade de Vulnerabilidade (CVSS) se tornou uma alternativa para muitos administradores.

Childs observou, no entanto, que esta abordagem é profundamente falha e pode levar ao gasto de recursos em bugs que provavelmente nunca serão explorados. Isso ocorre porque há uma série de informações críticas que a pontuação CVSS não fornece.

“Muitas vezes, as empresas não olham além do núcleo básico do CVSS para determinar a prioridade dos patches”, disse ele. “Mas o CVSS não analisa realmente a capacidade de exploração, ou se é provável que uma vulnerabilidade seja usada em liberdade. O CVSS não informa se o bug existe em 15 sistemas ou em 15 milhões de sistemas. E não diz se está ou não em servidores acessíveis ao público.”

Ele acrescentou: “E o mais importante, não diz se o bug está ou não presente em um sistema que é crítico para sua empresa específica”.

Assim, mesmo que um bug possa ter uma classificação crítica de 10 em 10 na escala CVSS, o seu verdadeiro impacto pode ser muito menos preocupante do que o rótulo crítico indicaria.

“Um bug de execução remota de código (RCE) não autenticado em um servidor de e-mail como o Microsoft Exchange vai gerar muito interesse por parte dos criadores de exploits”, disse ele. “Um bug RCE não autenticado em um servidor de e-mail como o Squirrel Mail provavelmente não atrairá tanta atenção.”

Para preencher as lacunas contextuais, as equipes de segurança muitas vezes recorrem a recomendações de fornecedores – que, observou Childs, têm seu próprio problema evidente: muitas vezes praticam a segurança através da obscuridade.

Os comunicados do Microsoft Patch Tuesday não possuem detalhes

Em 2021, a Microsoft tomou a decisão para remover resumos executivos
dos guias de atualização de segurança, informando aos usuários que as pontuações CVSS seriam suficientes para a priorização – uma mudança que Childs criticou.

“A mudança remove o contexto necessário para determinar o risco”, disse ele. “Por exemplo, um bug de divulgação de informações despeja memória aleatória ou PII? Ou, para ignorar um recurso de segurança, o que está sendo ignorado? As informações contidas nesses artigos são inconsistentes e de qualidade variável, apesar das críticas quase universais à mudança.”

Além de a Microsoft “remover ou ocultar informações em atualizações que costumavam produzir orientações claras”, agora também é mais difícil determinar informações básicas do Patch Tuesday, como quantos bugs são corrigidos a cada mês.

“Agora você tem que contar sozinho, e na verdade é uma das coisas mais difíceis que faço”, observou Childs.

Além disso, as informações sobre quantas vulnerabilidades estão sob ataque ativo ou são conhecidas publicamente ainda estão disponíveis, mas agora estão ocultas nos boletins.

“A título de exemplo, com 121 CVEs sendo corrigidos este mês, é meio difícil vasculhar todos eles para descobrir quais estão sob ataque ativo”, disse Childs. “Em vez disso, as pessoas agora confiam em outras fontes de informação, como blogs e artigos de imprensa, em vez do que deveria ser informação oficial do fornecedor para ajudar a determinar o risco.”

Deve-se notar que a Microsoft dobrou a aposta na mudança. Em conversa com Dark Reading na Black Hat USA, o vice-presidente corporativo do Security Response Center da Microsoft, Aanchal Gupta, disse que a empresa decidiu conscientemente limitar as informações que fornece inicialmente com seus CVEs para proteger os usuários. Embora os CVEs da Microsoft forneçam informações sobre a gravidade do bug e a probabilidade de ele ser explorado (e se está sendo explorado ativamente), a empresa será criteriosa sobre como divulgará informações sobre exploração de vulnerabilidades, disse ela.

O objetivo é dar às administrações de segurança tempo suficiente para aplicar o patch sem prejudicá-las, disse Gupta. “Se, em nosso CVE, fornecermos todos os detalhes de como as vulnerabilidades podem ser exploradas, estaremos zerando nossos clientes”, disse ela.

Outros fornecedores praticam a obscuridade

A Microsoft não está sozinha no fornecimento de poucos detalhes nas divulgações de bugs. Childs disse que muitos fornecedores não fornecem CVEs quando lançam uma atualização.

“Eles apenas dizem que a atualização corrige vários problemas de segurança”, explicou. "Quantos? Qual é a gravidade? Qual é a explorabilidade? Recentemente, até um fornecedor nos disse especificamente que não publicamos avisos públicos sobre questões de segurança. Essa é uma jogada ousada.”

Além disso, alguns fornecedores colocam avisos por trás de acessos pagos ou contratos de suporte, obscurecendo ainda mais o risco. Ou combinam vários relatórios de bugs em um único CVE, apesar da percepção comum de que um CVE representa uma vulnerabilidade única.

“Isso possivelmente leva a distorcer seu cálculo de risco”, disse ele. “Por exemplo, se você comprar um produto e vir 10 CVEs que foram corrigidos em um determinado período de tempo, poderá chegar a uma conclusão sobre o risco deste novo produto. No entanto, se você soubesse que esses 10 CVEs foram baseados em mais de 100 relatórios de bugs, você poderia chegar a uma conclusão diferente.”

Priorização da praga de patches de placebo

Além do problema de divulgação, as equipes de segurança também enfrentam problemas com os próprios patches. “Patches de placebo”, que são “correções” que na verdade não fazem alterações efetivas no código, não são incomuns, de acordo com Childs.

“Portanto, esse bug ainda está lá e pode ser explorado por agentes de ameaças, exceto agora que eles foram informados sobre isso”, disse ele. “Há muitas razões pelas quais isso pode acontecer, mas isso acontece – bugs tão legais que nós os corrigimos duas vezes.”

Muitas vezes também existem patches incompletos; na verdade, no programa ZDI, 10% a 20% dos bugs analisados ​​pelos pesquisadores são o resultado direto de um patch defeituoso ou incompleto.

Childs usou o exemplo de um problema de estouro de número inteiro no Adobe Reader, levando a uma alocação de heap subdimensionada, o que resulta em um estouro de buffer quando muitos dados são gravados nele.

“Esperávamos que a Adobe fizesse a correção, definindo qualquer valor acima de um determinado ponto como ruim”, disse Childs. “Mas não foi isso que vimos e, 60 minutos após o lançamento, houve um desvio de patch e eles tiveram que corrigir novamente. As reprises não são apenas para programas de TV.”

Como combater os problemas de priorização de patches

Em última análise, quando se trata de priorização de patches, o gerenciamento eficaz de patches e o cálculo de risco se resumem à identificação de alvos de software de alto valor dentro da organização, bem como ao uso de fontes de terceiros para restringir quais patches seriam os mais importantes para qualquer ambiente específico, o observaram os pesquisadores.

No entanto, a questão da agilidade pós-divulgação é outra área importante na qual as organizações devem se concentrar.

De acordo com Gorenc, diretor sênior da ZDI, os cibercriminosos não perdem tempo integrando vulnerabilidades com grandes superfícies de ataque em seus conjuntos de ferramentas de ransomware ou em seus kits de exploração, procurando transformar em armas as falhas recém-divulgadas antes que as empresas tenham tempo de corrigi-las. Esses chamados bugs de n dias são uma ajuda para os invasores, que, em média, conseguem fazer engenharia reversa de um bug em apenas 48 horas.

“Na maior parte, a comunidade ofensiva está usando vulnerabilidades de n dias que possuem patches públicos disponíveis”, disse Gorenc. “É importante para nós entendermos, no momento da divulgação, se um bug será realmente transformado em arma, mas a maioria dos fornecedores não fornece informações sobre a capacidade de exploração.”

Assim, as avaliações de risco empresarial precisam ser dinâmicas o suficiente para mudar após a divulgação, e as equipes de segurança devem monitorar as fontes de inteligência de ameaças para entender quando um bug é integrado a um kit de exploração ou ransomware, ou quando uma exploração é lançada online.

Além disso, um cronograma importante a ser considerado pelas empresas é quanto tempo leva para realmente implementar um patch em toda a organização e se há recursos de emergência que possam ser utilizados, se necessário.

“Quando ocorrem mudanças no cenário de ameaças (revisões de patches, provas públicas de conceitos e lançamentos de exploração), as empresas devem mudar seus recursos para atender às necessidades e combater os riscos mais recentes”, explicou Gorenc. “Não apenas a vulnerabilidade mais recente divulgada e nomeada. Observe o que está acontecendo no cenário de ameaças, oriente seus recursos e decida quando agir.”