All'interno di SharePoint Account di protezione di SharePoint

Pav Cherny

Contenuto

Pool di applicazioni e account di protezione
In esecuzione di codice personalizzato sui server di SharePoint
Su Dr. Jekyll e Mr. Hyde
Account di protezione e isolamento processo
Gli account di protezione in database di configurazione
Account di protezione e chiavi di credenziali
Non Interrompi il diritto

Quando si utilizza gli account di protezione di SharePoint, vi è un rischio elevato di creazione di configurazioni di sistema debole che possono esporre un intero ambiente SharePoint. Informazioni dettagliate e linee guida dettagliate che consentono di distribuire e proteggere correttamente server farm di SharePoint, Microsoft ha pubblicate. Il Guida di Office SharePoint Server Security, ad esempio è costituito da più di 300 pagine sulla pianificazione e l'implementazione sito e contenuto gerarchie, i metodi di autenticazione, i ruoli di protezione, amministratore e gli account di servizio e molti altri problemi di protezione. Il Foglio di lavoro Requisiti dell'account protezione di Windows SharePoint Servicesinoltre incluse informazioni essenziali sulla protezione delle configurazioni di account. Se protezione è importante per l'utente, in modo definito desideri assicurarsi di seguire questo foglio di lavoro.

Anche documentazione estesa, configurazione degli account di protezione può essere un'attività difficile. In effetti, le impostazioni predefinite di installazione a server singolo scostarsi da consigli del foglio di lavoro e alcuni componenti, ad esempio incluso in Windows SharePoint Services (WSS) 3.0, il servizio Web Integration di posta elettronica richiedere autorizzazioni elevate sul server, che not only strays dai consigli sulla protezione di Microsoft, ma è in conflitto diretta con procedure ottimali di protezione e common sense normale. Lo strumento di amministrazione centrale SharePoint 3.0 si applica Fortunatamente configurazioni di account di protezione critici senza avvisi, Microsoft Baseline Security Analyzer (MBSA) non rileva i punti deboli risultanti e pertanto rimane una sfida per proteggere una server farm di SharePoint e mantenere protetto.

In questo articolo, è possibile inserire SharePoint account di protezione in un microscope per illustrare come una configurazione debole possibile assegnare un utente malintenzionato controllo completo sull'tutte le raccolte siti e siti. Questo è un argomento alquanto riservato. Una parte, si desidera consentono di riconoscere i problemi di protezione che delineano le configurazioni di server di SharePoint. Dopo tutto, è necessario comprendere i punti di forza e punti deboli dell'ambiente SharePoint se si desidera proteggere in modo efficiente.

Invece, si desidera agevolare gli utenti malintenzionati. Per questo motivo, è possibile non mi fornisce qualsiasi fogli di lavoro o di strumenti personalizzati con questa colonna e verranno vincolare le discussioni di codice sorgente ad argomenti di base che devono essere familiare agli ogni sviluppatore professionista di ASP.NET. I frammenti di codice sorgente descritti in questa colonna deve Guida si rileva vulnerabilità, ma non consentono a chiunque sfruttare tali. Anche con competenze di programmazione limitate, sarà possibile utilizzare questi frammenti per creare pagine ASP.NET personalizzate se disponi di Microsoft Office SharePoint Designer 2007.

A versione di prova di Microsoft Office SharePoint Designer 2007è disponibile in linea. È possibile invitare, è possibile configurare un laboratorio di prova in base alle proprie preferenze, protezione ottimale, e quindi eseguire i frammenti di codice per scopi di verifica. Vediamo i siti di SharePoint si trovano il livello di protezione.

Pool di applicazioni e account di protezione

Gli account di protezione sono alla base molto del modello di elaborazione della richiesta di SharePoint. Definiscono il contesto di protezione dei processi di lavoro IIS eseguire applicazioni Web di SharePoint. Quando si crea un'applicazione Web di SharePoint, è necessario specificare, tra le altre cose, un pool di applicazioni con credenziali di account di protezione associati e un database di SharePoint con un metodo di autenticazione associato. Se si utilizza l'autenticazione di Windows (consigliato), SharePoint automaticamente concede l'account di protezione specificato dbOwner autorizzazioni sul database di contenuto in modo che il processo di lavoro IIS in esecuzione l'applicazione Web SharePoint può accedere alle raccolte siti e siti ospitati nel database. In caso contrario, è necessario fornire credenziali esplicite di SQL Server.

In ogni caso, raccolte di siti di SharePoint e i siti sono costrutti virtuale. Fisicamente, corrispondono ai record del database. Se si conosce il nome dell'account e password per stabilire una connessione diretta SQL Server al database del contenuto, è possibile consultare accesso completo a tutte le raccolte siti e sito dati indipendentemente dall'autorizzazioni e i controlli di accesso definiti a livello di SharePoint. SharePoint non può bloccare perché si è stabilisce una connessione diretta al server di database, come illustrato nella Figura 1 . L'account di protezione è pertanto una destinazione primo per un attacco.

Figura 1 ignorando SharePoint sito raccolte e siti per l'accesso ai dati

Per ridurre i rischi di protezione, Microsoft consiglia che è configurare applicazioni separate pool (e gli account di protezione) per le raccolte siti con contenuti autenticati e anonimo e di isolare le applicazioni che password archivio o in cui gli utenti hanno liberty ottimale per creare e gestire siti e per collaborare al contenuto. Seguendo questo consiglio di configurazione, l'idea sottostante è che un utente malintenzionato che ottiene il controllo su un pool di applicazioni verrà non quindi in modo implicito accedano universale a tutti i dati ospitati in della farm di SharePoint. Raccolte di siti di SharePoint e siti di altri database ancora non sono raggiungere, purché si utilizzare account di protezione separati per le applicazioni Web associate.

Microsoft introdotto il concetto di isolamento del processo di lavoro basato su pool di applicazioni con IIS 6.0 e gli stati che IIS è non subìto una vulnerabilità di singolo protezione critici mai poiché. Si tratta molto reassuring, assicurarsi di sfruttare i pool di applicazioni nella farm SharePoint. Tenere presente, tuttavia, che i siti Web IIS e le applicazioni Web SharePoint non sono sinonimi. Mentre è possibile isolare i siti Web IIS, è Impossibile isolare le applicazioni Web di SharePoint tra loro.

Isolamento autentica esiste solo se i siti Web non si condividono risorse, ma le applicazioni Web SharePoint sempre hanno le risorse in comune, come database di configurazione della farm. Come illustrato nella Figura 2 , controllare un account di protezione di SharePoint per essere implica la possibilità di accedere il database di configurazione di SharePoint. Tale funzionalità di accesso dovrebbe rendere ritiene rischioso se distribuiti della farm di SharePoint senza consentendo pensiero corretto la protezione degli account protezione, soprattutto se si ospitano raccolte siti e ai siti differenti clienti interni o esterni in un ambiente condiviso.

Nella figura 2 relazione tra le applicazioni Web di SharePoint, database di configurazione e i database del contenuto

In esecuzione di codice personalizzato sui server di SharePoint

Di SharePoint non divulgare informazioni di account di protezione; richiede codice dannoso per individuare i dettagli. Come tutti sappiamo, vulnerabilità della protezione consentono di pirati informatici caricare codice dannoso, ma a volte intrusione è ancora più semplice.

Nel caso più semplice, un utente malintenzionato potrebbe essere possibile accedere a un server di SharePoint localmente o tramite codice dannoso terminal server e la copia nella cartella %COMMONPROGRAMFILES%\Microsoft Shared\web server Extensions\12\TEMPLATE\Layouts. Si noti che SharePoint include questa cartella come sottocartella virtualizzata in ogni sito di SharePoint.

In un altro scenario, un amministratore di SharePoint può introdurre inavvertitamente codice dannoso per distribuire una soluzione personalizzata SharePoint da una fonte ambigua senza test appropriato e verifica del codice. Codice inline ASP.NET incorporato nelle pagine master e di contenuto è anche causa del problema. Per impostazione predefinita, SharePoint non elabora script sul lato server, ma chiunque di accedere in scrittura file web.config di un'applicazione Web di SharePoint può modificare le regole per l'elaborazione di script sul lato server. È necessario aggiungere solo una voce PageParserPath al file di web.config <pageparserpaths> sezione. Esattamente come funziona la voce PageParserPath?

Si supponga uno sviluppatore che utilizza SharePoint si chiama e complains su un messaggio di errore che Ottiene durante lo sviluppo di una pagina ASP.NET personalizzata che indica "blocchi di codice non sono consentiti in questo file." È la ricerca e individuata la soluzione in un sito di newsgroup o blog:

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

Forse ignorare gli avvisi di protezione o forse anche non menzionate le implicazioni di protezione. Indipendentemente, è necessario aggiungere questa riga al file web.config e tutti è buona perché risolto il problema.

Unwittingly, tuttavia, anche aprire un avenue per eseguire qualsiasi codice personalizzato nelle pagine ASP.NET con attendibilità completa. Se un utente malintenzionato ora carica una pagina ASP.NET dannoso, l'ambiente SharePoint è compromessi. Come indicato nella Figura 3 , è irrilevante dove in una gerarchia di raccolta siti un utente malintenzionato dispone dell'autorizzazione per caricare una pagina, può essere un innocent-ricerca sito team di piccole dimensioni. Influisce l'attacco sempre sull'applicazione Web e probabilmente la farm di intero server poiché database del contenuto e database di configurazione sono accessibili.

Nella figura 3 codice ASP.NET di attivazione in linea può compromettere un'applicazione Web SharePoint

Informazioni sui Jekyll Dr. Hyde Sig.

Come è un utente malintenzionato accedere a database del contenuto e di configurazione senza conoscere in modo esplicito le credenziali di account di protezione? Si tratta effettivamente relativamente semplice. Il processo di lavoro IIS che esegue l'applicazione Web SharePoint rappresenta l'utente di SharePoint e utilizza il token thread risultante per controlli di accesso. Ad esempio, Dr. Jekyll può accedere tutte alle risorse tali: SharePoint il token di protezione è consentito accedere. Ma l'applicazione Web SharePoint dispone anche di token del processo del processo di lavoro IIS, che è il token di protezione dell'account di protezione di SharePoint.

È Mr. Hyde che viene visualizzato quando è necessario ripristinare la rappresentazione chiamando il metodo WindowsIdentity.Impersonate statico e passando un puntatore zero, come illustrato nella 4 cifre e 4a . Dr. Jekyll non con nessun accesso diretto a del database, ma Mr. Hyde non. La strada è deselezionata per le connessioni SQL Server e query T-SQL.

Nella figura 4 le applicazioni Web di SharePoint avere due contesti di protezione fare clic su Immagine per una visualizzazione ingrandita

Figura 4a codice per recuperare i due contesti di protezione dell'applicazione Web di 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;
}

Account di protezione e isolamento processo

Pool di applicazioni e gli account di protezione non consentono proteggere raccolte siti e siti inseriti in un'applicazione Web configurata per l'esecuzione di codice non verificato. Loro scopo consiste nel ridurre, per mezzo di isolamento del processo, l'impatto di un exploit in un sito che consente a chi effettua un attacco inserire il codice al server agli attacchi di altri siti. Isolamento di processo può contribuire a raggiungere questo obiettivo, ma richiede posizionare altri siti nelle applicazioni Web separate che vengono eseguiti in pool di applicazioni con account di protezione diverse.

È necessario proteggere adeguatamente le credenziali dell'account, in caso contrario è pointless lo sforzo di configurazione. Una facile modo da fornire le credenziali di protezione riservati direttamente nelle mani errate è concedere l'accesso account pool di applicazioni metabase di IIS, è necessario per eseguire il servizio di gestione directory di Microsoft, una parte del servizio Web di integrazione di posta elettronica. Se l'account pool di applicazioni dispone di accesso della metabase, un utente malintenzionato può ripristinare la rappresentazione e quindi recuperare tutti gli account e password in testo non crittografato, come illustrato nella 5 cifre e 5a . L'intera server farm è persa perché l'utente non autorizzato ora può ignorare isolamento del processo eseguendo codice dannoso in uno qualsiasi di questi account di protezione e stabilire connessioni di SQL Server a tutti i database del contenuto.

Nella figura 5 Retrieving informazioni account di protezione dalla metabase di IIS

Figura 5a codice recuperare dal metabase di IIS le informazioni di account di protezione

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

Se si desidera una soluzione di servizio di gestione directory di Microsoft che non richiede l'accesso della metabase, deve cercare la colonna di settembre 2008" Integrazione di directory di SharePoint."

Gli account di protezione in database di configurazione

Se si seguono la regola per concedere autorizzazioni amministrative account pool di applicazioni o addirittura accesso in lettura molto così come la metabase di IIS sui server SharePoint, il codice nella Figura 5 raccolti soltanto un accesso negato messaggio. Ma, informazioni di account di protezione inoltre sono disponibile nel database di configurazione e Mr. Hyde ha accesso a questo database, come spiegato in precedenza.

È non può impedire SharePoint di protezione account accedere al database di configurazione, né può è negare l'accesso alla chiave che memorizza la stringa di connessione SQL Server corrispondente. La stringa di connessione potrebbe non funzionare immediatamente se si utilizza SQL Server 2005 Express, ma l'è possibile derivare il dato di origine di dati corretto dalla raccolta di siti SharePoint corrente (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString) e il nome del database configurazione corrispondente al nome della farm locale (SPFarm.Local.Name).

Purtroppo, questi ostacoli poco non interrompere un attacco. Indipendentemente se utilizzare SQL Server o SQL Server Express, Mr. Hyde possibile recuperare le informazioni visualizzate in figure 6 e 6a . Si noti che la password viene crittografata, tuttavia, in modo che l'attacco è non ancora completamente completata.

Nella figura 6 ottenere informazioni sull'account di protezione dalla configurazione della metabase

Figura 6a codice per recuperare le informazioni sulla account di protezione dalla configurazione della 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;
}

Ma anche senza decrittografare le password, pool di applicazioni che utilizzano lo stesso account di protezione già riconosciuti. Ad esempio, nella Figura 6 , l'applicazione pool v3 Amministrazione centrale SharePoint e SharePoint, 80 utilizzare l'account di servizio di rete e se SharePoint, 80 lezioni dell'applicazione Web compromesso, quindi Amministrazione centrale SharePoint v3 è compromessa nonché. L'account di protezione corrispondente è l'account di amministrazione centrale, che è elevate autorizzazioni sul server di SharePoint.

Non è deve essere utilizzata per i pool di applicazioni Web standard, ma SharePoint Products e tecnologie di configurazione guidata viene applicato questa configurazione in un'installazione a server singolo per impostazione predefinita. Di conseguenza, è molto importante che si esaminare e, se necessario, modificare la configurazione dell'account di protezione nell'ambiente SharePoint. Ulteriori informazioni su questo argomento viene descritto in dettaglio l'articolo della Microsoft Knowledge Base" Modifica account di servizio e password di account di servizio in SharePoint Server 2007 e in Windows SharePoint Services 3.0."

Account di protezione e chiavi di credenziali

Qual è la quantità di grandi sull'account di Amministrazione centrale? Soprattutto, a differenza di account di pool di applicazioni standard, l'account di amministrazione centrale abbia accesso il Registro di sistema percorso contenente la chiave di credenziali per decrittografare la password di account di protezione.

Nella figura 7 viene illustrato questo parametro e all'impostazione predefinita le impostazioni di protezione. Si può notare, amministratori locali, al gruppo WSS_RESTRICTED_WPG (che contiene l'account di amministrazione centrale) e l'account SYSTEM disporre accesso a questa chiave e ciò implica che le applicazioni Web di SharePoint non utilizzare account con autorizzazioni di amministratore locale, l'account di amministrazione centrale o l'account di sistema. Le applicazioni Web SharePoint non sarà in grado di accedere alla chiave di credenziali.

Nella figura 7 le assegnazioni di autorizzazione per accedere alla chiave del Registro di sistema FarmAdmin

Purtroppo, tuttavia, questo non è alcuna garanzia che un utente malintenzionato qualificata Impossibile determinare le password di account CredentialKey o la protezione, ad esempio tramite dirottamento del token SYSTEM, password cracking, oppure semplicemente inserire codice dannoso in pagine master o pagine di contenuto per esportare la chiave di credenziale da una posizione non protetta e quindi in attesa di un utente con autorizzazioni di amministratore locale per accedere al sito. Come può notare, è importante che non consente codice non verificato sui server.

Risorse di SharePoint

	SharePoint Products and Technologies sito
	TechCenter di Windows SharePoint Services
	Centro per sviluppatori Windows SharePoint Services
	Prodotti e Microsoft SharePoint blog del team di tecnologie

Dirottamento del token di sistema associare alcuni ulteriori e dettagliate spiegazioni, poiché è possibile evitare questo tipo di attacco se è evitare di utilizzare gli account di sistema incorporate, ad esempio il servizio di rete per le applicazioni Web di SharePoint. In effetti, Cerrudo Cesar, fondatore e responsabile aziendale Argeniss rilevati questa vulnerabilità, e ha dimostrato exploit in HITBSecConf2008 completa Knowledge protezione conferenza in Dubai, Emirati Arabi Uniti. Cesar mostrato come un'applicazione Web ASP.NET in esecuzione con l'account Servizio di rete può inserire una DLL nel servizio RPC (remote procedure call) e quindi manipolare il token di protezione di un thread del servizio RPC che esegue a livello di privilegi di sistema.

In seguito, un utente malintenzionato quindi sufficiente passare il token di protezione sistema hijacked al metodo WindowsIdentity.Impersonate per accedere al parametro del Registro di sistema CredentialKey e altre risorse protette. Microsoft confermata la vulnerabilità, pertanto è consigliabile evitare di utilizzare l'account di servizio di rete per le applicazioni Web di SharePoint.

Non Interrompi il diritto

Il 10 Leggi immutabili della protezionesono stati pubblicati da molto tempo fa e ancora applicare oggi stesso Microsoft Security Response Center. Jesper M. Johansson recente scritto una serie di tre parti chiamata" Rivedere le 10 leggi immutabili della protezione." Tali leggi si devono tenere presente quando si progetta la server farm di SharePoint e si deve seguire anche indicazioni di protezione per SharePoint i fogli di lavoro per applicare le configurazioni di account di protezione affidabile.

In un istantaneamente: utilizzare password complesse, non concedere protezione account con privilegi elevati autorizzazioni sui server di SharePoint, modificare la password spesso (comprese le credenziali di farm e tenere presente che non è assoluto isolamento tra applicazioni Web di SharePoint che consente di utilizzare risorse comuni, come non è nessuna protezione computer assoluto. Inoltre, non modificare il server codice regole di elaborazione, mantenere assembly non verificate fuori dai server e seguire il foglio di lavoro Requisiti dell'account protezione di Windows SharePoint Services nella configurazione di account di protezione e potrebbe essere possibile valutare l'ambiente SharePoint ragionevolmente protetto.

Tuttavia, se strict separazione di contenuto del sito è un requisito per l'organizzazione, consiglia da host è raccolte siti corrispondente nella farm di server distinto, probabilmente in separare insiemi di strutture di Active Directory e gli ambienti di SQL Server.

Cherny Pav è un esperto IT e l'autore specializzato nelle tecnologie Microsoft per la collaborazione e comunicazione unificata. Sua pubblicazioni includono white paper, manuali del prodotto e libri con particolare attenzione su operazioni e amministrazione del sistema. Pav è presidente di Biblioso Corporation, una società specializzata in servizi di documentazione e la localizzazione gestiti.