CVE-2022-45451

Introduzione

Specifiche di sistema:

• Windows 10 1809 x64 EN

Target:

• Acronis Home Cyber Protect
• Acronis Cyber Protect

Descrizione della vulnerabilità

Il driver di scansione anti-malware "ngscan" di Acronis soffre di un controllo degli accessi errato/inappropriato applicato alla porta di comunicazione del filtro. Il driver minifilter supporta le seguenti funzionalità che possono essere sfruttate:

• Lettura arbitraria di file
• Modifica di chiavi di registro sensibili (non sfruttata, condizioni di attivazione sconosciute) che può portare all'esecuzione locale di codice

Lettura arbitraria di file

L'analisi del driver ngscan.sys è iniziata decompilando il driver con Ida Pro. Il ricercatore ha notato che, mentre veniva creato un oggetto dispositivo, non erano stati creati symlink per interagire con il driver usando DeviceIoControl. Pertanto, l'analisi è continuata osservando le capacità della porta di comunicazione del filtro. Durante l'inizializzazione, il driver crea cinque (5) porte di comunicazione per supportare l'interazione da altri processi.

Fig. 1: Routine che supporta la creazione fino a cinque (5) porte di comunicazione del filtro (FCP)

È stata osservata la chiamata di questa funzione, che inizializza ciascuna delle 5 FCP con un dacl predefinito, con l'ultima FCP creata con un dacl NULL.

Fig. 2: Creazione FCP con DACL predefinito/NULL

L'analisi è continuata osservando le funzioni CreateNotifyCallback e MessageNotifyCallback specificate dal driver del filtro. Queste funzioni di callback vengono invocate ogni volta che un processo apre una connessione e invia un messaggio alla porta di comunicazione.

L'ispezione iniziale del MessageNotifyCallback ha mostrato che il buffer del messaggio in arrivo deve soddisfare i seguenti requisiti:

• il primo DWORD deve corrispondere al valore di intestazione atteso "TrMs" (Riga 37)
• il secondo DWORD deve contenere la lunghezza del contenuto del messaggio (nota: questo è diverso e distinto dalla InputBufferLength)
• la lunghezza del contenuto del messaggio deve essere minore o uguale alla dimensione totale del buffer di input meno la dimensione dell'intestazione del messaggio
  • L'intestazione del messaggio è composta dall'intestazione e dalla dimensione, e da un altro valore sconosciuto per un totale di 0xC (12) byte

Una volta superati i controlli, un numero di funzione viene analizzato dal InputBuffer e viene utilizzato nei seguenti casi switch per selezionare quale funzione eseguire con l'input fornito.

Fig. 3: Sottoinsieme di funzioni supportate dal MessageNotifyCallback

L'ispezione di ciascuna delle funzioni supportate ha mostrato due funzioni di interesse per un potenziale abuso che porta alla lettura arbitraria di file.

Fig. 4: Funzioni che supportano la creazione di un contesto di scansione e restituiscono l'handle del file del contesto di scansione (Righe 206, 233)

Sebbene la funzionalità esatta di un "contesto di scansione" non sia completamente nota, l'analisi ha mostrato che un contesto di scansione di file può essere creato per qualsiasi file specificato nel InputBuffer dell'utente. Una volta creato un contesto di scansione, l'ID del contesto di scansione viene restituito all'utente nel buffer di output.

Fig. 5: Routine di creazione del contesto di scansione che restituisce i dati del contesto di scansione all'utente

Fig. 6: Dati inviati al driver minifilter per richiedere l'accesso al file di registro SAM protetto (\??\C:\Windows\System32\config\SAM)

Fig. 7: Risposta dal driver minifilter che include l'ID del contesto di scansione (0x3aaf)

Una volta creato un contesto di scansione e recuperato l'ID, è possibile aprire un handle al file per il quale è stato creato il contesto di scansione nell'applicazione richiedente inviando nuovamente un messaggio alla porta di comunicazione.

Fig. 8: Recupero dell'handle del file del contesto di scansione creato

La funzione designata come CreateFileReturnHandle0 veniva chiamata solo se la funzione precedente SearchScanContextsByID restituiva un contesto di scansione valido. Ad esempio, solo se il processo richiedente forniva un ID contesto valido che era stato precedentemente creato chiamando la suddetta funzione di creazione della scansione. Il programma richiedente ha aperto con successo un handle al file privilegiato fornendo l'ID del contesto di scansione alla funzione specificata nella Figura 8 (Figura 4, Riga 233).

Fig. 9: Recupero riuscito dell'handle del file per il file SAM

Utilizzando processhacker, l'accesso all'handle del file è stato confermato visualizzando gli handle del processo richiedente:

Fig. 10: Processo contenente l'handle del file SAM

Fig. 11: Accesso in lettura concesso all'handle ottenuto

Potenziale iniezione di codice

Un'ulteriore esplorazione delle funzioni supportate ha mostrato il controllo di tre chiavi di registro che potrebbero essere sfruttate per ottenere l'esecuzione di codice.

Fig. 12: Funzioni che supportano l'apertura di handle alle chiavi di registro

Fig. 13: Apertura delle chiavi di registro che specificano la dll del monitor di hook da iniettare in un processo

Fig. 14: Funzione OpenKey che dimostra la capacità di modificare una chiave di registro con dati controllati dall'utente

Le circostanze per l'iniezione di dll per hooking da parte della suite Acronis non sono state determinate, anche se se il monitoraggio degli hook è abilitato, si ritiene che la dll specificata dalle chiavi di registro x64HookLib e x86HookLib verrebbe iniettata in un processo designato.

Fig. 15: x64HookLibKey che specifica la dll di hooking C:\ProgramData\Acronis\NGMP\shared\acr_protect.x64.dll

Condizione di gara che consente una limitata lettura arbitraria di file

Il processo di apertura di un contesto di scansione è stato pretermesso nell'analisi per la Lettura Arbitraria di File. Un processo può, invece di creare un contesto di scansione, forzare gli ID dei contesti di scansione inviando ripetutamente richieste alla funzione GetScanContextByID, iterando sui valori ContextID finché non viene trovato uno o più contesti di scansione validi.