SeTakeOwnershipPrivilege
Última actualización
¿Te fue útil?
Última actualización
¿Te fue útil?
SeTakeOwnershipPrivilege otorga a un usuario la capacidad de tomar posesión de cualquier "objeto protegible", es decir, objetos de Active Directory, archivos/carpetas NTFS, impresoras, claves de registro, servicios y procesos. Este privilegio asigna derechos WRITE_OWNER sobre un objeto, lo que significa que el usuario puede cambiar el propietario dentro del descriptor de seguridad del objeto. Los administradores tienen asignado este privilegio de forma predeterminada. Si bien es raro encontrar una cuenta de usuario estándar con este privilegio, podemos encontrarnos con una cuenta de servicio que, por ejemplo, tenga la tarea de ejecutar trabajos de respaldo e instantáneas VSS a las que se les asigne este privilegio.
También se le pueden asignar algunos otros, como SeBackupPrivilege
, SeRestorePrivilege
, y SeSecurityPrivilege
para controlar los privilegios de esta cuenta a un nivel más granular y no otorgarle a la cuenta derechos de administrador local completos. Estos privilegios por sí solos probablemente se podrían usar para escalar privilegios. Aún así, puede haber ocasiones en las que necesitemos tomar posesión de archivos específicos porque otros métodos están bloqueados o no funcionan como se espera. Abusar de este privilegio es un caso extremo. Aún así, vale la pena comprenderlo en profundidad, especialmente porque también podemos encontrarnos en un escenario en un entorno de Active Directory donde podemos asignar este derecho a un usuario específico que podemos controlar y aprovecharlo para leer un archivo confidencial en un recurso compartido de archivos.
La configuración se puede establecer en la Política de grupo en:
Computer Configuration
⇾ Windows Settings
⇾ Security Settings
⇾ Local Policies
⇾User Rights Assignment
Con este privilegio, un usuario podría tomar posesión de cualquier archivo u objeto y realizar cambios que podrían implicar el acceso a datos confidenciales, Remote Code Execution
( RCE
) o Denial-of-Service
(DOS).
Supongamos que nos encontramos con un usuario con este privilegio o se lo asignamos mediante un ataque como el abuso de GPO mediante SharpGPOAbuse . En ese caso, podríamos usar este privilegio para tomar el control de una carpeta compartida o archivos confidenciales como un documento que contenga contraseñas o una clave SSH.
Repasemos los privilegios de nuestro usuario actual.
Observe que en el resultado se observa que el privilegio no está habilitado. Podemos habilitarlo mediante este script que se detalla en esta publicación del blog, así como también este otro que se basa en el concepto inicial.
A continuación, elija un archivo de destino y confirme la propiedad actual. Para nuestros propósitos, apuntaremos a un archivo interesante que se encuentre en un recurso compartido de archivos. Es común encontrar recursos compartidos de archivos con directorios Public
y Private
con subdirectorios configurados por departamento. Dado el rol de un usuario en la empresa, a menudo puede acceder a archivos/directorios específicos. Incluso con una estructura como esta, un administrador de sistemas puede configurar incorrectamente los permisos en directorios y subdirectorios, lo que hace que los recursos compartidos de archivos sean una rica fuente de información para nosotros una vez que hayamos obtenido las credenciales de Active Directory (y, a veces, incluso sin necesidad de credenciales).
Para nuestro escenario, supongamos que tenemos acceso al recurso compartido de archivos de la empresa de destino y podemos explorar libremente tanto los subdirectorios Private
como Public
. En su mayor parte, encontramos que los permisos están configurados de manera estricta y no hemos encontrado ninguna información interesante en la parte Public
del recurso compartido de archivos. Al explorar la parte Private
, descubrimos que todos los usuarios del dominio pueden enumerar el contenido de ciertos subdirectorios, pero reciben un mensaje Access denied
cuando intentan leer el contenido de la mayoría de los archivos. Encontramos un archivo nombrado cred.txt
en el subdirectorio IT
de la carpeta Private
del recurso compartido durante nuestra enumeración.
Dado que nuestra cuenta de usuario tiene SeTakeOwnershipPrivilege
(que puede que ya haya sido otorgada), o explotamos alguna otra configuración incorrecta como un Objeto de Política de Grupo (GPO) demasiado permisivo para otorgarle a nuestra cuenta de usuario ese privilegio), podemos aprovecharlo para leer cualquier archivo que elijamos.
Nota: tenga mucho cuidado al realizar una acción potencialmente destructiva, como cambiar la propiedad de un archivo, ya que podría provocar que una aplicación deje de funcionar o interrumpir el funcionamiento de los usuarios del objeto de destino. Cambiar la propiedad de un archivo importante, como un archivo web.config
activo, no es algo que haríamos sin el consentimiento previo de nuestro cliente. Además, cambiar la propiedad de un archivo enterrado en varios subdirectorios (mientras se cambia el permiso de cada subdirectorio al mismo tiempo) puede ser difícil de revertir y debe evitarse.
Revisemos nuestro archivo de destino para recopilar un poco más de información sobre él.
Podemos ver que no se muestra el propietario, lo que significa que probablemente no tengamos suficientes permisos sobre el objeto para ver esos detalles. Podemos retroceder un poco y verificar quién es el propietario del directorio de TI.
Podemos ver que el recurso compartido de TI parece ser propiedad de una cuenta de servicio sccm_svc
y contiene un archivo cred.txt
con algunos datos en su interior.
Ahora podemos usar el binario takeown de Windows para cambiar la propiedad del archivo.
Podemos confirmar la propiedad utilizando el mismo comando que antes. Ahora vemos que nuestra cuenta de usuario es la propietaria del archivo.
Es posible que aún no podamos leer el archivo y necesitemos modificar la ACL del archivo icacls
para poder leerlo.
Otorguemos a nuestro usuario privilegios completos sobre el archivo de destino.
Si todo salió según lo planeado, ahora podemos leer el archivo de destino desde la línea de comandos, abrirlo si tenemos acceso RDP o copiarlo a nuestro sistema de ataque para un procesamiento adicional (como crackear la contraseña de una base de datos KeePass).
Después de realizar estos cambios, nos gustaría hacer todo lo posible para revertir los permisos o la propiedad de los archivos. Si por alguna razón no podemos hacerlo, debemos avisar a nuestro cliente y documentar cuidadosamente las modificaciones en un apéndice de nuestro informe. Nuevamente, aprovechar este permiso puede considerarse una acción destructiva y debe hacerse con mucho cuidado. Algunos clientes pueden preferir que documentemos la capacidad de realizar la acción como evidencia de una configuración incorrecta, pero no que aprovechemos por completo la falla debido al impacto potencial.
Archivos de interés
Algunos archivos locales de interés pueden incluir:
También podemos encontrarnos con archivos .kdbx
de base de datos de KeePass, cuadernos de OneNote, archivos como passwords.*
, pass.*
, creds.*
, scripts, otros archivos de configuración, archivos de disco duro virtual y más, de los cuales podemos extraer información confidencial para elevar nuestros privilegios y ampliar nuestro acceso.
Aproveche los derechos
SeTakeOwnershipPrivilege
sobre el archivo ubicado en "C:\TakeOwn\flag.txt
" y envíe el contenido.
Abrimos un Powershell de administrador y vemos el privilegio SeTakeOwnershipPrivilege
pero no está habilitado.
En el directorio C://Tool tenemos todos los binarios disponibles, incluidos los que usaremos: Enable-Privilege.ps1
y EnableAllTokenPrivs.ps1
Vemos que ya tenemos el privilegio SeTakeOwnershipPrivilege
habilitado.
Revisemos el archivo de flag.txt para recopilar un poco más de información sobre él. Ya sabemos que está en la ruta C:\TakeOwn\flag.txt
Vemos que no tiene ningún owner asociado o no es visible
Con takeown cambiamos el propietario del archivo al usuario actual.
Aún seguimos sin tener permisos para leer el archivo:
Vamos a usar icacls para otorgar permisos de lectura y escritura al usuario htb-student
.
Finalmente obtenemos la flag!