MS02-001: el uso de un SID falso puede aumentar los privilegios en Windows 2000

Seleccione idioma Seleccione idioma
Id. de artículo: 289243 - Ver los productos a los que se aplica este artículo

Para obtener información adicional acerca de este problema en Windows NT 4.0, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
289246 MS02-001: Forged SID Could Result in Elevation of Privilege in Windows NT 4.0
Expandir todo | Contraer todo

En esta página

Síntomas

Microsoft Windows NT y Windows 2000 protegen los recursos del sistema con listas de control de acceso (ACL). Las ACL son listas de identificadores de seguridad (SID) y listas de derechos o permisos de acceso que se conceden a ese principal de seguridad. Los SID son relativos a un dominio. El SID de un usuario o grupo de un dominio se basa siempre en el SID del dominio e identifica exclusivamente al usuario o grupo. Las ACL se colocan en un recurso para indicar a qué usuarios y grupos se les permite el acceso al recurso y qué nivel de acceso se permite a los usuarios y grupos. Cuando un usuario intenta el acceso al recurso, Windows compara la lista de los SID de la ACL con la lista de los SID que identifican al usuario y sus miembros de grupo, y concede o deniega el acceso según corresponda.

Cuando un usuario inicia sesión en un dominio, el SID de cuenta de usuario y los SID de miembros de grupo son determinados por un controlador de dominio en el dominio de cuenta de usuario. El SID del dominio de confianza, el Id. relativo (RID) de la cuenta de usuario, el RID del grupo principal de usuario y los SID de todos los miembros de grupo se combinan en una estructura de datos de autorización y pasan al equipo solicitante. Si el controlador de dominio que autentica ejecuta Windows 2000, también comprueba si el usuario tiene algún SID en su atributo SIDHistory e incluye esos SID en los datos de autorización.

Si el equipo que está solicitando la autenticación de usuario está en un dominio diferente del de la cuenta de usuario, la autenticación se produce usando una confianza. La confianza se crea entre dominios basados en Windows NT o Windows 2000 para simplificar la experiencia de autenticación del usuario, especialmente habilitando el inicio de sesión único. Cuando un dominio confía en otro, significa que el dominio que confía permite al dominio de confianza autenticar a los usuarios (o equipos) cuyas cuentas administra. Durante la autenticación, el equipo del dominio que confía acepta los datos de autorización proporcionados por el controlador del dominio de confianza. Para el equipo que está solicitando la autenticación no hay manera de determinar la validez de la información de la autorización, por lo que acepta los datos como exactos basándose en la existencia de la relación de confianza.

Existe una vulnerabilidad porque el dominio que confía no comprueba que el dominio de confianza está realmente autorizado para todos los SID de los datos de autorización. Si uno de los SID de la lista identifica a un usuario o grupo de seguridad que no está en el dominio de confianza, el dominio que confía acepta la información y la utiliza para posteriores decisiones de control de acceso. Si un atacante insertara algún SID en los datos de autorización del dominio de confianza, podría elevar sus privilegios a los que están asociados con cualquier usuario o grupo, incluyendo a los Administradores del dominio para el dominio que confía. Así, el atacante tendría acceso pleno de Administrador de dominio a los equipos del dominio que confía.

Explotar esta vulnerabilidad sería un reto. Como mínimo, un atacante necesitaría privilegios administrativos en el dominio de confianza y recursos técnicos para modificar estructuras de datos y funciones de bajo nivel del sistema operativo. Windows 2000 proporciona un mecanismo para introducir los SID adicionales en los datos de autorización, llamados SIDHistory. Sin embargo, no existe una interfaz de programación que permita a un atacante, incluso aunque tenga derechos administrativos, introducir un SID en la información de SIDHistory; en cambio un atacante necesitaría realizar una modificación binaria de las estructuras de datos que mantienen la información de SIDHistory. Para contrarrestar esos ataques potenciales, Microsoft ha agregado una característica de filtrado de SID a Windows NT 4.0 y Windows 2000. Con el filtrado de SID, un administrador puede hacer que los controladores de dominio de un dominio dado "pongan en cuarentena" un dominio de confianza. Ello haría que los controladores de dominio del dominio que confía quitaran todos los SID que no son relativos al dominio de confianza desde cualquier dato de autorización que se reciba de ese dominio. La cuarentena se realiza desde el dominio que confía y se realiza por dominios.

El filtrado de SID bloquea la confianza transitiva de Windows 2000. Si se encuentra un dominio en cuarentena en la ruta de confianza entre dos dominios, los usuarios de los dominios del otro lado del dominio en cuarentena no pueden tener acceso a los recursos del dominio en cuarentena. Por esa razón, los dominios en cuarentena deben ser dominios de hoja, sus dominios secundarios deben ser los únicos dominios de recursos que no contienen cuentas de usuario, o el dominio en cuarentena debe estar en un bosque independiente.

Un administrador de Windows 2000 no debe usar la característica de filtrado de SID para crear dentro de un bosque un dominio "de acceso restringido". El escenario de cuarentena recomendado es poner en cuarentena sólo los dominios que están en bosques independientes. Una confianza debería establecerse desde el dominio que ha de ser protegido al dominio que se va a poner en cuarentena, tras lo que el dominio que confía debe configurarse para filtrar los SID desde el dominio de confianza.

Microsoft recomienda que no use ese filtrado de SID entre dominios en el mismo bosque porque perturba la confianza predeterminada y el comportamiento de autenticación de un bosque, incluyendo la replicación dentro del bosque, y es probable que produzca problemas de programas que podría ser difícil solucionar. Este artículo contiene una lista de programas y funcionalidades que se sabe funcionan mal en los entornos de filtrado de SID. No use dominios de acceso restringido y siga las recomendaciones que se enumeran arriba si necesita esos programas o funcionalidades. Microsoft no puede proporcionar maneras de evitar esos problemas.

Solución

Para resolver este problema, obtenga el paquete de continuación de seguridad 1 (SRP1, Security Rollup Package 1) de Windows 2000. Para obtener información adicional acerca de SRP1, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base (en inglés):
311401 Windows 2000 Security Rollup Package 1 (SRP1), January 2002
La versión en inglés de esta revisión debe tener los atributos de archivo siguientes o posteriores:
   Fecha        Hora   Versión        Tamaño   Nombre de archivo
   -----------------------------------------------------------------
   08-Oct-2001  19:13  5.0.2195.4472  123,664  Adsldp.dll
   08-Oct-2001  19:13  5.0.2195.4308  130,832  Adsldpc.dll
   08-Oct-2001  19:13  5.0.2195.4016   62,736  Adsmsext.dll
   08-Oct-2001  19:13  5.0.2195.4384  364,816  Advapi32.dll
   08-Oct-2001  19:13  5.0.2195.4141  133,904  Dnsapi.dll
   08-Oct-2001  19:13  5.0.2195.4379   91,408  Dnsrslvr.dll
   08-Oct-2001  19:19  5.0.2195.4411  529,168  Instlsa5.dll
   08-Oct-2001  19:13  5.0.2195.4437  145,680  Kdcsvc.dll
   04-Oct-2001  21:00  5.0.2195.4471  199,440  Kerberos.dll
   04-Sep-2001  09:32  5.0.2195.4276   71,024  Ksecdd.sys
   27-Sep-2001  15:58  5.0.2195.4411  511,248  Lsasrv.dll    128 bits
   06-Sep-2001  18:31  5.0.2195.4301  507,152  Lsasrv.dll     56 bits
   06-Sep-2001  18:31  5.0.2195.4301   33,552  Lsass.exe
   27-Sep-2001  15:59  5.0.2195.4285  114,448  Msv1_0.dll
   08-Oct-2001  19:14  5.0.2195.4153  312,080  Netapi32.dll
   08-Oct-2001  19:13  5.0.2195.4357  370,448  Netlogon.dll
   08-Oct-2001  19:13  5.0.2195.4464  912,656  Ntdsa.dll
   08-Oct-2001  19:13  5.0.2195.4433  387,856  Samsrv.dll
   08-Oct-2001  19:13  5.0.2195.4117  111,376  Scecli.dll
   08-Oct-2001  19:13  5.0.2195.4476  299,792  Scesrv.dll
   29-May-2001  07:41  5.0.2195.3649    5,632  Sp2res.dll
   08-Oct-2001  19:13  5.0.2195.4025   50,960  W32time.dll
   01-Ago-2001  21:44  5.0.2195.4025   56,592  W32tm.exe
   08-Oct-2001  19:13  5.0.2195.4433  125,712  Wldap32.dll
				
NOTA: debido a la interdependencia entre archivos, esta revisión requiere Microsoft Windows 2000 Service Pack 2.

Estado

Microsoft ha confirmado que este problema puede causar cierto grado de vulnerabilidad de la seguridad en Microsoft Windows 2000.

Más información

Para obtener más información acerca de esta vulnerabilidad, visite el siguiente sitio Web de Microsoft:
http://www.microsoft.com/technet/security/bulletin/MS02-001.asp

Configurar el filtrado de SID

Puede configurar el filtrado de SID con la versión actualizada de la utilidad Netdom.exe del Service Pack 2 (SP2) de Windows 2000 en dominios basados en Windows 2000. Para que el filtrado de SID funcione adecuadamente, SP2 debe estar instalado en todos los controladores de dominio del dominio que confía (el dominio que tiene en cuarentena otro dominio). La versión actualizada de Netdom.exe se incluye en la carpeta Support Tools del CD-ROM del SP2, aunque también puede descargarla desde el sitio Web de Microsoft. Un modificador /filtersids se ha agregado a esta versión de Netdom.exe para configurar el filtrado de SID.

En los dominios basados en Windows 2000, para poner en cuarentena un dominio, use el comando siguiente una vez en un controlador de dominio del dominio (en este ejemplo, el dominio RESDOM filtra el dominio ACCDOM):
netdom trust RESDOM /D:ACCDOM /UD:ACCDOM\Administrator /PD:adminpwd /UO:RESDOM\Administrator /PO: adminpwd /filtersids:yes
El comando relacionado para deshabilitar el filtrado de SID es:
netdom trust RESDOM /D:ACCDOM /UD:ACCDOM\Administrator /PD:adminpwd /UO:RESDOM\Administrator /PO:"" /filtersids:no
Para comprobar los valores del filtrado de SID en un dominio, use este comando:
netdom trust RESDOM /D:ACCDOM /UD:ACCDOM\Administrator /PD: adminpwd /UO:RESDOM\Administrator /PO:adminpwd /filtersids
La duplicación típica de Active Directory hace que el valor se propague a todos los controladores de dominio del dominio.

Cambios en la autenticación y la auditoría

Consulte la Ayuda en pantalla de Windows 2000 para obtener información acerca de la manera de configurar la auditoría en Windows 2000.

Cuando se establece una confianza, el dominio que confía crea y almacena una estructura de datos llamada objeto dominio de confianza (TDO) que contiene el SID del dominio de confianza y otras informaciones relativas a la confianza. Cuando el filtrado de SID está habilitado para un dominio de confianza, las autenticaciones ante ese dominio no se realizan si los datos de autorización presentan un SID de dominio que no coincide con el SID del TDO del dominio de confianza para el dominio en cuarentena. Esta circunstancia sólo se puede producir si los datos de autorización fueron alterados. Si la autenticación no se realiza de esta manera y está habilitada la auditoría de inicio o de cierre de sesión, se genera un suceso en el registro de sucesos del controlador de dominio que está procesando la solicitud de autenticación en el dominio que confía.

SP2 incluye un nuevo suceso de auditoría de seguridad con el suceso Id. 548 para la autenticación NTLM y agrega un nuevo código de error (0xC000019B) al suceso Id. 677 durante la autenticación Kerberos. Son sucesos de error de inicio o de cierre de sesión que se generan cuando el SID de dominio es "suplantado". Las siguientes entradas de ejemplo demuestran estos sucesos.

Durante la autenticación NTLM:
   Tipo de suceso:     Auditoría de error
   Origen del suceso:   Seguridad
   Categoría del suceso: Inicio/Cierre de sesión
   Id. de suceso:       548
   Fecha:           Fecha de suceso
   Hora:           Hora de suceso
   Usuario:           NT AUTHORITY\SYSTEM
   Equipo:       Nombre del equipo donde se registró el suceso
   Descripción:
     Error de inicio de sesión.
     Motivo:                 SID de dominio incoherente
     Nombre de usuario:              Nombre del usuario que es autenticado
     Dominio:                 Nombre del dominio en cuarentena
     Tipo de inicio de sesión:             3
     Proceso de inicio de sesión:          NtLmSsp
     Paquete de autenticación: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
     Nombre de estación de trabajo:       Nombre del equipo cliente
				
Durante la autenticación Kerberos:
   Tipo de suceso:     Auditoría de error
   Origen del suceso:   Seguridad
   Categoría del suceso: Inicio de sesión de la cuenta
   Id. de suceso:       677
   Fecha:           Fecha de suceso
   Hora:           Hora de suceso
   Usuario:           NT AUTHORITY\SYSTEM
   Equipo:       Nombre del equipo donde se registró el suceso
   Descripción:
     Error en 	solicitud de vale de autenticación:
     Nombre de usuario:              Nombre del usuario que es autenticado
     Dominio de usuario:            Nombre del dominio del usuario
     Nombre de servicio:           Nombre completo del dominio en cuarentena
     Opciones de vale:         0x0
     Código de error:           0xC000019B
     Dirección de cliente:         127.0.0.1

   Tipo de suceso:     Auditoría de error
   Origen del suceso:   Seguridad
   Categoría del suceso: Inicio/Cierre de sesión
   Id. de suceso:       537
   Fecha:           Fecha de suceso
   Hora:           Hora de suceso
   Usuario:           NT AUTHORITY\SYSTEM
   Equipo:       Nombre del equipo cliente
   Descripción:
     Error de inicio de sesión:
     Motivo:                 Se produjo un error inesperado durante el inicio de sesión
     Nombre de usuario:              Nombre del usuario que es autenticado
     Dominio:                 Nombre del dominio del usuario
     Tipo de inicio de sesión:             2
     Proceso de inicio de sesión:          User32  
     Paquete de autenticación: Negociación
     Nombre de estación de trabajo:       Nombre del equipo cliente
				

Limitaciones del filtrado de SID

Hay tres posibles inconvenientes relacionados con el filtrado de SID que podrían impedir el acceso de algunos usuarios a los recursos para los que están autorizados:
  • El filtrado de SID y SIDHistory son mecanismos mutuamente excluyentes. Si el filtrado de SID es efectivo en un dominio, filtra cualquier información de SIDHistory en los datos de autorización que entran desde los dominios en cuarentena.
  • El filtrado de SID puede bloquear los beneficios del inicio de sesión único de la confianza transitiva de Windows 2000. Por ejemplo, supongamos que el dominio A confía en el dominio B, y que el dominio B confía en el dominio C. Normalmente, en Windows 2000, un usuario del dominio C tendría acceso a los recursos del dominio A, porque el dominio A confía transitivamente en el dominio C. Sin embargo, si un dominio A tiene un filtrado de SID que es efectivo para el dominio B, ya no se permitiría que el dominio B confirmara a un usuario del dominio C, porque el dominio B ya no tiene autoridad para los SID del dominio C.
  • El filtrado de SID filtra los SID que están asociados con la pertenencia de un usuario a grupos universales si los grupos no se han mantenido en el dominio de cuenta del usuario.

Programas y características incompatibles

Se sabe que son incompatibles con el filtrado de SID los siguientes programas y las siguientes características de Windows 2000:
  • Pertenencia a grupo universal en todos los grupos universales que no están en el dominio de cuenta de usuario
  • Características de Microsoft Exchange 2000 que se basan en los grupos universales
  • SIDHistory para cuentas migradas
  • La confianza transitiva no funciona adecuadamente
  • Duplicación de Active Directory: para este motivo en particular, el filtrado de SID no debe usarse entre dominios en el mismo bosque. El filtrado de SID sólo se debe usar para filtrar confianzas externas.
Para obtener información adicional acerca de cómo obtener una revisión para Windows 2000 Datacenter Server, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
265173 The Datacenter Program and Windows 2000 Datacenter Server Product
Para obtener información adicional acerca de cómo instalar múltiples revisiones con un único reinicio, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base:
296861 Utilizar QChain.exe para instalar varias revisiones con sólo un reinicio

Propiedades

Id. de artículo: 289243 - Última revisión: jueves, 13 de noviembre de 2003 - Versión: 1.0
La información de este artículo se refiere a:
  • Service Pack 1 de Microsoft Windows 2000
  • Service Pack 2 de Microsoft Windows 2000
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Advanced Server
Palabras clave: 
kbbug kbfix kbwin2000presp3fix kbsecvulnerability kbwin2000sp3fix kbsecurity kbsecbulletin kbsechack KB289243

Enviar comentarios

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com