Exploração 0day “in-the-wild”
Nos últimos três anos, publicamos relatórios anuais de revisão de 0 dias encontrados explorados na rede.
Este post do blog é uma visão geral de uma palestra, “0-day In-the-Wild Exploitation in 2022…so far”, que dei na FIRST conference em junho de 2022. Os slides estão disponíveis aqui.
O mais recente desses relatórios é o relatório Year in Review 2021 , que publicamos há apenas alguns meses em abril. Enquanto planejamos manter essa cadência anual, estamos publicando um pequeno relatório de bônus hoje, analisando os 0 dias na rede detectados e divulgados no primeiro semestre de 2022.
Em 15 de junho de 2022, havia 18 0 dias detectados e divulgados como explorados em estado selvagem em 2022 . Quando analisamos esses dias 0, descobrimos que pelo menos nove dos dias 0 são variantes de vulnerabilidades corrigidas anteriormente. Pelo menos metade dos 0 dias que vimos nos primeiros seis meses de 2022 poderiam ter sido evitados com testes de correção e regressão mais abrangentes. Além disso, quatro dos dias 0 de 2022 são variantes dos dias 0 selvagens de 2021. Apenas 12 meses após o patch original de 0 dias na rede, os invasores voltaram com uma variante do bug original.
| produtos | 2022 ITW 0 dia | Variante |
| Windows win32k | CVE-2022-21882 | CVE-2021-1732 (2021 itw) |
| iOS IOMobileFrameBuffer | CVE-2022-22587 | CVE-2021-30983 (2021 itw) |
| janelas | CVE-2022-30190 (“Follina”) | CVE-2021-40444 (2021 itw) |
| Interceptadores de acesso à propriedade do Chromium | CVE-2022-1096 | CVE-2016-5128 CVE-2021-30551 (2021 itw) CVE-2022-1232 (endereça a correção incompleta do CVE-2022-1096) |
| Chromium v8 | CVE-2022-1364 | CVE-2021-21195 |
| WebKit | CVE-2022-22620 (“Zumbi”) | Bug foi corrigido originalmente em 2013, patch foi regredido em 2016 |
| Google Pixel | CVE-2021-39793 ** Enquanto este CVE diz 2021, o bug foi corrigido e divulgado em 2022 | Linux mesmo bug em um subsistema diferente |
| Confluência Atlassiana | CVE-2022-26134 | CVE-2021-26084 |
| janelas | CVE-2022-26925 (“PetitPotam”) | CVE-2021-36942 (Patch regrediu) |
Então o que isso quer dizer?
Quando as pessoas pensam em exploits de dia 0, muitas vezes pensam que esses exploits são tão tecnologicamente avançados que não há esperança de pegá-los e evitá-los. Os dados pintam uma imagem diferente. Pelo menos metade dos 0 dias que vimos até agora este ano estão intimamente relacionados a bugs que vimos antes. Nossa conclusão e descobertas no relatório de revisão anual de 2020 foram muito semelhantes.
Muitos dos 0 dias in-the-wild de 2022 se devem ao fato de a vulnerabilidade anterior não ter sido totalmente corrigida. No caso dos bugs do Windows win32k e do interceptor de acesso à propriedade Chromium, o fluxo de execução que as explorações de prova de conceito levaram foi corrigido, mas o problema de causa raiz não foi resolvido: os invasores conseguiram voltar e acionar a vulnerabilidade original por um caminho diferente. E no caso dos problemas do WebKit e do Windows PetitPotam, a vulnerabilidade original já havia sido corrigida, mas em algum momento regrediu para que os invasores pudessem explorar a mesma vulnerabilidade novamente. No bug IOMobileFrameBuffer do iOS, um estouro de buffer foi resolvido verificando se um tamanho era menor que um determinado número, mas não verificava um limite mínimo nesse tamanho.slides da palestra .
Quando explorações de dia 0 são detectadas em estado selvagem, é o caso de falha para um invasor. É um presente para nós, defensores da segurança, aprender o máximo que pudermos e tomar medidas para garantir que esse vetor não possa ser usado novamente. O objetivo é forçar os invasores a começar do zero cada vez que detectamos uma de suas façanhas: eles são forçados a descobrir uma vulnerabilidade totalmente nova, eles precisam investir tempo para aprender e analisar uma nova superfície de ataque, eles devem desenvolver uma marca novo método de exploração. Para fazer isso de forma eficaz, precisamos de correções corretas e abrangentes.
Isso não visa minimizar os desafios enfrentados pelas equipes de segurança responsáveis por responder aos relatórios de vulnerabilidade. Como dissemos em nosso relatório de revisão do ano de 2020:
Ser capaz de corrigir de forma correta e abrangente não é apenas apertar um botão: requer investimento, priorização e planejamento. Também requer o desenvolvimento de um processo de correção que equilibre a proteção rápida dos usuários e a garantia de que é abrangente, o que às vezes pode estar em tensão. Embora esperemos que nada disso seja uma surpresa para as equipes de segurança de uma organização, esta análise é um bom lembrete de que ainda há muito trabalho a ser feito.
Exatamente quais investimentos são provavelmente necessários depende de cada situação única, mas vemos alguns temas comuns em torno de pessoal/recursos, estruturas de incentivo, maturidade do processo, automação/teste, cadência de lançamento e parcerias.
Praticamente, alguns dos esforços a seguir podem ajudar a garantir que os bugs sejam corrigidos de forma correta e abrangente. O Project Zero planeja continuar ajudando nos seguintes esforços, mas esperamos e incentivamos as equipes de segurança da plataforma e outros pesquisadores de segurança independentes a investirem nesses tipos de análises também:
- Análise de causa raiz
Entendendo a vulnerabilidade subjacente que está sendo explorada. Também tenta entender como essa vulnerabilidade pode ter sido introduzida. Realizar uma análise de causa raiz pode ajudar a garantir que uma correção esteja abordando a vulnerabilidade subjacente e não apenas quebrando a prova de conceito. A análise de causa raiz geralmente é um pré-requisito para uma análise bem-sucedida de variantes e patches.
- Análise de variantes
Procurando por outras vulnerabilidades semelhantes à vulnerabilidade relatada. Isso pode envolver procurar o mesmo padrão de bug em outro lugar, auditar mais detalhadamente o componente que continha a vulnerabilidade, modificar fuzzers para entender por que eles não encontraram a vulnerabilidade anteriormente etc. A maioria dos pesquisadores encontra mais de uma vulnerabilidade ao mesmo tempo. Ao encontrar e corrigir as variantes relacionadas, os invasores não podem simplesmente “plug and play” com uma nova vulnerabilidade depois que a original é corrigida.
- Análise de patches
Analisar o patch proposto (ou lançado) quanto à completude em comparação com a vulnerabilidade de causa raiz. Eu encorajo os fornecedores a compartilhar como eles planejam lidar com a vulnerabilidade com o relator de vulnerabilidades antecipadamente para que o relator possa analisar se o patch aborda de forma abrangente a causa raiz da vulnerabilidade, juntamente com a análise interna do próprio fornecedor.
- Análise da técnica de exploração
Entendendo a primitiva obtida com a vulnerabilidade e como ela está sendo usada. Embora geralmente seja padrão do setor corrigir vulnerabilidades, as técnicas de mitigação de exploração não acontecem com tanta frequência. Embora nem toda técnica de exploração sempre possa ser mitigada, a esperança é que ela se torne o padrão e não a exceção. As amostras de exploração precisarão ser compartilhadas mais prontamente para que fornecedores e pesquisadores de segurança possam realizar a análise da técnica de exploração.
O compartilhamento transparente dessas análises também ajuda o setor como um todo. Publicamos nossas análises neste repositório . Incentivamos os fornecedores e outros a publicarem os seus também. Isso permite que desenvolvedores e profissionais de segurança entendam melhor o que os invasores já sabem sobre esses bugs, o que, esperançosamente, leva a soluções e segurança geral ainda melhores.
Fonte: https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html
