Vinod ha le informazioni giuste, ma per approfondire un po ':
La Gestione controllo servizi (SCM, vedi anche MSDN ) è il processo genitore di tutti i servizi di Windows, ed è anche un Richoto Procedura chiamata (RPC) server. Quando viene avviato un servizio (e supponendo che il servizio non sia in un file binario condiviso, in genere svchost.exe , che è una configurazione utilizzata principalmente per i servizi scritti da Microsoft), SCM lancia il comando di servizio (nell'esempio, C:\Program Files (x86)\Donald Duck\Donald_Duck.exe e quindi attende che il servizio si riconnetta a SCM tramite RPC e segnala che è in fase di avvio . Se il servizio non riesce a segnalare allo SCM (o segnala che non è stato possibile avviare per qualche motivo, o non riesce a passare dallo stato di avvio a quello di esecuzione) entro un limite di tempo (30000 ms o 30 secondi) allora lo SCM ucciderà il processo .
A scopo di sfruttamento, ci sono tre modi per aggirare questo.
- Esegui il tuo lavoro all'interno della finestra dei 30 secondi (idealmente bene all'interno di esso, poiché su una macchina sufficientemente carica puoi spendere un sacco di quella finestra in attesa del tempo della CPU o dell'I / O). Se tutto quello che devi fare è, ad esempio, cambiare una chiave di registro o accedere a un file, o forse qualcosa come iniettare una DLL in un altro processo privilegiato, questo di solito va bene.
- Avvia un processo figlio che esegue il lavoro effettivo. Lo SCM ucciderà il processo che ha avviato, ma i figli di quel processo possono continuare l'esecuzione.
- Riferisci all'SCM che sei, di fatto, il servizio dirottato e stai facendo la cosa giusta. Questo non è banale, ma in realtà non è così difficile se si conosce una programmazione C o, in particolare, Win32 (in particolare, non è necessario sapere nulla di RPC, poiché è tutto racchiuso in API
ServiceDoThing() Win32). Potrebbe essere necessario farlo se, ad esempio, è importante per il tuo scenario di exploit che il servizio sembra essere in esecuzione (forse qualche altro componente si preoccupa se l'avvio del servizio è riuscito, o qualche processo di monitoraggio si lamenterà con qualcuno se il lancio fallisce) . La documentazione sulla segnalazione di un programma di servizio si trova in MSDN .
Indipendentemente da tutto ciò, c'è qualcos'altro da considerare. A meno che qualcuno non abbia modificato le autorizzazioni NTFS dai loro valori predefiniti, non puoi effettivamente creare nessuno di quei file senza già essere un amministratore! Per impostazione predefinita, gli utenti non amministratori possono creare (o modifica) directory ma non file nella directory principale di un'unità e, naturalmente, la directory Program Files (x86) esiste già, quindi non è possibile crearne una nuova copia. Né puoi rinominarlo, per sostituirlo con un'altra directory che controlli. Inoltre, non puoi creare, modificare o rinominare i contenuti di Program Files o Program Files (x86) , senza i privilegi di amministratore.
Poiché avere i privilegi di amministratore equivale ad avere i privilegi di SISTEMA (cioè, un amministratore può prendere il controllo e modificare l'ACL su qualsiasi cosa a cui desidera accedere anche se normalmente è di solo SISTEMA, o può semplicemente lanciare un programma come SISTEMA) , se hai abbastanza privilegi per sfruttare questo errore di codifica, hai già tutti i privilegi che ti darebbe. In altre parole, non c'è Escalation of Privilege qui . È è ancora un errore di codifica e potrebbe avere un impatto sulla sicurezza su un sistema configurato in modo errato, ma a quel punto l'errore si riduce a chiunque abbia modificato gli ACL nella directory principale dell'unità o in Program Files (x86) directory.