Alternativas ao comprometimento

  • Artigo

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012

Lei Número Sete: a rede mais segura é aquela que é bem administrada. - Dez leis imutáveis da administração de segurança

Em organizações que sofreram eventos de comprometimento catastróficos, as avaliações geralmente revelam que as organizações têm visibilidade limitada sobre o estado real das infraestruturas de TI, o que pode diferir consideravelmente dos estados "conforme documentado". Essas variações introduzem vulnerabilidades que expõem o ambiente ao comprometimento, muitas vezes com pouco risco de descoberta até que o comprometimento tenha progredido ao ponto de os invasores efetivamente serem os "proprietários" do ambiente.

Avaliações detalhadas da configuração do AD DS dessas organizações, PKIs (infraestruturas de chave pública), servidores, estações de trabalho, aplicativos, ACLs (listas de controle de acesso) e outras tecnologias revelam configurações incorretas e vulnerabilidades que, se corrigidas, poderiam ter impedido o comprometimento inicial.

A análise da documentação, dos processos e dos procedimentos de TI identifica as vulnerabilidades introduzidas por lacunas nas práticas administrativas que foram aproveitadas pelos invasores para, em última análise, obter privilégios que foram usados para comprometer por completo a floresta do Active Directory. Uma floresta totalmente comprometida é aquela em que os invasores comprometem não apenas sistemas individuais, aplicativos ou contas de usuário, mas escalonam o acesso para obter um nível de privilégio no qual podem modificar ou destruir todos os aspectos da floresta. Quando uma instalação do Active Directory é comprometida nesse grau, os invasores podem fazer alterações que permitam manter uma presença em todo o ambiente, ou pior, destruir o diretório e as contas e os sistemas gerenciados por ele.

Embora várias das vulnerabilidades comumente exploradas nas descrições a seguir não sejam ataques contra o Active Directory, elas permitem que os invasores estabeleçam uma base em um ambiente que possa ser usado para executar ataques de escalonamento de privilégios (também chamados de elevação de privilégio) e, por fim, atacar e comprometer o AD DS.

Esta seção do documento tem como foco descrever os mecanismos que os invasores normalmente usam para obter acesso à infraestrutura e, por fim, iniciar ataques de elevação de privilégio. Confira também as seguintes seções:

Observação

Embora este documento tenha como foco os sistemas Active Directory e Windows que fazem parte de um domínio do AD DS, os invasores raramente se concentram apenas no Active Directory e no Windows. Em ambientes com uma combinação de sistemas operacionais, diretórios, aplicativos e repositórios de dados, é comum descobrir que sistemas não Windows também foram comprometidos. Isso é particularmente verdadeiro se os sistemas fornecem uma "ponte" entre ambientes Windows e não Windows, como servidores de arquivos acessados por clientes Windows e UNIX ou Linux, diretórios que fornecem serviços de autenticação para vários sistemas operacionais ou metadados que sincronizam dados entre diretórios diferentes.

O AD DS é um alvo devido aos recursos centralizados de gerenciamento de configuração e acesso que ele fornece não apenas para os sistemas Windows, mas para outros clientes. Qualquer outro diretório ou aplicativo que forneça serviços de gerenciamento de configuração e autenticação pode e será alvo de invasores determinados. Embora este documento tenha como foco as proteções que podem reduzir a probabilidade de um comprometimento das instalações do Active Directory, todas as organizações que incluem computadores, diretórios, aplicativos ou repositórios de dados não Windows também devem se preparar para ataques contra esses sistemas.

Alvos iniciais de violação

Ninguém cria intencionalmente uma infraestrutura de TI que expõe a organização ao comprometimento. Quando uma floresta do Active Directory é construída pela primeira vez, em geral, ela é intocada e atual. À medida que os anos passam e novos sistemas operacionais e aplicativos são adquiridos, eles são adicionados à floresta. À medida que os benefícios de capacidade de gerenciamento fornecidos pelo Active Directory são reconhecidos, cada vez mais conteúdo é adicionado ao diretório, mais pessoas integram os computadores ou os aplicativos ao AD DS e os domínios são atualizados para dar suporte às novas funcionalidades oferecidas pelas versões mais atuais do sistema operacional Windows. No entanto, o que acontece ao longo do tempo é que, mesmo quando uma nova infraestrutura é adicionada, outras partes da infraestrutura talvez não sejam mantidas tão bem quanto eram inicialmente, os sistemas e os aplicativos funcionem corretamente e, portanto, não recebam atenção, e as organizações comecem a se esquecer de que não eliminaram a infraestrutura herdada deles. Com base no que vemos na avaliação de infraestruturas comprometidas, quanto mais antigo, maior e mais complexo o ambiente, mais provável é que haja inúmeras instâncias de vulnerabilidades comumente exploradas.

Seja qual for a motivação do invasor, a maioria das violações de segurança da informação começa com o comprometimento de um ou dois sistemas de cada vez. Esses eventos iniciais, ou pontos de entrada na rede, geralmente aproveitam vulnerabilidades que poderiam ter sido corrigidas, mas não foram. O DBIR (Relatório de Investigações de Violação de Dados) de 2012, um estudo anual produzido pela Verizon RISK Team em cooperação com várias agências de segurança nacional e outras empresas, afirma que 96% dos ataques "não foram altamente difíceis" e que "97% das violações poderiam ter sido evitadas por meio de controles simples ou intermediários". Essas descobertas podem ser uma consequência direta das vulnerabilidades comumente exploradas a seguir.

Lacunas em implantações de antivírus e antimalware

Lei Número Oito: um verificador de malware desatualizado é apenas marginalmente melhor do que nenhum verificador. - Dez leis imutáveis da segurança (versão 2.0)

A análise das implantações antivírus e antimalware das organizações geralmente revela um ambiente no qual a maioria das estações de trabalho é configurada com um software antivírus e antimalware habilitado e atual. As exceções geralmente são estações de trabalho que se conectam com pouca frequência ao ambiente corporativo ou dispositivos de funcionários para os quais um software antivírus e antimalware pode ser difícil de ser implantado, configurado e atualizado.

No entanto, as populações de servidores tendem a ser menos consistentemente protegidas em muitos ambientes comprometidos. Conforme relatado nas Investigações de Violação de Dados de 2012, 94% de todos os comprometimentos de dados envolviam servidores, o que representa um aumento de 18% em relação ao ano anterior e 69% dos ataques incorporaram um malware. Em populações de servidores, não é incomum descobrir que as instalações antivírus e antimalware estão configuradas de maneira inconsistente, desatualizadas, configuradas incorretamente ou até desabilitadas. Em alguns casos, o software antivírus e antimalware é desabilitado pela equipe administrativa, mas em outros casos, os invasores desabilitam o software depois de comprometer um servidor por meio de outras vulnerabilidades. Quando o software antivírus e antimalware está desabilitado, os invasores plantam um malware no servidor e se concentram em propagar o comprometimento entre a população do servidor.

É importante não apenas garantir que seus sistemas estejam protegidos com a proteção contra malware atual e abrangente, mas também monitorar os sistemas para desabilitar ou remover programas de software antivírus e antimalware e reiniciar automaticamente a proteção quando ela estiver desabilitada manualmente. Embora nenhum software antivírus e antimalware possa garantir a prevenção e a detecção de todas as infecções, uma implementação de antivírus e antimalware adequadamente configurada e implantada pode reduzir a probabilidade de infecção.

Aplicação de patch incompleta

Lei Número Três: se você não acompanhar as correções de segurança, sua rede não será sua por muito tempo. - Dez leis imutáveis da administração de segurança

A Microsoft lança boletins de segurança na segunda terça-feira de cada mês, embora em raras ocasiões as atualizações de segurança sejam lançadas entre as atualizações de segurança mensais (elas também são conhecidas como atualizações "fora de banda") quando a vulnerabilidade é determinada como um risco urgente para os sistemas de clientes. Não importa se uma pequena empresa configura os computadores Windows para usar o Windows Update a fim de gerenciar a aplicação de patch do sistema e de aplicativos ou se uma organização de grande porte usa um software de gerenciamento, como o Microsoft Endpoint Configuration Manager para implantar patches de acordo com planos hierárquicos detalhados: vários clientes corrigem as infraestruturas do Windows em tempo relativamente hábil.

No entanto, poucas infraestruturas incluem apenas computadores Windows e aplicativos da Microsoft e, em ambientes comprometidos, é comum descobrir que a estratégia de gerenciamento de patch da organização contém lacunas. Os sistemas Windows desses ambientes recebem patches de maneira inconsistente. Sistemas operacionais não Windows são corrigidos esporadicamente, quando são. Os aplicativos COTS (commercial off-the-shelf) contêm vulnerabilidades para as quais existem patches, mas que não foram aplicados. Os dispositivos de rede geralmente são configurados com credenciais padrão de fábrica e sem atualizações de firmware vários anos após a instalação. Os aplicativos e os sistemas operacionais que não têm mais suporte dos fornecedores geralmente são mantidos em execução, apesar de não poderem mais ser corrigidos contra vulnerabilidades. Cada um desses sistemas sem patch representa outro ponto de entrada potencial para os invasores.

A consumerização da TI introduziu desafios adicionais, pois os dispositivos pertencentes aos funcionários estão sendo usados para acessar dados corporativos, e a organização pode ter pouco ou nenhum controle sobre a aplicação de patch e a configuração dos dispositivos pessoais dos funcionários. O hardware de classe empresarial normalmente é fornecido com opções de configuração e recursos de gerenciamento prontos para a empresa, ao custo de menos opções na personalização individual e na seleção de dispositivos. O hardware voltado para funcionários oferece uma gama mais ampla de fabricantes, fornecedores, recursos de segurança de hardware, recursos de segurança de software, recursos de gerenciamento e opções de configuração, e muitos recursos corporativos podem estar completamente ausentes.

Patch e software de gerenciamento de vulnerabilidades

Se um sistema de gerenciamento de patch eficaz estiver em vigor para os sistemas Windows e aplicativos da Microsoft, parte da superfície de ataque que as vulnerabilidades não corrigidas cria terá sido resolvida. No entanto, a menos que os sistemas não Windows, aplicativos não Microsoft, infraestrutura de rede e dispositivos de funcionários também sejam mantidos atualizados em patches e outras correções, a infraestrutura permanecerá vulnerável. Em alguns casos, o fornecedor de um aplicativo pode oferecer funcionalidades de atualização automática. Em outros, pode haver a necessidade de criar uma abordagem para recuperar e aplicar regularmente patches e outras correções.

Aplicativos e sistemas operacionais desatualizados

"Não é possível esperar que um sistema operacional de seis anos proteja você contra um ataque de seis meses." – Profissional de segurança da informação com dez anos de experiência na proteção de instalações corporativas

Embora "atualize-se, mantenha-se atualizado" possa soar como uma frase de marketing, os sistemas operacionais e os aplicativos desatualizados criam risco nas infraestruturas de TI de muitas organizações. Um sistema operacional lançado em 2003 ainda pode ter suporte do fornecedor e ser fornecido com atualizações para resolver vulnerabilidades, mas talvez esse sistema operacional não contenha recursos de segurança adicionados em versões mais recentes do sistema operacional. Sistemas desatualizados podem até exigir o enfraquecimento de determinada configuração de segurança do AD DS para dar suporte aos recursos secundários desses computadores.

Em geral, os aplicativos que foram escritos para usar protocolos de autenticação herdados por fornecedores que não dão mais suporte ao aplicativo não podem ter aprimoramento de ferramentas para dar suporte a mecanismos de autenticação mais fortes. No entanto, o domínio do Active Directory de uma organização ainda pode ser configurado para armazenar hashes do LAN Manager ou senhas criptografadas reversivelmente para dar suporte a esses aplicativos. Os aplicativos escritos antes da introdução de sistemas operacionais mais recentes talvez não funcione bem ou em sistemas operacionais atuais, exigindo que as organizações mantenham sistemas cada vez mais antigos e, em alguns casos, um hardware e um software completamente sem suporte.

Mesmo nos casos em que as organizações atualizaram os controladores de domínio para o Windows Server 2012, o Windows Server 2008 R2 ou o Windows Server 2008, é comum encontrar partes significativas da população de servidores membro executando o Windows Server 2003, o Windows 2000 Server ou o Windows NT Server 4.0 (que são completamente sem suporte). Quanto mais tempo uma organização mantém sistemas arcaicos, mais a disparidade entre os conjuntos de recursos aumenta e maior a probabilidade de que os sistemas de produção não tenham suporte. Além disso, quanto mais uma floresta do Active Directory é mantida, mais observamos que sistemas e aplicativos herdados são perdidos nos planos de atualização. Isso pode significar que um só computador que executa um aplicativo individual pode introduzir vulnerabilidades em todo o domínio ou em toda a floresta, porque o Active Directory está configurado para dar suporte aos protocolos e aos mecanismos de autenticação herdados.

Para eliminar sistemas e aplicativos herdados, primeiro, você deve se concentrar em identificá-los e catalogá-los e, depois, em determinar se deseja atualizar ou substituir o aplicativo ou o host. Embora possa ser difícil encontrar substituições para aplicativos altamente especializados para os quais não há suporte nem um caminho de atualização, você pode conseguir aproveitar um conceito chamado "destruição criativa" para substituir o aplicativo herdado por um novo aplicativo que fornece a funcionalidade necessária. O planejamento para evitar o comprometimento é descrito com mais detalhes em "Planejamento para evitar o comprometimento" mais adiante neste documento.

Configuração incorreta

Lei Número Quatro: não é muito útil instalar correções de segurança em um computador que nunca foi protegido para começar. - Dez leis imutáveis da administração de segurança

Mesmo em ambientes em que os sistemas geralmente são mantidos atualizados e corrigidos, costumamos identificar lacunas ou configurações incorretas no sistema operacional, nos aplicativos em execução em computadores e no Active Directory. Algumas configurações incorretas expõem apenas o computador local ao comprometimento, mas depois que um computador passa ter um "proprietário", os invasores geralmente se concentram em propagar ainda mais o comprometimento entre outros sistemas e, por fim, para o Active Directory. Veja a seguir algumas das áreas comuns em que identificamos configurações que introduzem riscos.

No Active Directory

As contas do Active Directory que são o alvo mais comum dos invasores são aquelas que são membros dos grupos mais privilegiados, como membros dos grupos DA (Administradores do Domínio), EA (Administradores Corporativos) ou BA (Administradores Internos) no Active Directory. A associação desses grupos deve ser reduzida ao menor número de contas possível para que a superfície de ataque desses grupos seja limitada. É até possível eliminar a associação "permanente" nesses grupos privilegiados, ou seja, você pode implementar configurações que permitem preencher temporariamente esses grupos somente quando os respectivos privilégios de domínio e de floresta forem necessários. Quando contas altamente privilegiadas são usadas, elas devem ser usadas somente em sistemas designados e seguros, como controladores de domínio ou hosts administrativos seguros. Informações detalhadas para ajudar a implementar todas essas configurações são fornecidas em Como reduzir a superfície de ataque do Active Directory.

Quando avaliamos a associação dos grupos com privilégios mais altos no Active Directory, geralmente encontramos uma associação excessiva nos três grupos com mais privilégios. Em alguns casos, as organizações têm dezenas, até mesmo centenas de contas em grupos DA. Em outros casos, as organizações colocam as contas diretamente em grupos de Administradores internos, pensando que o grupo é "menos privilegiado" do que o grupo DAs. Não é. Muitas vezes, encontramos vários membros permanentes do grupo EA no domínio raiz da floresta, apesar do fato de os privilégios de EA serem rara e temporariamente necessários. Encontrar a conta administrativa diária de um usuário de TI nos três grupos também é comum, embora essa seja uma configuração efetivamente redundante. Conforme descrito em Como reduzir a superfície de ataque do Active Directory, se uma conta é membro permanente de um desses grupos ou de todos eles, a conta pode ser usada para comprometer e até destruir o ambiente do AD DS e as contas e os sistemas gerenciados por ele. As recomendações para a configuração segura e o uso de contas privilegiadas no Active Directory são fornecidas em Como reduzir a superfície de ataque do Active Directory.

Em controladores de domínio

Quando avaliamos os controladores de domínio, geralmente os encontramos configurados e gerenciados de maneira diferente dos servidores membro. Às vezes, os controladores de domínio executam os mesmos aplicativos e utilitários instalados em servidores membro, não porque são necessários nos controladores de domínio, mas porque os aplicativos fazem parte de um build padrão. Esses aplicativos podem fornecer uma funcionalidade mínima nos controladores de domínio, mas contribuem consideravelmente com a superfície de ataque, exigindo a definição de configuração que abre portas, cria contas de serviço altamente privilegiadas ou permite acesso ao sistema aos usuários que não devem se conectar a um controlador de domínio para qualquer finalidade diferente da autenticação e da aplicação da Política de Grupo. Em algumas violações, os invasores usaram ferramentas que já estavam instaladas em controladores de domínio não apenas para obter acesso aos controladores de domínio, mas para modificar ou danificar o banco de dados do AD DS.

Quando extraímos as definições de configuração do Internet Explorer em controladores de domínio, descobrimos que os usuários fizeram logon com contas que têm altos níveis de privilégio no Active Directory e usaram as contas para acessar a Internet e a intranet dos controladores de domínio. Em alguns casos, as contas definiram as configurações do Internet Explorer nos controladores de domínio para permitir o download de conteúdo da Internet e utilitários de freeware foram baixados de sites da Internet e instalados nos controladores de domínio. A Configuração de Segurança Aprimorada do Internet Explorer está habilitada para Usuários e Administradores por padrão, mas muitas vezes observamos que foi desabilitada para Administradores. Quando uma conta altamente privilegiada acessa a Internet e baixa um conteúdo em qualquer computador, esse computador é colocado em risco grave. Quando o computador é um controlador de domínio, toda a instalação do AD DS é colocada em risco.

Como proteger controladores de domínio

Os controladores de domínio devem ser tratados como componentes críticos de infraestrutura, protegidos de maneira mais rigorosa e configurados de maneira mais rígida do que os servidores de arquivos, impressão e aplicativos. Os controladores de domínio não devem executar nenhum software que não seja necessário para que o controlador de domínio funcione ou não proteja o controlador de domínio contra ataques. Os controladores de domínio não devem ter permissão para acessar a Internet, e as configurações de segurança devem ser definidas e impostas por GPOs (Objetos de Política de Grupo). Recomendações detalhadas para a instalação, a configuração e o gerenciamento seguros de controladores de domínio são fornecidas em Como proteger controladores de domínio contra ataques.

No sistema operacional

Lei Número Dois: se um adversário pode alterar o sistema operacional do seu computador, ele não é mais o seu computador. - Dez leis imutáveis da segurança (versão 2.0)

Embora algumas organizações criem configurações de linha de base para servidores de diferentes tipos e permitam a personalização limitada do sistema operacional após a instalação, a análise de ambientes comprometidos geralmente revela um grande número de servidores implantados de maneira ad hoc e configurados manual e independentemente. As configurações entre dois servidores que executam a mesma função podem ser completamente diferentes, em que nenhum dos servidores está configurado com segurança. Por outro lado, as linhas de base de configuração do servidor podem ser impostas de maneira consistente, mas também consistentemente configuradas de modo incorreto, ou seja, os servidores são configurados de uma forma que cria a mesma vulnerabilidade em todos os servidores de determinado tipo. Uma configuração incorreta inclui práticas como desabilitar recursos de segurança, conceder direitos e permissões excessivos a contas (particularmente a contas de serviço), usar credenciais locais idênticas entre sistemas e permitir a instalação de aplicativos e utilitários não autorizados que criam vulnerabilidades por si próprios.

Como desabilitar recursos de segurança

Às vezes, as organizações desabilitam o WFAS (Firewall do Windows com Segurança Avançada) por acreditar que ele é difícil de ser configurado ou que ele exige uma configuração muito complexa. No entanto, do Windows Server 2008 em diante, quando qualquer função ou recurso é instalado em um servidor, ele é configurado por padrão com os privilégios mínimos necessários para que a função ou o recurso funcione, e o Firewall do Windows é configurado automaticamente para dar suporte à função ou ao recurso. Ao desabilitar o WFAS (e não usar outro firewall baseado em host no lugar), as organizações aumentam a superfície de ataque de todo o ambiente do Windows. Os firewalls de perímetro fornecem alguma proteção contra ataques direcionados diretamente a um ambiente da Internet, mas não fornecem proteção contra ataques que exploram outros vetores de ataque, como ataques de drive-by download ou ataques originados de outros sistemas comprometidos na intranet.

As configurações do UAC (Controle de Conta de Usuário) às vezes são desabilitadas em servidores, porque a equipe administrativa acha os prompts intrusivos. Embora o artigo 2526083 do Suporte da Microsoft descreva os cenários em que o UAC pode ser desabilitado no Windows Server, a menos que você esteja executando uma instalação Server Core (em que o UAC está desabilitado por design), você não deve desabilitar o UAC em servidores sem consideração e pesquisa cuidadosas.

Em outros casos, as configurações do servidor são definidas para valores menos seguros porque as organizações aplicam definições de configuração de servidor desatualizadas a novos sistemas operacionais, como a aplicação de linhas de base do Windows Server 2003 aos computadores que executam o Windows Server 2012, o Windows Server 2008 R2 ou o Windows Server 2008, sem alterar as linhas de base para que ela reflitam as alterações no sistema operacional. Em vez de levar linhas de base de servidor antigas para novos sistemas operacionais, ao implantar um novo sistema operacional, revise as alterações de segurança e as definições de configuração para garantir que as configurações implementadas sejam aplicáveis e apropriadas para o novo sistema operacional.

Como conceder um privilégio excessivo

Em quase todos os ambientes que avaliamos, o privilégio excessivo é concedido a contas locais e baseadas em domínio nos sistemas Windows. Os usuários recebem direitos de Administrador local nas estações de trabalho, os servidores membro executam os serviços configurados com direitos além do que precisam para funcionar e os grupos Administradores locais em toda a população de servidores contêm dezenas ou até mesmo centenas de contas locais e de domínio. O comprometimento de apenas uma conta privilegiada em um computador permite que os invasores comprometam as contas de todos os usuários e serviços que fazem logon no computador e coletem e aproveitem as credenciais para propagar o comprometimento para outros sistemas.

Embora os ataques PtH (Pass-the-Hash) e outros ataques de roubo de credenciais sejam onipresentes hoje em dia, isso ocorre porque há ferramentas livremente disponíveis que simplificam e facilitam a extração das credenciais de outras contas privilegiadas quando um invasor obtém acesso de nível Administrador ou SISTEMA em um computador. Mesmo sem ferramentas que permitam a coleta de credenciais das sessões de logon, um invasor com acesso privilegiado em um computador pode instalar com facilidade agentes de pressionamento de teclas que capturam pressionamentos de teclas, capturas de tela e conteúdo da área de transferência. Um invasor com acesso privilegiado a um computador pode desabilitar o software antimalware, instalar rootkits, modificar arquivos protegidos ou instalar um malware no computador que automatiza os ataques ou transforma um servidor em um host de drive-by download .

As táticas usadas para estender uma violação além de um só computador variam, mas o segredo para propagar o comprometimento é a aquisição de acesso altamente privilegiado a sistemas adicionais. Ao reduzir o número de contas com acesso privilegiado a qualquer sistema, você reduz a superfície de ataque não apenas desse computador, mas a probabilidade de um invasor coletar credenciais importantes do computador.

Como padronizar as credenciais de administrador local

Há muito tempo se discute entre os especialistas em segurança se há valor na renomeação de contas de Administrador local em computadores Windows. O que é realmente importante sobre as contas de Administrador local é se elas estão configuradas com o mesmo nome de usuário e senha em vários computadores.

Se a conta de Administrador local for nomeada com o mesmo valor entre servidores e a senha atribuída à conta também estiver configurada com o mesmo valor, os invasores poderão extrair as credenciais da conta em um computador no qual o acesso de nível de Administrador ou de SISTEMA foi obtido. O invasor não precisa comprometer inicialmente a conta de Administrador. Ele só precisa comprometer a conta de um usuário que seja membro do grupo local Administradores ou de uma conta de serviço configurada para ser executada como LocalSystem ou com privilégios de Administrador. Em seguida, o invasor pode extrair as credenciais da conta de Administrador e reproduzir essas credenciais em logons de rede para outros computadores na rede.

Desde que outro computador tenha uma conta local com o mesmo nome de usuário e senha (ou hash de senha) das credenciais de conta que estão sendo apresentadas, a tentativa de logon é bem-sucedida e o invasor obtém acesso privilegiado ao computador de destino. Nas versões atuais do Windows, a conta de Administrador interno é desabilitada por padrão, mas em sistemas operacionais herdados, a conta é habilitada por padrão.

Observação

Algumas organizações configuraram intencionalmente contas de Administrador local para serem habilitadas na crença de que isso fornece uma "proteção contra falhas" caso todas as outras contas privilegiadas sejam bloqueadas de um sistema. No entanto, mesmo que a conta de Administrador local esteja desabilitada e não haja outras contas disponíveis que possam habilitar a conta ou fazer logon no sistema com privilégios de Administrador, o sistema poderá ser inicializado no modo de segurança e a conta de Administrador local interno poderá ser habilitada de novo, conforme descrito no artigo 814777 do Suporte da Microsoft. Além disso, se o sistema ainda aplicar GPOs com sucesso, um GPO poderá ser modificado para (temporariamente) habilitar de novo a conta de Administrador ou Grupos Restritos poderão ser configurados para adicionar uma conta baseada em domínio ao grupo local Administradores. Os reparos podem ser executados, e a conta de Administrador pode ser desabilitada novamente. Para evitar efetivamente um comprometimento lateral que usa as credenciais da conta de Administrador local interno, os nomes de usuários e as senhas exclusivos precisam ser configurados para contas de Administrador local. Para implantar senhas exclusivas para contas de Administrador local por meio de um GPO, confira Solução para o gerenciamento da senha da conta de Administrador interno por meio do GPO no TechNet.  

Como permitir a instalação de aplicativos não autorizados

Lei Número Um: se um adversário pode persuadir você a executar o programa dele no seu computador, ele não é mais exclusivamente o seu computador. - Dez leis imutáveis da segurança (versão 2.0)

Se uma organização implanta configurações de linha de base consistentes entre servidores, a instalação de aplicativos que não fazem parte da função definida de um servidor não deve ser permitida. Ao permitir que um software que não faça parte da funcionalidade designada de um servidor seja instalado, os servidores são expostos à instalação inadvertida ou mal-intencionada de programas de software que aumentam a superfície de ataque do servidor, introduzem vulnerabilidades de aplicativo ou causam instabilidade no sistema.

Aplicativos

Conforme já descrito, os aplicativos geralmente são instalados e configurados para usar contas que recebem mais privilégios do que o aplicativo de fato exige. Em alguns casos, a documentação do aplicativo especifica que as contas de serviço precisam ser membros do grupo local Administradores de um servidor ou precisam ser configuradas para serem executadas no contexto do LocalSystem. Isso geralmente não ocorre porque o aplicativo exige esses direitos, mas porque determinar quais direitos e permissões as contas de serviço de um aplicativo precisam exige investimento em tempo e esforço adicionais. Se um aplicativo não for instalado com os privilégios mínimos necessários para o aplicativo e os recursos configurados funcionarem, o sistema será exposto a ataques que aproveitam privilégios de aplicativo sem nenhum ataque contra o próprio sistema operacional.

Falta de práticas seguras de desenvolvimento de aplicativos

A infraestrutura existe para dar suporte às cargas de trabalho de negócios. Quando essas cargas de trabalho são implementadas em aplicativos personalizados, é fundamental garantir que os aplicativos sejam desenvolvidos com as melhores práticas seguras. A análise da causa raiz de incidentes em toda a empresa geralmente revela que um comprometimento inicial é feito por meio de aplicativos personalizados, especialmente aqueles que são para a Internet. A maioria desses comprometimentos é realizada por meio do comprometimento de ataques conhecidos, como ataques de SQLi (injeção de SQL) e XSS (cross-site scripting).

A injeção de SQL é uma vulnerabilidade de aplicativo que permite que a entrada definida pelo usuário modifique uma instrução SQL que é transmitida para o banco de dados para execução. Essa entrada pode ser fornecida por meio de um campo no aplicativo, um parâmetro (como a cadeia de consulta ou um cookie) ou outros métodos. O resultado dessa injeção é que a instrução SQL fornecida ao banco de dados é fundamentalmente diferente do que o desenvolvedor pretendia. Veja, por exemplo, uma consulta comum usada na avaliação de uma combinação de nome de usuário/senha:

SELECT userID FROM users WHERE username = 'sUserName' AND password = 'sPassword'

Quando isso é recebido pelo servidor de banco de dados, ele instrui o servidor a analisar a tabela de usuários e retornar qualquer registro userID, em que o nome de usuário e a senha correspondam aos fornecidos pelo usuário (presumivelmente por meio de um formulário de logon de algum tipo). Naturalmente, a intenção do desenvolvedor nesse caso será retornar apenas um registro válido se um nome de usuário e senha corretos puderem ser fornecidos pelo usuário. Se um dos dois estiver incorreto, o servidor de banco de dados não poderá encontrar um registro correspondente e retornará um resultado vazio.

O problema ocorre quando um invasor faz algo inesperado, como fornecer um SQL próprio no lugar de dados válidos. Como o SQL é interpretado em tempo real pelo servidor de banco de dados, o código injetado será processado como se o desenvolvedor o tivesse colocado por conta própria. Por exemplo, se o invasor inseriu administrador para a ID de usuário e xyz OU 1=1 como a senha, a instrução resultante processada pelo banco de dados é:

SELECT userID FROM users WHERE username = 'administrator' AND password = 'xyz' OR 1=1

Quando essa consulta é processada pelo servidor de banco de dados, todas as linhas na tabela serão retornadas na consulta, porque 1=1 sempre será avaliada como True. Portanto, não importa se o nome de usuário e a senha corretos são conhecidos ou fornecidos. O resultado final na maioria dos casos é que o usuário será conectado como o primeiro usuário no banco de dados do usuário. Na maioria dos casos, esse será o usuário administrativo.

Além de apenas fazer logon, instruções SQL malformadas como essa podem ser usadas para adicionar, excluir ou alterar dados ou até remover (excluir) tabelas inteiras de um banco de dados. Nos casos mais extremos em que o SQLi é combinado com privilégio excessivo, os comandos do sistema operacional podem ser executados para permitir a criação de usuários, baixar ferramentas de ataque ou executar qualquer outra ação da escolha dos invasores.

No cross-site scripting, a vulnerabilidade é introduzida na saída do aplicativo. Um ataque começa com um invasor fornecendo dados malformados para o aplicativo, mas, nesse caso, os dados malformados estão na forma de um código de script (como JavaScript) que será executado pelo navegador da vítima. A exploração de uma vulnerabilidade de XSS pode permitir que um invasor execute qualquer função do aplicativo de destino no contexto do usuário que iniciou o navegador. Os ataques XSS normalmente são iniciados por um email de phishing incentivando o usuário a selecionar um link que se conecta ao aplicativo e executa o código de ataque.

Em geral, o XSS é explorado em cenários de banco online e comércio eletrônico, em que um invasor pode fazer compras ou transferir dinheiro no contexto do usuário explorado. No caso de um ataque direcionado a um aplicativo personalizado de gerenciamento de identidades baseado na Web, ele pode permitir que um invasor crie identidades próprias, modifique permissões e direitos e leve a um comprometimento sistêmico.

Embora uma discussão completa sobre cross-site scripting e injeção de SQL esteja fora do escopo deste documento, o OWASP (Open Web Application Security Project) publica uma lista das dez principais vulnerabilidades e contramedidas com uma discussão detalhada.

Independentemente do investimento em segurança de infraestrutura, se aplicativos mal projetados e escritos forem implantados nessa infraestrutura, o ambiente ficará vulnerável a ataques. Mesmo infraestruturas bem protegidas geralmente não podem fornecer contramedidas eficazes para esses ataques de aplicativo. Compondo o problema, aplicativos mal projetados podem exigir que as contas de serviço recebam permissões excessivas para que o aplicativo funcione.

O SDL (Microsoft Security Development Lifecycle) é um conjunto de controles estruturais de processo que funcionam para aprimorar a segurança desde o início da coleta de requisitos e estendendo-se pelo ciclo de vida do aplicativo até que ele seja desativado. Essa integração de controles de segurança efetivos não é apenas crítica do ponto de vista da segurança, mas essencial para garantir que a segurança do aplicativo seja econômica e eficaz. Avaliar um aplicativo quanto a problemas de segurança quando o código foi efetivamente concluído exige que as organizações tomem decisões sobre a segurança do aplicativo somente antes ou mesmo depois que o aplicativo é implantado. Uma organização pode optar por resolver as falhas do aplicativo antes de implantar o aplicativo em produção, gerando custos e atrasos, ou o aplicativo pode ser implantado em produção com as falhas de segurança conhecidas, expondo a organização ao comprometimento.

Algumas organizações colocam o custo total de correção de um problema de segurança no código de produção como acima de US$ 10 mil por problema, e os aplicativos desenvolvidos sem um SDL efetivo podem ter, em média, mais de dez problemas de alta gravidade a cada 100 mil linhas de código. Em aplicativos grandes, os custos aumentam rapidamente. Por outro lado, muitas empresas definem um parâmetro de comparação de menos de um problema a cada 100 mil linhas de código na fase final de revisão de código do SDL e visam a não ter nenhum problema em aplicativos de alto risco na produção.

A implementação do SDL aprimora a segurança incluindo requisitos de segurança no início da coleta de requisitos e o design de um aplicativo fornece a modelagem de ameaças para aplicativos de alto risco, exige treinamento e monitoramento eficazes de desenvolvedores e exige padrões e práticas de código claras e consistentes. O efeito resultante de um SDL são aprimoramentos significativos na segurança do aplicativo, reduzindo o custo para desenvolver, implantar, manter e desativar um aplicativo. Embora uma discussão detalhada sobre o design e a implementação do SDL esteja fora do escopo deste documento, veja o Microsoft Security Development Lifecycle para obter diretrizes e informações detalhadas.