In termini di impatto, un attaccante con l'autenticazione di un utente normale può eseguire codice arbitrario in remoto con privilegi di amministratore. Per quanto riguarda la difficoltà di sfruttamento, la vulnerabilità è molto facile da sfruttare e, di conseguenza, estremamente pericolosa.

Dal punto di vista delle caratteristiche, la vulnerabilità 34527 si basa sulla vulnerabilità CVE-2021-1675. La 1675 è una vulnerabilità di elevazione locale dei privilegi e di esecuzione remota di codice, e ha molte somiglianze con la 34527.

Prima di comprendere il principio di funzionamento della vulnerabilità, dovremmo farci un'idea generale dell'architettura dello spooler di stampa di Windows; questo ci aiuterà a chiarire le relazioni tra i vari moduli coinvolti dalla vulnerabilità.

== Flusso di chiamata di CVE-2021-1675

=== Architettura dello spooler di stampa di Windows

L'architettura dello spooler può essere rappresentata come in <<spooler_arch>>:

[[spooler_arch]] .Print Spooler Architecture image::Print Spooler Architecture.png[]

Nello specifico, lo spooler di stampa serve a gestire i processi di stampa ed è composto dai seguenti componenti:

winspool.drv:: la libreria a collegamento dinamico fornita all'utente. Questo file definisce le API Win32 relative allo spooler che l'utente può chiamare. Tutte le API in esso contenute ottengono i servizi sotto forma di chiamate a procedure remote.

spoolsv.exe:: spoolsv.exe svolge il ruolo di server nel sistema ed è il primo programma a gestire le chiamate API. Questa architettura è stata pensata per consentire allo spooler di stampa di gestire sia i processi di stampa locali sia, senza alcuna distinzione, quelli remoti.

spoolsv.dll:: il programma di routing. Inoltra le richieste di stampa ricevute da spoolsv.exe ai vari provider di stampa e decide quale di essi gestirà definitivamente la richiesta. Il suo scopo è distinguere se il processo di stampa è remoto o locale. Su una macchina remota, assegna il processo al provider di stampa locale.

localspl.dll:: il provider di stampa locale. Il compito principale del provider di stampa è soddisfare le esigenze di gestione dei processi di stampa; la stragrande maggioranza delle API è implementata in questo modulo.

Proseguendo sulla base della teoria sopra descritta, facciamo un esempio: quando si chiama la funzione AddPrinterDriverEx (CVE-2021-1675), il flusso è il seguente:

=== Selezione della versione della funzione

Innanzitutto, questa funzione è in realtà una macro che, in base all'ambiente di compilazione locale, seleziona la versione Unicode (W) o la versione ANSI (A), come in <>:

[[AddPrinterDriverEx]] .AddPrinterDriverEx image::AddPrinterDriverEx.png[]

Ma sia la versione a caratteri wide sia quella a caratteri stretti portano allo stesso risultato, poiché le stringhe del kernel di Windows sono codificate in Unicode; pertanto, alla fine, le chiamate della versione ANSI vengono convertite in chiamate della versione Unicode, come in <>:

[[AnsiToUnicode]] .AnsiToUnicode image::AnsiToUnicode.png[]

Una volta che tutti i parametri della funzione ANSI sono stati convertiti nella versione Unicode, viene chiamata una funzione (<>):

[[AnsiCallUnicode]] .AnsiCallUnicode image::AnsiCallUnicode.png[]

Tale funzione è in realtà la versione Unicode di AddPrinterDriverEx (<>):

[[GetUnicodeProcAddress]] .GetUnicodeProcAddress image::GetUnicodeProcAddress.png[]

=== La funzione API invia la richiesta RPC al server dello spooler

All'interno della funzione della versione Unicode, viene innanzitutto selezionato il tipo dei parametri della funzione in base al valore di Level:

image::pDriverInfo.png[]

In questa vulnerabilità si imposta Level a 2, selezionando cioè per il parametro pDriverInfo il tipo di struttura DRIVER_INFO_2. Subito dopo, Windows elabora i parametri della funzione e, una volta completata l'elaborazione, prosegue la gestione dell'API tramite una chiamata a procedura remota:

image::set arguments.png[]

image::NdrClientCall3.png[]

=== Il meccanismo MSRPC

Il meccanismo di chiamata a procedura remota di Microsoft è costruito sullo standard DCE. In termini semplici, una chiamata a procedura remota consiste nell'eseguire su un sistema remoto processi predefiniti dal programmatore o dal sistema stesso.

Concretamente, la RPC serializza la funzione da chiamare in remoto, la trasmette al sistema remoto attraverso la rete; il sistema remoto la deserializza e la esegue. Nell'architettura realizzata da Microsoft, TCP/IP e SMB sono i protocolli generalmente scelti per trasportare le chiamate RPC.

Per usare MSRPC, è necessario innanzitutto definire la descrizione dell'interfaccia IDL della funzione da chiamare, quindi usare lo strumento MIDL per generare gli stub di serializzazione corrispondenti per il client e per il server. Per alcune API Win32, invece, lo stub lato server è già definito, quindi è sufficiente generare e usare lo stub lato client.

MSRPC usa un UUID per identificare un determinato tipo di protocollo; ad esempio, MS-RPRN descrive il protocollo di stampa remota e tutte le funzioni relative alla stampa remota fanno parte di questo protocollo. MSPRC usa l'UUID 12345678-1234-ABCD-EF00-0123456789AB per identificare tale protocollo (<<rprn_uuid>>):

[[rprn_uuid]] .MS-RPRN UUID image::spoolss uuid.png[]

Successivamente, sempre su questa connessione, si può usare l'operator number per identificare le funzioni all'interno del protocollo e chiamarle in remoto; ad esempio, AddPrinterDriverEx si identifica con 89 (<<addPrinterDriverEx_opnum>>):

[[addPrinterDriverEx_opnum]] .AddPrinterDriverEx Opnum image::AddPrinterDriverEx Opnum.png[]

Nell'uso di MSRPC ci sono due punti a cui prestare particolare attenzione:

[IMPORTANT]

• Per le connessioni TCP/IP viene usata una porta dinamica, il cui valore deve essere ottenuto tramite l'endpoint mapper in ascolto sulla porta 135.

"As you can see in your output, the scripts are trying to connect to port 135 (endpoint mapper) in order to get the TCP/IP port where the DCOM endpoint is listening (that is a dynamic port)." -- SecureAuthCorp/impacket issue #412

• Inoltre, alcune funzioni RPC richiedono l'autenticazione per essere chiamate; per questo motivo la vulnerabilità richiede i privilegi di un utente normale. ====

=== spoolsv.exe gestisce le richieste API

[[call_flow]] .RpcAddPrinterDriverEx Call Flow image::Function Calls.png[]

Come si può vedere da <<call_flow>>, spoolsv.exe chiama queste funzioni; dall'analisi interna delle funzioni, però, il modulo non esegue alcuna operazione significativa oltre all'inizializzazione. Alla fine, il modulo chiama la funzione puntata da pLocalProvidor, cioè la funzione LocalAddPrinterDriverEx nel modulo localspl.dll. In quanto provider di stampa locale, localspl è effettivamente il modulo che implementa la funzionalità dell'API.

=== Logica di implementazione della funzione del provider di stampa locale

[[LocalAddPrinterDriverEx]] .LocalAddPrinterDriverEx image::LocalAddPrinterDriverEx.png[]

Innanzitutto, <> mostra che il modulo verifica che lo spooler sia in esecuzione e poi salta alla funzione SplAddPrinterDriverEx.

[[SplAddPrinterDriverEx]] .SplAddPrinterDriverEx image::SplAddPrinterDriverEx.png[]