wh04m1001/diagtrackeopExploit di escalation dei privilegi di Windows che abusa di SeImpersonate tramite DiagTrack RPC, utilizzando Secondary Logon per ottenere un token INTERACTIVE e i privilegi di SYSTEM.
Solo un altro modo per abusare del privilegio SeImpersonate.
Questa PoC si basa su questo blog di @crisprss.
In questo blog @crisprss ha mostrato un metodo interessante per abusare del privilegio SeImpersonate usando AzureAttestService, che è incluso nelle versioni recenti di SQL server; la PoC per questo può essere trovata qui https://github.com/crisprss/magicAzureAttestService.
In quel blog mostra anche un altro possibile modo per abusare del privilegio SeImpersonate usando il servizio DiagTrack, ma l'autore non è riuscito a trasformarlo in un'arma; questo è tratto da quel blog (tradotto dal cinese, quindi forse non accurato al 100%):
But just when I thought it could be triggered normally, I didn't realize that this service is transparent to service users, which also means that it is not feasible to simulate pipeline privilege escalation through service users, because service users such as sqlserver There is no way to call the RPC interface, which also means that you can only escalate rights from the administrator user to SYSTEM in this way, so here is just a process sharing
E sì, se provi a chiamare il metodo esposto da quel server RPC da un utente di servizio, ottieni un errore di accesso negato
Ma perché gli utenti normali, non privilegiati, possono chiamare questo metodo?
La mia ipotesi era che, poiché gli utenti di servizio operano nella sessione 0, non abbiano NT AUTHORITY\INTERACTIVE SID nel loro token, mentre gli utenti normali che accedono via RDP o in modo interattivo ce l'hanno.
Quindi come possiamo ottenere NT AUTHORITY\INTERACTIVE SID dalla sessione 0? In realtà molto semplice: il servizio Secondary Logon lo farà per noi. Possiamo usare la chiamata API LogonUser per ottenere un token con NT AUTHORITY\INTERACTIVE SID e non abbiamo bisogno di credenziali valide perché useremo il tipo di logon NewCredentials(9). Quando viene usato il tipo di logon NewCredentials, Secondary Logon creerà una nuova sessione di logon e copierà il token del chiamante, ma inserirà anche un NT AUTHORITY\INTERACTIVE SID; questa è una situazione perfetta per noi perché non dobbiamo avere credenziali valide (le credenziali usate con il tipo di logon NewCredentials non vengono verificate finché l'utente non tenta di accedere a una risorsa di rete).
Quindi, ora che abbiamo un token con NT AUTHORITY\INTERACTIVE SID, l'exploit funzionerà? Sì, funzionerà :D
Questa PoC è testata su Windows 10 e Windows 2019.
@crisprss - https://www.crisprx.top/archives/561