SharePoint à l'intérieur Comptes de sécurité de SharePoint

Pav Cherny

Contenu

Comptes de sécurité et de pools d'applications
Exécution de code personnalisé sur SharePoint Server
À propos de Dr. Jekyll et M. Hyde
Comptes de sécurité et isolation de processus
Comptes de sécurité dans la base de données de configuration
Comptes de sécurité et les clés d'informations d'identification
Ne pas rompre la loi

Lorsque vous utilisez des comptes de sécurité de SharePoint, il y a un risque élevé de création de configurations système faibles qui peuvent exposer un environnement SharePoint ensemble. Pour vous aider à déployer et sécuriser des batteries de serveurs SharePoint correctement, Microsoft a publié des informations détaillées et des instructions détaillées. Le Office SharePoint Server Security guide, par exemple, comporte plus de 300 pages sur de planification et implémentation de hiérarchies de site et de contenu, méthodes d'authentification, rôles de sécurité, administrateur et comptes de service et plusieurs autres problèmes de sécurité. Le Feuille de calcul exigences du compte Windows SharePoint Services de sécuritéfournit également les informations essentielles concernant la sécurité configurations des comptes. Si la sécurité est importante pour vous, vous souhaitez certainement Veillez à suivre cette feuille de calcul.

Même avec une documentation complète, la configuration de comptes de sécurité peut être une tâche difficile. En fait, modifier les paramètres par défaut des installations à serveur unique à partir de recommandations de la feuille de calcul, et certains composants, tels que le service Web d'intégration E-mail inclus dans Windows SharePoint Services (WSS) 3.0, nécessitent des autorisations avec des privilèges élevés sur le serveur, ce qui not only strays dans les recommandations de sécurité Microsoft mais est en conflit direct avec les bonnes pratiques de sécurité et common sense ordinaire. L'outil d'administration centrale de SharePoint 3.0 s'applique Heureusement configurations des comptes sans avertissements sécurité critiques, Microsoft Baseline Security Analyzer (MBSA) ne pas détecter les points faibles qui en résulte et donc il reste un défi pour sécuriser une batterie de serveurs SharePoint, en conservant sécurisé.

Dans cette chronique, je placer des comptes de sécurité de SharePoint sous un microscope pour vous montrer comment une configuration faible peut donner un utilisateur malveillant plein contrôle sur toutes les collections de sites et sites. Ceci est un sujet un peu la casse. D'une part, je souhaite pouvoir reconnaître les défis de sécurité qui entourent les configurations de serveurs SharePoint. Après tout, vous devez comprendre les forces et les points faibles de votre environnement SharePoint si vous souhaitez sécuriser efficacement.

D'autre part, je ne souhaite aider les utilisateurs malveillants. Pour cette raison, je ne suis pas fournir les feuilles de calcul ou les outils personnalisés cette colonne et je vous contraindre les discussions sur le code source vers les rubriques base qui doivent être familiers pour chaque développeur ASP.NET professionnel. Les extraits de code source abordée dans cette colonne doit Aide vous détecter des problèmes, mais pas vous aider à toute personne exploiter les. Même avec compétences de programmation limitées, vous devriez pouvoir utiliser ces extraits de code pour créer des pages ASP.NET personnalisées si vous avez Microsoft Office SharePoint Designer 2007.

A version d'évaluation de Microsoft Office SharePoint Designer 2007est disponible en ligne. Je vous invitons à configurer un laboratoire de test en fonction de vos propres préférences de, sécuriser les meilleures que vous le pouvez, puis exécutez les extraits de code fins de vérification. Nous allons voir comment sécurisé vos sites SharePoint sont !

Comptes de sécurité et de pools d'applications

Les comptes de sécurité sont au cœur très du modèle requête-traitement SharePoint. Ils définissent le contexte de sécurité des processus de travail IIS exécuter des applications Web SharePoint. Lorsque vous créez une SharePoint application Web, vous devez spécifier, entre autres, un pool d'applications avec informations d'identification sécurité associé compte et une base de données SharePoint avec une méthode d'authentification associés. Si vous utilisez l'authentification Windows (recommandée), SharePoint accorde automatiquement le compte de sécurité spécifiée dbOwner autorisations sur la base de données de contenu afin que le processus de traitement IIS exécution de l'application Web SharePoint peuvent y accéder aux collections de sites et des sites hébergés dans cette base de données. Dans le cas contraire, vous devez fournir des informations d'identification SQL Server explicites.

En tout cas, les collections de sites SharePoint et sites sont des constructions virtuelles. Physiquement, ils correspondent aux enregistrements de base de données. Si vous connaissez le nom de compte et le mot de passe pour établir une connexion SQL Server directe à la base de données de contenu, vous pouvez accéder complet à tous les collections de sites et ses données de site indépendamment d'autorisations et des contrôles d'accès définis au niveau du SharePoint. SharePoint ne peut pas vous empêcher parce que vous établissez une connexion directe au serveur de base de données, comme illustré dans la figure 1 . Le compte de sécurité est donc une cible de prime pour une attaque.

fig01.gif

Figure 1 contourner SharePoint site collections et des sites pour accéder aux données

Pour atténuer les risques de sécurité, Microsoft recommande de configurer applications distinctes pools (et comptes de sécurité) pour les collections de sites authentifié et anonyme contenu et pour isoler les applications que mots de passe banque ou où les utilisateurs ont très liberty créer et gérer des sites et de collaboration sur le contenu. En suivant ce conseil de configuration, l'idée sous-jacente est qu'un pirate qui réussit à contrôler un pool d'applications pas puis implicitement auront universel accès à toutes les données hébergées dans la batterie de serveurs SharePoint. Collections de sites SharePoint et sites d'autres bases de données sont toujours pas atteindre, condition que vous utilisez des comptes de sécurité distinct pour leurs applications Web associées.

Microsoft a tout d'abord introduit le concept d'isolation de processus de travail basé sur les pools d'applications avec IIS 6.0 et états que IIS n'a pas rencontré un problème de sécurité critique unique jamais depuis. C'est très reassuring, par conséquent, veillez à tirer parti des pools d'applications de batteries de serveurs SharePoint. Gardez à l'esprit, toutefois, que sites Web IIS et les applications Web SharePoint ne sont pas synonymes. Pendant que vous pouvez isoler les sites Web IIS, vous ne pouvez pas isoler des applications Web SharePoint les unes des autres.

Isolation authentique existe uniquement si sites Web ne partagent pas de ressources, mais les applications Web SharePoint toujours ont ressources en commun, comme base de données configuration de la batterie. Comme illustré à la figure 2 , de plus de contrôle sur un compte de sécurité de SharePoint implique la possibilité d'accéder à la base de données de configuration SharePoint. Cette fonctionnalité d'accès Assurez-vous vous pensez sensation Si déployé votre batterie sans donner pensée appropriée la protection de vos comptes de sécurité, en particulier si vous hébergez des collections de sites et les sites des clients internes ou externes différents dans un environnement partagé.

La figure 2 une relation entre les applications Web SharePoint, base de données de configuration et bases de données de contenu

Exécution de code personnalisé sur SharePoint Server

De la zone SharePoint n'est pas divulguer des informations de compte sécurité ; elle prend le code malveillant à découvrir les détails. Comme nous le savez, des failles de sécurité permettent de pirates à télécharger un code malveillant, mais parfois intrusions sont encore plus facile.

Dans le cas plus simple, un utilisateur malveillant peut être en mesure de se connecter à un serveur SharePoint localement ou via Terminal Server et copie le code malveillant dans le dossier %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts. Notez que SharePoint inclut ce dossier comme sous-dossier virtualisé dans chaque site SharePoint.

Dans un autre scénario, un administrateur SharePoint peut involontairement présente un code malveillant en déployant une solution SharePoint personnalisée à partir d'une source douteux sans test approprié et vérification de code. Code en ligne ASP.NET incorporé dans les pages maîtres et de contenu est également cause du problème. Par défaut, SharePoint ne traite pas les scripts côté serveur, mais toute personne ayant accès en écriture au fichier web.config une application Web SharePoint peut modifier les règles de traitement des scripts côté serveur. Vous devez uniquement ajouter une entrée PageParserPath de fichier web.config <pageparserpaths> section. Comment exactement l'entrée PageParserPath fonctionne-t-il ?

Nous allons supposez qu'un développeur qui est à l'aide de SharePoint vous appelle et complains sur un message d'erreur il récupère pendant le développement d'une page ASP.NET personnalisée indiquant « blocs de code sont non autorisés dans ce fichier. » Vous rechercher sur Internet et rechercher la solution dans un site de groupe de discussion ou un blog :

<PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="true" IncludeSubFolders="true" />

Peut-être vous ignorez les avertissements de sécurité ou peut-être les implications de sécurité ne sont pas encore mentionnées. Quel, que vous ajoutez cette ligne à votre fichier web.config et tout le monde est désormais bon car vous parvient à résoudre le problème.

Unwittingly, toutefois, vous aussi simplement ouvert un moyen pour exécuter tout code personnalisé dans les pages ASP.NET avec une autorisation totale. Si un utilisateur malveillant téléchargements maintenant une page ASP.NET malveillante, l'environnement SharePoint est en péril. Comme indiqué dans la figure 3 , il est inutile où dans une hiérarchie du site collection un utilisateur malveillant possède l'autorisation pour télécharger une page, il peut être un innocent-recherche site petite équipe. L'attaque affecte toujours l'application Web et éventuellement toute la batterie car la base de données de contenu et de base de données de configuration sont accessibles.

La figure 3

La figure 3 Activation en ligne ASP.NET code peut compromettre une application Web SharePoint

Sur Dr. Jekyll et m. Hyde

Comment agresseur accéder aux bases de données de contenu et de configuration sans connaître explicitement les informations d'identification du compte de sécurité ? Il est en fait relativement simple. Le processus de travail IIS qui s'exécute l'application Web SharePoint emprunte l'identité de l'utilisateur de SharePoint et utilise le jeton de thread résultant pour les vérifications d'accès. Par exemple, Dr. Jekyll peuvent accéder aux toutes les ressources SharePoint que son jeton de sécurité est autorisé à accéder. Mais l'application Web SharePoint a également le jeton de processus du processus de travail IIS, qui est le jeton de sécurité du compte de sécurité de SharePoint.

Il est M. Hyde qui s'affiche lorsque vous revenir l'emprunt d'identité en appelant la méthode WindowsIdentity.Impersonate statique et en transmettant un pointeur nul comme illustré dans les 4 chiffres et 4 a . Dr. Jekyll n'a aucun accès direct à la bases de données, mais M. Hyde ne. La route est désactivée pour les connexions SQL Server et les requêtes T-SQL.

fig4a_screen.gif

La figure 4 applications Web SharePoint ont deux contextes de sécurité (cliquez sur l'image pour l'agrandir)

Code de 4 a figure pour récupérer les contextes de sécurité application Web SharePoint deux

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;
}

Comptes de sécurité et isolation de processus

Pools d'applications et comptes de sécurité ne peut pas vous aider protéger les collections de sites et les sites placés dans une application Web configurée pour s'exécuter du code non vérifié. Leur but est de réduire, par le biais d'isolation du processus, l'impact d'un système d'exploitation sur un site qui permet à un agresseur à injecter du code sur le serveur aux attaques d'autres sites. Isolation du processus peut vous aider à atteindre cet objectif, mais elle nécessite vous permet de placer les autres sites dans les applications Web distinctes qui s'exécutent dans pools d'applications avec des comptes de sécurité.

Vous devez protéger correctement les informations d'identification du compte, sinon, l'effort de configuration est inutile. Une facile façon à fournir ces informations d'identification sécurité sensibles directement dans les mains incorrects consiste à accorder accès aux comptes de pool d'applications à la métabase IIS, qui est requise pour exécuter le service de gestion d'annuaire, une partie du service Web d'intégration courrier électronique. Si le compte du pool d'applications dispose d'un accès métabase, un utilisateur malveillant peut rétablir l'emprunt d'identité et puis extraire tous les comptes et mots de passe en texte clair, comme illustré dans les figures 5 et 5 a . La batterie de serveurs serveur entier est perdue parce que l'utilisateur malveillant peut ignorer maintenant Isolation du processus en exécutant un code malveillant sous un de ces comptes de sécurité et établir des connexions SQL Server à toutes les bases de données contenus.

fig5a_screen.gif

La figure 5 Récupération des informations de compte de sécurité à partir de la métabase IIS

Code de 5 a figure pour récupérer des informations de compte de sécurité à partir de la métabase 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 vous êtes intéressé par une solution de service de gestion d'annuaire qui ne nécessite l'accès métabase, vous devez rechercher des mon article de septembre 2008 " Intégration Directory SharePoint."

Comptes de sécurité dans la base de données de configuration

Si vous suivez la règle pas accorder des autorisations d'administration des comptes pool d'applications ou même ainsi, bien que les accès de lecture à la métabase IIS sur vos serveurs SharePoint, le code de produit seul figure 5 accès est refusé le message. Mais les informations de compte de sécurité sont également disponibles dans la base de données de configuration et M. Hyde a accès à cette base de données, comme expliqué plus haut.

Vous ne pouvez pas refuser le SharePoint sécurité comptes d'accès à la base de données de configuration ni pouvez vous refusez l'accès à la clé de Registre qui stocke la chaîne de connexion SQL Server correspondante. La chaîne de connexion ne peut pas immédiatement fonctionner si vous utilisez SQL Server 2005 Express, mais vous pouvez obtenir les informations de source de données approprié de la collection de sites SharePoint en cours (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString) et le nom de la base de données de configuration correspond au nom de la batterie locale (SPFarm.Local.Name).

Malheureusement, ces obstacles peu ne pas arrêter une attaque. Indépendamment de si vous utilisez SQL Server ou SQL Server Express, M. Hyde pouvez récupérer les informations affichées dans 6 chiffres et 6 . Notez que le mot de passe est chiffré, toutefois, afin de l'attaque n'a pas encore complètement réussi.

fig6a_screen.gif

La figure 6 obtenir des informations de compte de sécurité de la configuration de métabase

Figure 6 le code pour récupérer des informations de compte de sécurité de la configuration de la métabase

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;
}

Mais même sans déchiffrer le mot de passe, pools d'applications qui utilisent le même compte de sécurité sont déjà reconnus. Par exemple, dans la figure 6 , l'application pools l'administration centrale de SharePoint v3 et SharePoint, 80 utiliser le compte Service réseau et si SharePoint — 80 se trouve être l'application Web compromise, puis v3 de l'administration centrale de SharePoint est compromis ainsi. Le compte de sécurité correspondante est le compte de l'administration centrale, qui possède des autorisations élevés sur le serveur SharePoint.

Il ne doit pas être utilisé pour les pools d'applications Web standard, mais les produits SharePoint et Assistant Configuration de technologies applique cette configuration dans une installation serveur unique par défaut. Par conséquent, il est très important que vous examinez et, si nécessaire, modifiez la configuration de compte de sécurité dans votre environnement SharePoint. Plus d'informations sur ce sujet est décrit dans en détail dans l'article de la base de connaissances » Comment modifier comptes de service et les mots de service passe de comptes dans SharePoint Server 2007 et dans Windows SharePoint Services 3.0."

Comptes de sécurité et les clés d'informations d'identification

Quel est donc la beaucoup big sur le compte de l'administration centrale ? Plus important encore, contrairement aux comptes de pool d'application standard, le compte de l'administration centrale a accès à l'emplacement de Registre qui stocke la clé Informations d'identification pour déchiffrer le mot de passe de compte sécurité.

la figure 7 illustre ce paramètre et par défaut les paramètres de sécurité. Que vous pouvez le voir, les administrateurs locaux, le groupe WSS_RESTRICTED_WPG (qui contient le compte de l'administration centrale) et le compte SYSTEM a accès à cette clé et cela implique que vos applications Web SharePoint doivent d'utiliser comptes avec des autorisations d'administrateur local, le compte de l'administration centrale ou le compte système. Applications Web SharePoint ne doivent pas pouvoir accéder à la clé informations d'identification.

fig07a.gif

La figure 7 affectations d'autorisations pour accéder à la clé de Registre FarmAdmin

Malheureusement, cependant, ne c'est aucune garantie qu'un pirate compétent ne peut pas déterminer mots des sécurité ou CredentialKey passe des comptes, tels que via détournement de jeton système, mot de passe trouvé, ou simplement en plaçant un code malveillant dans les pages maîtres ou pages de contenu pour exporter la clé informations d'identification à un emplacement non protégé et puis attend un utilisateur disposant d'autorisations d'administrateur local pour accéder au site. Comme vous pouvez le voir, il est important que vous ne pas autoriser le code non vérifié sur vos serveurs.

Ressources SharePoint

bluebullet.gif Les produits et technologies Web site SharePoint

bluebullet.gif Windows SharePoint Services TechCenter

bluebullet.gif Centre de développement Windows SharePoint Services

bluebullet.gif Produits et Microsoft SharePoint technologies blog de l'équipe

Détournement de jeton système nécessite une explication plus détaillée, car vous pouvez empêcher cette forme d'attaque si il préférable d'utiliser les comptes système intégré, tel que Service réseau, pour vos applications Web SharePoint. En fait, Cesar Cerrudo, fondateur et directeur général de Argeniss découvert ce problème, il a démontré le système d'exploitation à la HITBSecConf2008 long connaissances sécurité conférence dans Dubai, Émirats arabes unis. Cesar montré comment une application Web ASP.NET qui s'exécute sous le compte service réseau peut injecter une DLL dans le service Appel de procédure distante (RPC) et ensuite détourner le jeton de sécurité d'un thread dans le service RPC qui s'exécute au niveau de privilège système.

Après cela, un utilisateur malveillant puis ne doit transmettre le jeton de sécurité système hijacked à la méthode WindowsIdentity.Impersonate pour pouvoir utiliser le paramètre de Registre CredentialKey et autres ressources protégées. Microsoft confirmé le problème, donc vous évitez d'utiliser le compte service réseau de vos applications Web SharePoint.

Ne pas rompre la loi

Le 10 Lois immuables de sécuritéa été publié par Microsoft Security Response Center longtemps et toujours appliquer dès aujourd'hui. Jesper A M. Johansson récemment écrit une série en trois parties appelée » Reconsidérer les 10 lois immuables de sécurité." Vous devez conservez ces lois ESPRIT lorsque vous créez votre batteries de serveurs SharePoint et vous devez également suivre les instructions de sécurité de SharePoint et les feuilles de calcul pour appliquer les configurations des comptes sécurité fiable.

En bref : utilisez mots de passe forts, n'accorder sécurité comptes les autorisations avec des privilèges élevés sur vos serveurs SharePoint, modifier mots de passe souvent (y compris les informations d'identification batterie de serveurs) et n'oubliez pas qu'il y n'a aucune absolue isolation entre les applications Web SharePoint qui utilisent des ressources communes, tout comme il est sans sécurité informatique absolue. En outre, ne modifiez pas le serveur règles de traitement du code, conserver non vérifiés assemblys éloigné vos serveurs et suivre la feuille exigences du compte Windows SharePoint Services de sécurité de votre configuration de compte de sécurité, et vous pourrez à prendre en compte votre environnement SharePoint raisonnablement sécurisé.

Toutefois, si séparation stricte de contenu de site est obligatoire pour votre organisation, je recommande que vous ordinateur hôte les collections de sites correspondant de batteries de serveurs distincts, probablement en séparer forêts Active Directory et environnements de SQL Server.

Pav Cherny est un expert informatique et l'auteur spécialisé dans les technologies Microsoft de collaboration et de communication unifiée. Son compositions incluent les blancs, produit manuels et livres avec une spécialisation sur les opérations INFORMATIQUES et d'administration système. Pav est président de Biblioso Corporation, une entreprise spécialisée dans les services de documentation et de localisation gérés.