0 
0 Acompanhar os patches de vulnerabilidade de segurança é um desafio, na melhor das hipóteses, mas priorizar quais bugs focar se tornou mais difícil do que nunca, graças a pontuações CVSS sem contexto, avisos de fornecedores confusos e correções incompletas que deixar os administradores com uma falsa sensação de segurança.
Esse é o argumento que Brian Gorenc e Dustin Childs, ambos com a Zero Day Initiative (ZDI) da Trend Micro, fizeram do palco da Black Hat USA durante sua sessão, ” Calculando 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, o gerente de comunicações da ZDI, Childs, disse que notou uma tendência preocupante, que é uma diminuição na qualidade do patch e redução das comunicações em torno das atualizações de segurança.
“O problema real 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 seus riscos”, observou ele. “Os patches defeituosos também podem ser uma benção para explorar os escritores, já que ‘n-days’ são muito mais fáceis de usar do que zero-days.”
O problema com pontuações CVSS e prioridade de correção
A maioria das equipes de segurança cibernética está com falta de pessoal e sob pressão, e o mantra “sempre manter todas as versões de software atualizadas” nem sempre faz sentido para departamentos que simplesmente não têm recursos para cobrir a orla. É por isso que priorizar quais patches aplicar de acordo com sua classificação de gravidade na Common Vulnerability Severity Scale (CVSS) se tornou um substituto para muitos administradores.
Childs observou, no entanto, que essa abordagem é profundamente falha e pode levar ao gasto de recursos em bugs que provavelmente nunca serão explorados. Isso porque há uma série de informações críticas que a pontuação do CVSS não fornece.
“Muitas vezes, as empresas não procuram mais do que o núcleo básico do CVSS para determinar a prioridade de patches”, disse ele. “Mas o CVSS realmente não analisa a possibilidade de exploração, ou se uma vulnerabilidade provavelmente será usada em estado selvagem. O CVSS não informa se o bug existe em 15 sistemas ou em 15 milhões de sistemas. E não não diga 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, 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 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 vai gerar tanta atenção.”
Para preencher as lacunas contextuais, as equipes de segurança geralmente recorrem a avisos de fornecedores – que, observou Childs, têm seu próprio problema evidente: eles geralmente praticam a segurança através da obscuridade.
Os avisos do Microsoft Patch Tuesday não têm detalhes
Em 2021, a Microsoft tomou a decisão de remover os resumos executivos dos guias de atualização de segurança, informando aos usuários que as pontuações do CVSS seriam suficientes para 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 um desvio de recurso de segurança, o que está sendo ignorado? As informações nessas anotações 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 a si mesmo, e é realmente 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 conhecidas publicamente ainda estão disponíveis, mas enterradas nos boletins agora.
“Como exemplo, com 121 CVEs sendo corrigidos este mês , é meio difícil vasculhar todos eles para procurar 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 uma informação oficial do fornecedor para ajudar a determinar o risco.”
Deve-se notar que a Microsoft duplicou a mudança . Em uma 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 liberar informações de 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 sem nossos clientes”, disse ela.
Outros fornecedores praticam a obscuridade
A Microsoft não está sozinha em fornecer detalhes escassos 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 ele. “Quantos? Qual é a gravidade? Qual é a possibilidade de exploração? Recentemente, um fornecedor nos disse especificamente que não publicamos avisos públicos sobre questões de segurança. É uma jogada ousada.”
Além disso, alguns fornecedores colocam avisos por trás de paywalls ou contratos de suporte, obscurecendo ainda mais seus riscos. Ou combinam vários relatórios de bugs em um único CVE, apesar da percepção comum de que um CVE representa uma única vulnerabilidade única.
“Isso leva a possivelmente distorcer seu cálculo de risco”, disse ele. “Por exemplo, se você olhar para a compra de 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 desse novo produto. No entanto, se você conhecesse esses 10 CVEs foram baseados em mais de 100 relatórios de bugs, você pode chegar a uma conclusão diferente.”
Priorização de Pragas 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. “Placebo patches”, que são “correções” que não fazem alterações efetivas no código, não são incomuns, de acordo com Childs.
“Então, esse bug ainda está lá e pode ser explorado por agentes de ameaças, exceto que agora eles foram informados sobre isso”, disse ele. “Há muitas razões pelas quais isso pode acontecer, mas acontece – bugs tão bons que os corrigimos duas vezes.”
Muitas vezes também há patches incompletos; na verdade, no programa ZDI, um total de 10% a 20% dos bugs que os pesquisadores analisam 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 alocação de heap subdimensionada, o que resulta em 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 certo ponto como ruim”, disse Childs. “Mas não foi isso que vimos, e dentro de 60 minutos do lançamento, houve um desvio de patch e eles tiveram que corrigir novamente. Reprises não são apenas para programas de TV.”
Como combater 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, o pesquisadores notaram.
No entanto, a questão da agilidade pós-divulgação é outra área-chave para as organizações se concentrarem.
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 kits de exploração, procurando armar falhas recém-divulgadas antes que as empresas tenham tempo de corrigir. Esses chamados bugs de n-dia são catnip para os invasores, que, em média, podem fazer engenharia reversa de um bug em menos de 48 horas.
“Na maioria das vezes, a comunidade ofensiva está usando vulnerabilidades de n-dia que possuem patches públicos disponíveis”, disse Gorenc. “É importante para nós entendermos na divulgação se um bug será realmente usado como arma, mas a maioria dos fornecedores não fornece informações sobre a possibilidade de exploração”.
Assim, as avaliações de risco corporativo 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 implantar um patch em toda a organização e se há recursos de emergência que podem ser usados, se necessário.
“Quando ocorrem alterações no cenário de ameaças (revisões de patches, provas de conceito públicas 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 mais recente vulnerabilidade divulgada e nomeada. Observe o que está acontecendo no cenário de ameaças, oriente seus recursos e decida quando agir.”
FONTE: DARK READING