Meccanismo di sfruttamento della sottoapplicazione di SteelSeries per l'escalation dei privilegi
Analisi riassuntiva
Il ricercatore della sicurezza di Akamai Tomer Peled ha recentemente scoperto due vulnerabilità nell'applicazione di SteelSeries.
SteelSeries è un'azienda di hardware che produce periferiche per computer e vanta più di 9 milioni di clienti in tutto il mondo.
Alle vulnerabilità sono stati assegnati i numeri CVE-2023-31461 e CVE-2023-31462. SteelSeries ha agito tempestivamente per correggere queste vulnerabilità nel maggio 2023.
Queste vulnerabilità consentono a un utente malintenzionato di eseguire codice con privilegi più elevati di quelli ottenuti inizialmente, ed eventualmente con privilegi di amministratore. Per sfruttare queste vulnerabilità, il criminale deve inviare due pacchetti locali a un server IPC in ascolto. Il server eseguirà quindi il payload del criminale con privilegi elevati.
La causa principale di queste vulnerabilità risiede nella gestione non sicura dei permessi nel listener IPC del servizio e nella mancanza di protezione contro il path traversal.
L'Akamai Security Intelligence Group (SIG) ha divulgato responsabilmente le vulnerabilità ai team di supporto e di ingegneria di SteelSeries e le ha sottoposte al MITRE per le CVE assegnate.
Il SIG ha scoperto che il servizio era vulnerabile in diversi data center che monitoriamo e ha informato i clienti del rischio e di come mitigarlo.
- Forniamo un exploit POC (Proof of Concept) e una osquery per individuare i computer con il servizio vulnerabile.
Introduzione
SteelSeries è un'azienda di hardware specializzata in periferiche per computer, come tastiere, mouse, cuffie, ecc. Per personalizzare questi dispositivi, SteelSeries offre ai suoi utenti un'applicazione - SteelSeries GG - che può essere scaricata dal suo sito web.
Questa applicazione, composta dal modulo principale SteelSeries GG e da diverse sottoapplicazioni, è un meccanismo che SteelSeries utilizza per migliorare la user experience.
Nella nostra ricerca, abbiamo trovato due modi per registrare la nostra sottoapplicazione e specificare il codice da eseguire attraverso di essa, portando eventualmente all'esecuzione di codice con autorizzazioni più elevate. In questo post del blog, forniamo i dettagli tecnici di queste vulnerabilità e un exploit PoC.
Dettagli tecnici
Per impostazione predefinita, l'applicazione SteelSeries GG viene eseguita a un livello di integrità medio e, solitamente, nel contesto dell'amministratore. Di conseguenza, in determinate circostanze può essere eseguita in un contesto ad alta integrità. Questo dettaglio, unito al fatto che SteelSeries GG è un processo in ascolto (Figura 1), lo rende un buon obiettivo per chi è alla ricerca di una vulnerabilità.
Figura 1. Process Hacker e netstat mostrano l'applicazione SteelSeries GG in ascolto
Il meccanismo delle sottoapplicazioni e l'API di comunicazione interprocesso
Il meccanismo delle sottoapplicazioni viene utilizzato per gestire le funzioni opzionali di SteelSeries e migliorare la user experience. Un esempio di tale sottoapplicazione è Sonar, "una suite avanzata di strumenti software audio per il gaming che offre a tutti la possibilità di regolare separatamente l'audio di gioco, la chat del team e il microfono", come definito da SteelSeries. Le sottoapplicazioni vengono eseguite in background e comunicano con il modulo principale dell'applicazione tramite un'API di comunicazione interprocesso (IPC).
L'API IPC di SteelSeries GG espone diversi tipi di operazioni che un utente può richiedere, tra cui modifiche alla configurazione, azioni amministrative, modifiche al profilo utente e così via. L'aspetto più interessante è che l'API espone un'interfaccia per gestire le sottoapplicazioni, dalla creazione e cancellazione all'abilitazione e disabilitazione.
La funzionalità di instradamento delle API (ossia, la modalità di gestione di ogni richiesta API) è implementata utilizzando la libreria open source di gorilla/mux . Sapendo questo, possiamo esplorare più facilmente la superficie di attacco. La funzione di instradamento in sé è molto grande, ma è essenzialmente solo un insieme di istruzioni if per ciascuna delle opzioni API disponibili (Figura 2).
Figura 2. L'implementazione del routing HTTP in SteelSeries GG
Queste chiamate API sono disponibili a chiunque avvii una connessione con il server in ascolto ("SteelSeriesGG.exe") e non richiedono autenticazione.
Ho scelto di concentrarmi sui gestori di eventi delle sottoapplicazioni, poiché avevano il maggior potenziale di impatto. Dopo aver riorganizzato il codice disassemblato in IDA, abbiamo scoperto che i gestori di instradamento per le sottoapplicazioni hanno il prototipo mostrato nella Figura 3.
Figura 3. Prototipo di funzione di gestione nel codice gorilla/mux
Sfruttamento del meccanismo delle sottoapplicazioni
Una delle chiamate API che possiamo effettuare è la creazione di una nuova sottoapplicazione. Questo processo viene eseguito inviando una richiesta POST al percorso /subApps con un payload JSON che contiene diversi parametri, quattro dei quali sono interessanti per noi: "name", "executableName" , "isEnabled" e "shouldAutoStart".
Utilizzando questi campi, possiamo praticamente creare una nuova sottoapplicazione come utenti non privilegiati, indirizzarla verso un eseguibile in una posizione non privilegiata ed eventualmente programmarla all'avvio di ogni applicazione.
SteelSeries GG crea il percorso completo del file eseguibile della sottoapplicazione come segue:
<StellSeriesGG install location>\Apps\<name>\<executableName>.exe
Poiché i campi "name" e "executableName" sono concatenati in questo modo, abbiamo pensato di provare a sferrare un attacco di tipo path traversal. A quanto pare, SteelSeries GG non è resistente ai path traversal e il percorso preceduto da "../../../../" è stato accettato, come si può vedere nella Figura 4.
Figura 4. Il path traversal è accettato durante la creazione di una nuova sottoapplicazione
Quando viene creata una sottoapplicazione, le informazioni su di essa vengono memorizzate nel database di SteelSeries GG. Esiste un altro modo per controllare le sottoapplicazioni attraverso questo database? In effetti, il database è ubicato in una posizione non sicura. Ciò significa che, anche senza accedere all'API della sottoapplicazione, potremmo essere in grado di aggiungere una sottoapplicazione direttamente al database. Tuttavia, i malintenzionati dovranno trovare una vulnerabilità per abusare di questo difetto di progettazione, che di per sé non è sfruttabile e quindi non rappresenta un rischio immediato.
Potreste pensare che la creazione di una sottoapplicazione in una posizione controllata significhi che abbiamo ottenuto l'escalation dei privilegi (una volta eseguito un file binario da quel percorso), ma provando, abbiamo scoperto che c'è un'altra restrizione: la convalida del certificato. SteelSeries si assicura giustamente che i file eseguibili delle sottoapplicazioni siano firmati e approvati. Per eseguire il nostro payload, dovremo bypassare il processo di verifica.
La funzione di verifica richiama la funzione WinVerifyTrust e una catena di funzioni WinAPI per confrontare alcuni campi del certificato con le stringhe codificate nell'applicazione.
Questa convalida è un po' complicata da bypassare, ma può essere ottenuta in due modi:
Hijacking del DLL
TOCTOU (Time-Of-Check to Time-Of-Use)
Il vettore dell'hijacking del DLL
Con la tecnica dell'hijacking del DDL, possiamo fare affidamento sul fatto che SteelSeries si affida a diversi file binari esistenti; uno di questi è SteelSeriesEngine.exe, che carica la libreria SSEDEVICE.dll. Compileremo la nostra libreria con lo stesso nome, in modo che venga caricata al posto della libreria SSEDEVICE DLL originale. Le funzioni esportate della nostra DLL richiameranno le funzioni della DLL originale.
Tuttavia, la funzione chiamata al caricamento della nostra DLL implementerà la nostra logica dannosa (Figura 5). La tecnica è ulteriormente spiegata nel blog relativo al proxying DLL di itm4n.
Figura 5. Hijacking del DLL della funzione SSEDEVICE
L'animazione nella figura Figura 6 mostra il processo di invio del pacchetto iniziale per l'esecuzione del payload dei criminali (nel nostro caso, l'apertura di un'istanza cmd) con privilegi elevati.
Figura 6. Il processo di invio del pacchetto iniziale per l'esecuzione del payload dei criminali con privilegi elevati
Il vettore TOCTOU
In questo caso, sfruttiamo l'intervallo di tempo tra la verifica del certificato e l'effettiva esecuzione del file binario (Figura 7). In altre parole, cerchiamo di raggiungere una race condition scambiando rapidamente il file legittimo con uno dannoso utilizzando lo strumento BaitAndSwitch di James Forshaw. Vogliamo sostituirlo subito dopo la verifica del certificato. In questo modo, la verifica avviene su un file legittimo, ma poi viene eseguito un file dannoso non verificato.
Per natura, il funzionamento delle race condition non è garantito. Per stabilizzare questo exploit, possiamo cercare di guadagnare più tempo per la sostituzione e ampliare la nostra finestra di opportunità.
Figura 7. Illustrazione del vettore TOCTOU
Ricordiamo che la verifica del certificato si basa su due test: una chiamata a WinVerifyTrust e un controllo tra alcuni campi del certificato e le stringhe codificate nell'applicazione. Possiamo impiantare un certificato con questi valori esatti nel nostro file eseguibile. Questo miglioramento consente al malintenzionato di raggiungere una race condition anche se il passaggio avviene tra i due test, in quanto il nostro file binario dannoso soddisfa tutti i criteri del secondo test.
L'animazione nella figura Figura 8 mostra il processo che va dall'attesa dell'avvio del processo di verifica con BaitAndSwitch all'esecuzione del file binario del criminale (in questo caso, il file cmd.exe).
Figura 8. Il processo che va dall'attesa dell'avvio del processo di verifica con BaitAndSwitch all'esecuzione del file binario del criminale
Rilevamento e mitigazione
Per facilitare il rilevamento di risorse vulnerabili nella rete, forniamo una osquery per trovare istanze di SteelSeries GG e la sua versione attualmente installata:
SELEZIONARE name,version dai programmi in cui il nome risulta SIMILE A '%SteelSeries%' |
I clienti di Akamai Guardicore Segmentation possono usare questa query con Insight per individuare le applicazioni che richiedono le patch.
SteelSeries aggiorna le sue applicazioni con ogni nuova patch. Ciò potrebbe ridurre le possibilità che i vostri dispositivi siano affetti da queste vulnerabilità, ma consigliamo ai responsabili della sicurezza di aggiornare la loro versione di SteelSeries a una superiore alla 39.
Conclusione
SteelSeries è una grande azienda con un enorme bacino d'utenza, con oltre 9 milioni di clienti in tutto il mondo. Qualsiasi vulnerabilità nei suoi prodotti ha un impatto intrinseco. Le conseguenze si amplificano se si considera la facilità di sfruttamento di queste vulnerabilità e il loro effetto sul computer, ovvero la possibilità di ottenere l'esecuzione di file binari in contesto di amministrazione.
La portata dell'impatto non è limitata al computer dell'utente; anche le aziende potrebbero essere interessate. Il computer portatile di un dipendente che si connette a un dispositivo vulnerabile o esegue un'applicazione vulnerabile può essere successivamente connesso alla rete aziendale e "importare" i rischi nell'organizzazione. Per questo motivo, è importante che le aziende prendano in considerazione l'implementazione di una politica BYOD (Bring Your Own Device) e che istruiscano i dipendenti sui pericoli derivanti dall'utilizzo di tali dispositivi.
Abbiamo analizzato le reti dei clienti Akamai per cercare le istanze dell'applicazione vulnerabile e abbiamo informato i clienti interessati.
Come parte del nostro costante impegno volto a proteggere i nostri clienti e la community, continueremo ad analizzare patch e altri sistemi per le vulnerabilità. Per restare aggiornati sulle ultime ricerche sulla sicurezza di Akamai, seguiteci su Twitter.
Cronologia delle divulgazioni
27/04/2023 - Richiesta CVE inviata a MITRE
01/05/2023 - E-mail inviata all'assistenza clienti di SteelSeries
02/05/2023 - CVE assegnate da MITRE
03/05/2023 - 04/06/2023 - Conversazioni con il team tecnico di SteelSeries
31/05/2023 - Pubblicazione delle correzione
17/07/2023 - Revisione della bozza da parte di SteelSeries
18/07/2023 - Pubblicazione del post del blog
