CVE-2020-0753-and-CVE-2020-0754

Writeup e POC per CVE-2020-0753, CVE-2020-0754 e sei vulnerabilità DOS di Windows non corrette

Exploit del bug di race condition nel FileSystem - analisi di CVE-2020-0753 e CVE-2020-0754

Il servizio Windows Error Reporting ha corretto 2 bug di Elevation of Privilege nell'ultimo Patch Tuesday; ai due bug sono stati assegnati CVE-2020-0753 e CVE-2020-0754. Entrambi i bug sfruttano un bug di race condition nelle operazioni FileSystem del servizio. Tuttavia, questi due bug non sono così facili da sfruttare a causa delle piccole finestre di race e delle posizioni incerte in cui vengono rilasciati i file. Qui condividiamo le nostre tecniche per sfruttarli.

La causa principale dei due bug di race è descritta nei nostri report; la causa effettiva può essere espressa come Prevedibile è vulnerabile. Quando il servizio WER elabora i file temporanei, manipola la posizione C:\ProgramData\Microsoft\Windows\WER\Temp, che è una directory con permessi di lettura/scrittura per gli Utenti Autenticati. Ciò significa che un utente normale con medio IL può sovrascrivere un file creato dal servizio WER e persino trasformarlo in un link del FileSystem per danneggiare/eliminare altri file che altrimenti non avrebbe potuto toccare.

Per mantenere sicure le operazioni sui file, il servizio WER si affida a un'API standard chiamata GetTempFileNameW, avvolta da wersvc.dll->UtilGetTempFile; questa API aiuta WerSvc a generare un nome di file casuale non occupato nella forma "WER****.tmp",

la parte casuale del nome del file è generata con un numero esadecimale di 4 byte, da 0000-FFFF; se un numero è già stato usato per creare un file, l'API proverà un altro nome casuale.

La strategia ha chiaramente un difetto: se si creano 65535 file denominati da WER0000.tmp a WERFFFE.tmp, l'API sceglierà un numero casuale e verificherà se il nome file esiste, ad esempio WERA560.tmp; troverà che il file esiste già e continuerà quindi a testare da WERA560.tmp fino a WERFFFF.tmp. Durante questa fase di test si apre una finestra di opportunità, perché abbiamo trovato un modo per bloccare WerSvc sulla chiamata GetTempFileNameW per 4-5 secondi, che è un intervallo di tempo piuttosto ampio. Nel frattempo, forziamo il servizio a depositare un file temporaneo con un nome fisso, cioè WERFFFF.tmp.

Dopo che il servizio crea il file temporaneo chiamato WERFFFF.tmp, l'API chiude automaticamente l'handle che detiene sul file e restituisce il nome al servizio per ulteriori operazioni sul file; questo è esattamente il punto che introduce il bug. Tre condizioni sono soddisfatte:

1. Il file creato dal servizio si trova in una posizione controllabile da un utente normale.
2. Il servizio chiude tutti gli handle al file
3. Il servizio userà il file in seguito (scrittura o eliminazione)

Qui il servizio scriverà contenuti nel file e lo eliminerà. Sia la scrittura che l'eliminazione causeranno un'escalation di privilegi sfruttando i link del FileSystem e alcune tecniche di exploitation.

Per trasformare il bug in eliminazione arbitraria di file, abbiamo sfruttato creativamente molteplici directory junction per completare l'exploit. Il nostro exploit contiene i seguenti passaggi:

• inseriamo tutti i WER***.tmp in $pwd\1\ e creiamo la junction $pwd\2\ -> $pwd\1\;
• creiamo un processo che attiva continuamente questa funzione con il percorso $pwd\2\ e un altro processo che esegue continuamente il comando SetOplock $pwd\1\WERFFFF.tmp;
• Una volta attivato l'Oplock, creiamo la junction $pwd\2\ -> \RPC CONTROL\, e quindi creiamo i symbolic link \RPC CONTROL\WERFFFF.tmp -> $target e \RPC CONTROL\WERFFFF.tmp.etl -> $target
• Rilasciamo l'oplock e il file target verrà eliminato con privilegi di sistema.

L'exploit dettagliato e la POC sono forniti in WERReport-CVE-2020-0753.

Sfruttando il difetto in GetTempFileNameW, otteniamo una posizione prevedibile su cui il servizio opererà; utilizzando junction FileSystem a più livelli, rendiamo la race condition sfruttabile in modo affidabile.

Nel frattempo, abbiamo notato che questo tipo di bug di race può anche causare un potenziale problema di sovrascrittura di file, che potrebbe quindi portare a bug di Escalation di Privilegi in determinate circostanze.

Dalla corruzione arbitraria di file con controllo parziale all'escalation di privilegi

Per spiegare perché la corruzione arbitraria di un file (se si può controllare una parte molto piccola del contenuto del file: meno di 63 byte) può trasformarsi in EoP, dobbiamo prestare attenzione al meccanismo di funzionamento di Windows Defender.

Windows Defender dispone di un database di firme malware. Se un file contiene una firma malware, Defender lo considererà un malware e lo eliminerà. Tuttavia, questa funzionalità comporta una superficie d'attacco aggiuntiva. Ad esempio, al WCTF2019 @icchy di tokyowesterns ha progettato una challenge CTF di Windows chiamata "Gyotaku The Flag", che usa questa funzionalità come oracolo per far trapelare informazioni.

Qui sfruttiamo questa funzionalità di Windows Defender per eliminare file arbitrari se disponiamo di una corruzione arbitraria di file con controllo parziale del contenuto. Possiamo semplicemente scrivere una firma malware in un file e attivare una scansione predefinita di Windows Defender; il file verrà messo nell'area di isolamento di Defender; un utente normale (cioè un utente non amministratore con medio IL) può eliminarlo semplicemente attivando l'operazione di scansione per 2 volte.

Quindi un bug di corruzione arbitraria di file può essere trasformato in eliminazione arbitraria di file, purché una stringa di firma malware possa essere inserita nel file target usando il bug.

• Passo 1:

Corrompi il file target con un bug, inserendovi una stringa caratteristica riconoscibile da Windows Defender.

• Passo 2:

Attiva una scansione di Windows Defender sul file target, causandone l'isolamento.

• Passo 3:

Attiva nuovamente la scansione, il file target viene eliminato.

Sfruttando questa tecnica otteniamo un'eliminazione arbitraria di file con l'aiuto di Defender.

L'eliminazione arbitraria di file può essere sfruttata molto più facilmente per ottenere ulteriori privilegi.

Sei vulnerabilità DOS del FileSystem non corrette in Microsoft OneDrive

Microsoft OneDrive è il pacchetto applicativo che fornisce il servizio di archiviazione personale su cloud; questa applicazione è integrata in Windows come opzione di installazione predefinita da Windows 8. Durante la nostra ricerca, sono state trovate e inviate a MSRC 6 vulnerabilità nelle attività pianificate di manutenzione di OneDrive.

---

Ecco una tabella delle vulnerabilità che esporremo relative alle attività pianificate di Microsoft OneDrive:

Tutti e 6 i bug sono causati dalla gestione impropria, da parte del servizio, di hardlink e symlink durante l'operazione su posizioni controllabili da un utente normale. Durante lo sfruttamento di questi bug, una difficoltà deriva dal fatto che il nome del file contiene di solito un pid del processo corrente o un timestamp che indica quando il file viene utilizzato. Entrambi i problemi possono essere risolti impostando un oplock su un file DLL univoco che il servizio tenterà di caricare quando viene avviato; in questo modo abbiamo la capacità di ottenere tutto ciò che ci serve per prevedere il nome del file su cui il servizio tenterà di operare in seguito. Una POC di esempio è fornita nella directory FileSyncConfigTemp_hardlink.

Impatto delle vulnerabilità

Tutte le 6 vulnerabilità sopra indicate sono fornite con report completo e programma POC; sebbene la maggior parte dei bug causi prima di tutto una corruzione arbitraria di file, questo tipo di bug può comunque causare un crash di sistema (sovrascrivendo file di configurazione critici del sistema), e tutti richiederebbero la reinstallazione di Windows. Soddisfano quindi lo standard del tipo di bug Windows System Denial of Service.

Inoltre, questo tipo di bug può effettivamente causare Elevation of Privilege in determinati contesti. Abbiamo discusso la tecnica di exploitation che può sfruttare un problema di sovrascrittura arbitraria di file per ottenere una primitiva di eliminazione arbitraria di file; di conseguenza, l'Elevation of Privilege è raggiungibile.

Crediti delle vulnerabilità

Fangming Gu

Zhiniang Peng di Qihoo 360 Core Security

Cronologia

Feb 02 2020: Vulnerabilità segnalate

Feb 08 2020: MSRC ha indagato e risposto in merito ai 6 bug in OneDrive che abbiamo inviato; la loro conclusione è di non correggerli a causa di Troppa interazione richiesta all'utente / troppo difficile costruire un exploit affidabile.

Feb 08 2020: Abbiamo risposto: Non è necessaria alcuna interazione con l'utente. Basta solo attendere l'esecuzione dell'attività pianificata. Quindi, questo scenario è tipico.

Feb 11 2020: MSRC ha risposto: Come si ottiene il file specifico sulla macchina dell'utente? E si mettono tutte le permutazioni di quel file in quella cartella? Deve corrispondere esattamente a Data/Ora/PID? È per questi motivi che sembra richiedere troppo sforzo da parte dell'utente.

Feb 11 2020: Abbiamo risposto: La nostra POC è una versione semplificata, per ridurre lo sforzo di prevedere il nome del file. In realtà, basta impostare un oplock. Poi si possono ottenere tutti i valori {pid}, {ora}, {data}. Quindi, non è necessaria alcuna interazione con l'utente.

Feb 12 2020: Abbiamo chiesto se possiamo pubblicare il writeup per queste 6 vulnerabilità.

Feb 13 2020: MSRC ha risposto: Potete pubblicare un writeup.

Feb 22 2020: Dettagli pubblicati

Sebbene l'hardlink abbia già ricevuto una correzione nelle build di Windows Insider Preview, non è stato corretto nell'ultima versione rilasciata di Windows. E non sembra esserci alcun piano per fornire un backport a tutti i sistemi operativi supportati :( . E rifiutarsi di correggere queste vulnerabilità non sembra un'azione responsabile.