Abusing Service Misconfigurations
Windows Services
Los servicios de Windows son administrados por el Administrador de control de servicios (SCM). El SCM es un proceso encargado de gestionar el estado de los servicios según sea necesario, comprobar el estado actual de cualquier servicio determinado y, en general, proporcionar una forma de configurar los servicios.
Cada servicio en una máquina Windows tendrá un ejecutable asociado que el SCM ejecutará cada vez que se inicie un servicio. Es importante tener en cuenta que los ejecutables de servicio implementan funciones especiales para poder comunicarse con el SCM y, por lo tanto, ningún ejecutable puede iniciarse como servicio con éxito. Cada servicio también especifica la cuenta de usuario bajo la cual se ejecutará el servicio.
Para comprender mejor la estructura de un servicio, verifiquemos la configuración del servicio apphostsvc con el sc qc
comando:
Aquí podemos ver que el ejecutable asociado se especifica a través del parámetro BINARY_PATH_NAME y la cuenta utilizada para ejecutar el servicio se muestra en el parámetro SERVICE_START_NAME .
Los servicios tienen una Lista de control de acceso discrecional (DACL), que indica quién tiene permiso para iniciar, detener, pausar, consultar el estado, consultar la configuración o reconfigurar el servicio, entre otros privilegios. El DACL se puede ver desde Process Hacker (disponible en el escritorio de su máquina):
Todas las configuraciones de servicios se almacenan en el registro en HKLM\SYSTEM\CurrentControlSet\Services\
:
Existe una subclave para cada servicio del sistema. Nuevamente, podemos ver el ejecutable asociado en el valor ImagePath y la cuenta utilizada para iniciar el servicio en el valor ObjectName . Si se ha configurado una DACL para el servicio, se almacenará en una subclave llamada Seguridad . Como ya habrás adivinado, sólo los administradores pueden modificar dichas entradas de registro de forma predeterminada.
Insecure Permissions on Service Executable
Si el ejecutable asociado con un servicio tiene permisos débiles que permiten a un atacante modificarlo o reemplazarlo, el atacante puede obtener los privilegios de la cuenta del servicio de manera trivial.
Para entender cómo funciona esto, veamos una vulnerabilidad encontrada en Splinterware System Scheduler. Para comenzar, consultaremos la configuración del servicio usando sc
:
Podemos ver que el servicio instalado por el software vulnerable se ejecuta como svcuser1 y el ejecutable asociado al servicio está en formato C:\Progra~2\System~1\WService.exe
. Luego procedemos a verificar los permisos del ejecutable:
Y aquí tenemos algo interesante. El grupo Everyone
tiene permisos de modificación (M) en el ejecutable del servicio. Esto significa que podemos simplemente sobrescribirlo con cualquier carga útil de nuestra preferencia y el servicio lo ejecutará con los privilegios de la cuenta de usuario configurada.
Generemos una carga útil de servicio exe usando msfvenom y la sirvamos a través de un servidor web Python:
Luego podemos extraer el fichero malicioso desde la Powershell con el siguiente comando:
Una vez que el archivo malicioso está en el servidor de Windows, procedemos a reemplazar el ejecutable del servicio con nuestra carga útil. Dado que necesitamos otro usuario para ejecutar nuestro archivo malicioso, también queremos otorgar permisos completos al grupo Everyone
:
Ponemos a la escucha con nc
en nuestra máquina atacante:
Y finalmente, reinicie el servicio. Si bien en un escenario normal, probablemente tendría que esperar a que se reinicie el servicio, se le han asignado privilegios para reiniciar el servicio usted mismo para ahorrarle algo de tiempo. Utilice los siguientes comandos desde el símbolo del sistema cmd.exe:
Nota: PowerShell tiene sc
como alias Set-Content
, por lo tanto, debe usarlo sc.exe
para controlar los servicios con PowerShell de esta manera.
Como resultado, obtendrás una reverse shell con privilegios svcusr1:
Unquoted Service Paths
Cuando no podemos escribir directamente en los ejecutables del servicio , todavía existe la posibilidad de forzar a un servicio a ejecutar ejecutables arbitrarios mediante el uso de una característica bastante oscura.
Cuando se trabaja con servicios de Windows, ocurre un comportamiento muy particular cuando el servicio está configurado para apuntar a un ejecutable "sin comillas". Por si en caso con comillas queremos decir que la ruta del ejecutable asociado no está entre comillas correctamente para tener en cuenta los espacios en el comando.
Como ejemplo, veamos la diferencia entre dos servicios (estos servicios se utilizan sólo como ejemplos y es posible que no estén disponibles en su máquina). El primer servicio utilizará una cita adecuada para que el SCM sepa sin lugar a dudas que tiene que ejecutar el archivo binario señalado por "C:\Program Files\RealVNC\VNC Server\vncserver.exe"
, seguido de los parámetros dados:
Recuerde: PowerShell tiene sc
como alias de Set-Content
, por lo tanto, debe usar sc.exe
para controlar los servicios si se encuentra en un mensaje de PowerShell. Ahora veamos otro servicio sin cotización adecuada:
Cuando el SCM intenta ejecutar el binario asociado, surge un problema. Dado que hay espacios en el nombre de la carpeta "Disk Sorter Enterprise", el comando se vuelve ambiguo y el SCM no sabe cuál de los siguientes está intentando ejecutar:
C:\Mis Programas\Disk.exe
Clasificador
Empresa\bin\disksrs.exe
C:\Mis Programas\Disk Sorter.exe
Empresa\bin\disksrs.exe
C:\Mis programas\Disk Sorter Enterprise\bin\disksrs.exe
Esto tiene que ver con cómo el símbolo del sistema analiza un comando. Normalmente, cuando envía un comando, los espacios se utilizan como separadores de argumentos, a menos que formen parte de una cadena entrecomillada. Esto significa que la interpretación "correcta" del comando sin comillas sería ejecutar C:\\MyPrograms\\Disk.exe
y tomar el resto como argumentos.
En lugar de fallar como probablemente debería, SCM intenta ayudar al usuario y comienza a buscar cada uno de los binarios en el orden que se muestra en la tabla:
Primero, busque
C:\\MyPrograms\\Disk.exe
. Si existe, el servicio ejecutará este ejecutable.Si este último no existe, buscará
C:\\MyPrograms\\Disk Sorter.exe
. Si existe, el servicio ejecutará este ejecutable.Si este último no existe, buscará
C:\\MyPrograms\\Disk Sorter Enterprise\\bin\\disksrs.exe
. Se espera que esta opción funcione correctamente y normalmente se ejecutará en una instalación predeterminada.
A partir de este comportamiento, el problema se hace evidente. Si un atacante crea cualquiera de los ejecutables que se buscan antes del ejecutable del servicio esperado, puede obligar al servicio a ejecutar un ejecutable arbitrario.
Si bien esto suena trivial, la mayoría de los ejecutables del servicio se instalarán de C:\Program Files
forma C:\Program Files (x86)
predeterminada, lo que los usuarios sin privilegios no pueden escribir. Esto evita que se explote cualquier servicio vulnerable. Hay excepciones a esta regla: - Algunos instaladores cambian los permisos de las carpetas instaladas, haciendo que los servicios sean vulnerables. - Un administrador podría decidir instalar los archivos binarios del servicio en una ruta no predeterminada. Si ese camino es escribible en todo el mundo, la vulnerabilidad puede explotarse.
En nuestro caso, el administrador instaló los archivos binarios del Disk Sorter en formato c:\MyPrograms
. De forma predeterminada, hereda los permisos del C:\
directorio, lo que permite a cualquier usuario crear archivos y carpetas en él. Podemos comprobar esto usando icacls
:
El BUILTIN\\Users
grupo tiene privilegios AD y WD , lo que permite al usuario crear subdirectorios y archivos, respectivamente.
El proceso de crear un fichero malicioso de servicio .exe con msfvenom y transferirla al host de destino es el mismo que antes, así que siéntase libre de crear el siguiente fichero y cargarla en el servidor como antes. También iniciaremos un oyente para recibir el shell inverso cuando se ejecute:
Una vez que la carga útil esté en el servidor, muévala a cualquiera de las ubicaciones donde pueda ocurrir un secuestro. En este caso, moveremos nuestra carga útil a C:\MyPrograms\Disk.exe
. También otorgaremos a todos permisos completos sobre el archivo para asegurarnos de que el servicio pueda ejecutarlo:
Una vez que se reinicia el servicio, su carga útil debería ejecutarse:
Como resultado, obtendrás un shell inverso con privilegios svcusr2:
Insecure Service Permissions
Es posible que aún tenga una pequeña posibilidad de aprovechar un servicio si el DACL ejecutable del servicio está bien configurado y la ruta binaria del servicio está citada correctamente. Si el servicio DACL (no el DACL ejecutable del servicio) le permite modificar la configuración de un servicio, podrá reconfigurar el servicio. Esto le permitirá señalar cualquier ejecutable que necesite y ejecutarlo con cualquier cuenta que prefiera, incluido el propio SISTEMA.
Aquí podemos ver que el BUILTIN\\Users
grupo tiene el permiso SERVICE_ALL_ACCESS, lo que significa que cualquier usuario puede reconfigurar el servicio.
Antes de cambiar el servicio, construyamos otro shell inverso de servicio .exe e iniciemos un detector en la máquina del atacante:
Luego transferiremos el ejecutable del shell inverso a la máquina de destino y lo almacenaremos en C:\Users\thm-unpriv\rev-svc3.exe
. Siéntete libre de usar wget para transferir tu ejecutable y moverlo a la ubicación deseada. Recuerde otorgar permisos a todos para ejecutar su carga útil:
Para cambiar el ejecutable asociado al servicio y la cuenta, podemos usar el siguiente comando (tenga en cuenta los espacios después de los signos iguales cuando use sc.exe):
Tenga en cuenta que podemos usar cualquier cuenta para ejecutar el servicio. Elegimos LocalSystem porque es la cuenta con mayor privilegio disponible. Para activar nuestra carga útil, todo lo que queda es reiniciar el servicio:
Y recibiremos un shell en la máquina de nuestro atacante con privilegios de SISTEMA:
Última actualización