Dentro de SharePoint Cuentas de seguridad de SharePoint
Pav Cherny
Contenido
Los grupos de aplicaciones y cuentas de seguridad
Ejecuta el código personalizado en servidores de SharePoint
Acerca de Dr. Jekyll y Sr.. Hyde
Cuentas de seguridad y aislamiento de procesos
Las cuentas de seguridad de la base de datos de configuración
Las cuentas de seguridad y claves de credenciales
No interrumpir el derecho
Cuando utiliza cuentas de seguridad de SharePoint, hay un alto riesgo de creación de configuraciones del sistema no seguro que pueden exponer un completo entorno de SharePoint. Para ayudarle a implementar y proteger los conjuntos de servidores de SharePoint correctamente, Microsoft ha publicado abundante información y directrices detalladas. El Guía de seguridad del servidor de SharePoint de Office, por ejemplo, consta de más de 300 páginas acerca del planeamiento e implementación de las jerarquías de sitio y contenido, los métodos de autenticación, las funciones de seguridad, administrador y las cuentas de servicio y muchos otros problemas de seguridad. El Hoja de cálculo de requisitos de cuenta de seguridad de Windows SharePoint ServicesTambién proporciona información esencial acerca de seguridad de las configuraciones de la cuenta. Si la seguridad es importante para usted, desea asegúrese de seguir esta hoja de cálculo.
Incluso con una extensa documentación, configuración de cuentas de seguridad puede ser una tarea difícil. De hecho, la configuración predeterminada de las instalaciones de servidor único desviarse de recomendaciones de la hoja de cálculo, y algunos componentes, como el servicio Web integración de correo electrónico incluido en Windows SharePoint Services (WSS) 3.0, requieren permisos elevados en el servidor, que not only strays de las recomendaciones de seguridad de Microsoft, pero está en conflicto directa con las recomendaciones de seguridad y common sense sin formato. La herramienta de administración central de SharePoint 3.0 Afortunadamente aplica las configuraciones de cuenta de seguridad críticas sin advertencias, Microsoft Baseline Security Analyzer (MBSA) no detecta las debilidades resultantes y, por lo que sigue siendo un desafío para proteger un conjunto de servidores de SharePoint y para mantener seguro.
En esta columna, colocar cuentas de seguridad de SharePoint bajo un microscopio para mostrarle cómo una configuración poco segura puede dar a un atacante completo control sobre todas las colecciones de sitios y sitios. Éste es un tema un poco importante. Por un lado, desea ayudar a reconocer los desafíos de seguridad que rodean las configuraciones de servidor de SharePoint. Después de todo, debe comprender las ventajas y los puntos débiles de su entorno de SharePoint si desea protegerlo de forma eficaz.
Por otro lado, no deseo ayudar a usuarios malintencionados. Por este motivo, no estoy proporcionando hojas de cálculo ni herramientas personalizadas en esta columna y le restringir las discusiones del código de origen a temas básicos que deben conocer a cada desarrollador profesional de ASP.NET. Los fragmentos de código de origen se tratan en esta columna debe ayuda que detecta vulnerabilidades, pero no ayuda a alguien explotarlos. Incluso con limitados conocimientos de programación, debe poder utilizar estos fragmentos de código para crear páginas ASP.NET personalizadas si tiene Office SharePoint Designer 2007.
A versión de prueba de Microsoft Office SharePoint Designer 2007está disponible en línea. Invitamos a que para configurar un laboratorio de pruebas conforme a sus propios las preferencias, proteger mejor los mientras puede y, a continuación, ejecute los fragmentos de código para fines de comprobación. Vamos a ver cómo segura los sitios de SharePoint.
Los grupos de aplicaciones y cuentas de seguridad
Las cuentas de seguridad son en el núcleo muy del modelo de procesamiento de solicitudes de SharePoint. Definen el contexto de seguridad de los procesos de trabajo IIS que ejecutar aplicaciones de la Web de SharePoint. Cuando crea una SharePoint aplicación Web, debe especificar, entre otras cosas, un grupo de aplicaciones con credenciales de cuenta de seguridad asociados y una base de datos de SharePoint con un método de autenticación asociado. Si utiliza la autenticación de Windows (recomendado), SharePoint concede automáticamente la cuenta de seguridad especificado dbOwner permisos en la base de datos de contenido para que el proceso de trabajo IIS que se ejecuta la aplicación Web de SharePoint puede tener acceso a las colecciones de sitios y sitios alojados en esta base de datos. De lo contrario, debe proporcionar credenciales explícitas de SQL Server.
En cualquier caso, las colecciones de sitios de SharePoint y los sitios son construcciones virtuales. Físicamente, corresponden a los registros de la base de datos. Si sabe el nombre de cuenta y contraseña para establecer una conexión directa de SQL Server a la base de datos de contenido, puede tener acceso completo a todas sus colecciones de sitios y datos de sitio independientemente de permisos y controles de acceso definidos en el nivel de SharePoint. SharePoint no puede bloquear porque se está establecer una conexión directa con el servidor de base de datos, tal como se muestra en la figura 1 . La cuenta de seguridad, por tanto, es un objetivo principal para un ataque.
Figura 1 sitio SharePoint eludir las colecciones y los sitios para tener acceso a los datos
Para mitigar los riesgos de seguridad, Microsoft recomienda que se configuren de aplicaciones independientes grupos (y las cuentas de seguridad) para las colecciones de sitios con contenido autenticado y anónimo y para aislar las aplicaciones que las contraseñas de almacén o donde los usuarios tienen liberty excelente para crear y administrar sitios y para colaborar en el contenido. Si sigue este consejo de configuración, la idea subyacente es que un intruso que obtenga el control sobre un grupo de aplicaciones no, a continuación, implícitamente tendrá acceso universal a todos los datos alojados en el conjunto de servidores de SharePoint. Colecciones de sitios de SharePoint y los sitios en otras bases de datos está aún fuera de alcance, siempre que utiliza cuentas de seguridad independiente para las aplicaciones Web asociadas.
En primer lugar, Microsoft introdujo el concepto de aislamiento de procesos de trabajo basándose en los grupos de aplicaciones con IIS 6.0 y los estados que IIS ha no sufrido una vulnerabilidad de seguridad críticas único nunca ya que. Es muy tranquilizador, por lo que asegúrese aprovechar los grupos de aplicaciones en conjuntos de servidores de SharePoint. Tenga en cuenta, sin embargo, sitios Web de IIS y las aplicaciones Web de SharePoint no son sinónimos. Aunque puede aislar los sitios Web de IIS, no se puede aislar las aplicaciones Web de SharePoint entre sí.
Aislamiento original existe sólo si sitios Web no comparten recursos, pero las aplicaciones Web de SharePoint siempre tienen los recursos en común, como base de datos de configuración el conjunto. Tal como se muestra en la figura 2 , tengan control sobre una cuenta de seguridad de SharePoint implica la capacidad de obtener acceso a la base de datos de configuración de SharePoint. Esa capacidad de acceso debe hacer que se siente incómodo si ha implementado el conjunto de servidores de SharePoint sin conceder pensamiento adecuado a la protección de las cuentas de seguridad, especialmente si se alojar colecciones de sitios y sitios de clientes internos o externos diferentes en un entorno compartido.
.gif)
La Figura 2 relación entre las aplicaciones Web de SharePoint, base de datos de configuración y bases de datos de contenido
Ejecuta el código personalizado en servidores de SharePoint
De fábrica, SharePoint no revelar información de la cuenta de seguridad; adopta código malintencionado para descubrir los detalles. Como todos sabemos, vulnerabilidades de seguridad pueden permitir a los atacantes cargar código malintencionado, pero a veces es incluso más fácil intrusiones.
En el caso más simple, es posible que un atacante no puedan iniciar sesión a un servidor de SharePoint localmente o a través de Terminal Server y copia código malintencionado en la carpeta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts. Tenga en cuenta que SharePoint incluye esta carpeta como una subcarpeta virtualizada en cada sitio de SharePoint.
En otro escenario, un administrador de SharePoint sin darse cuenta podría introducir código malintencionado al implementar una solución SharePoint personalizada de un origen cuestionable sin probar correcta y la comprobación del código. ASP.NET de línea de código incrustado en las páginas maestras y contenidas también es motivo de preocupación. De forma predeterminada, SharePoint no procesa secuencias de comandos del lado del servidor, pero cualquier usuario con acceso de escritura en archivo web.config de una aplicación Web de SharePoint puede cambiar las reglas de procesamiento de secuencias de comandos del lado del servidor. Se necesita agregar sólo una entrada de PageParserPath a del archivo web.config <pageparserpaths> sección. ¿Exactamente cómo funciona la entrada PageParserPath?
Vamos a Supongamos un desarrollador que utiliza SharePoint le llama y se queja sobre un mensaje de error Obtiene al desarrollar una página ASP.NET personalizada que se indica "bloques de código no están permitidos en este archivo." Es buscar en Internet y encontrar la solución en un sitio de grupo de noticias o blog:
<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />
Quizás omitir las advertencias de seguridad o tal vez incluso no mencionadas las implicaciones de seguridad. No importa, agrega esta línea al archivo web.config y ahora todos es Feliz porque resolver el problema.
Accidentalmente, sin embargo, es también sólo abierto una Avenida para ejecutar cualquier código personalizado en las páginas ASP.NET con plena confianza. Si un atacante ahora carga una página ASP.NET malintencionada, el entorno de SharePoint está en peligro. Como se indica en la figura 3 , es donde irrelevante en una jerarquía de la colección de sitios un atacante tiene el permiso para cargar una página, puede ser un innocent-buscando sitio de grupo pequeño. El ataque siempre afecta a la aplicación Web y, posiblemente, todo el conjunto de servidores porque la base de datos de contenido y base de datos de configuración son accesibles.
.gif)
La figura 3 el código ASP.NET de habilitación en línea puede poner en peligro una aplicación Web de SharePoint
Acerca de Dr. Jekyll y Hyde d.
¿Cómo puedan intruso obtener acceso a bases de datos de contenido y de configuración sin saber explícitamente las credenciales de cuenta de seguridad? Es en realidad bastante sencillo. El proceso de trabajo IIS que se ejecuta la aplicación Web de SharePoint suplanta al usuario de SharePoint y utiliza el símbolo de subproceso resultante para las comprobaciones de acceso. Por ejemplo, Dr. Jekyll puede tener acceso a todos los recursos de SharePoint que se permite tener acceso a su token de seguridad. Pero la aplicación Web de SharePoint también tiene el token del proceso del proceso de trabajo IIS, que es el token de seguridad de la cuenta de seguridad de SharePoint.
Es Sr.. Hyde que muestra hacia arriba al revertir suplantación llamando al método de WindowsIdentity.Impersonate estático, y pasando un puntero cero, como se ilustra en las figuras 4 y 4a . Dr. Jekyll no tiene directamente acceso a las bases de datos, pero Sr.. Hyde no. El camino es claro para conexiones de SQL Server y consultas de T-SQL.
La figura 4 las aplicaciones de Web de SharePoint tienen dos contextos de seguridad (haga clic en la imagen de una vista más grande)
Código de 4a de la figura para recuperar los dos contextos de seguridad de aplicación Web de SharePoint
private string GetMrHyde()
{
string retVal = string.Empty;
retVal = "Dr Jekyll is: " + WindowsIdentity.GetCurrent().Name + "<br>";
WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
retVal += "Mr Hyde is: " + WindowsIdentity.GetCurrent().Name + "<br>";
impCtx.Undo();
return retVal;
}
Cuentas de seguridad y aislamiento de procesos
Grupos de aplicaciones y las cuentas de seguridad no pueden ayudarle a proteger las colecciones de sitios y sitios en una aplicación Web configurada para ejecutar el código no comprobado. Su propósito es mitigar, por medio del aislamiento de procesos, el impacto de un ataque en un sitio que permite a un atacante inyectar código en el servidor para atacar a otros sitios. Aislamiento de procesos puede ayudar a lograr este objetivo, pero requiere que coloque los otros sitios en diferentes aplicaciones Web que se ejecutan en grupos de aplicaciones con cuentas de seguridad diferentes.
Debe proteger adecuadamente las credenciales de cuenta, en caso contrario, es inútil el esfuerzo de configuración. Una fácil de ofrecer estas credenciales de seguridad confidencial directamente en las manos equivocadas consiste en conceder acceso de las cuentas de grupo de aplicación a la metabase de IIS, que es necesario para ejecutar el servicio de administración de directorios, una parte del servicio Web de integración de correo electrónico. Si la cuenta de grupo de aplicación tiene acceso de metabase, un atacante puede revertir la suplantación y después recuperar todas las cuentas y contraseñas en texto sin cifrar, como se ilustra en las figuras 5 y 5a . Todo el conjunto de servidores se pierde porque el atacante puede eludir ahora aislamiento de procesos mediante ejecutar código malintencionado en cualquiera de estas cuentas de seguridad y establecimiento de conexiones de SQL Server a todas las bases de datos de contenido.
La figura 5 Recuperando información de cuenta de seguridad de la metabase de IIS
Código de 5a de la figura para recuperar información de cuenta de seguridad de la metabase de IIS
private string GetMetabaseAppPoolIDs()
{
WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
string retVal = string.Empty;
try
{
string metabasePath = "IIS://localhost/w3svc/AppPools";
DirectoryEntry appPools = new DirectoryEntry(metabasePath);
foreach (DirectoryEntry appPool in appPools.Children)
{
switch (int.Parse(appPool.Properties["AppPoolIdentityType"].Value.ToString()))
{
case 0: // Local System
retVal += "<br>" + appPool.Name
+ " (Local System)";
break;
case 1: // Local Service
retVal += "<br>" + appPool.Name
+ " (Local Service)";
break;
case 2: // Network Service
retVal += "<br>" + appPool.Name
+ " (Network Service)";
break;
case 3: // Custom
retVal += "<br>" + appPool.Name
+ " (" + appPool.Properties["WAMUserName"].Value
+ " [Pwd: " + appPool.Properties["WAMUserPass"].Value
+ "])";
break;
}
}
}
catch (Exception ee)
{
retVal = "Metabase " + ee.Message;
}
impCtx.Undo();
}
Si está interesado en una solución de servicio de administración de directorios que no requiere acceso de metabase, que debe buscar de la columna de septiembre de 2008 " Integración del directorio de SharePoint."
Las cuentas de seguridad de la base de datos de configuración
Si sigue la regla no para conceder permisos administrativos de cuentas de grupo de aplicaciones o incluso así tanto como acceso de lectura a la metabase de IIS en los servidores de SharePoint, el código en figura 5 sólo proporciona acceso mensaje denegado. Pero también está disponible en la base de datos de configuración y Sr. información de la cuenta de seguridad. Hyde tiene acceso a esta base de datos, como se explicó anteriormente.
Es no pueden denegar el acceso de las cuentas de seguridad de SharePoint a la base de datos de configuración ni puede denegar el acceso a la clave del registro que almacena la cadena de conexión de SQL Server correspondiente. La cadena de conexión no es posible que funciona inmediatamente si se utilizar SQL Server 2005 Express, pero se puede derivar la información de origen de datos correctos de la colección de sitios SharePoint actual (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString) y el nombre de la base de datos de configuración correspondiente al nombre del conjunto local (SPFarm.Local.Name).
Lamentablemente, estos obstáculos poco no detener un ataque. Independientemente de si se utilizar SQL Server o SQL Server Express, Sr.. Hyde puede recuperar la información mostrada en las figuras 6 y 6a . Tenga en cuenta que la contraseña está cifrada, sin embargo, por lo que el ataque ha no aún totalmente correcta.
Figura 6 obtener información de la cuenta de seguridad de la configuración de la metabase
Figura código de 6a para recuperar información de cuenta de seguridad de la configuración de la metabase
private string EnumAppPoolAccounts()
{
string retVal = string.Empty;
try
{
WindowsImpersonationContext impCtx = WindowsIdentity.Impersonate(IntPtr.Zero);
string regConfigDB = @"SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Secure\ConfigDB";
RegistryKey keyConfigDB = Registry.LocalMachine.OpenSubKey(regConfigDB);
string ConfigDB = (string)keyConfigDB.GetValue("dsn");
SqlConnection sqlConn = new SqlConnection(ConfigDB);
sqlConn.Open();
SqlCommand sqlCmd = new SqlCommand("SELECT Name, Properties FROM Objects"
+ " WHERE ClassId = 'B8369089-08AD-4978-B1CB-C597B5E90F64'", sqlConn);
sqlCmd.CommandType = System.Data.CommandType.Text;
SqlDataReader sqlReader = sqlCmd.ExecuteReader();
while (sqlReader.Read())
{
retVal += "<br>" + sqlReader.GetString(0);
string appPoolXML = sqlReader.GetString(1);
if (!string.IsNullOrEmpty(appPoolXML))
{
XmlDocument xmlDoc = new XmlDocument();
xmlDoc.LoadXml(appPoolXML);
XmlElement root = xmlDoc.DocumentElement;
XmlNode ndType = root.SelectSingleNode("/object/fld[@name= 'm_IdentityType']");
if (ndType != null && ndType.InnerText.ToLower() != "specificuser")
{
retVal += " (" + ndType.InnerText + ")";
}
else
{
retVal += " ("
+ root.SelectSingleNode("/object/sFld[@name='m_Username']").InnerText
+ " [Pwd: "
+ root.SelectSingleNode("/object/fld[@name='m_Password']").InnerText
+ "])";
}
}
}
sqlReader.Close();
sqlConn.Close();
impCtx.Undo();
}
catch (Exception ee)
{
retVal = ee.Message;
}
return retVal;
}
Pero incluso sin descifrar contraseñas, grupos de aplicaciones que utilizan la misma cuenta de seguridad ya están reconocibles. Por ejemplo, en la figura 6 , la aplicación pools v3 de administración central de SharePoint y SharePoint, 80 utilizar la cuenta de servicio de red y si SharePoint: 80 resulta ser la aplicación Web en peligro, v3 de administración central de SharePoint se ve comprometida también. La cuenta de seguridad correspondiente es la cuenta de administración central, que tiene elevados permisos en el servidor de SharePoint.
No debe utilizarse para grupos de aplicaciones Web estándar, pero los productos de SharePoint y Asistente para configuración de las tecnologías se aplica esta configuración en una instalación de servidor único de forma predeterminada. Por lo tanto, es muy importante que revise y, si es necesario, cambiar la configuración de la cuenta de seguridad en su entorno de SharePoint. Obtener más información acerca de este tema se describe en detalle en el artículo de Microsoft Knowledge Base" Cómo cambiar cuentas de servicio y contraseñas de cuenta de servicio en SharePoint Server 2007 y en Windows SharePoint Services 3.0."
Las cuentas de seguridad y claves de credenciales
¿Cuál es el problema sobre la cuenta de administración central? Lo más importante, a diferencia de las cuentas de grupo de aplicación estándar, la cuenta de administración central tiene acceso a la ubicación del registro que almacena la clave de credenciales para descifrar las contraseñas de cuenta de seguridad.
Figura 7 muestra este parámetro y su valor predeterminado configuración de seguridad. Como puede ver, administradores locales, el grupo WSS_RESTRICTED_WPG (que contiene la cuenta de administración central) y la cuenta del sistema tiene acceso a esta clave; esto implica las aplicaciones Web de SharePoint no deben utilizar las cuentas con permisos de administrador local, la cuenta de administración central o la cuenta del sistema. Las aplicaciones Web de SharePoint no deberían poder obtener acceso a la clave de credenciales.
La figura 7 las asignaciones de permisos a tener acceso a la clave del registro FarmAdmin
Por desgracia, sin embargo, esto no es ninguna garantía de que un atacante cualificado no puede determinar las contraseñas de cuenta CredentialKey o seguridad, como mediante Apropiación de símbolo (token) del sistema, contraseña descifrado, o simplemente colocar código malintencionado en las páginas maestras o las páginas de contenido para exportar la clave de credenciales en una ubicación no protegida y, a continuación, en espera de un usuario con permisos de administrador local para tener acceso al sitio. Como puede ver, es importante que no permita a código no comprobado en los servidores.
Recursos de SharePoint
Secuestro de símbolo (token) de sistema merece alguna explicación más detallada porque puede evitar esta forma de ataque si evitar el uso de las cuentas de sistema integrado, tales como servicio de red, para sus aplicaciones Web de SharePoint. De hecho, Cesar Cerrudo, fundador y director general de Argeniss descubren esta vulnerabilidad, y había demostrado el ataque en la HITBSecConf2008 detallado conocimiento seguridad conferencia en Dubai, Emiratos Árabes Unidos. Cesar mostraron cómo una aplicación de Web de ASP.NET que se ejecuta en la cuenta de servicio de red puede insertar un archivo DLL en el servicio llamada A procedimiento remoto (RPC) y, a continuación, apropiarse el token de seguridad de un subproceso en el servicio RPC que se ejecuta en el nivel de privilegios del sistema.
Después de esto, un atacante, a continuación, sólo tiene que pasar el token de seguridad del sistema interceptado al método WindowsIdentity.Impersonate para tener acceso al parámetro de registro de CredentialKey y otros recursos protegidos. Microsoft había confirmado la vulnerabilidad, por lo que debería evitar con la cuenta de servicio de red para las aplicaciones Web de SharePoint.
No interrumpir el derecho
El Diez normas inmutables de seguridadse han publicado por Microsoft Security Response Center hace mucho tiempo y todavía se aplican actualmente. Jesper CARACTERÍSTICAS. Johansson recientemente escribió una serie de tres partes, denominada" Visita las diez normas inmutables de seguridad." Estas leyes debe tenga en cuenta al diseñar los conjuntos de servidores SharePoint, y también debe seguir las directrices de seguridad de SharePoint y hojas de cálculo para aplicar configuraciones de cuenta de seguridad confiables.
En pocas palabras: Utilice contraseñas seguras, no conceder seguridad permisos elevados de cuentas en los servidores de SharePoint, cambiar las contraseñas con frecuencia (incluidas las credenciales del conjunto de servidores) y tenga en cuenta que no es aislamiento entre aplicaciones Web de SharePoint que utilizan recursos comunes, simplemente porque no hay ninguna seguridad informática absoluta absoluto. Además, no cambia el servidor codificar reglas de procesamiento, mantener sin comprobar ensamblados fuera de los servidores y siga la hoja de los requisitos de cuenta de seguridad de Windows SharePoint Services en la configuración de seguridad de la cuenta y quizá no pueda tener en cuenta el entorno de SharePoint razonablemente seguro.
Sin embargo, si separación estricta de contenido del sitio es un requisito para su organización, es recomendable que host las correspondientes colecciones de sitios en conjuntos de servidores independientes, posiblemente, en separar bosques de Active Directory y entornos de SQL Server.
Pav Cherny es un experto en TI y el autor especializado en tecnologías de Microsoft para la colaboración y comunicación unificada. Sus publicaciones incluyen notas del producto, manuales de producto y libros con un foco sobre las operaciones y administración del sistema. Pav es presidente de Biblioso Corporation, una empresa que está especializada en servicios administrados de documentación y localización.