Ensinando novos truques a um framework antigo: os perigos da automação de UI do Windows
Comentários editoriais e adicionais por Tricia Howard
Resumo executivo
O pesquisador de segurança da Akamai, Tomer Peled, explorou novas maneiras de usar e abusar do framework de automação de interface de usuário (UI Automation) da Microsoft e descobriu uma técnica de ataque que contorna a detecção de pontos de extremidade (EDR).
Para explorar essa técnica, o usuário precisa ser convencido a executar um programa que utilize a automação de interface de usuário. Isso pode levar à execução de comandos de forma furtiva, permitindo a coleta de dados sensíveis, redirecionamento de navegadores para sites de phishing e muito mais.
A detecção dessa técnica é desafiadora de várias maneiras, incluindo para EDR. Todas as tecnologias de EDR que testamos contra essa técnica não conseguiram identificar nenhuma atividade maliciosa.
Essa técnica pode ser usada em qualquer ponto de extremidade do Windows com sistema operacional XP ou superior.
Nesta publicação do blog, fornecemos um artigo completo sobre como (ab)usar do framework de automação de interface de usuário (incluindo possíveis ataques que poderiam aproveitá-lo) e apresentamos uma PoC (prova do conceito) para cada vetor de abuso discutido. Também oferecemos opções de detecção e redução.
Introdução
As pessoas que escrevem para ganhar a vida adoram softwares de ditado e de verificação gramatical. As pessoas que fazem pesquisa de segurança por profissão gostam de quebrar coisas e escrever sobre isso. Então, depois de meses vendo anúncios sobre esses assistentes de escrita, decidimos mexer um pouco e ver o que poderíamos encontrar.
Especificamente, queríamos entender como um aplicativo pode manipular a interface de outro aplicativo remotamente. O que descobrimos foi tão chocante quanto descobrir que ainda existem pessoas que usam o XP: é processado por um framework muito antigo chamado framework de automação de interface de usuário.
Esse framework foi criado nos tempos do Windows XP para ajudar pessoas com deficiência a usar o computador com mais facilidade. Ele recebeu permissões elevadas para ajudar em coisas como aumentar o texto, ler o texto em voz alta e até simular cliques (em algumas situações). Para isso, a automação de interface de usuário precisa de permissão para manipular quase qualquer elemento da interface presente na tela, o que faz sentido considerando o propósito pretendido: a tecnologia fará apenas o que foi autorizada a fazer.
Aqui começa nossa jornada de pesquisa para entender o impacto que os invasores podem causar ao abusar da automação de interface de usuário.
Descobrimos que invasores podem abusar da automação de interface de usuário para exfiltração de dados, manipular navegação na internet, executar comandos e até ler e escrever mensagens de aplicativos de chat como WhatsApp ou Slack. E tudo isso passou despercebido por todos os fornecedores de EDR que testamos.
Esta publicação de blog fornecerá tudo o que você precisa saber sobre esse framework, desde como ele funciona até como seus recursos podem ser abusados. Concluiremos com opções de detecção e mitigação para as equipes de defesa.
Interação com automação de UI de interface de usuário via Com
Para interagir com elementos de outros aplicativos, a UIA (framework de automação de interface de usuário) utiliza o COM (modelo de objetos componente) como seu mecanismo de IPC (comunicação interprocesso).
O COM é um framework projetado pela Microsoft para permitir que diferentes programas se comuniquem entre si, independentemente da linguagem em que foram escritos ou compilados. O framework COM permite que os desenvolvedores criem componentes chamados objetos COM. Esses objetos são registrados em um ponto de extremidade do Windows com seu nome, um identificador único universal (UUID) e um binário que contém sua lógica e outros valores configuráveis.
Para interagir com a UIA, os usuários criam seu objeto COM chamando a função "CoCreateInstance" com o UUID da classe CUIAutomation e o UUID da interface UIAutomation, como visto na tabela a seguir.
UUID da CUIAutomation |
ff48dba4-60ef-4201-aa87-54103eef594e |
UUID da Interface UIAutomation |
30cbe57d-d9d0-452a-ab13-7ac5ac4825ee |
Durante a criação do objeto COM, o sistema carregará o DLL especificado no registro, que neste caso é o "UIAutomationCore.dll".
Isso soa familiar para você? Os leitores mais atentos podem ter notado que isso soa semelhante à nossa análise extensa sobre MS-RPC. O uso do COM, já que o RPC serve como base, explicando essas semelhanças.
Automação de interface de usuário — Olá, Mundo
Antes de entrar em como os invasores podem abusar deste framework, talvez seja útil revisar como interagir com a UIA de forma geral (com C++). Isso fornecerá o contexto necessário para entender onde as coisas deram errado na implementação desse framework. Você pode revisar como interagir com a UIA em nosso GitHub.
Uma vez que o objeto da UIA é criado, seu DLL será carregado no aplicativo do usuário, bem como em todos os outros processos que possuam elementos de interface de usuário.
Nada mais ocorrerá até que adicionemos manipuladores de eventos para mudanças na interface do processo remoto. O exemplo abaixo mostra como configurar um manipulador para quaisquer mudanças na dica de ferramenta (tooltip) que está atualmente aberta para o usuário.
ppAutomation->AddAutomationEventHandler(UIA_ToolTipOpenedEventId, pTargetElement, TreeScope_Subtree, NULL, (IUIAutomationEventHandler*)whatsappEventHandler);
Uma vez feito isso, a UIA abrirá um "servidor" no processo remoto que se comunica com nossa aplicação (Figura 1). Os dados transferidos entre eles consistem nas informações sobre todos os elementos de interface do processo remoto.
Fig. 1: Carregamento da DLL UIA em todos os processos com elementos de UI
De acordo com a documentação da Microsoft, o seguinte protótipo de manipulador é o padrão esperado pela UIA:
HRESULT HandleAutomationEvent(
[in] IUIAutomationElement *sender,
[in] EVENTID eventId
);
Podemos identificar o aplicativo exato que foi trazido para a frente da interface de usuário (abrindo-o ou por qualquer outro meio) invocando a função "sender.get_CurrentName" dentro do manipulador. Agora que podemos identificar qual aplicativo está em foco, podemos tentar ler/escrever nele.
Para isso, precisamos encontrar um elemento que desejamos ler/escrever, iterando por todos os elementos (que são descendentes do elemento sender ) e, em seguida, ou ler o valor da UI, alterar o valor do texto ou recuperar o elemento invocável e chamar sua função "Invoke" (Figura 2).
Fig. 2: O processo de encontrar e manipular um elemento em alto nível
Abusando da automação de UI para atividades maliciosas
Na seção anterior, discutimos como abusar da UIA. Agora, vamos abordar as possíveis atividades maliciosas proporcionadas pelo abuso dessa tecnologia. A melhor forma de ilustrar essas atividades é por meio de exemplos. Temos três principais:
- Leitura e escrita de mensagens
- Roubo de dados sensíveis
- Execução de comandos
Leitura e escrita de mensagens
Todo aplicativo de mensagens possui uma interface gráfica (GUI) que contém diferentes tipos de elementos de UI que podemos acessar usando a UIA. A Figura 3 é um exemplo da interface gráfica do Slack, que provavelmente é familiar para você.
Fig 3: Como o Slack geralmente se apresenta
As ações disponíveis dentro de uma GUI vão desde selecionar conversas (que são implementadas como botões nos bastidores) até ler mensagens (blocos de texto), oferecendo uma grande variedade de interações possíveis.
Uma vez que um invasor consiga "conectar-se" à janela de UI de um aplicativo, ele pode simular um clique na conversa desejada (por meio do elemento de botão da UI) e entrar nele. A partir daí, o invasor pode escolher entre ler a conversa e exfiltrar os dados ou localizar o elemento de UI responsável por escrever uma mensagem, alterar o valor do texto no campo de entrada (elemento TextArea) e simular um clique no botão de envio.
Claro, esse tipo de manipulação também seria refletido na tela, deixando muito a cargo da sorte do invasor. Uma abordagem mais discreta seria ler apenas da conversa atualmente aberta e coletar dados ao longo de um período mais longo (Figura 4).
Fig. 4: Lendo mensagens do Slack
Outra opção para manter a furtividade sem adotar uma abordagem passiva é usar o mecanismo de cache da UIA. Além dos elementos de UI atualmente exibidos na tela com os quais podemos interagir, mais elementos são carregados antecipadamente e colocados em cache. Podemos também interagir com esses elementos, como ler mensagens que não estão visíveis na tela, ou até mesmo definir o texto em uma caixa de entrada e enviar mensagens sem que isso seja refletido na tela.
Embora não tenhamos conseguido verificar isso antes de este post ser publicado, o mecanismo de cache pode também nos permitir interagir com esses elementos enquanto o computador estiver bloqueado, o que nos permitiria realizar interações sem ser detectado pelo usuário.
Roubo de dados sensíveis
Uma das maneiras mais prejudiciais que pensamos de (ab)usar da UIA é roubar informações de cartões de crédito.
Após um usuário acessar um comerciante on-line, um invasor pode programaticamente escutar mudanças nos elementos da interface do usuário configurando um manipulador. Uma vez que a alteração tenha sido feita (isto é, as informações do cartão de crédito foram inseridas), o invasor pode recuperar o texto dos elementos de UI para exfiltração posterior (Figura 5).
Fig. 5: Coleta de informações de cartão de crédito do navegador
Execução de comandos
Outro caminho comum de ataque em navegadores é via phishing e redirecionamentos de navegador.
Filtrando as janelas da interface do usuário do Firefox/Chrome/Edge, os invasores podem simplesmente procurar pela barra de pesquisa Elemento da interface do usuário e definir seu valor para o que desejam e simular um clique (Figura 6). Para tornar isso mais furtivo, eles podem esperar pelo momento em que a página da Web exibida seja atualizada ou alterada, de modo que a mudança para um site diferente seja menos perceptível.
Isso permitiria que os invasores redirecionassem os usuários para sites maliciosos sob seu controle. A partir daí, as possibilidades são efetivamente infinitas: exploração do navegador (por exemplo, usando o Browser Exploitation Framework [BeEF]), ataques "drive-by", mascaramento de sites legítimos para phishing ou coleta de credenciais e muito mais.
![Isso permitiria que os invasores redirecionassem os usuários para sites maliciosos sob seu controle. A partir daí, as possibilidades são efetivamente infinitas: exploração de navegador (por exemplo, usando o Browser Exploitation Framework [BeEF]), ataques "drive-by", mascaramento de sites legítimos para phishing ou coleta de credenciais, e mais.](/site/pt/images/blog/2024/2024-december-windows-ui-automation-attack-technique-evades-edr-six.gif)
Fig. 6: Redirecionando o usuário para BeEF
Impacto potencial da automação de UI
Os ataques que discutimos nas seções anteriores existem há décadas, com implementações diferentes, e a maioria das ferramentas de defesa sabe como detectá-los e responder a eles.
No entanto, tudo o que discutimos acima é considerado um recurso automação de UI (UIA). Isso remonta ao propósito original da aplicação: Esses níveis de permissão precisam existir para que a o aplicativo funcione corretamente. É por isso que a UIA é capaz de contornar o Defender — o aplicativo não encontra nada de anormal. De fato, nenhum EDR que testamos conseguiu identificar essas ações como maliciosas — provavelmente pela mesma razão. Se algo é visto como um recurso e não um erro, a lógica do sistema seguirá o comportamento do recurso.
Isso torna esse framework potencialmente muito lucrativo para invasores, e é por isso que acreditamos que uma maior conscientização é fundamental para lidar com esse vetor de ataque.
Mais pesquisas
UIA sobre DCOM
O DCOM (COM distribuído) é uma maneira de chamar objetos COM remotamente entre máquinas. Teoricamente, deveria ser possível acessar remotamente a UIA (Automação de IU) por meio do DCOM, permitindo que todos os ataques discutidos sejam executados sem a necessidade de phishing ou acesso local.
Como parte de nossa análise, percebemos que o objeto COM da UIA não está configurado para permitir o DCOM por padrão. Isso diminui significativamente o potencial de ataque, exceto em caso de configuração incorreta.
Embora a UIA em si não esteja disponível via DCOM, encontramos algo relacionado:o objeto COM/DCOM UIAutomationCrossBitnessHook. Este objeto não requer privilégios para ativação e execução remota.
Ao reverter seu DLL, descobrimos que sua interface contém duas funções: uma para definir o gerenciador de UI e outra para desfazê-lo. Parece que ele não possui outra funcionalidade remota, então não conseguimos usá-lo para ler ou escrever dados, mas poderia ser um bom alvo de pesquisa no futuro.
Pipes nomeados pela UIA
Anteriormente no post, mencionamos que a UIA abre um "servidor" em um processo remoto. Nos bastidores, esses servidores e clientes são implementados usando pipes nomeados. A convenção de nomenclatura consiste na string constante UIA_PIPE seguida do ID do processo e algum outro identificador (Figura 7).
Fig. 7: Pipes nomeados da IU dentro do aplicativo do invasor
Agora, é aqui que as coisas ficam assustadoras: Pipes nomeados podem aceitar conexões remotas. Isso é muito perigoso neste caso, porque significa que um invasor poderia manipular elementos da interface de usuário pela rede. No entanto, quando tentamos nos conectar a partir de um servidor remoto, encontramos um erro ACCESS_DENIED .
Isso ocorre porque a Microsoft configurou a bandeira PIPE_REJECT_REMOTE_CLIENTS ao criar o pipe nomeado. Isso significa que não podemos acessar a UIA remotamente por meio desses pipes, mas eles ainda estão disponíveis localmente. É possível enumerar esses pipes (sem adivinhar o ID do processo ou o identificador) e acessá-los, o que pode abrir caminho para algum tipo de elevação de privilégios ou ataques de personificação, embora isso não tenha sido parte dessa análise.
Detecção/mitigação
A Microsoft reconheceu que esse framework não deve interagir com aplicativos de maior privilégio. Portanto, por padrão, os aplicativos que utilizam o framework UI Automation são executados com nível de confiança médio e não têm permissão para acessar processos com privilégios mais elevados. Isso pode ser contornado usando um aplicativo assinado com um arquivo de manifesto contendo a chave requestedExecutionLevel.uiAccess configurada como true:
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
quanto à detecção, os administradores podem monitorar o uso do arquivo UIAutomationCore.dll. Se for carregado em um processo previamente desconhecido, isso deve levantar uma preocupação legítima.
Da mesma forma, administradores de rede podem monitorar os pipes nomeados que são abertos no ponto de extremidade pela UIA, como outro indicador de seu uso, o que pode ser feito utilizando as seguintes consultas do osquery:
SELECT DISTINCT pid, name, proc.path FROM process_memory_map AS pmm JOIN processes AS proc USING(pid) WHERE pmm.path LIKE '%uiautomationcore.dll'
Processos que carregam UIAutomationCore.dll
WITH uia_pipes AS (SELECT name AS pipe_name, SUBSTR(name, 10, INSTR(SUBSTR(name, 10), '_')-1) AS pid FROM pipes WHERE name LIKE 'UIA_PIPE_%' ) SELECT DISTINCT pid, name AS process_name, path, pipe_name FROM uia_pipes JOIN processes USING(pid)
Processos que abriram o pipe nomeado UI Automation
Conclusão
Esta análise é um exemplo infeliz de como uma tecnologia criada para o bem pode ser sequestrada para fins maliciosos. Embora o framework UI Automation possa ser útil para pessoas com deficiência, ele também oferece oportunidades para invasores simularem spyware.
Embora a exploração da UIA possa ser mais difícil do que outros ataques, o fato de que os EDR não conseguem detectá-lo pode tornar a UIA uma superfície de ataque altamente atraente. Na tentativa de reduzir sua atratividade para os agentes de ameaças, a Microsoft impôs algumas restrições à UIA, mas os invasores ainda podem se aproveitar dele com a quantidade certa de habilidade. Nosso objetivo é que esta publicação do blog ajude a aumentar a conscientização sobre essa técnica de ataque e ajude os equipes de defesa a se protegerem contra esse vetor de ataque.
