Explorando o SharePointContas de segurança do SharePoint

Pav Cherny

Conteúdo

Pools de aplicativos e contas de segurança
Execução de código personalizado em SharePoint Servers
Sobre o Médico e o Monstro
Contas de segurança e isolamento do processo
Contas de segurança no banco de dados de configuração
Contas de segurança e chaves de credenciais
Não viole a lei

Ao usar contas de segurança do SharePoint, há um risco elevado de criar configurações frágeis do sistema que possam expor um ambiente inteiro do SharePoint. Para ajudá-lo a implantar e proteger corretamente farms de servidores do SharePoint, a Microsoft publicou informações abrangentes e diretrizes detalhadas. O Guia de Segurança do Office SharePoint Server, por exemplo, apresenta mais de 300 páginas sobre o planejamento e a implementação de hierarquias de conteúdo e site, métodos de autenticação, brechas de segurança, contas de serviço e administrador, além de muitas outras questões de segurança. A planilha Requisitos de conta de segurança do Windows SharePoint Services também fornece informações essenciais sobre configurações de conta de segurança. Se a segurança for importante para você, certamente você seguirá as recomendações apresentadas nessa planilha.

Mesmo com documentação abrangente, a configuração de contas de segurança pode ser uma tarefa difícil. Na verdade, as configurações padrão de instalações de um único servidor desviam-se das recomendações da planilha, e determinados componentes, como o Serviço Web Integração de Email, incluído no Windows SharePoint Services (WSS) 3.0, exigem permissões elevadas no servidor, que não apenas se desviam das recomendações de segurança da Microsoft, mas também estão em conflito com as práticas recomendadas de segurança e senso comum. A ferramenta Administração Central do SharePoint 3.0 felizmente aplica configurações críticas de conta de segurança sem avisos, o Microsoft Baseline Security Analyzer (MBSA) não detecta a fragilidade resultante e, portanto, permanece um desafio proteger um farm de servidores do SharePoint – e mantê-lo seguro.

Neste artigo, examinei de perto as contas de segurança do SharePoint para mostrar a você como uma configuração fraca pode dar a um invasor controle total sobre todos os sites e conjuntos de sites. Esse é um tópico de certa forma delicado. Por um lado, quero ajudá-lo a reconhecer os desafios de segurança que envolvem as configurações do SharePoint Server. Afinal de contas, é necessário compreender os pontos fortes e fracos do seu ambiente do SharePoint para protegê-lo com eficiência.

Por outro lado, não quero auxiliar pessoas mal-intencionadas. Por esse motivo, não estou fornecendo planilhas ou ferramentas personalizadas neste artigo e abordarei apenas discussões de código-fonte a tópicos básicos com os quais todos os desenvolvedores profissionais de ASP.NET devem estar familiarizados. Os snippets de código-fonte abordados nesta coluna devem ajudá-lo a detectar vulnerabilidades, mas não ajudar alguém a explorá-los. Mesmo com habilidades limitadas de programação, você deve ser capaz de usar esses snippets para criar páginas ASP.NET personalizadas se tiver o Microsoft Office SharePoint Designer 2007.

Há uma versão de avaliação do Microsoft Office SharePoint Designer 2007 disponível online. Convido você a configurar um laboratório de teste, de acordo com suas próprias preferências, protegê-lo da melhor forma possível e então executar os snippets de código para fins de verificação. Vejamos qual o nível de proteção de seus sites do SharePoint!

Pools de aplicativos e contas de segurança

As contas de segurança são a base do modelo de processamento de solicitação do SharePoint. Elas definem o contexto de segurança dos processos de trabalho do IIS que executam os aplicativos web do SharePoint. Quando você cria um aplicativo web do SharePoint, é necessário especificar, entre outras coisas, uma ferramenta de aplicativo com credenciais de conta de segurança associadas e um banco de dados do SharePoint com um método de autenticação associado. Se você usar a autenticação do Windows (recomendada), o SharePoint concederá as permissões dbOwner da conta de segurança no banco de dados de conteúdo, de modo que o processo de trabalho do IIS executando o aplicativo web do SharePoint poderá obter acesso aos conjuntos de sites e sites hospedados nesse banco de dados. Caso contrário, você deverá fornecer credenciais explícitas do SQL Server.

Em qualquer um dos casos, os conjuntos de sites e sites são construções virtuais. Fisicamente, eles correspondem a registros de banco de dados. Se você souber o nome da conta e a senha para estabelecer uma conexão direta do SQL Server com o banco de dados de conteúdo, poderá ter acesso total a seus conjuntos de sites e dados de sites, independentemente de permissões e controles de acesso definidos no nível do SharePoint. O SharePoint não pode bloquear você, pois você está estabelecendo uma conexão direta com o servidor do banco de dados, como ilustrado na Figura 1. Portanto, a conta de segurança é o principal alvo para uma invasão.

fig01.gif

Figura 1 Como ignorar conjuntos de sites do SharePoint e sites para acessar dados

Para reduzir riscos de segurança, a Microsoft recomenda que você configure pools de aplicativos separados (e contas de segurança) para conjuntos de sites com conteúdo autenticado e anônimo; além disso, ela recomenda que você isole aplicativos que armazenam senhas ou nos quais os usuários tenham total liberdade para criar e administrar sites, bem como colaborar no conteúdo. Seguindo esse dispositivo de configuração, a idéia subjacente é que um invasor que obtém controle de um pool de aplicativos não terá então, implicitamente, acesso universal a todos os dados hospedados no farm de servidores do SharePoint. Os sites e conjuntos de sites do SharePoint em outros bancos de dados ainda estão fora de alcance, desde que você use contas de segurança separadas para seus aplicativos web associados.

A Microsoft foi a primeira a introduzir o conceito de isolamento do processo de trabalho com base em pools de aplicativos com o IIS 6.0 e declara que o IIS não sofreu desde então uma única vulnerabilidade crítica de segurança. Isso é muito tranqüilizador, então, aproveite os pools de aplicativos nos farms do SharePoint. No entanto, lembre-se de que os sites do IIS e os aplicativos web do SharePoint não são sinônimos. Embora você ainda possa isolar sites do IIS, não é possível isolar aplicativos web do SharePoint um do outro.

O verdadeiro isolamento ocorre apenas se sites não compartilharem recursos, ainda que aplicativos web do SharePoint sempre tenham recursos em comum, como o banco de dados de configuração do farm. Como ilustrado na Figura 2, obter controle em uma conta de segurança do SharePoint implica capacidade de acessar o banco de dados de configuração do SharePoint. Essa capacidade de acesso deverá fazer com que você não se sinta confortável se tiver implantado o seu farm do SharePoint sem considerar adequadamente a proteção de suas contas de segurança, especialmente se você estiver hospedando sites e conjuntos de sites de diferentes clientes internos ou externos em um ambiente compartilhado.

Figura 2 A relação entre aplicativos web do SharePoint, banco de dados de configuração e bancos de dados de conteúdo

Execução de código personalizado em SharePoint Servers

Por definição de fábrica, o SharePoint não divulga informações de conta de segurança; ele usa o código malicioso para descobrir os detalhes. Como todos nós sabemos, as vulnerabilidades de segurança podem permitir que invasores carreguem código malicioso, mas às vezes a invasão é ainda mais fácil.

No caso mais simples, um invasor pode ser capaz de fazer logon em um SharePoint Server localmente ou através do Terminal Server, e copiar o código malicioso na pasta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\TEMPLATE\Layouts. Observe que o SharePoint inclui essa pasta como uma subpasta virtualizada em cada site do SharePoint.

Em outro cenário, um administrador do SharePoint pode introduzir, sem saber, código malicioso implantando uma solução personalizada do SharePoint a partir de uma fonte questionável sem a verificação de código e os testes adequados. O código ASP.NET embutido incorporado nas páginas mestras e de conteúdo também é motivo de preocupação. Por padrão, o SharePoint não processa scripts do lado do servidor, mas qualquer um com acesso de gravação a um arquivo web.config do aplicativo web do SharePoint pode alterar as regras para processamento de scripts do lado do servidor. Você só precisa adicionar uma entrada PageParserPath à seção <PageParserPaths> do arquivo web.config. Como funciona exatamente a entrada PageParserPath?

Vamos supor que um desenvolvedor que esteja usando o SharePoint ligue para você e reclame sobre uma mensagem de erro que ele recebe ao desenvolver uma página ASP.NET personalizada, declarando "Blocos de código não são permitidos neste arquivo". Você pesquisa na Internet e descobre a solução em um site de blog ou grupo de notícias:

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

Talvez você ignore os avisos de segurança ou as implicações de segurança nem sejam mencionadas. Independentemente, você adiciona essa linha ao seu arquivo web.config e agora todos estão satisfeitos, pois sabem que você resolveu o problema.

No entanto, involuntariamente, você também acabou de abrir uma via para executar qualquer código personalizado em páginas ASP.NET com total confiança. Agora, se um invasor carregar uma página ASP.NET maliciosa, o ambiente do SharePoint estará em risco. Como indicado na Figura 3, é irrelevante onde, em uma hierarquia do conjunto de sites, um invasor tem a permissão para carregar uma página – pode ser um pequeno site aparentemente “inocente” da empresa. A invasão sempre afeta o aplicativo web e, possivelmente, o farm inteiro de servidores, pois o banco de dados de conteúdo e o banco de dados de configuração estão acessíveis.

Figure 3

Figura 3 Habilitar código ASP.NET embutido pode comprometer um aplicativo web do SharePoint

Sobre o Médico e o Monstro

Então, como um invasor faz para obter acesso a bancos de dados de conteúdo e configuração sem saber explicitamente as credenciais de conta de segurança? Na verdade, é relativamente simples e direto. O processo de trabalho do IIS que executa o aplicativo web do SharePoint representa o usuário do SharePoint e usa o token de thread resultante para verificações de acesso. Por exemplo, O Médico pode acessar todos os recursos do SharePoint aos quais seu token de segurança permitir acesso. Mas o aplicativo web do SharePoint também tem o token de processo do processo de trabalho do IIS, que é o token de segurança da conta de segurança do SharePoint.

É o Monstro que é exibido quando você reverte a representação chamando o método WindowsIdentity.Impersonate estático e transmitindo um ponteiro zero, como ilustrado nas Figuras 4 e 4a. O Médico não tem acesso direto aos bancos de dados, mas O Monstro, sim. O caminho está livre para conexões do SQL Server e consultas do T-SQL.

fig4a_screen.gif

Figura 4 Os aplicativos web do SharePoint têm dois contextos de segurança (clique na imagem para ampliá-la)

Figura 4a Código para recuperar os dois contextos de segurança do aplicativo web do 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;
}

Contas de segurança e isolamento do processo

Os pools de aplicativo e contas de segurança não podem ajudá-lo a proteger sites e conjuntos de sites inseridos em um aplicativo web configurado para executar código não verificado. Sua finalidade é reduzir, através do isolamento do processo, o impacto de uma exploração em um site que permite que um invasor insira código no servidor para invadir outros sites. O isolamento do processo pode ajudar a atingir esse objetivo, mas ele requer que você insira os outros sites em aplicativos web separados executados em pools de aplicativos com diferentes contas de segurança.

É necessário proteger adequadamente as credenciais de conta; caso contrário, o esforço de configuração será inútil. Uma forma fácil de fornecer essas credenciais confidenciais de segurança diretamente para a pessoa errada é conceder acesso de contas do pool de aplicativos à metabase do IIS, que é necessária para execução do Serviço de Gerenciamento de Diretório – uma parte do Serviço Web Integração de Email. Se a conta do pool de aplicativos tiver acesso à metabase, um invasor poderá reverter a representação e, então, recuperar todas as contas e senhas em texto não criptografado, como ilustrado nas Figuras 5 e 5a. O farm inteiro de servidores é perdido, pois o invasor agora pode ignorar o isolamento do processo executando código malicioso em qualquer uma dessas contas de segurança e estabelecendo conexões do SQL Server com todos os bancos de dados de conteúdo.

fig5a_screen.gif

Figura 5 Recuperação de informações de conta de segurança da metabase do IIS

Figura 5a Código para recuperação de informações de conta de segurança da metabase do 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();
}

Se você estiver interessado em uma solução do Serviço de Gerenciamento de Diretório que não requeira acesso à metabase, leia a minha coluna de setembro de 2008, "Integração de diretórios do SharePoint".

Contas de segurança no banco de dados de configuração

Se você seguir a regra de não conceder permissões administrativas a contas do pool de aplicativos ou até mesmo acesso de leitura à metabase do IIS nos seus servidores do SharePoint, o código na Figura 5 irá gerar apenas uma mensagem de Acesso negado. Mas as informações da conta de segurança também estão disponíveis no banco de dados de configuração e O Monstro tem acesso a esse banco de dados, como explicado anteriormente.

Você não pode negar o acesso de contas de segurança do SharePoint ao banco de dados de configuração nem pode negar acesso à chave de Registro que armazena a cadeia de conexão do SQL Server correspondente. A cadeia de conexão pode não funcionar imediatamente se você usar o SQL Server 2005 Express, mas você pode derivar as informações da fonte de dados correta do atual conjunto de sites do SharePoint (SPContext.Current.Site.ContentDatabase.DatabaseConnectionString) e o nome do banco de dados de configuração corresponderá ao nome do farm local (SPFarm.Local.Name).

Infelizmente, esses pequenos obstáculos não impedem uma invasão. Independentemente de você usar o SQL Server ou o SQL Server Express, O Monstro pode recuperar as informações exibidas nas Figuras 6 e 6a. No entanto, observe que a senha é criptografada, de modo que a invasão ainda não foi concluída com êxito.

fig6a_screen.gif

Figura 6 Obtenção de informações de conta de segurança da metabase de configuração

Figura 6a Código para recuperação de informações de conta de segurança da metabase de configuração

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

Mas mesmo sem descriptografar senhas, os pools de aplicativos que usam a mesma conta de segurança já são reconhecíveis. Por exemplo, na Figura 6, os pools de aplicativos SharePoint Central Administration v3 e SharePoint—80 usam a conta Serviço de Rede e se o SharePoint—80 for comprometer o aplicativo web, então o SharePoint Central Administration v3 também será comprometido. A conta de segurança correspondente é a conta Administração Central, que possui as permissões elevadas no SharePoint Server.

Ela não deve ser usada para pools de aplicativos web padrão, ainda que, por padrão, o Assistente de Configuração de Produtos e Tecnologias do SharePoint aplique essa configuração em uma instalação de único servidor. Portanto, é muito importante que você revise e, se necessário, altere a configuração da conta de segurança no seu ambiente do SharePoint. Mais informações sobre esse tópico são descritas detalhadamente no artigo da Base de Dados de Conhecimento Microsoft "Como alterar contas de serviço e senhas de contas de serviço no SharePoint Server 2007 e no Windows SharePoint Services".

Contas de segurança e chaves de credenciais

Então, o que há de interessante em relação à conta Administração Central? O mais importante, ao contrário de contas de pool de aplicativos padrão, é que a conta Administração Central tem acesso ao local de Registro que armazena a chave de credencial para descriptografar as senhas da conta de segurança.

A Figura 7 mostra esse parâmetro e suas configurações de segurança padrão. Como você pode ver, os Administradores locais, o grupo WSS_RESTRICTED_WPG (que contém a conta Administração Central) e a conta SYSTEM têm acesso a essa chave e isso implica que os seus aplicativos web do SharePoint não devem usar contas com permissões de administrador local, a conta Administração Central ou a conta SYSTEM. Os aplicativos web do SharePoint não devem ser capazes de acessar a chave de credencial.

fig07a.gif

Figura 7 Atribuições de permissão para acesso à chave do Registro FarmAdmin

No entanto, infelizmente, não há garantia de que um invasor capacitado não possa determinar a CredentialKey ou senhas de conta de segurança, como através de seqüestro do token SYSTEM, descoberta de senha ou simplesmente ao inserir código malicioso em páginas mestras ou páginas de conteúdo, a fim de exportar a chave de credencial para um local não protegido e então aguardar para que um usuário com permissões de administrador local acesse o site. Como você pode ver, é importante que você não permita código não verificado em seus servidores.

Recursos do SharePoint

bluebullet.gif Site dos Produtos e Tecnologias do SharePoint

bluebullet.gif TechCenter do Windows SharePoint Services

bluebullet.gif Windows SharePoint Services Developer Center

bluebullet.gif Blog da equipe de produtos e tecnologias do Microsoft SharePoint

O seqüestro do token SYSTEM merece uma explicação mais detalhada, pois você pode impedir essa forma de invasão se evitar usar as contas embutidas do sistema, como o Serviço de Rede, para seus aplicativos web do SharePoint. Na verdade, Cesar Cerrudo, fundador e CEO da Argeniss, descobriu essa vulnerabilidade e demonstrou a exploração na HITBSecConf2008 Deep Knowledge Security Conference em Dubai, nos Emirados Árabes Unidos. Cesar mostrou como um aplicativo web ASP.NET em execução na conta Serviço de Rede pode inserir uma DLL no serviço RPC (Chamada de Procedimento Remoto) e, em seguida, seqüestrar o token de segurança de um thread no serviço RPC executado no nível de privilégio SYSTEM.

Depois disso, um invasor só precisa então passar o token de segurança SYSTEM seqüestrado para o método WindowsIdentity.Impersonate para obter acesso ao parâmetro do Registro CredentialKey e outros recursos protegidos. A Microsoft confirmou a vulnerabilidade para que você evite usar a conta Serviço de Rede para seus aplicativos web do SharePoint.

Não viole a lei

As 10 leis imutáveis da segurança foram publicadas pelo Microsoft Security Response Center há algum tempo e ainda se aplicam atualmente. Jesper M. Johansson escreveu recentemente uma série de três partes denominada "Revisitando as 10 leis imutáveis da segurança". Você deve manter essas leis em mente ao criar os seus farms de servidores do SharePoint; além disso, você deve seguir as planilhas e diretrizes de segurança do SharePoint para aplicar configurações confiáveis de conta de segurança.

Em resumo: use senhas fortes, não conceda permissões elevadas de contas de segurança em seus servidores do SharePoint, altere senhas com freqüência (incluindo as credenciais do farm) e lembre-se de que não há isolamento absoluto entre aplicativos web do SharePoint que usam recursos comuns, assim como não há segurança absoluta no computador. Além disso, não altere as regras de processamento de código de servidor, mantenha os assemblies não verificados distantes dos seus servidores e siga a planilha Requisitos de conta de segurança do Windows SharePoint Services na configuração de sua conta de segurança, e você poderá considerar seu ambiente do SharePoint razoavelmente seguro.

No entanto, se a separação rigorosa de conteúdo do site for um requisito para sua organização, recomendo que você hospede os conjuntos de sites correspondentes em farms de servidores separados, possivelmente em florestas do Active Directory e ambientes do SQL Server.

Pav Cherny é especialista em TI e autor especializado em tecnologias Microsoft para colaboração e comunicação unificada. Entre suas publicações estão white papers, manuais de produto e livros com foco em operações de TI e administração do sistema. Pav é presidente da Biblioso Corporation, empresa especializada em serviços de documentação gerenciada e localização.