Insegnare nuovi trucchi ad un vecchio sistema: i pericoli di Windows UI Automation
Editoriale e commenti aggiuntivi di Tricia Howard
Analisi riassuntiva
Tomer Peled, ricercatore della sicurezza di Akamai, ha scoperto nuovi modi per usare e abusare del sistema di UI Automation di Microsoft e ha rilevato una tecnica di attacco in grado di eludere il rilevamento e la risposta degli endpoint (EDR).
Per sfruttare questa tecnica, è necessario convincere un utente ad eseguire un programma che utilizza UI Automation, il che può condurre all'esecuzione di codice nascosto allo scopo di esfiltrare dati sensibili, rendirizzare i browser ai siti di phishing e molto altro.
Il rilevamento di questa tecnica è complesso in molti casi, inclusa la funzione EDR. Tutte le tecnologie EDR che abbiamo sottoposto a test sulla base di questa tecnica non sono riuscite ad individuare attività dannose.
Questa tecnica può essere utilizzata su tutti gli endpoint di Windows con sistema operativo XP e versioni successive..
In questo blog, viene fornito un articolo completo su come (ab)usare del sistema di UI Automation (inclusi i possibili attacchi che potrebbero sfruttarlo) e viene presentata una PoC (Proof-of-Concept) per ciascun vettore di attacco che abbiamo esaminato. Inoltre, vengono fornite le opzioni di rilevamento e mitigazione disponibili.
Introduzione
Chi scrive per vivere ama i software di dettatura e controllo grammaticale. Chi fa ricerche sulla sicurezza per vivere ama rompere le cose e scrivere su cosa ha scoperto. Quindi, dopo aver visto per mesi annunci sugli assistenti di scrittura, abbiamo deciso di guardarci intorno e vedere cosa riuscivamo a trovare.
Nello specifico, volevamo capire come un'applicazione riesca a manipolare l'interfaccia utente di un'altra applicazione da remoto. Quello che abbiamo scoperto ci ha lasciato esterrefatti come sapere che ci sono ancora persone che usano XP: l'elaborazione viene eseguita da un sistema obsoleto denominato UI Automation.
Questo sistema è stato progettato ai tempi di Windows XP per aiutare le persone con disabilità ad utilizzare il computer più facilmente, consentendo di eseguire operazioni come ingrandire il testo, leggere il testo ad alta voce e, persino, simulare i clic (in alcuni casi). Per effettuare queste operazioni, UI Automation ha bisogno di ottenere i permessi per manipolare gli elementi dell'interfaccia utente visualizzati sullo schermo, il che rende comprensibile considerare lo scopo prefissato: la tecnologia farà solo ciò per cui è stata o meno progettata.
Il nostro percorso di ricerca è partito da questo punto per cercare di capire l'impatto esercitato dai criminali in caso di abuso di UI Automation.
Abbiamo scoperto che i criminali possono abusare di UI Automation per esfiltrare dati, manipolare la navigazione in Internet, eseguire comandi e, persino, leggere e scrivere messaggi da applicazioni di chat come WhatsApp o Slack, il tutto eludendo il rilevamento effettuato da tutti i vendor di soluzioni EDR che abbiamo esaminato.
Questo blog si propone di fornirvi informazioni su tutto ciò che dovete sapere su questo sistema, dal suo funzionamento al modo con cui è possibile sfruttare le sue funzioni. In conclusione, vengono fornite informazioni sul rilevamento e sulla mitigazione per i team addetti alla sicurezza.
Interazione con UI Automation tramite COM
Per interagire con elementi presenti in altre applicazioni, il sistema UI Automation (UIA) sfrutta il modello COM (Component Object Model) come una forma di comunicazione interprocesso (IPC).
Il modello COM è un sistema progettato da Microsoft per consentire a diversi programmi di comunicare tra loro Indipendentemente dal linguaggio in cui sono stati scritti o compilati. Il sistema COM consente agli sviluppatori di creare componenti denominati oggetti COM, che sono registrati su un endpoint di Windows con un proprio nome, un identificatore univoco universale (UUID) e un file binario che contiene la sua logica e altri valori configurabili.
Per interagire con UIA, è possibile creare i relativi oggetti COM richiamando la funzioneCoCreateInstance" con l'UUID della classe CUIAutomation e l'UUID dell'interfaccia UIAutomation, come illustrato nella tabella.
UUID della classe CUIAutomation |
ff48dba4-60ef-4201-aa87-54103eef594e |
UUID dell'interfaccia UIAutomation |
30cbe57d-d9d0-452a-ab13-7ac5ac4825ee |
Durante la creazione dell'oggetto COM, il sistema carica il file DLL specificato nel Registro di sistema, che, in questo caso, è denominato "UIAutomationCore.dll".
Tutto ciò vi suona familiare? Un lettore attento avrà notato che quanto sopra riportato è simile alla nostra discussione su MS-RPC. L'oggetto COM utilizza l'RPC come base, ecco perché si tratta di una situazione simile.
UI Automation - Hello World
Prima di passare al modo con cui i criminali abusano di questo sistema, vi consigliamo di esaminare come interagire con UIA in generale (con C++). In tal modo, potrete disporre delle conoscenze necessarie per capire quali sono le aree in cui l'implementazione di questo sistema ha creato problemi. Potete esaminare come interagire con UIA nel nostro GitHub.
Una volta creato l'oggetto UIA, il relativo file DLL viene caricato nell'applicazione dell'utente, insieme a tutti gli altri processi contenenti elementi dell'interfaccia utente.
Non si verificherà nient'altro finché non si aggiungono gli handler dell'evento per le modifiche apportate all'interfaccia utente del processo remoto. Nell'esempio riportato di seguito, viene illustrato come configurare un handler per le modifiche apportate nella descrizione comando attualmente aperta per un utente.
ppAutomation->AddAutomationEventHandler(UIA_ToolTipOpenedEventId, pTargetElement, TreeScope_Subtree, NULL, (IUIAutomationEventHandler*)whatsappEventHandler);
Una volta effettuata questa operazione, UIA aprirà un "server" sul processo remoto che comunica con la nostra applicazione (Figura 1). I dati trasferiti tra queste posizioni sono informazioni relative a tutti gli elementi dell'interfaccia utente del processo remoto.
Figura 1. Caricamento del file UIA.dll in tutti i processi con elementi dell'interfaccia utente
In base alla documentazione di Microsoft, l'handler riportato di seguito è il prototipo standard che UIA si aspetta:
HRESULT HandleAutomationEvent(
[in] IUIAutomationElement *sender,
[in] EVENTID eventId
);
Possiamo identificare quale applicazione viene visualizzata sull'interfaccia utente (tramite apertura o con altri metodi) richiamando la funzione "sender.get_CurrentName" dall'interno dell'handler. Ora possiamo individuare l'applicazione visualizzata provando ad effettuare un'operazione di lettura/scrittura su di essa.
Per effettuare questa operazione, dobbiamo trovare un elemento da cui leggere/scrivere iterando tramite tutti gli elementi (che discendono dall'elemento che ha eseguito l'invio) e leggendo il valore della loro interfaccia utente, cambiando il loro valore del testo o recuperando il loro elemento richiamabile e richiamando la sua funzione "Richiama" (Figura 2).
Figura 2. Processo di individuazione e manipolazione di un elemento ad un livello elevato
Abuso di UI per scopi dannosi
Nella sezione precedente, abbiamo descritto in che modo è possibile abusare di UIA. Ora parleremo delle possibili attività eseguite a scopi dannosi dopo l'abuso. Il modo migliore per descrivere queste attività è usare alcuni esempi. Nello specifico, riportiamo di seguito tre esempi:
- Lettura e scrittura di messaggi
- Furto di dati sensibili
- Esecuzione di comandi
Lettura e scrittura di messaggi
Ogni applicazione di messaggistica presenta un'interfaccia utente grafica (GUI), che contiene diversi tipi di elementi dell'interfaccia utente a cui è possibile accedere tramite UIA. Nella Figura 3 è illustrato un esempio della GUI di Slack, che dovreste trovare familiare.
Figura 3. Funzionamento tipico di Slack
Le azioni disponibili di una GUI variano dalla selezione di conversazioni (implementate come pulsanti in background) alla lettura di messaggi (blocchi di testo), quindi possiamo scegliere tra tanti elementi con cui interagire.
Dopo essersi "connesso" alla finestra dell'interfaccia utente di un'applicazione di questo tipo, un criminale può simulare un clic sulla conversazione desiderata (tramite il pulsante dell'interfaccia utente) e accedervi. A questo punto, il criminale può leggere la conversazione ed esfiltrare i dati desiderati e/o individuare l'elemento dell'interfaccia utente responsabile della scrittura dei messaggi, modificare il valore del testo nel relativo elemento TextArea e simulare un clic sul pulsante di invio.
Ovviamente, questo tipo di manipolazione si riflette anche sullo schermo, lasciando al criminale varie possibilità. Un approccio più insidioso consiste nell'accedere in modalità di sola lettura da una conversazione attualmente aperta e raccogliere i dati per un periodo più lungo (Figura 4).
Figura 4. Lettura dei messaggi da Slack
Un'altra opzione per mantenere la modalità invisibile senza adottare un approccio passivo consiste nell'utilizzare il meccanismo di caching di UIA. Oltre agli elementi dell'interfaccia utente attualmente visualizzati sullo schermo con cui è possibile interagire, vengono caricati altri elementi preventivamente e memorizzati in una cache. È possibile anche interagire con questi elementi, ad es. per leggere i messaggi non visualizzati sullo schermo, o, persino, impostare la casella di testo e inviare i messaggi senza far visualizzare nulla sullo schermo.
Anche se non l'abbiamo potuto verificare prima della pubblicazione di questo blog, il meccanismo di caching dovrebbe consentire anche di interagire con questi elementi a computer bloccatoe all'insaputa dell'utente.
Furto di dati sensibili
Uno dei metodi più devastanti per abusare di UIA consiste nel rubare i dati delle carte di credito.
Quando un utente accede ad un negozio online, il criminale può ascoltare in modo programmatico le modifiche apportate agli elementi dell'interfaccia utente configurando un handler. Una volta apportata una modifica (ossia, dopo aver immesso i dati della carta di credito), il criminale può recuperare il testo dagli elementi dell'interfaccia utente per esfiltrarli successivamente (Figura 5).
Figura 5. Raccolta dei dati della carta di credito dal browser
Esecuzione di comandi
Un altro percorso di attacco usato comunemente consiste nel reindirizzamento di browser e phishing.
Usando il filtro firefox/chrome/edge nelle finestre dell'interfaccia utente, i criminali possono effettuare una semplice ricerca degli elementi dell'interfaccia utente desiderati con la barra di ricerca e impostarne il valore nel modo desiderato, quindi simulare un clic (Figura 6). Per rimanere in modalità invisibile, i criminali aspettano il momento in cui la pagina web attualmente visualizzata viene aggiornata o cambiata per far sì che il passaggio ad un altro sito web passi inosservato.
In questo modo, i criminali potranno reindirizzare gli utenti a siti dannosi da loro controllati, da cui avranno possibilità di attaccare tramite metodi praticamente illimitati: sfruttamento del browser, ad es., utilizzando lo strumento BeEF (Browser Exploitation Framework), attacchi di tipo drive-by, siti legittimi spacciati per sferrare phishing o attacchi per la raccolta di credenziali e molto altro.
Figura 6. Reindirizzamento di un utente a BeEF
Il potenziale impatto di UI Automation
Gli attacchi descritti nelle sezioni precedenti vengono sferrati da decenni con varie implementazioni e gli strumenti di difesa sanno perlopiù come rilevare e rispondere a queste minacce.
Tuttavia, tutto ciò di cui abbiamo discusso sopra viene considerata una funzione di UI Automation. Ritorniamo quindi allo scopo previsto dell'applicazione: questi livelli di autorizzazione devono esistere per poterli usare. Ecco perché UIA riesce a bypassare Defender: l'applicazione non trova nulla fuori dal comune. In realtà, nessuna tecnologia EDR da noi esaminata è riuscita a considerare queste azioni come dannose e, probabilmente, per lo stesso motivo. Se qualcosa viene visto come una funzione e non come un bug, la logica del sistema la considererà una funzione.
Ecco perché questo sistema è potenzialmente molto allettante per i criminali ed ecco perché riteniamo che una maggiore consapevolezza sia la chiave per contrastare questo vettore di attacco.
Ulteriori ricerche
UIA tramite DCOM
La tecnologia DCOM (Distributed COM) consente di richiamare gli oggetti COM da remoto da un computer all'altro. In teoria, dovrebbe essere sempre possibile accedere all'applicazione UIA da remoto tramite DCOM per consentire di sferrare, pertanto, tutti gli attacchi di cui abbiamo trattato senza richiedere un accesso locale/phishing.
Come parte della nostra analisi, abbiamo capito che l'oggetto COM di UIA non è configurato per supportare la tecnologia DCOM per impostazione predefinita, il che fa diminuire notevolmente il potenziale degli attacchi, eliminando gli errori di configurazione.
Anche se UIA non è disponibile tramite DCOM, abbiamo riscontrato un elemento correlato: l'oggetto COM/DCOM denominatoUIAutomationCrossBitnessHook , che non richiede privilegi per l'attivazione e l'esecuzione da remoto.
Decompilando il relativo DLL, abbiamo scoperto che la sua interfaccia contiene due funzioni: una per impostare l'utilità di gestione dell'interfaccia utente e l'altra per annullare la configurazione specificata. Sembra che non siano presenti altre funzionalità remote, per cui non abbiamo potuto usare l'applicazione per leggere o scrivere dati, ma si tratta di un argomento interessante su cui potremmo focalizzare la nostra ricerca in futuro.
Named pipe di UIA
In questo post, abbiamo già menzionato il fatto che UIA consente di accedere ad un "server" su un processo remoto. I server e i client di questo tipo vengono implementati in background tramite le named pipe. La convenzione di denominazione è costituita dalla stringa della costante UIA_PIPE seguita dall'ID del processo e da altri identificatori (Figura 7).
Figura 7. Named pipe dell'interfaccia utente all'interno dell'applicazione del criminale
È qui che la situazione diventa preoccupazione: le named pipe accettano connessioni remote. Questa situazione è molto pericolosa in tal caso perché significa che un criminale potrebbe riuscire a manipolare gli elementi dell'interfaccia utente tramite la rete. Quando abbiamo cercato di effettuare la connessione da un server remoto, tuttavia, abbiamo ricevuto un messaggio di errore del tipo ACCESS_DENIED perché
Microsoft ha impostato il contrassegno PIPE_REJECT_REMOTE_CLIENTS durante la creazione della named pipe. pertanto, non è possibile accedere all'applicazione UIA da remoto tramite queste pipe, che sono, tuttavia, disponibili in locale. È possibile enumerare queste pipe (senza dover indovinare l'identificatore o l'ID del processo) e accedervi, il che apre la porta a forme ti attacchi di elevazione dei privilegi o impersonificazione, anche se questo argomento non è parte della nostra analisi attuale.
Rilevamento/Mitigazione
Microsoft ha scoperto che questo sistema non dovrebbe interagire con applicazioni dai privilegi elevati Pertanto, per impostazione predefinita, le applicazioni che utilizzano il sistema di UI Automation vengono eseguite ad un livello di affidabilità medio e non possono accedere a processi dai privilegi elevati. Questo problema può essere bypassato utilizzando un'applicazione firmata con un file manifest contenente la chiave requestedExecutionLevel.uiAccess impostata su True:
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
Come per il rilevamento, gli amministratori possono monitorare l'uso del file UIAutomationCore.dll, che, se caricato in un processo in precedenza sconosciuto, dovrebbe sollevare legittime preoccupazioni.
Allo stesso modo, gli amministratori possono monitorare le named pipe aperte su un endpoint da parte di UIA, come altro indicatore di utilizzo, usando le seguenti 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'
Processi che caricano il file 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)
Processi che hanno aperto la named pipe di UI Automation
Conclusione
Questa analisi descrive un esempio sfortunato di come una tecnologia creata a fin di bene può essere sfruttata dai criminali per scopi illeciti. Anche se il sistema di UI Automation può risultare utile per le persone con disabilità, fornisce, inoltre, ai criminali varie opportunità per simulare uno spyware.
Anche se sfruttare l'applicazione UIA può sembrare più difficile di altri attacchi, il fatto che riesca ad eludere la tecnologia EDR rende l'applicazione UIA una superficie di attacco molto allettante. Nell'intento di ridurre la sua attrattiva nei confronti dei criminali, Microsoft ha impostato alcune restrizioni sull'applicazione UIA, tuttavia i criminali possono comunque sfruttarla a proprio vantaggio con le adeguate competenze. Speriamo che questo blog sia riuscito a far conoscere meglio questa tecnica di attacco e che riesca ad aiutare gli addetti alla sicurezza a difendere le loro aziende da attacchi di questo tipo.
