Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2020-0753-and-CVE-2020-0754 — Descrizione e Proof of Concept per CVE-2020-0753, CVE-2020-0754 e sei vulnerabilità DOS risolte di Windows. | Kitploit
Strumenti/GitHubGitHub/afang5472/cve-2020-0753-and-cve-2020-0754
Escalation di PrivilegiAnalisi delle VulnerabilitàExploitPaper e RicercaApprendimento e FormazioneBinary Exploitation
GitHubafang5472/cve-2020-0753-and-cve-2020-0754

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

Descrizione e Proof of Concept per CVE-2020-0753, CVE-2020-0754 e sei vulnerabilità DOS risolte di Windows.

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi
Vedi Repository
14816 anni faNon ancora revisionato

Writeup e POC per CVE-2020-0753, CVE-2020-0754 e sei vulnerabilità DOS di Windows 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 Elevazione dei Privilegi nell'ultimo Patch Tuesday, i due bug sono assegnati a 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 di finestre di race piccole e posizioni incerte di drop dei file. Qui condividiamo le nostre tecniche per sfruttarli.

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

Per mantenere le operazioni sui file sicure, il servizio WER si affida a un'API standard chiamata GetTempFileNameW e la racchiude con wersvc.dll->UtilGetTempFile, questa API aiuta WerSvc a generare un nome file casuale non occupato nella forma "WER****.tmp", la parte casuale del nome file è generata con un numero esadecimale a 4 byte, da 0000-FFFF, se un numero è già stato utilizzato per creare un file, l'API prenderà un altro nome file casuale.

La strategia ha chiaramente un difetto se si creano 65535 file nominati da WER0000.tmp a WERFFFE.tmp, l'API prenderà un numero casuale e testerà il nome file per vedere se esiste, ad esempio WERA560.tmp, troverà che il file esiste già, quindi continuerà a testare da WERA560.tmp fino a WERFFFF.tmp, durante il test, appare una finestra di preparazione perché abbiamo trovato un modo per far bloccar WerSvc sulla chiamata GetTempFileNameW per 4-5 secondi, che è un intervallo di tempo piuttosto grande. Nel frattempo, forziamo il servizio a rilasciare un file temporaneo con 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 file al servizio per ulteriori operazioni sul file, questo è esattamente il punto in cui viene introdotto il bug. Sono soddisfatte tre condizioni:

  1. Il file creato dal servizio è in una posizione controllabile dall'utente normale.
  2. Il servizio chiude tutti gli handle al file.
  3. Il servizio utilizzerà il file in seguito (scrittura o cancellazione).

Qui il servizio scriverà contenuti nel file e lo cancellerà. Sia la scrittura che la cancellazione causeranno un'escalation dei privilegi sfruttando i link del FileSystem e alcune tecniche di exploit.

Per trasformare il bug in cancellazione arbitraria di file, sfruttiamo in modo creativo più directory junction per completare l'exploit. Il nostro exploit contiene i seguenti passaggi:

  • mettiamo tutti i WER***.tmp in $pwd\1\, e creiamo un junction da $pwd\2\ a $pwd\1\;
  • creiamo un processo per attivare continuamente questa funzione con il percorso $pwd\2\ e creiamo un altro processo per eseguire continuamente il comando SetOplock $pwd\1\WERFFFF.tmp;
  • Una volta attivato l'oplock, creiamo un junction da $pwd\2\ a \RPC CONTROL\, e poi creiamo un oggetto simbolico \RPC CONTROL\WERFFFF.tmp -> $target e \RPC CONTROL\WERFFFF.tmp.etl -> $target
  • Rilasciamo l'oplock, il file target verrà cancellato con privilegi di sistema.

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

Sfruttando il difetto in GetTempFileNameW, otteniamo una posizione prevedibile in cui il servizio opererà; utilizzando junction del 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 possibile problema di sovrascrittura di file, che potrebbe portare a bug di Escalation dei Privilegi in determinate circostanze.

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

Per spiegare il motivo per cui la corruzione arbitraria di file (se si può controllare una piccolissima parte del contenuto del file: meno di 63 byte) può essere trasformata in EoP, dobbiamo prestare attenzione al meccanismo di funzionamento di Windows Defender.

Windows Defender ha un database di firme malware. Se un file contiene una firma malware, Defender lo considererà un malware e lo cancellerà. Tuttavia, questa funzionalità comporta una superficie di attacco aggiuntiva. Per esempio, in WCTF2019 @icchy di tokyowesterns ha progettato una sfida CTF di Windows chiamata "Gyotaku The Flag", che utilizza questa funzionalità come oracolo per perdere informazioni.

Qui sfruttiamo questa funzionalità di Windows Defender per eliminare file arbitrari se abbiamo una corruzione arbitraria di file con controllo parziale del contenuto del file. 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, che può essere cancellata da un utente normale (cioè un utente non amministratore di medio IL) semplicemente attivando l'operazione di scansione per 2 volte.

Quindi un bug di corruzione arbitraria di file può essere trasformato in cancellazione arbitraria di file purché una stringa di firma malware possa essere inserita nel file di destinazione utilizzando il bug.

  • Passo 1:

Corrompi il file di destinazione con un bug, inserisci una stringa di caratteristica riconoscibile da Windows Defender.

  • Passo 2:

Attiva Windows Defender per scansionare il file di destinazione, causando l'isolamento del file.

  • Passo 3:

Attiva la scansione di nuovo, il file di destinazione viene cancellato.

Sfruttando questa tecnica otteniamo una cancellazione arbitraria di file con l'aiuto di Defender.

La cancellazione arbitraria di file può essere sfruttata molto più facilmente per ottenere ulteriori privilegi.

Sei vulnerabilità DOS del FileSystem corrette in Microsoft OneDrive

Microsoft OneDrive è il pacchetto applicativo che fornisce il servizio di archiviazione personale sul cloud,

questa applicazione è stata integrata in Windows come opzione di installazione predefinita da Windows 8. Durante la nostra ricerca, sono state trovate 6 vulnerabilità nelle attività pianificate di manutenzione di OneDrive e sono state inviate a MSRC.


Ecco una tabella delle vulnerabilità che esporremo nelle attività pianificate rilevanti di Microsoft OneDrive:

Tutti i 6 bug sono causati dal servizio che gestisce in modo improprio hardlink e symlink, mentre opera in posizioni controllabili dall'utente normale. Durante lo sfruttamento di questi bug, una difficoltà deriva dal fatto che il nome file solitamente contiene un pid del processo corrente o un timestamp che segna quando il file viene operato. Entrambi possono essere risolti impostando un oplock su un file dll unico che il servizio proverà a caricare quando viene attivato per l'esecuzione, dove abbiamo la capacità di ottenere tutto ciò di cui abbiamo bisogno per prevedere il nome file che il servizio proverà a operare successivamente. Un POC di esempio è fornito nella directory FileSyncConfigTemp_hardlink.

Impatti delle Vulnerabilità

Tutte le 6 vulnerabilità sopra indicate sono fornite con report completo e programma POC, sebbene la maggior parte dei bug causi inizialmente una corruzione arbitraria di file, questo tipo di bug causa comunque un crash del sistema (sovrascrivendo file di configurazione critici del sistema), e tutti richiederebbero la reinstallazione di Windows. Soddisfacendo così lo standard del tipo di bug di Denial of Service del sistema Windows.

Inoltre, questo tipo di bug può effettivamente causare un'Elevazione dei Privilegi in determinati contesti. Abbiamo discusso la tecnica di exploit che può sfruttare un problema di sovrascrittura arbitraria di file per ottenere una primitiva di cancellazione arbitraria di file, quindi l'Elevazione dei Privilegi è raggiungibile.

Crediti delle Vulnerabilità

Fangming Gu

Zhiniang Peng of Qihoo 360 Core Security

Cronologia

Feb 02 2020: Vulnerabilità segnalate

Feb 08 2020: MSRC ha investigato e risposto riguardo i 6 bug in OneDrive che abbiamo inviato, la loro conclusione è di non correggere a causa di Troppa interazione utente richiesta/troppo difficile costruire un exploit affidabile.

Feb 08 2020: Abbiamo risposto: Non è necessaria alcuna interazione utente. Devi solo aspettare che l'attività pianificata venga eseguita. Quindi, questo scenario è tipico.

Feb 11 2020: MSRC ha risposto: Come ottieni il file specifico sulla macchina dell'utente? E stai mettendo ogni permutazione di quel file in quella cartella? Deve corrispondere esattamente a Data/Ora/PID? È per questi motivi che sembra che richieda troppo sforzo da parte dell'utente.

Feb 11 2020: Abbiamo risposto: Il nostro POC è una versione semplificata. Per ridurre lo sforzo di prevedere il nome file. In realtà, devi solo impostare un oplock. Poi puoi ottenere tutto {pid}, {ora}, {data}. Quindi, non è necessaria interazione utente.

Feb 12 2020: Chiedendo se possiamo pubblicare il writeup per quelle 6 vulnerabilità.

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

Feb 22 2020: Dettagli pubblicati

Aggiornamento stato: Tutte le 6 vulnerabilità hanno ricevuto una correzione nel Patch Tuesday di marzo 2020.

Scarica lo strumento
Programma VulnerabileTipoPOC Fornito
FileSyncConfig.exeHardLinksì
FileSyncHelper.exeHardLinksì
OneDriveFileSyncConfig.exeSymLinksì
OneDriveSetup.exeHardLinksì
OneDriveSetup.exeHardLinksì
OneDriveStandaloneUpdater.exeHardLinksì