emilc3978/cve-2022-37969pocTutorial do CVE-2022-37969 com foco na metodologia de exploração do Kernel, não nas causas internas da CVE
Isto foi feito para esclarecer aspetos gerais relacionados à exploração no Windows. Explica conceitos básicos aplicados ao CVE-2022-37969. O resultado final é um PoC funcional. Não esclarece todos os aspetos sobre o CVE, mas fornece pedaços de código reutilizáveis e explica mecanismos que podem ser encontrados em muitos exploits genéricos.
O utilizador-alvo seria um engenheiro reverso iniciante, um desenvolvedor de exploits que procura um código-fonte de prova de conceito funcional para testar e entender os conceitos básicos de Windows Internals. Fornece um ponto de referência para aprendizagem adicional.
Requisitos: Depuração básica do kernel, Engenharia Reversa básica, conceitos básicos de Windows Internals, habilidades de programação em c/c++
Um programa é um pedaço de código que está em execução numa máquina. Geralmente, um programa recebe dados (entrada), faz cálculos usando as entradas e gera dados (saída). A maioria dos programas são escritos por humanos e, portanto, têm bugs. Um bug é gerado por algum código-fonte que não foi escrito corretamente (o programador queria fazer algo com a entrada, o código resultante foi diferente do resultado pretendido). A maioria dos bugs é corrigida antes do lançamento do produto, mas alguns permanecem. Isto acontece porque existem diferentes tipos de bugs, alguns mais difíceis de detetar do que outros.
O Windows é um programa de computador, foi escrito por humanos e, portanto, tem bugs. Por que é importante? Porque os sistemas Windows podem executar programas que operam dados sensíveis, como contas bancárias, bases de dados de saúde e outros. Alguns bugs podem ser usados para ganhar acesso ilegal a dados restritos (este é um bom caso de uso para um exploit).
Existem vários tipos de bugs, alguns úteis, outros não. Geralmente, os bugs são gerados por entradas no programa que, em conjunto com as linhas de código que foram escritas incorretamente, geram um comportamento ou saída malformados. Encontrar essa entrada é trabalho do especialista em segurança (ou hacker). O próximo passo é avaliar o comportamento/saída malformada resultante e responder à pergunta: "Pode ser usado de forma útil?" É aqui que os bugs são classificados em diferentes categorias. Por exemplo, um bug pode gerar um comportamento que corrompe algumas estruturas de dados e faz com que o computador alvo reinicie. Sua utilidade é limitada. Um bug pode fazer com que a entrada seja escrita numa zona de memória que controla as permissões de acesso a ficheiros restritos. Este tipo de bug é mais útil.
Assim, a partir do conjunto de todos os bugs possíveis, o hacker procura o subconjunto mais útil para o seu propósito. De forma geral, o problema é: "Posso dar ao programa alvo uma entrada especialmente criada para que não quebre o sistema, mas possa elevar o meu nível de acesso e lucrar?"
Após esta introdução não técnica, o âmbito do tutorial pode ser formulado: Conseguimos encontrar um programa Windows que aceite uma entrada malformada e, como resultado de um código errado do desenvolvedor, possa elevar ilegalmente as nossas permissões de utilizador normal para administrador?
Programa alvo: Windows CLFS (Common Log File System Driver)
Nome do exploit: CVE-2022-37969
Tipo: Escalação de Privilégio Local
DOWNLOAD DO ISO VULNERÁVEL: Download Aqui
O espaço de endereçamento do Windows é aproximadamente dividido entre espaço do utilizador (execução de programas gerais) e espaço do kernel (execução do próprio sistema operativo e componentes de hardware – drivers). Um utilizador normal não deve aceder ao espaço do kernel, mas existem mecanismos pelos quais programas de utilizador normal podem aceder a partes do código do kernel (chamadas de sistema, procedimentos de driver). Por que precisamos de acesso? Para interagir com o SO de forma segura e controlada, conforme fornecido pelos designers do SO.
Alguns drivers usam entradas de dados fornecidas pelo utilizador para operar em estruturas de dados do espaço do kernel. Se a entrada gerar um bug, o kernel pode ser corrompido. Um caso é o Common Log File System Driver. Usando algumas entradas especiais, podemos forçar o driver a alterar estruturas de dados do kernel que detêm o nível de acesso de privilégio para o utilizador e sobrescrever utilizador normal com administrador.
O que precisa ser modificado para elevar o privilégio para administrador?
Começamos com o objetivo final em mente. O Windows armazena, dentro de uma estrutura de dados do kernel chamada _EPROCESS, informações para cada processo em execução no sistema. Exemplo de _Eprocess
Um campo importante é struct _EX_FAST_REF Token. Esta é outra estrutura de dados que aponta para dados que referenciam o nível de privilégio desse respetivo processo. Na imagem seguinte, o processo System tem um token de sistema e o processo Explorer tem um token de utilizador normal.
Assim, para elevar o privilégio do Explorer.exe, precisaríamos de copiar o valor do Token do _EPROCESS do System para o Token do _EPROCESS do Explorer. Iremos conseguir algo semelhante copiando o Token do System para o Token do nosso próprio programa e lançando um Command Prompt a partir do processo elevado (os processos filhos herdam o token do processo pai).
Para completar estas ações, precisamos de mecanismos para:
Introdução: A natureza do Windows ao longo dos anos: Com a descoberta de novas vulnerabilidades, o Windows precisou de patches para as mitigar. Além disso, com o surgimento de novas tecnologias, o Windows precisou de atualizações para se manter competitivo. Um requisito crucial era a retrocompatibilidade com versões anteriores. E, por vezes, a segurança era alcançada através da obscuridade. Estruturas de dados, definições de funções foram removidas dos manuais, mas a funcionalidade ainda permaneceu. Através de engenharia reversa, os investigadores conseguiram usar essas funcionalidades para vários fins.
Para encontrar o endereço do kernel do _EPROCESS, iremos usar uma função não documentada: NtQuerySystemInformation (Veja o link para parâmetros). Usando o parâmetro SystemInformationClass, podemos especificar que tipo de informação queremos obter. Iremos obter informações gerais de processo especificando o valor SystemExtendedHandleInformation (#define SystemExtendedHandleInformation 0x40).
Uma ressalva ao usar NtQuerySystemInformation é que não sabemos de antemão qual é o comprimento dos dados retornados, mas NtQuerySystemInformation tem um mecanismo que ajuda. Se for chamada com um array de tamanho errado para os dados necessários, retorna ERROR e o tamanho correto dos dados que deveriam ter sido solicitados. Isto pode ser usado para ler corretamente as Informações do Processo da seguinte forma:
NtQuerySystemInformation com um parâmetro SystemInformationLength dummyReturnLength retornadoNtQuerySystemInformation novamente com o valor correto de SystemInformationLength retornado anteriormente