virtualAPP con Mark Russinovich en SpringBoard

Estándar

Hola a tod@s!

Buscando información sobre la virtualización de aplicaciones, tanto en local como en remoto, y de las posibilidades de hacerlo con Windows 7, me he topado con dos vídeos muy interesantes de Mark Russinovich sobre cómo la virtualización de aplicaciones antiguas puede ayudar en procesos de migración a otros sistemas operativos.

Las sesiones (2), las podéis encontrar en los siguientes enlaces:

Windows 7 Application Compatibility Part 1

http://technet.microsoft.com/es-es/windows/dd981014.aspx?ITPID=stepcon 

El vídeo se puede descargar completito desde esta dirección  

Windows 7 Application Compatibility Part 2. Virtualization

http://technet.microsoft.com/es-es/windows/ee532933

El vídeo de esta sesión se puede descargar completito desde esta dirección

Saludos!



SYSTEM, causa y efecto III de IV

Estándar

SYSTEM. causa y efecto I de IV

SYSTEM, causa y efecto II de IV

SYSTEM, causa y efecto IV de IV

Hola a tod@s!
Este post está dedicado a observar el funcionamiento de un SID en lo referente a un usuario específico.
Un SID, o identificador de seguridad, es una estructura para identificar inequívocamente a un usuario o un grupo específico.
Desde Windows NT, esta estructura se encuentra definida en la librería WINNT.H.
La estructura de un SID contiene, entre otros, los siguientes elementos:

  • Revisión del SID
  • Un identificador de autoridad que identifica la autoridad de ese SID
  • Un identificador relativo (RID), el cual identifica unívocamente un usuario o grupo, en relación a la autoridad asignada al SID

La combinación del identificador de autoridad, unido a los identificadores de las sub-autoridades, asegura que no haya dos valores SID iguales.
El formato de un SID se forma usando una cadena estandarizada, la cual hace más fácil la identificación de sus componentes. El formato de cadena de un SID es el siguiente:
S-R-I-S[VALORES]
En donde:

Imagen 1.- Relación Valores & Especificación

Aplicando los elementos anteriores, un SID válido sería el siguiente:

S-1-5-32-545

En donde la traducción de este SID sería la siguiente:

 

Imagen 2.- Valores e identificación

Si se quieren obtener los SID validados en el sistema operativo, éstos se pueden extraer de varias formas.
Una forma ágil de obtener los SID del sistema operativo, es utilizando herramientas ya creadas específicamente para este tipo de usos. Las más conocidas con GETSID, del Kit de recursos de NT, y PSGETSID, de la archiconocida SysInternals. La utilización de este tipo de herramientas no conlleva ningún tipo de problemas, y su uso es rápido e intuitivo.

 
 

Imagen 3.- Uso de PsGetSid

Otra vía de acceso a los SID validados en un sistema operativo es por el registro de Windows. Las claves asociadas que guardan información relativa a un SID de usuario son varias, pero las más usuales y prácticas son las siguientes:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
HKEY_USERS

Imagen.- SID en Registro de Windows

Otra forma rápida, fácil, y para toda la familia, es a través de Scripting. WMI y PowerShell, tienen capacidad para obtener todas las clases asociadas a un SID, y extraer la información de manera ágil. Gracias a que PowerShell tiene acceso rápido a toda la sintaxis de WMI, se puede scriptar todos los comandos de manera sencilla.

 

Imagen.- Extracción de SID a través de PowerShell

 
En el siguiente y último capítulo, veremos cómo se comporta la cuenta SYSTEM, así como el sistema operativo,  a la hora de intentar iniciar una sesión interactiva en el sistema, tal y como se suele utilizar en técnicas de elevación local de privilegios.
Saludos!!
Referencias
PSGETSID
http://technet.microsoft.com/en-us/sysinternals/bb897417
GETSID
http://download.microsoft.com/download/win2000platform/Getsid/1.0/NT5/EN-US/getsid.exe
Win32_SID Class
http://msdn.microsoft.com/en-us/library/aa394450(v=vs.85).aspx
How to Associate a Username with a Security Identifier (SID)
http://support.microsoft.com/kb/154599/en-us
How to deal with localized and renamed user and group names
http://support.microsoft.com/kb/157234/en-us

SYSTEM, causa y efecto. II de IV

Estándar

SYSTEM. causa y efecto I de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a tod@s!!
En la primera entrega dedicada a las diferencias entre la cuenta SYSTEM y una cuenta de tipo administrador, estuvimos repasando las diferencias a nivel de privilegios que tienen estas cuentas, diferencias a nivel de ficheros, directorios y registro.
Este capítulo, lo dedicaremos a repasar las diferencias que tienen estos usuarios, pero a nivel de sesión de usuario.
A la hora de administrar un equipo basado en Windows, siempre hay que pensar, como mínimo, en la existencia de dos usuarios iniciados como mínimo en el sistema operativo. Uno de estos usuarios podrá ser una cuenta, como máximo, con un privilegio de cuenta administrativa, y como mínimo, con el mínimo privilegio posible, o lo que es lo mismo, con una cuenta de usuario o usuario de dominio. La otra cuenta, será la cuenta SYSTEM, que será la encargada de administrar las operaciones internas que necesite realizar el sistema.
Cuentas como SYSTEM o LOCALSYSTEM, son cuentas que no tienen contraseñas asociadas a ellas, y cualquier intento de asociar una credencial a ellas, como por ejemplo a la hora de utilizar estas cuentas para iniciar un servicio, serán ignoradas por el propio sistema operativo.
También este tipo de cuentas, al ser internas del propio sistema operativo, tampoco tienen un perfil asociado en el administrador de cuentas del sistema (SAM), tal y como se puede ver en la siguiente imagen.


Imagen 1.- Cuentas extraídas a través de la SAM

A cada cuenta de usuario, se le asocia un perfil, una vez que se autentica correctamente en el sistema por primera vez. Este perfil, será el que utilice para las tareas comunes del sistema, y será en su perfil, en donde se guardará toda la información y modificación que sobre esta sesión realice.
Los perfiles de usuario, en sistemas basados en Windows XP/2003 se almacenan en el directorio DOCUMENTS AND SETTINGS. En sistemas basados en Windows Vista/7/2008, estos perfiles se almacenan en la raíz del sistema operativo, en el directorio USERS.
Cada cuenta, a su vez, puede iniciar sesión en el sistema de forma independiente, y compartir sesiones entre diferentes usuarios al mismo tiempo, con la única diferencia de que cada cuenta cargará única y exclusivamente su perfil.
Cuando el sistema operativo arranca, éste necesita cargar en memoria aplicaciones y claves de registro en el inicio del mismo. Estas tareas, las realiza la cuenta SYSTEM por diseño. A la hora de autenticarse en el sistema, Windows carga un subsistema de autenticación llamado MSGINA (Componentes de identificación y autorización). Este subsistema, es el que utilizaremos para autenticarnos debidamente en el sistema.
Por diseño, Windows también carga componentes de accesibilidad, necesarios para personas con carencias físicas, tales como falta de visión, miembros amputados, etc, etc…

Por otra parte, la cuenta SYSTEM, también es utilizada a nivel de políticas de grupo en equipos que formen parte de los servicios de Directorio Activo, para asuntos relacionados con la instalación y desinstalación de aplicaciones, ejecución de scripts, etc…, ya que existen políticas de grupo a nivel de máquina, y a nivel de usuario.
Windows también tiene otras cuentas de usuario asociadas a la creación y administración de servicios. En sistemas basados en Windows XP/2003, estas cuentas, tienen sus perfiles de usuario ubicados en el siguiente directorio:


Imagen 2.- ubicación de perfiles de sistema en Windows XP/2003

En sistemas basados en Windows Vista/7/2008, los perfiles de estas cuentas se almacenan en:


Imagen 3.- Ubicación de perfiles de sistema en Windows Vista/7/2008

Dicho esto, y para resumir, si en un sistema basado en Windows XP por ejemplo, existe como mínimo una cuenta SYSTEM arrancada en el sistema antes de iniciar sesión, ésta cargará con su perfil única y exclusivamente, pero… Dónde se encuentra ese perfil??
La cuenta SYSTEM, al ser una cuenta especial de usuario del propio sistema, tiene una ubicación propia. A partir de Windows XP, la ruta en donde se encuentra este perfil de usuario, es la siguiente:


Imagen 4.- Ubicación del perfil de usuario de la cuenta  SYSTEM

A nivel de sesiones, las cuentas de sistema, se comportan de diferente manera a las cuentas de usuario normales, ya que cada cuenta se ejecuta en una sesión diferente, y por ende, en diferentes espacios de memoria.
Si por ejemplo un usuario normal, crea un objeto nuevo en el sistema operativo, y tiene control total sobre el mismo, puede que la cuenta de SYSTEM, no pueda tener privilegios para tener acceso a ese objeto.
Un ejemplo válido lo tenemos con el comando SUBST. Este comando, permite asociar una unidad física del sistema a un determinado PATH. Dependiendo de quién cree este objeto en el sistema, y en qué sesión de usuario se haya ejecutado el comando,  un usuario podrá tener control total sobre él, y el otro no.

 
Imagen 5.- Acceso a objetos. El usuario SYSTEM no accede al objeto

Pero como toda ley, tiene su trampa. Si se necesita obtener acceso a ese objeto, siempre se puede recurrir a la impersonalización, es decir, utilizar la capacidad de poder ejecutar código bajo un contexto de seguridad distinto al de nuestro usuario.
Para que un usuario pueda suplantar a otro cliente tras la autenticación, es necesario tener un determinado privilegio. Este privilegio se llama SeImpersonatePriviilege, y en Windows Vista/7/2008 se puede visualizar con el comando WHOAMI /PRIV.


Imagen 6.- Privilegios para impersonalizar a otro usuario

En el siguiente capítulo, hablaremos de los SID de usuario en Windows, cómo se forman, cuál es su estructura, y la forma de acceso a ellos.  
Saludos!!

REFERENCIAS

Personalización de GINA
http://msdn.microsoft.com/en-us/magazine/cc163803.aspx
Comando SUBST
http://www.computerhope.com/substhlp.htm
Perfiles Locales
http://msdn.microsoft.com/en-us/library/bb776894(VS.85).aspx
Cuenta LOCALSYSTEM
http://msdn.microsoft.com/en-us/library/ms684190(v=vs.85).aspx
Derechos de usuario en Windows
http://technet.microsoft.com/en-us/library/bb457125.aspx
Impersonalización y secuestro de Tokens
http://www.argeniss.com/research/TokenKidnapping.pdf

SYSTEM, causa y efecto. I de IV

Estándar


SYSTEM, causa y efecto II de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a todos!!

En esta serie de 4 capítulos, examinaremos las sutiles diferencias entre un usuario administrador y un usuario de sistema (SYSTEM). Estas diferencias, serán cruciales a la hora de decidir qué tipo de cuenta será necesaria para la explotación de un fallo en el sistema, o decidir si es o no imprescindible el uso de técnicas para ganar una posible elevación de privilegios. También nos ayudarán a conocer el porqué de ciertos comportamientos dispares entre cuentas aparentemente similares.
A nivel de sistema operativo, tanto la cuenta Administrador como la cuenta de sistema, son cuentas con los mismos privilegios. Esta equidad, sólo se manifiesta a nivel de ficheros. A nivel de directorios, la cuenta SYSTEM tendrá, obligatoriamente por diseño del sistema operativo, mayores privilegios que una cuenta de tipo Administrador.
La cuenta SYSTEM, es usada por el sistema operativo para la carga o precarga de elementos cruciales en el inicio del sistema operativo. Servicios y procesos que necesita Windows para el buen funcionamiento del sistema, y para el inicio del mismo. La cuenta, diseñada para ese propósito, es una cuenta interna, y por tal motivo, no podemos administrarla utilizando funciones básicas de administración, como por ejemplo las siguientes:

  • Administración de usuarios
  • Añadir o eliminar de grupos
  • Derechos especiales de usuario

Para demostrar esto, se pueden utilizar dos ejemplos básicos. Uno es a nivel de ficheros, y otro por ejemplo, es a nivel de Registro.
En Windows XP, por defecto la cuenta SYSTEM tiene control total en todos los ficheros y directorios del sistema operativo, y no como la cuenta Administrador, que tiene control total en casi todos los elementos del sistema. Un ejemplo válido es la carpeta SYSTEM VOLUME INFORMATION, ubicada en la raíz del sistema instalado, y que tiene como objetivo el almacenamiento de las copias de seguridad o puntos de restauración. Si se intenta obtener acceso a este directorio a través de una cuenta con privilegios únicamente de administrador, obtendremos un bonito error, ya que a nivel NTFS, no tenemos privilegios.

 
Imagen 1.- Acceso denegado en SYSTEM VOLUME INFORMATION

Otro ejemplo válido lo tenemos a la hora de visualizar elementos del registro de Windows. La cuenta SYSTEM tiene, por diseño del propio sistema operativo, control total sobre ciertas claves de registro, imprescindibles para el buen funcionamiento del mismo. Algunos de estos ejemplos son la clave SAM, en donde se almacenan los datos de los usuarios existentes en el sistema, y la totalidad de los permisos en la clave SECURITY, ubicada en la clave HKLM (HKEY LOCAL MACHINE). En la siguiente imagen, se puede visualizar un ejemplo de este tipo.


Imagen 2.- Elementos de registro visibles a través de la cuenta SYSTEM


A partir de Windows Vista en adelante, en el apartado referente al control de ficheros y directorios, y siempre hablando a nivel NTFS, se añade una nueva entidad con control total en el sistema. Esta entidad, llamada TrustedInstaller, es la encargada de una nueva característica en Windows Server 2008 y Windows Vista/7, llamada Windows Resource Protection.

Imagen 3.- Lista de control de acceso discrecional en Windows 7

En el siguiente post, repasaremos el funcionamiento de ambas cuentas a nivel de sesiones de usuario, evaluando el funcionamiento de las mismas en base a los perfiles que éstas crean.
Saludos!!
Referencias
Funcionamiento de ICACLS
http://technet.microsoft.com/es-es/library/cc753525(WS.10).aspx
Mecanismos reemplazados en Windows Server 2008
http://msdn.microsoft.com/en-us/library/aa382540(v=vs.85).aspx
Cómo es usada la cuenta SYSTEM en Windows
http://support.microsoft.com/kb/120929/en-us