Sí se puede enseñar a un marco viejo trucos nuevos: Los peligros de la automatización de la interfaz de usuario de Windows
Comentario editorial y adicional de Tricia Howard
Resumen ejecutivo
Tomer Peled, investigador de seguridad de Akamai, exploró nuevas formas de utilizar el marco de automatización de la interfaz de usuario de Microsoft y hacer un uso indebido del mismo, y descubrió una técnica de ataque que elude la detección y respuesta de terminales (EDR).
Para sacar el máximo provecho de esta técnica, hay que persuadir a un usuario para que ejecute un programa que utilice la automatización de la interfaz de usuario. Esto puede dar lugar a una ejecución de comandos sigilosa que permite recopilar datos confidenciales, redirigir los navegadores a sitios web de phishing y mucho más.
La detección de esta técnica presenta desafíos en varios aspectos, también para la EDR. Ninguna de las tecnologías de EDR que hemos probado con esta técnica pudieron detectar algún tipo de actividad maliciosa.
Esta técnica se puede utilizar en todos los terminales de Windows con el sistema operativo XP y superior.
En esta entrada del blog, ofrecemos un informe completo sobre cómo usar el marco de automatización de la interfaz de usuario y hacer un uso indebido del mismo (incluidos los posibles ataques que podrían aprovecharlo), y presentamos una prueba de concepto (PoC) para cada vector de abuso que analizamos. También ofrecemos opciones de detección y mitigación.
Introducción
A los que escribimos para ganarnos la vida nos encanta el dictado y el software de corrección gramatical. A los que realizamos investigaciones sobre seguridad para ganarnos la vida nos encanta romper cosas y escribir sobre ello. Así que, después de estar meses viendo anuncios para estos asistentes de escritura, decidimos experimentar un poco y ver lo que podíamos encontrar.
En concreto, queríamos comprender cómo una aplicación puede manipular de forma remota la interfaz de usuario (IU) de otra aplicación. Lo que descubrimos fue sorprendente, tanto como el hecho de descubrir que la gente todavía utiliza XP: se procesa mediante un marco muy antiguo denominado marco de automatización de la interfaz de usuario.
Este marco fue concebido en los días de Windows XP como una manera de ayudar a las personas con discapacidad a usar el ordenador de forma más fácil. Se le proporcionaron permisos elevados para ayudar con determinadas cosas, como agrandar el texto, leer el texto en voz alta e incluso simular clics (en algunas situaciones). Para ello, la automatización de la interfaz de usuario necesita permiso para manipular casi cualquier elemento de la IU que esté presente en la pantalla, lo cual tiene sentido si tenemos en cuenta el propósito previsto: la tecnología solo hará lo que se le dice que puede y no puede hacer.
Aquí es donde comenzamos nuestro proceso de investigación para averiguar el impacto que pueden tener los atacantes si hacen un uso indebido de la automatización de la interfaz de usuario.
Descubrimos que los atacantes pueden hacer un uso indebido de la automatización de la interfaz de usuario para exfiltrar datos, manipular la navegación por Internet, ejecutar comandos e incluso leer y escribir mensajes () desde aplicaciones de chat como WhatsApp o Slack. Y ninguno los proveedores de EDR que probamos pudo detectar nada de esto.
Esta entrada del blog le proporcionará todo lo que necesita saber sobre este marco, desde cómo funciona hasta cómo se puede hacer un uso indebido de sus funciones. Concluiremos con las opciones de detección y mitigación disponibles para los miembros del equipo azul.
Interacción con la automatización de la interfaz de usuario a través del marco COM
Para interactuar con elementos de otras aplicaciones, el marco de automatización de la interfaz de usuario (UIA) aprovecha el Modelo de objetos componentes (COM) como mecanismo de comunicación entre procesos (IPC).
COM es un marco diseñado por Microsoft para permitir que diferentes programas se comuniquen entre sí independientemente del lenguaje en el que estén escritos o compilados. El marco COM permite a los desarrolladores crear componentes denominados objetos COM. Estos objetos se registran en un terminal de Windows con su nombre, un identificador único universal (UUID) y un binario que contiene su lógica y otros valores configurables.
Para interactuar con la UIA, los usuarios crean su objeto COM llamando a la función "CoCreateInstance" con el UUID de la clase CUIAutomation y el UUID de la interfaz de UIAutomation, como se muestra en la tabla.
UUID de CUIAutomation |
ff48dba4-60ef-4201-aa87-54103eef594e |
UUID de la interfaz de UIAutomation |
30cbe57d-d9d0-452a-ab13-7ac5ac4825ee |
Durante la creación del objeto COM, el sistema cargará el archivo DLL especificado en el registro, que en este caso es "UIAutomationCore.dll".
¿Le suena familiar algo de esto? Puede que el lector con vista de lince se haya dado cuenta de que todo esto suena similar a nuestro exhaustivo examen de MS-RPC. El objeto COM utiliza RPC como base, de ahí sus similitudes.
Automatización de la interfaz de usuario: "Hello World"
Antes de entrar a explicar la forma en que los atacantes podrían hacer un uso indebido de este marco, es posible que desee revisar cómo interactuar con la UIA en general (con C++). Esto le proporcionará la información que necesita para ver dónde se han torcido las cosas con la implementación de este marco. Puede revisar cómo se puede interactuar con la UIA en nuestro GitHub.
Una vez creado el objeto de la UIA, su DLL se cargará en la aplicación del usuario, así como cualquier otro proceso que tenga cualquier elemento de la IU.
No ocurrirá nada más hasta que añadamos controladores de eventos para los cambios de la IU del proceso remoto. El ejemplo siguiente muestra cómo configurar un controlador para cualquier cambio en la información sobre herramientas que actualmente está abierta para un usuario.
ppAutomation->AddAutomationEventHandler(UIA_ToolTipOpenedEventId, pTargetElement, TreeScope_Subtree, NULL, (IUIAutomationEventHandler*)whatsappEventHandler);
Una vez hecho esto, la UIA abrirá un "servidor" en el proceso remoto que se comunica con nuestra aplicación (Figura 1). Los datos que se transfieren entre ellos es la información sobre todos los elementos de la IU del proceso remoto.
Fig. 1: El archivo DLL de la UIA cargándose en todos los procesos con elementos de la IU
Según la documentación de Microsoft, el siguiente prototipo de controlador es el controlador estándar que espera la UIA:
HRESULT HandleAutomationEvent(
[in] IUIAutomationElement *sender,
[in] EVENTID eventId
);
Podemos identificar la aplicación exacta que se trajo al frente de la IU (abriéndola o por cualquier otro medio) mediante la invocación de la función "sender.get_CurrentName" desde el interior del controlador. Ahora que podemos identificar qué aplicación está en el foco de atención, podemos intentar leer/escribir en ella.
Para ello, necesitamos encontrar un elemento del que queremos leer/escribir mediante la iteración a través de todos los elementos (que son descendientes del elemento sender ) y leer su valor de IU, cambiar su valor de texto o recuperar su elemento invocable y llamar a su función "Invoke" (Figura 2).
Fig. 2: El proceso de encontrar y manipular un elemento en un nivel alto
Uso indebido de la automatización de la interfaz de usuario para actividades maliciosas
En la última sección hemos hablado sobre cómo hacer un uso indebido de la UIA, y ahora vamos a hablar de las posibles actividades maliciosas que el uso indebido permite. La mejor manera de mostrarlas es a través de ejemplos, y tenemos tres:
- Lectura y escritura de mensajes
- Robo de datos confidenciales
- Ejecución de comandos
Lectura y escritura de mensajes
Cada aplicación de mensajería tiene una interfaz gráfica de usuario (GUI) que contiene diferentes tipos de elementos de la IU a los que podemos acceder mediante la UIA. La Figura 3 es un ejemplo de la GUI de Slack, que probablemente le resulte familiar.
Fig. 3: El aspecto típico de Slack
Las acciones disponibles en una GUI abarcan desde la selección de conversaciones (que se implementan como botones en segundo plano) hasta la lectura de mensajes (bloques de texto), por lo que tenemos una enorme cantidad de cosas con las que podemos interactuar.
Una vez que un atacante es capaz de "conectarse" a la ventana de la IU de dicha aplicación, puede simular un clic en la conversación que desea (a través del elemento del botón de la IU) e introducirse en ella. Desde ahí, pueden elegir entre leer la conversación y exfiltrar los datos, o buscar el elemento de la IU responsable de escribir un mensaje, cambiar el valor del texto en su elemento TextArea y simular un clic en el botón de envío.
Por supuesto, este tipo de manipulación también se reflejaría en la pantalla, dejando mucho al azar por parte del atacante. Un enfoque más sigiloso sería el de solo lectura de la conversación abierta actualmente y la recopilación de datos durante un periodo más largo (Figura 4).
Fig. 4: Lectura de mensajes de Slack
Otra opción para mantener el sigilo sin adoptar un enfoque pasivo es utilizar el mecanismo de almacenamiento en caché de la UIA. Además de los elementos de la IU que se muestran actualmente en la pantalla y con los que podemos interactuar, se cargan más elementos por adelantado y se colocan en una caché. También podemos interactuar con esos elementos, como leer mensajes que no se muestran en la pantalla, o incluso configurar el cuadro de texto y enviar mensajes sin que se refleje en la pantalla.
Aunque no pudimos verificarlo antes de que esta entrada del blog se publicara, el mecanismo de almacenamiento en caché también podría permitirnos interactuar con esos elementos mientras el ordenador está bloqueado, permitiéndonos ampliar nuestras interacciones y permanecer completamente en el anonimato para el usuario.
Robo de datos confidenciales
Una de las maneras más perjudiciales que se nos ocurrió de usar la UIA (y usarla de forma indebida) era para robar la información de tarjetas de crédito.
Después de que un usuario entre en una tienda online, un atacante puede escuchar mediante programación los cambios en los elementos de la IU mediante la configuración de un controlador. Una vez que se ha realizado un cambio (es decir, cuando se ha introducido la información de la tarjeta de crédito), el atacante puede recuperar el texto de los elementos de la IU para su exfiltración posterior (Figura 5).
Fig. 5: Recopilación de información de la tarjeta de crédito desde el navegador
Ejecución de comandos
Otra forma común de atacar a los navegadores es a través del phishing y las redirecciones del navegador.
Filtrando las ventanas de la IU de Firefox/Chrome/Edge , los atacantes pueden simplemente buscar el elemento de la IU de su barra de búsqueda , establecer su valor en el que deseen y simular un clic (Figura 6). Para hacerlo de forma más sigilosa, pueden esperar al momento en que la página web que se muestra actualmente se actualice o cambie, de modo que la transferencia a un sitio web diferente sea menos perceptible.
Esto permitiría a los atacantes redirigir a los usuarios a sitios maliciosos que están bajo su control. Desde allí, las posibilidades son efectivamente infinitas: explotación del navegador (por ejemplo, mediante el uso de Browser Exploitation Framework [BeEF]), ataques de descarga involuntaria, enmascaramiento de sitios como legítimos para phishing o recopilación de credenciales, y mucho más.
![Esto permitiría a los atacantes redirigir a los usuarios a sitios maliciosos que están bajo su control. A partir de ahí, las posibilidades son infinitas: explotación del navegador (por ejemplo, mediante el uso de Browser Exploitation Framework [BeEF]), ataques de descarga involuntaria, enmascaramiento de sitios como legítimos para phishing o recopilación de credenciales, y mucho más.](/site/es/images/blog/2024/2024-december-windows-ui-automation-attack-technique-evades-edr-six.gif)
Fig. 6: Redirección de un usuario a BeEF
Posible impacto de la automatización de la interfaz de usuario
Los ataques que hemos mencionado en las secciones anteriores han existido durante décadas con diferentes implementaciones, y la mayoría de las herramientas de defensa saben cómo detectarlos y responder ante ellos.
Sin embargo, todo lo que hemos comentado anteriormente se considera una función de la automatización de la interfaz de usuario. Esto se remonta al propósito previsto de la aplicación: estos niveles de permisos tienen que existir para poder utilizarlos. Este es el motivo por el que la UIA puede eludir Defender: la aplicación no encuentra nada fuera de lo común. De hecho, ninguna de las tecnologías de EDR que probamos pudo detectar estas acciones como maliciosas, probablemente por el mismo motivo. Si algo tiene el aspecto de una función en lugar de un error, la lógica del ordenador decidirá que se trata de una función.
Esto hace que este marco sea potencialmente muy lucrativo para los atacantes, y por eso creemos que una mayor concienciación es clave para lidiar con este vector de ataque.
Investigación adicional
UIA a través de DCOM
El objeto COM distribuido (DCOM) es una forma de llamar a objetos COM de forma remota entre ordenadores. En teoría, debería ser posible acceder de forma remota a la UIA a través de DCOM, permitiendo así que todos los ataques que hemos comentado se ejecuten sin el requisito de phishing/acceso local.
Como parte de nuestro análisis, nos dimos cuenta de que el objeto COM de la UIA no está configurado para permitir el objeto DCOM de forma predeterminada. Esto reduce significativamente el potencial de ataque, evitando los errores de configuración.
Aunque la UIA en sí misma no está disponible a través de DCOM, encontramos algo relacionado: el objeto COM/DCOMUIAutomationCrossBitnessHook . Este objeto no requiere un privilegio para la activación y ejecución remotas.
Al invertir su DLL, encontramos que su interfaz contiene dos funciones: una para establecer el administrador de la IU y la otra para anular su establecimiento. Parece que no tiene ninguna otra funcionalidad remota, por lo que no podríamos utilizarla para leer o escribir datos, pero podría ser un buen objetivo de investigación para el futuro.
Canales con nombres asignados por la UIA
Anteriormente en la publicación hemos mencionado que la UIA abre un "servidor" en un proceso remoto. Entre bastidores, estos servidores y clientes se implementan mediante canales con nombre. La convención de nomenclatura consta de la cadena constante UIA_PIPE seguida del ID del proceso y algún otro identificador (Figura 7).
Fig. 7: Canales con nombre de la IU dentro de la aplicación del atacante
Aquí es donde la cosa se pone realmente aterradora: los canales con nombre pueden aceptar conexiones remotas. Esto es muy peligroso en este caso porque significa que un atacante podría manipular elementos de la IU a través de la red. Sin embargo, cuando intentamos conectarnos desde un servidor remoto, nos encontramos con un error de tipo ACCESS_DENIED .
Esto se debe a que Microsoft ha establecido el indicador PIPE_REJECT_REMOTE_CLIENTS al crear el canal con nombre. Esto significa que no podemos acceder a la UIA de forma remota a través de esos canales, pero siguen estando disponibles localmente. Es posible enumerar esos canales (sin adivinar el ID del proceso o el identificador) y acceder a ellos, lo que podría allanar el camino para algún tipo de ataque de elevación de privilegios o suplantación, aunque eso no formaba parte de este análisis.
Detección y mitigación
Microsoft reconoció que este marco no debería interactuar con aplicaciones con mayores privilegios. Por lo tanto, de forma predeterminada, las aplicaciones que utilizan el marco de automatización de la interfaz de usuario se ejecutan en un nivel de confianza medio y no tienen permiso para acceder a procesos con mayores privilegios. Esto se puede omitir mediante una aplicación firmada con un archivo de manifiesto que contenga la clave requestedExecutionLevel.uiAccess establecida en true (verdadero):
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
En cuanto a la detección, los administradores pueden supervisar el uso de UIAutomationCore.dll. Si se carga a un proceso previamente desconocido, debería generar una preocupación legítima.
De forma similar, los administradores de red pueden supervisar los canales con nombre que la UIA abre en un terminal, como otro indicador de su uso, lo que puede hacer mediante las siguientes osqueries:
SELECT DISTINCT pid, name, proc.path FROM process_memory_map AS pmm JOIN processes AS proc USING(pid) WHERE pmm.path LIKE '%uiautomationcore.dll'
Procesos que cargan 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)
Procesos que abrieron el canal con nombre de la automatización de la interfaz de usuario
Conclusión
Este análisis es un desafortunado ejemplo de cómo la tecnología creada para el bien puede secuestrarse con fines maliciosos. Aunque el marco de automatización de la interfaz de usuario puede ser útil para personas con discapacidad, también ofrece oportunidades para que los atacantes imiten el spyware.
Aunque la vulneración de la UIA puede ser más difícil que otros ataques, el hecho de que la EDR no pueda detectarla puede hacer de la UIA una superficie de ataque muy atractiva. En un esfuerzo por reducir su atractivo para los atacantes, Microsoft ha impuesto algunas restricciones a la UIA, pero los atacantes aún pueden aprovecharla con las habilidades adecuadas. Nuestra esperanza es que esta entrada del blog aumente la concienciación con respecto a esta técnica de ataque y ayude a los equipos azules a defenderse de este vector de ataque.
