Páginas

Mostrando entradas con la etiqueta CIFS. Mostrar todas las entradas
Mostrando entradas con la etiqueta CIFS. Mostrar todas las entradas

23 junio, 2020

Hydra, Medusa y Ncrack: Password cracking a servicios por fuerza bruta en profundidad y en anchura (Password spraying)

THC-Hydra, Medusa y Ncrack son herramientas para realizar ataques de fuerza bruta a servicios activos cliente/servidor como: ssh, ftp, rdp, smb, mysql, telnet, http, imap, vnc, etc.

Para mostrar el uso de estas herramientas usaré el siguiente escenario de ejemplos. Escaneando con nmap los equipos remotos y puertos empleados para cada tipo de servicio.
nmap -p 21 10.0.0.16      # Windows 7 servicio FTP
nmap -p 3389 10.0.0.16    # Windows 7 servicio RDP
nmap -p 445 10.0.0.16     # Windows 7 servicio SMB/CIFS
nmap -p 22 10.0.0.40      # Linux servicio SSH
hydra-fuerza-bruta-wordlist-ftp
Figura 1: Escaneo de puertos a máquina en servicios SSH, RDP, FTP y SMB.

THC-Hydra

Hydra es una de las herramientas más conocidas para este tipo de ataques a servicios online. Hay que tener en cuenta que este tipo de ataques son activos y no pasivos, por lo que hay una interacción con el servicio que vamos comprometer mediante un intento de autenticación de credenciales.

Esto creará un evento en el log de la máquina remota servidora del servicio, en el caso de tener algún tipo de control de eventos en el endpoint se podrían detectar intentos de conexión con credenciales erróneas y disparar alertas.

Principalmente se pueden definir 3 tipos de ataques:
  • Fuerza bruta por diccionario con múltiples usuarios y passwords
  • Fuerza bruta en profundidad
  • Fuerza bruta en anchura o Password spraying

Fuerza bruta por diccionario con múltiples usuarios y passwords

Este tipo de ataques se caracterizan por usar un wordlist tanto para un conjunto de usuarios y de contraseñas en plano previamente definidos. En el siguiente ejemplo hay nombres de usuarios y contraseñas definidos en los ficheros "users" y "wordlist" respectivamente a un intento de conexión a la máquina remota 10.0.0.16 que será un Windows 7 con un servicio FTP.
hydra -L users -P wordlist -vV 10.0.0.16 ftp
  • -L: Fichero que contiene la lista de usuarios.
  • -P: Fichero que contiene la lista de passwords.
  • -v: Modo verbose
  • -V: Muestra el intento por cada login+pass
  • 10.0.0.16 ftp: Especificamos la IP de la máquina remota y el tipo de servicio.
El usuario "ventas" y la password "Pa$$w0rd123" serán las credenciales válidas para acceder al servicio FTP. Hydra probará intentos de conexión al servicio haciendo un barrido entre las distintas posibilidades combinatorias entre los distintos usuarios y contraseñas definidas.

hydra-fuerza-bruta-wordlist-ftp
Figura 2: Hydra - Fuerza bruta por diccionario con múltiples usuarios y passwords al servicio FTP.

Como ya comenté anteriormente, estos ataques son reconocimiento activos por lo que dejan un rastro en el log del servidor remoto. En la siguiente captura se puede ver el intento de conexión fallida al intentar autenticarse con el usuario "luis" y su password en el servidor FTP remoto.

log-intento-inicio-sesion-ftp-filezilla
Figura 3: Log en el servidor FTP del intento de autenticación.  

Fuerza bruta en profundidad

Fuerza bruta en profundidad o fuerza bruta, a secas: Se trata utilizar muchas contraseñas para una sola cuenta de usuario.

Como ejemplo se realiza un ataque de fuerza bruta al servicio RDP a una cuenta concreta llamada "maria" y probar un wordlist con varias contraseñas posibles.
hydra -l maria -P wordlist -vV 10.0.0.16 rdp
  • -l: Nombre de usuario único.
  • -P: Fichero de lista de contraseñas.
Un detalle a tener en cuenta cuando realice los intentos de conexión es que si el user/pass son correctos cerrará la sesión del usuario actual que esté conectado a la máquina si lo hubiese. 

hydra-fuerza-bruta-profundidad-rdp
Figura 4: Hydra - Fuerza bruta en profundidad al servicio RDP.

Al igual que el servicio anterior RDP también dejará un evento registrado en equipo remoto. Pudiendo ver la IP y puerto del equipo que intentó realizar la conexión así como que usuario intentó autenticarse.

log-intento-inicio-sesion-rdp
Figura 5: Log en el equipo remoto por un intento de autenticación al servicio RDP.

Fuerza bruta en anchura o Password spraying

Fuerza bruta en anchura o Password spraying: Se trata de usar la misma contraseña para muchas cuentas de usuario.

Aprovechando el mismo escenario que en el ejemplo anterior, se muestra un ataque de password spraying en el servicio de recursos compartidos de Windows SMB. 
hydra -L users -p M4ria.12 -vV 10.0.0.16 smb
  • -L: Fichero de lista de usuarios.
  • -p: Contraseña única.
Haciendo referencia a un fichero llamado "users" que contiene una lista de usuarios se le especifica una misma contraseña única.

hydra-fuerza-bruta-anchura-smb
Figura 6: Hydra - Fuerza bruta en anchura o password spraying al servicio SMB.

Como cualquier servicio de Windows de un protocolo conocido, al igual que los casos anteriores, se creará un evento relacionado obteniendo el nombre de usuario y equipo desde donde se intentó realizar la conexión de autenticación. 

log-intento-inicio-sesion-smb
Figura 7: Log en el equipo remoto por un intento de autenticación al servicio SMB.

En cualquier caso cuando un usuario o password específico se usarán los argumentos -l o -p en minúscula y en el caso de hacer referencia a wordlists serán -L o -P en mayúscula.

Fuerza bruta en servicios web como Facebook o Instagram

Servicios que permitan una autenticación web, por ejemplo redes sociales como Facebook o Instagram también es posible realizar ataques de fuerza bruta, aunque el número de intentos es muy limitado y en el caso de fallar varias veces consecutivas es muy probable que la cuenta con la que estamos probando se desactive temporalmente como medida de seguridad, precisamente para evitar este tipo de ataques.

Lo primero sería conocer la IP que nos está respondiendo, no siempre será la misma, puede variar según la zona geográfica y el balanceador que nos responda. Con un simple "ping facebook.com" o "ping insgram.com" obtendremos la IP en ese momento.

Para protocolo HTTPS puerto 443 (https-get).
hydra -L users -P pass -vV <FACEBOOK_IP> -s 443 -f https-get /login
hydra -L users -P pass -vV <INSTAGRAM_IP> -s 443 -f https-get /accounts/login/
Para protocolo HTTP puerto 80 (http-get).
hydra -L users -P pass -vV <FACEBOOK_IP> -s 80 -f http-get /login
hydra -L users -P pass -vV <INSTAGRAM_IP> -s 80 -f http-get /accounts/login/ 
Figura 8: Ataque de fuerza bruta a servicios web como Facebook o Instagram.

Medusa

Medusa es otra alternativa a THC-Hydra. Los tipos de servicios son reconocidos por el tipo de protocolo que usan. 

Medusa utiliza módulos para referirse al protocolo del servicio, es posible implementar diversos módulos a parte de los que trae por defecto. 

Estos módulos están disponibles en el path.
/usr/lib/x86_64-linux-gnu/medusa/modules

Para el siguiente ejemplo cambiaremos de escenario. Un servidor SSH expuesto en un sistema Linux se intentará un ataque de fuerza bruta con wordlists de un conjunto de usuarios y passwords.
medusa -U users -P wordlist -h 10.0.0.40 -M ssh
  • -U: Fichero de lista de usuarios
  • -P: Fichero de lista de contraseñas
  • -h: Host remoto
  • -M: Tipo de módulo.
En la siguiente captura se pueden ver los intentos de conexión con las distintas combinaciones posibles entre user/pass. 

medusa-fuerza-bruta-ssh
Figura 9: Medusa - Fuerza bruta en profundidad al servicio SSH.

Al tratarse de un ataque de fuerza bruta, son ataques activos por lo que este tipo de conexiones también dejan un registro de log en el fichero /var/log/auth.log mostrando fecha, nombre de usuario, IP y puerto desde donde se intentó realizar la conexión de autenticación.

log-fuerza-bruta-ssh
Figura 10: Log en la máquina remota del intento de autenticación al servicio SSH.

Ncrack

Ncrack desarrollada por nmap.org es otra herramienta alternativa a THC-Hydra y Medusa. Se caracteriza por su gran velocidad, su enfoque modular y la capacidad de escalar a múltiples hosts. Su sintaxis es similar a nmap

Continuando el ejemplo anterior, realizamos un ataque de fuerza bruta al servicio SSH con un mismo usuario usando una wordlist de contraseñas.
ncrack -p 22 --user pepe -P wordlist 10.0.0.40
  • -p: Puerto estándar usando por el servicio.
  • --user: Nombre de usuario único.
  • -P: Fichero de lista de contraseñas.
Al igual que THC-Hydra y Medusa, Ncrack también deja su registro en el log. En la siguiente captura se observa como en un primer intento con el usuario juan no fue posible realizar la conexión con el usuario juan pero si con el usuario pepe, lo cual es correcto. Con una lista de 8 contraseñas posibles, en ambos el tiempo de comprobación fue de 3 segundos.

ncrack-fuerza-bruta-ssh
Figura 11: Ncrack - Fuerza bruta en profundidad al servicio SSH. 

Saludos!

26 agosto, 2019

Compartir recursos con Samba sin usuario y sin password entre Linux y Windows

Para poder compartir recursos Samba desde Linux a Windows sin usar ningún login usuario/password de modo que sea un acceso invitado, debemos configurar una serie de directivas en el fichero de configuración de Samba.

Instalación de Samba (en el caso de distribuciones basadas en Debian).
sudo apt install samba samba-client smbfs
Creamos la carpeta que vamos a compartir. Un usuario externo que tiene acceso al equipo a través de Samba, el sistema le da como nombre de usuario nobody y como nombre de grupo nogroup, por lo que hacemos propietarios de esta carpeta a los usuarios externos.
sudo mkdir /mnt/publica
sudo chmod 777 /mnt/publica
sudo chown nobody:nogroup /mnt/publica
Editamos el fichero de configuración de Samba.
/etc/samba/smb.conf
Añadimos o modificamos las siguientes directivas. Workgroup será el nombre del grupo de trabajo (en caso de no formar parte de un entorno de dominio) y permitimos el acceso a invitados.
[global]
   workgroup = WORKGROUP
   usershare allow guests = yes
Establecemos el recurso compartido.
[NombreRecursoCompartido]
   comment = Mi recurso compartido
   path = /mnt/publica
   browseable = Yes
   writeable = Yes
   public = yes

security = SHARE
  • browseable: Atravesar y navegar entre las subcarpetas del recurso compartido.
  • writeable: Escribir en el recurso compartido.
  • public: el sinónimo de "guest ok", permite el ver y acceder al recurso comapartido de manera pública.
  • security: Por defecto suele estar comentado como ";   security = user", permite que se pueda acceder sin establecer ningún nombre de usuario.
La directiva "security" es la que realmente permita un acceso tipo invitado desde cualquier otro sistema que no sea Linux ya se Windows o MacOS.

Debe colocarse sin espacios y al final del fichero de configuración smb.conf, un salto de línea después del último recurso compartido.

Reiniciamos el servidor Samba para aplicar los cambios.
sudo systemctl restart samba
Hago referencia a uno de mis repositorios sobre un caso práctico de este ejemplo.

Riesgo de seguridad

No se recomienda habilitar la directiva "usershare allow guests" por motivos de seguridad, la configuración por defecto estará deshabilitada con valor "No". 

12 marzo, 2019

Gestión de backups de recurso compartido CIFS a un servidor FTP remoto de forma sincronizada con rsync

Una forma de  realizar backups de ficheros o directorios independientes entre un sistema Windows y servidor FTP remoto y los ficheros a realizar el backup están en un recurso compartido CIFS (SMB) de Windows, si disponemos de un sistema Linux podremos montar en dos directorios el recurso compartido Windows y el servidor FTP remoto. A posteriori realizar la copia sincronizada con rsync entre el directorio montado con CIFS y el directorio remoto FTP donde se almacenará la copia.

Accedemos al sistema linux e instalamos los paquetes cifs-utils para poder montar sistemas de ficheros compartidos desde un sistema Windows y curlftpfs para montar el servidor FTP remoto.
sudo apt install -y cifs-utils
sudo apt install -y curlftpfs
Creamos un directorio para montar el recurso compartido Windows y otro para montar el espacio del servidor FTP remoto y otorgamos permisos de control total, aunque esto dependerá de la gestión de usuarios y grupos de como tengamos configurado el entorno Linux. (Como ejemplo se montará partiendo de /mnt).
mkdir /mnt/ftpbackup ; chmod -R 777 /mnt/ftpbackup
mkdir /mnt/cifsbackup ; chmod -R 777 /mnt/cifsbackup
Montamos el recurso compartido cifs de Windows.
mount -t cifs //server/compartida /mnt/cifsbackup -o username=user,password=passw,domain=dominio
  • //server/compartida: Será el recurso compartido cifs de Windows.
  • /mnt/cifsbackup: Directorio que se usará para montar el recurso cifs de Windows en la máquina Linux.
  • User, password y dominio: Será el usuario, contraseña y dominio si se trata de un usuario de dominio, si se trata de un usuario local de Windows sería el hostname de la máquina Windows.
Montamos el directorio del servidor FTP remoto en el directorio local de la máquina Linux. (Como ejemplo se montará partiendo de /mnt.)
curlftpfs user:passw@serverftp /mnt/ftpbackup
  • user: Usuario de acceso al servidor FTP.
  • passw: Password de acceso al servidor FTP.
  • serverftp: URL, IP o hostname de acceso al servidor FTP.
  • /mnt/ftpbackup: Directorio donde se montará el servidor FTP remoto en la máquina Windows.
Una vez montados ambos recursos solo queda realizar el backup y que sincronice los datos desde el recurso compartido cifs de Windows hacia el servidor FTP remoto, al estar montados en el sistema Linux estos se tratarían como directorios locales.
rsync -rtvp --log-file=/var/log/ficherolog /mnt/cifsbackup /mnt/ftpbackup
  • r: Recursividad entre directorios.
  • r: Preserva la modificación de fechas.
  • v: Vervose, muestra más detalles.
  • p: Preserva los permisos de los ficheros y directorios.
  • --log-file=/var/log/ficherolog: Almacena los resultados en un fichero de log.
  • /mnt/cifsbackup: Datos origen.
  • /mnt/ftpbackup: Datos destino.
Para desmontar los recursos de los directorios.
umount /mnt/ftpbackup
umount /mnt/smbbackup
Para automatizar este proceso podemos crear un fichero bash script .sh que monten ambos recursos, realize el backup con rsync, enviarse el fichero de log a una dirección de correo electrónico y finalmente desmontar ambos recursos para que no permanezacan en la máquina Linux si no lo deseamos.

Si queremos programar la ejecución de este script .sh a una fecha/hora concreta añadimos el script a una nnueva línea en /etc/crontab de modo que se ejecute de forma programada.

Saludos!

15 enero, 2019

Ejecutar WMIC en equipos remotos de la red local (Windows Management Instrumentation)

Si nos surgen problemas para la ejecución sentencias WMIC en máquinas o nodos remotos, mostraré los errores más comunes y como solucionarlos.

Un error puede ser que no esté habilitado las llamadas a procedimientos remotos (RPC).
Error:
Descripción = El servidor RPC no está disponible.
Error - "El servidor RPC no está disponible" (wmic)
Figura 1: Error - "El servidor RPC no está disponible" (wmic).

Otro error común podría ser la falta de permisos para ejecutar WMIC en nodos remotos.
Error:
Descripción = Acceso denegado.
Error - "El servidor RPC no está disponible" (wmic)
Figura 2: Error - "Acceso denegado" (wmic).

Comprobar que el servicio "Instrumental de administración de Windows" (Winmgmt) está habilitado en el tipo de inicio automático y esté en ejecución.

Servicios winmgmt (wmic) en Windows
Figura 3: Servicios winmgmt (wmic) en Windows.

Habilitar la regla por aplicaciones permitidas del firewal (WFAS) de Windows para permitir comunicaciones y llamadas RPC de WMI. Dependiendo cada caso si se trata de una red privada o de dominio.

Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI
Figura 4: Reglas del WFAS (Windows Firewall Advanced Security) permitir la comunicación para WMI.

Verificar que el uso compartido de archivos e impresoras esté activado para el tipo de red según sea el caso. Por defecto en una red de dominio esta característica suele estar activada por defecto cuando un equipo cliente se uno al dominio.

Activar el uso de recurso compartido de archivos e impresoras
Figura 5: Activar el uso de recurso compartido de archivos e impresoras.

Comprobar que en la consola del equipo remoto haya permisos suficientes para el usuario que ejecutará wmic.

Esto se puede modificar en la consola de Microsoft "wmimgmt.msc", en la pestaña de seguridad, se modifican los permisos para permitir la "Llamada remota habilita" y "Ejecutar métodos".

Permisos de seguridad al Control WMI
Figura 6: Permisos de seguridad al Control WMI.

Por último, y algo fundamental según las pruebas que he realizado, es que independientemente de si el equipo cliente remoto en el que se quiere ejecutar WMI forme parte de una red de dominio o una red privada. Será necesario crear un valor en el registro de Windows "LocalAccountTokenFilterPolicy" algo ya comentado en este artículo.

Desde mi punto de vista esto no es aconsejable a métodos de seguridad, no es para nada una buena práctica, pero si se trata de casos puntuales en los que se necesita realizar una serie de acciones remotas simplemente, por seguridad aconsejo volver a eliminar este valor del registro.

Para poder ejecutar este valor en el registro podemos hacerlo ejecutando una CMD en el equipo remoto a través de PsExec (PsTools de Sysinternals). En este artículo se detalla como hacerlo.

El valor LocalAccountTokenFilterPolicy se trata básicamente de "deshabilitar" el UAC (User Account Control) para la ejecución de acciones remotas.

Para añadir el valor LocalAccountTokenFilterPolicy a través de una CMD:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Para posteriormente eliminar el valor LocalAccountTokenFilterPolicy a través de una CMD:
reg delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\system /v LocalAccountTokenFilterPolicy /f

En el siguiente ejemplo se puede ver como se ejecuta WMIC remotamente desde un equipo local a un equipo remoto usando "wmic /node", especificando la dirección IP local o el hostname del equipo remoto y un usuario/password con privilegios administrativos en la máquina remota.
wmic /node:ip_hostname /user:usuario /password:password bios get serialnumber
Ejecución remota de "wmic /node"
Figura 7: Ejecución remota de "wmic /node".

Saludos!

10 enero, 2019

Ejecutar una CMD en un equipo remoto con psexec

Esto es algo que suelo utilizar en muchos casos cuando los servicios para administraciones remotas que necesito en ese momento no están habilitados en el equipo remoto.

O bien me conecto con este tip para ejecutar una CMD en el equipo remoto y habilitar los servicios que sean necesarios para posteriormente administrar el equipo remoto de forma más cómoda a través del registro remoto (regedit) o los snap-ins MSC (administrador de dispositivos, impresoras, firewall, servicios, etc.) de administración remota añadidos a través de una MMC (Microsoft Management Console).

Como levantamos una CMD con privilegios administrativos ya sea de un administrador local o de dominio podemos ejecutar acciones remotas mediante la consola, "netsh" para la administración de redes o Firewall, "sc" para servicios, "reg" para la manipulación de entradas del registro, "wmic" instrumental de administración de Windows, etc. Aunque como comentaba anteriormente es más cómodo invocar las propias consolas de administración remotas MSC de Microsoft.

Para esto será necesario descargar psexec, parte de la colección de herramientas de Sysinternals de Microsoft.

Haciendo uso de PsExec ejecutamos lo siguiente en una CMD con privilegios de nuestro equipo local.
psexec \\EquipoRemoto -u UserAdmin -p Password cmd.exe
  • EquipoRemoto: nombre o IP del equipo remoto al que nos queremos conectar.
  • UserAdmin: usuario con privilegios de administrador local o de dominio sobre la máquina remota.
  • Password: Passoword del usuario establecido anteriormente.
  • Seguidamente indicamos la aplicación a ejecutar de forma remota, en este caso sería una CMD remota, por lo tanto "cmd.exe" o indicar la ruta absoluta para este binario o el que sea. "C:\Windows\System32\cmd.exe"
  • Con el parámetro psexec /i indicamos una interacción GUI con ventana del equipo remoto. "C:\Windows\regedit.exe", etc.
Podemos usar el parámetro -h para ejecutar el token de elevación si en el sistema remoto tiene habilitado el UAC. Y el parámetro -s cmd.exe para ejecutar el proceso remoto en la cuenta del sistema.

En la siguiente captura se puede ver un ejemplo y una comprobación consultando las IPs y un whoami de como realmente estamos estamos dentro del equipo remoto.
Ejecución de una CMD en un equipo remoto con psexec
Figura 1: Ejecución de una CMD en un equipo remoto con psexec.

En el caso de que obtengamos un error de acceso denegado, comparto el siguiente artículo como referencia para realizar la configuración previa WinRM.

25 junio, 2016

Permitir ejecuciones remotas con cualquier usuario al intentar acceder al recurso compartido C$ (LocalAccountTokenFilterPolicy)

En Windows existen ciertos recursos compartidos establecidos por defecto con intenciones administrativas. Entre ellos está el conocido C$ (C dolar, el símbolo "$" indica que se trata de un recurso que el sistema mantiene "oculto"), que seguramente muchos usaríamos para poder conectarnos al equipo remoto de una red de forma subyacente al usuario de ese equipo, básicamente tener acceso a su disco del sistema C: (letra de unidad asignada por defecto en sistemas Windows).

Podemos ver en la consola de Microsoft (fsmgmt.msc) de "Carpetas comparitdas", los recursos que por defecto son compartidos, donde veremos el conocido c$ (C dolar) entre otros.

Figura 1: Consola Miscroft fsmgmt.msc "Carpetas compartidas".

Para que esta conexión sea posible, a parte de tener las debidas configuraciones de red bien configuradas como veremos más adelante. Hablando en este caso de una "red privada o doméstica" es necesario una de las dos siguientes posibilidades:
  • Conocer el usuario y contraseña con privilegios administrativos de la máquina remota.
  • Crear un usuario y contraseña igual que el usuario con el que intentamos conectarnos al equipo remoto.
En este caso nos quedaremos con la opción más cómoda que sería la de añadir el usuario al equipo remoto.

En el caso de formar parte de una red de dominio, esto se debería administrar con grupos en el propio controlador de dominio (DC). En este caso podríamos crear un grupo en el que incluiríamos a los usuarios administrativos y ese grupo incluirlo en grupo de administradores de forma manual o por algún script mediante GPOs en los equipos de la red de Dominio.

Escenario de ejemplo:
  • Equipo: PLUTON | Usuario activo: maria
  • Equipo: JUPITER | Usuario activo: juan
En el siguiente ejemplo, de una red privada, el usuario activo en el equipo local es "juan" (equipo: Jupiter), pero el usuario remoto con el que queremos acceder desde el cliente es "maria" (del equipo: Pluton, pero que se creará también el equipo Jupiter). Por lo que en el equipo remoto crearíamos una cuenta de usuario con la misma contraseña que la del equipo donde queremos acceder y lo agregamos al grupo de Administradores, de modo que haya una coherencia entre este usuario en ambas máquinas.

Figura 2: Usuarios administradores del equipo remoto.

Hasta este punto todo correcto. Pero cuando intentamos acceder con el usuario y contraseña del mismo que el del equipo remoto aunque exista dicha coherencia de credenciales igualmente, por seguridad, nos solicita usuario y contraseña a través del UAC. Por lo que queremos es evitar o eludir el UAC en este caso.

Escribiendo en una ventana de ejecución el nombre o dirección IP del equipo remoto seguido del recurso compartido C$: \\equipo_remoto\c$.

Figura 3: Ejecutando el recurso compartido C$ hacía un equipo remoto de la misma red.

En sistemas Windows XP dentro de una red era común si teníamos los suficientes privilegios en un usuario frente a un equipo remoto el poder acceder a su disco C: (letra de unidad asignada por defecto a un sistema Windows) ya que este por defecto se compartía.

Esto a partir de Windows Vista en adelante con la incorporación del sistema UAC (User Account Control) nos solicita, por seguridad, que nos autentiquemos con un el usuario privilegiado de la máquina remota y por lo tanto confirmemos las credenciales del usuario con el que intentamos acceder a la máquina remota. En siguiente caso el usuario maria del equipo Pluton quiere conectarse al equipo Jupiter.

Figura 4: Autenticación de login con UAC para el acceso al recurso compartido C$.

Para poder eludir el UAC, solamente en este caso, podremos hacerlo fácilmente añadiendo un valor con un dato específico en una clave concreta del registro de Windows. Pero antes comentaré algunas configuraciones previas a tener en cuenta para todos los equipos de red o en los que queramos tener este tipo de acceso.

Antes de establecer la clave de registro oportuna, revisamos la configuración de la red privada para comprobar si está todo bien establecido, por defecto cuando nos unimos a un grupo de trabajo de una red privada o de hogar esto se autoconfigura correctamente.

En el caso de usar una red privada, formar parte de un grupo de trabajo o grupo del hogar, nos centraremos en la configuración de uso compartido avanzado de este. En el apartado privado (que sería el que correspondería en este caso) comprobaremos que esté activado la "detección de redes, compartir archivos e impresoras, y que Windows administre las conexiones del grupo del hogar".

Por defecto, cuando configuramos un equipo para que este se una a un grupo del hogar esta configuración debería estar ya preestablecida del siguiente modo.

Figura 5: Configuración del uso compartido de redes (entorno privado).

En un segundo bloque vemos la configuración de "Todas las redes" las cuales son otro tipo de características en la que digamos que el uso compartido no afecta para "perfiles públicos o invitados".

Deberemos tener activa las tres opciones disponibles, o simplemente las dos últimas opciones "Usar un cifrado de 128 bits y activar el uso compartido por contraseña", el cual en este caso no tendrá relevancia si lo tenemos activado o desactivado, ya que no se trataría de recursos compartidos de forma intencionada sino de los recursos compartidos por defecto del sistema, esta característica no está disponible en equipos que se encuentren en un dominio.

En la primera opción "Activar el uso compartido para todos los usuarios a carpetas públicas" se refiere aquellas carpetas del perfil de usuario que por defecto Windows comparte, pero que no tienen una gran importancia si no guardamos nada en ellas.

Figura 6: Configuración del uso compartido de redes (todas las redes).

Al activar las características anteriores, sobre todo la que respeta al uso compartido de archivos e impresoras, esta por defecto añade unas determinas reglas de entrada en el WFAS (Windows Firewall Advanced Security) referentes al protocolo SMB (Service Mensage Block), las cuales se deberían aplicar en este caso solo al perfil privado.

Figura 7: Reglas de entrada del Firewall avanzado para SMB "Compartir archivos e impresoras".

Por último comprobaremos un par de servicios. El servicio "Examinador de equipos" (Browser) realiza repetidas comprobaciones de actualización para conocer a los equipos vecinos de una misma red, de modo que así nuestro equipo estará actualizando la lista de equipos latentes dentro de la red.

Figura 8: Servicio "Examinador de equipos de red" (Browser).

El servicio "Servidor" (LanmanServer) nos proporcionará compatibilidad para todos aquellos equipos que quieran acceder a este, ofreciendo así el servicio necesario para acceder a sus recursos compartidos.

Figura 9: Servicio "Servidor" (LanmanServer)

Finalmente y el motivo por lo que escribo este artículo, sería añadir el valor necesario el registro de Windows para poder bypassear la autenticación UAC. La autenticación se hace pero se hace forma subyacente, esto simplemente nos evita autenticarnos con usuario y contraseña de forma manual.

En el registro de Windows del equipo remoto que queremos conectarnos (Jupiter), buscamos la clave:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Añadimos un nuevo valor REG_DWORD de 32 bits (aunque el sistema sea de x64 el valor tendría que ser igualmente de 32 bits). El nombre de este valor será: LocalAccountTokenFilterPolicy y la información de dato la establecemos a "1".

Figura 10: "LocalAccountTokenFilterPolicy" para evitar la autenticación manual en acceso a C$.

Ahora simplemente cerramos el registro y probamos, si aún así no se actualizasen los cambios, cerraríamos sesión o si fuese necesario (que en las pruebas que he realizado no ha sido necesario) reiniciaríamos el equipo.

Veremos que ahora al intentar acceder al recurso compartido C$ del equipo remoto al que hemos añadido este valor no nos pedirá de forma visible la autenticación de un usuario con privilegios para acceder a el y a ese recurso.

Se puede ver en una fsmgmt.msc la existencia de una sesión remota activa del usuario maria procediente del equipo remoto Pluton, la cual solo usó el usuario usuario local creado en el grupo administradores del equipo Jupiter (equipo al que remoto al que se conectó maria) para autenticarse, aunque como se ve en la captura de pantalla la sesión es con referencia al equipo remoto que accedió. (usuario maria del equipo Pluton accedió al equipo > Jupiter) . Visualizando las sesiones activas en la consola fsmgmt.msc.

Figura 11: Conexión remota activa, existencia de una sesión de usuario conectada al equipo.

Esto está definido por Microsoft (KB951016): https://support.microsoft.com/es-es/kb/951016

Saludos!

19 enero, 2016

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.

17 marzo, 2014

PsTools: Suite de herramientas para la gestión y administración de equipos remotos en redes locales

PsTools es una suite de herramientas útiles para los administradores de sistemas y redes. Esta compuesto por multitudes de utilidades las cuales se utilizan en forma de comandos.

El autor de todo esto, es el conocido Mark Russinovich -programador y fundador de Sysinternals, empresa que Microsoft posteriormente compró-. Esta suite data del año 2007 (lo cual aún hoy me extraña que no hubiese publicado nada en el blog sobre ellas) pero aun tuvo recientes actualizaciones para ciertas herramientas que la componen.

El punto fuerte de este pack de tools en la mayoría de ellas es que sirven para realizar tareas administrativas a equipos remotos de una red local o de dominio, de manera subyacente al usuario final.

El uso de estas herramientas es en forma de comandos mediante una shell de Windows. Así que una vez descarguemos las herramientas que necesitemos o directamente la suite completa PsTools. Simplemente nos tendríamos que colocar el prompt en el path donde esté la carpeta raíz de PsTools descargada o donde la hubiésemos ubicado después de descargar el paquete.

En mi caso agregué la ruta: "C:\Windows\PsTools" a la variable de entorno 'PATH' de Windows.
De modo que ya no tengo por que estar siempre situado en la ruta raíz donde tenga las PsTools, me bastaría con hacer uso de las herramientas desde cualquier ruta en el que esté ubicado, ya que gracias a la variable de entorno añadida, Windows sabrá encontrar el camino raíz de los ejecutables que componen PsTools.

El pack de PsTools incluye las siguientes utilidades:
  • PsExec: Permite ejecutar procesos en cualquier contexto de usuario.
  • PsFile: Muestra los archivos abiertos de forma remota en un sistema.
  • PsGetSid: Muestra el identificador de seguridad (SID) de Windows de un equipo o un usuario.
  • PsInfo: Muestra información acerca de un sistema de Windows.
  • PsKill: Elimina o finaliza los procesos por nombre o identificador PID.
  • PsList: Muestra información detallada acerca de procesos en ejecución.
  • PsLoggedOn: Muestra todos los usuarios que han iniciado la sesión de forma local, así como todos los usuarios de recursos compartidos remotos.
  • PsLogList: Vuelca los registros de eventos de Windows.
  • PsPasswd: Cambia las contraseñas de cuentas de usuario.
  • PsService: Consulta y controla los servicios de Windows.
  • PsShutdown: Apaga, reinicia o suspende un equipo, o lo coloca en modo de hibernación.
  • PsSuspend: Suspende procesos en ejecución.
Esta no es una entrada para profundizar en cada una de ellas, ni era la intención de hacerlo, si no que iré haciendo uso de ellas a medida que me vayan surgiendo la necesidad de usarlas y exponer en posteriores artículos casos más concretos.

Saludos!

11 septiembre, 2012

Habilitar o deshabilitar los recursos compartidos administrativos por defecto de Windows sin eliminarlos completamente (C$ ADMIN$)

Windows crea una serie de recursos compartidos por defecto que están "ocultos", pero que en realidad pueden ser accesibles de una forma muy sencilla mediante una ruta UNC tipo \\nombreDeEquipo o dirección IP\nombreRecursoCompartido$. Por ejemplo para acceder al disco local del equipo remoto \\192.168.1.12\c$. Si en el equipo hay definido un usuario con password nos solicitará estas credenciales para poder acceder.

En entornos corporativos bajo un dominio Active Directory es habitual que el personal de TI use estos recursos compartidos administrativos para una gestión y administración de las máquinas. En equipos personales (que no estén unidos a un dominio) recomiendo deshabilitar los recursos compartidos administrativos si no son necesarios.

El símbolo $ en Windows establece que ese recurso compartido se mantiene oculto al resto de la red y que solamente conociendo el nombre del recurso compartido podríamos acceder a el.

Recursos compartidos administrativos

  • LetraUnidad$: El volumen compartido de forma completa, normalmente C:\ pero a cualquier unidad de medio extraíble conectada al equipo se le crearía un recurso compartido por defecto.
  • ADMIN$: Se utiliza durante la administración remota de un equipo.
  • IPC$: Comparte las canalizaciones con nombre que debe tener para la comunicación entre programas. Este recurso no puede eliminarse.

En Windows Server también encontramos

  • PRINT$: Permite la administración remota de impresoras.
  • FAX$: Utilizado por los clientes de fax, durante la transmisión de fax.

Recursos compartidos administrativos especiales en Windows Domain Controllers

  • NETLOGON: Procesa las solicitudes de inicio de sesión de dominio.
  • SYSVOL: Controla la replicación de Active Directory, GPOs, etc.
Estos recursos compartidos los encontramos en la consola de administración de carpetas o recursos compartidos fsmgmt.msc (File System ManaGeMenT). También podremos acceder a través de la consola de componentes de administrador de equipos compmgmt.msc (Component Management).

Figura 1: Consola de Microsoft de Recursos compartidos fsmgmt.msc.

Deshabilitar los recursos compartidos administrativos por seguridad

Un posible atacante que de algún modo conozca unas credenciales de acceso válidas o pueda realizar un bypass de esta autenticación a través de alguna vulnerabilidad existente en la máquina podría lograr acceso a estos recursos.

Hay que tener en cuenta que ciertas aplicaciones de bases de datos y/o servidores de correo pueden trabajar con estos recursos compartidos para su correcto funcionamiento. Si utilizamos alguna aplicación que puede estar utilizando estos recursos lo mejor es que ya no toquemos nada, igualmente en la mayoría de este tipo de situaciones suelen ocurrir dentro de organizaciones corporativas.

Habilitar o deshabilitar recursos compartidos administrativos: C$ y ADMIN$

Abrimos la consola de recursos compartidos locales fsmgmt.msc, manualmente podemos dejar de compartir estos recursos, pero en el caso de que los necesitemos en un futuro no los podríamos volver a restaurar de forma automática. Dejarlos sin compartir o eliminarlos manualmente no sería una buena práctica, lo aconsejable sería deshabilitarlos y tener la posibilidad de recuperarlos en un futuro si fuese necesario.

Lo podemos hacer mediante el registro de Windows regedit. Nos situamos en la siguiente ruta.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
  1. Creamos un valor tipo DWORD 32 bits
  2. Llamado AutoShareWks.
  3. Asignamos el valor 0.
0 = Deshabilita los recursos compartidos administrativos.
1 = Habilita los recursos compartidos administrativos.

Para aplicar los cambios podemos reiniciar la máquina o simplemente reiniciar el servicio "Servidor" LanmanServer.

Podemos reiniciarlo también a través de una consola cmd.
net stop lanmanserver
net start lanmanserver
Figura 2: Servicio "Servidor" LanmanServer.

Restaurar recursos compartidos administrativos NETLOGON y SYSVOL en un controlador de dominio Windows Server

Microsoft recomienda que no se elimine ni modifique estos recursos compartidos especiales en el caso de NETLOGON y SYSVOL en un controlador de dominio Windows Server. Si se eliminaron los recursos compartidos administrativos predeterminados o si la creación automática de estos recursos compartidos está desactivada, para restaurar los recursos compartidos de modo que se creen automáticamente en un controlador de dominio Windows Server.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
  1. Creamos un valor tipo DWORD 32 bits
  2. Llamado AutoShareServer.
  3. Asignamos el valor 1.
Con valor 1 creará los recursos automáticamente. Con valor 0 se deshabilitaría la creación automática de recursos compartidos especiales.


Saludos!

24 abril, 2011

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

Lecturas recomendables


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!

Entradas Populares