Permisos débiles
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
Los permisos en los sistemas Windows son complicados y difíciles de conseguir. Una ligera modificación en un lugar puede introducir un fallo en otro. Como pentesters, debemos comprender cómo funcionan los permisos en Windows y las distintas formas en que se pueden aprovechar las configuraciones erróneas para aumentar los privilegios. Los fallos relacionados con los permisos que se analizan en esta sección son relativamente poco comunes en las aplicaciones de software publicadas por grandes proveedores (pero se ven de vez en cuando), pero son comunes en el software de terceros de proveedores más pequeños, el software de código abierto y las aplicaciones personalizadas.
Los servicios suelen instalarse con privilegios de SYSTEM, por lo que aprovechar un fallo relacionado con los permisos de un servicio a menudo puede llevar al control total del sistema de destino. Independientemente del entorno, siempre debemos comprobar si hay permisos débiles y poder hacerlo tanto con la ayuda de herramientas como de forma manual en caso de que nos encontremos en una situación en la que no tengamos nuestras herramientas disponibles.
Podemos utilizar del conjunto de herramientas GhostPack para verificar si hay binarios de servicio que tengan ACL débiles.
La herramienta identifica el PC Security Management Service
, que ejecuta el binario SecurityService.exe
cuando se inicia.
Comprobación de permisos con icacls
Reemplazo de binario de servicio
Este servicio también lo pueden iniciar usuarios sin privilegios, por lo que podemos hacer una copia de seguridad del binario original y reemplazarlo con un binario malicioso generado con msfvenom
. Puede brindarnos un reverse shell como SYSTEM
, o agregar un usuario administrador local y brindarnos control administrativo total sobre la máquina.
Verifiquemos nuevamente la salida de SharpUp
para ver si hay servicios modificables. Vemos que es posible que WindscribeService
esté mal configurado.
Al verificar el grupo de administradores locales se confirma que nuestro usuario htb-student
no es miembro.
Podemos usar nuestros permisos para cambiar la ruta binaria de forma maliciosa. Cambiémosla para agregar a nuestro usuario al grupo de administradores locales. Podríamos configurar la ruta binaria para ejecutar cualquier comando o ejecutable que elijamos (como un reverse shell).
A continuación, debemos detener el servicio, para que el nuevo comando binpath
se ejecute la próxima vez que se inicie.
Dado que tenemos control total sobre el servicio, podemos iniciarlo nuevamente y el comando que colocamos en el binpath
se ejecutará aunque se devuelva un mensaje de error. El servicio no se inicia porque el binpath
no apunta al ejecutable del servicio real. Aún así, el ejecutable se ejecutará cuando el sistema intente iniciar el servicio antes de generar un error y detener el servicio nuevamente, ejecutando cualquier comando que especifiquemos en el binpath
.
Por último, verifique que nuestro usuario haya sido agregado al grupo de administradores locales.
Podemos limpiar después de nosotros y asegurarnos de que el servicio esté funcionando correctamente deteniéndolo y restableciendo la ruta binaria al ejecutable del servicio original.
Si todo va según lo previsto, podremos reiniciar el servicio sin problemas.
Al consultar el servicio se mostrará que se está ejecutando nuevamente según lo previsto.
Cuando se instala un servicio, la configuración del registro especifica una ruta al binario que se debe ejecutar al iniciar el servicio. Si este binario no está encapsulado entre comillas, Windows intentará ubicarlo en carpetas diferentes. Tome la ruta binaria de ejemplo que se muestra a continuación.
Windows decidirá el método de ejecución de un programa en función de su extensión de archivo, por lo que no es necesario especificarla. Windows intentará cargar los siguientes ejecutables potenciales en orden al iniciar el servicio, lo que implica que es un archivo .exe:
C:\Program
C:\Program Files
C:\Program Files (x86)\System
C:\Program Files (x86)\System Explorer\service\SystemExplorerService64
Servicio de consulta
Si podemos crear los siguientes archivos, podremos secuestrar el binario del servicio y obtener la ejecución del comando en el contexto del servicio, en este caso, NT AUTHORITY\SYSTEM
.
C:\Program.exe\
C:\Program Files (x86)\System.exe
Sin embargo, la creación de archivos en la raíz de la unidad o en la carpeta de archivos de programa requiere privilegios administrativos. Incluso si el sistema se hubiera configurado incorrectamente para permitir esto, el usuario probablemente no podría reiniciar el servicio y dependería de un reinicio del sistema para aumentar los privilegios. Aunque no es raro encontrar aplicaciones con rutas de servicio sin comillas, no suele ser un problema explotable.
Podemos identificar rutas binarias de servicio sin comillas usando el siguiente comando.
También vale la pena buscar ACL de servicios débiles en el Registro de Windows. Podemos hacerlo usando accesschk
.
Podemos abusar de esto usando el cmdlet de PowerShell Set-ItemProperty
para cambiar el ImagePath
valor, usando un comando como:
Comprobar programas de inicio
Podemos utilizar WMIC para ver qué programas se ejecutan al iniciar el sistema. Supongamos que tenemos permisos de escritura en el registro para un binario determinado o que podemos sobrescribir un binario que figura en la lista. En ese caso, es posible que podamos escalar privilegios a otro usuario la próxima vez que el usuario inicie sesión.
Aumente los privilegios en el host de destino utilizando las técnicas que se muestran en esta sección. Envíe el contenido de la flag en la carpeta
WeakPerms
en el escritorio del administrador.
No podemos iniciar Powershell como admin ya que nos pide contraseña de administrador. Seguiremos como un usuario normal.
Vemos que es posible que WindscribeService
esté mal configurado.
Al verificar el grupo de administradores locales se confirma que nuestro usuario htb-student
no es miembro.
Podemos usar nuestros permisos para cambiar la ruta binaria de forma maliciosa desde un CMD. Cambiémosla para agregar a nuestro usuario al grupo de administradores locales. Podríamos configurar la ruta binaria para ejecutar cualquier comando o ejecutable que elijamos (como un reverse shell).
Dado que tenemos control total sobre el servicio, podemos iniciarlo nuevamente y el comando que colocamos en el binpath
se ejecutará aunque se devuelva un mensaje de error.
Una vez hecho esto reiniciamos el equipo y volvemos a acceder para que se apliquen los cambios:
Verificamos que nuestro usuario ha sido agregado al grupo de administradores locales.
Abrimos una Powershell como administrador ya que no nos pide contraseña por estar dentro del grupo Administrators y ya podríamos acceder a la flag:
Usando podemos verificar la vulnerabilidad y ver que a los grupos EVERYONE
y BUILTIN\Users
se les han otorgado permisos completos al directorio y, por lo tanto, cualquier usuario del sistema sin privilegios puede manipular el directorio y su contenido.
A continuación, utilizaremos de la suite Sysinternals para enumerar los permisos del servicio. Los indicadores que utilizamos, en orden, son -q
(omitir banner), -u
(suprimir errores), -v
(verbose), -c
(especificar el nombre de un servicio de Windows) y -w
(mostrar solo objetos que tienen acceso de escritura). Aquí podemos ver que todos los usuarios autenticados tienen derechos sobre el servicio, lo que significa control total de lectura y escritura sobre él.
Otro ejemplo notable es el Windows , que se encarga de descargar e instalar actualizaciones del sistema operativo. Se considera un servicio esencial de Windows y no se puede eliminar. Dado que es responsable de realizar cambios en el sistema operativo mediante la instalación de actualizaciones de seguridad y funciones, se ejecuta como la cuenta todopoderosa NT AUTHORITY\SYSTEM
. Antes de instalar el parche de seguridad relacionado con , era posible elevar los privilegios de una cuenta de servicio a SYSTEM
. Esto se debía a permisos débiles, que permitían a las cuentas de servicio modificar la ruta binaria del servicio e iniciar/detener el servicio.
Esta y detallan muchas posibles ubicaciones de ejecución automática en los sistemas Windows.
Podemos ver que todos los usuarios autenticados tienen derechos sobre el servicio, lo que significa control total de lectura y escritura sobre él.