Caminhos para o acordo

Lei número sete: A rede mais segura é uma bem administrada. - 10 Leis Imutáveis de 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 do estado real de suas infraestruturas de TI, o que pode diferir significativamente de seus estados "conforme documentado". Essas variações introduzem vulnerabilidades que expõem o ambiente à compromissão, muitas vezes com pouco risco de detecção até que a compromissão tenha progredido até o ponto em que os invasores efetivamente controlam o ambiente.

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

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

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

Esta seção deste documento se concentra em descrever os mecanismos que os invasores normalmente usam para obter acesso à infraestrutura e, eventualmente, para lançar ataques de elevação de privilégios. Consulte também as seguintes secções:

Note

Embora este documento se concentre no Ative Directory e nos sistemas Windows que fazem parte de um domínio AD DS, os atacantes raramente se concentram apenas no Ative Directory e no Windows. Em ambientes com uma mistura de sistemas operacionais, diretórios, aplicativos e repositórios de dados, é comum descobrir que sistemas que não são Windows também foram comprometidos. Isso é particularmente verdadeiro se os sistemas fornecerem 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 metadiretórios que sincronizam dados entre diretórios diferentes.

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

Metas iniciais de violação

Ninguém cria intencionalmente uma infraestrutura de TI que exponha a organização ao comprometimento. Quando uma floresta do Active Directory é construída pela primeira vez, ela geralmente é imaculada 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 gerenciamento que o Ative Directory oferece são reconhecidos, mais e mais conteúdo é adicionado ao diretório, mais pessoas integram seus computadores ou aplicativos ao AD DS e os domínios são atualizados para oferecer suporte à nova funcionalidade oferecida pelas versões mais atuais do sistema operacional Windows. O que também acontece com o tempo, no entanto, é que, mesmo quando uma nova infraestrutura está sendo adicionada, outras partes da infraestrutura podem não ser mantidas tão bem quanto eram inicialmente, sistemas e aplicativos estão funcionando corretamente e, portanto, não estão recebendo atenção, e as organizações começam a esquecer que não eliminaram sua infraestrutura legada. Com base no que vemos na avaliação de infraestruturas comprometidas, quanto mais antigo, maior e mais complexo for o ambiente, maior é a probabilidade de existirem inúmeros casos de vulnerabilidades comumente exploradas.

Independentemente da motivação do atacante, 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, muitas vezes aproveitam vulnerabilidades que poderiam ter sido corrigidas, mas não foram. O Relatório de Investigações de Violação de Dados (DBIR) de 2012, que é um estudo anual produzido pela Equipe Verizon RISK 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 foram evitáveis por meio de controles simples ou intermediários". Estas conclusões podem ser uma consequência direta das vulnerabilidades comummente exploradas que se seguem.

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

Lei Número Oito: Um scanner de malware desatualizado é apenas marginalmente melhor do que nenhum scanner. - Dez Leis Imutáveis de Segurança (Versão 2.0)

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

As populações de servidores, no entanto, 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 envolveram servidores, o que representa um aumento de 18% em relação ao ano anterior, e 69% dos ataques incorporaram malware. Em populações de servidores, não é incomum descobrir que as instalações de antivírus e antimalware estão inconsistentemente configuradas, desatualizadas, mal configuradas ou até mesmo desativadas. Em alguns casos, o software antivírus e antimalware é desativado pela equipe administrativa, mas em outros casos, os invasores desativam o software depois de comprometer um servidor por meio de outras vulnerabilidades. Quando o software antivírus e antimalware é desativado, os invasores instalam malware no servidor e se concentram em propagar o comprometimento em toda a população do servidor.

É importante não só garantir que os seus sistemas estão protegidos com proteção antimalware atual e abrangente, mas também monitorizar os sistemas para desativar ou remover software antivírus e antimalware e reiniciar automaticamente a proteção quando esta é desativada manualmente. Embora nenhum software antivírus e antimalware possa garantir a prevenção e deteção de todas as infeções, uma implementação antivírus e antimalware corretamente configurada e implantada pode reduzir a probabilidade de infeção.

Correção 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. - 10 Leis Imutáveis de 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 (também conhecidas como atualizações "fora de banda") quando a vulnerabilidade é determinada como representando um risco urgente para os sistemas dos clientes. Quer uma pequena empresa configure os seus computadores Windows para utilizar o Windows Update para gerir patches de sistemas e aplicações ou uma grande organização utilize software de gestão como o Microsoft Endpoint Configuration Manager para implementar patches de acordo com planos hierárquicos detalhados, muitos clientes corrigem as suas infraestruturas Windows de forma relativamente atempada.

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 patches da organização contém lacunas. Os sistemas Windows nesses ambientes são corrigidos de forma inconsistente. Os sistemas operacionais que não são Windows são corrigidos esporadicamente, se é que existem. Os aplicativos comerciais prontos para uso (COTS) contêm vulnerabilidades para as quais existem patches, mas não foram aplicados. Os dispositivos de rede são frequentemente configurados com credenciais padrão de fábrica e sem atualizações de firmware anos após a instalação. Aplicativos e sistemas operacionais que não são mais suportados por seus fornecedores geralmente são mantidos em execução, apesar do fato de que eles não podem mais ser corrigidos contra vulnerabilidades. Cada um desses sistemas sem patches representa outro ponto de entrada potencial para os invasores.

A consumerização da TI introduziu desafios adicionais na medida em que os dispositivos de propriedade dos funcionários estão sendo usados para acessar dados de propriedade da empresa, e a organização pode ter pouco ou nenhum controle sobre a aplicação de patches 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 focado no funcionário 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.

Software de Gestão de Patches e Vulnerabilidades

Se um sistema de gerenciamento de patches eficaz estiver em vigor para os sistemas Windows e aplicativos da Microsoft, parte da superfície de ataque criada por vulnerabilidades não corrigidas foi resolvida. No entanto, a menos que os sistemas não Windows, aplicativos que não sejam da Microsoft, infraestrutura de rede e dispositivos de funcionários também sejam mantidos up-toatualizados sobre patches e outras correções, a infraestrutura permanece vulnerável. Em alguns casos, o fornecedor de um aplicativo pode oferecer recursos de atualização automática; em outros, pode haver a necessidade de conceber uma abordagem para recuperar e aplicar regularmente patches e outras correções.

Aplicações e Sistemas Operativos Desatualizados

"Você não pode esperar que um sistema operacional de seis anos o proteja contra um ataque de seis meses." - Profissional de Segurança da Informação com 10 anos de experiência em segurança de instalações corporativas

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

Os aplicativos que foram escritos para usar protocolos de autenticação herdados por fornecedores que não oferecem mais suporte ao aplicativo geralmente não podem ser reformulados para oferecer suporte a mecanismos de autenticação mais fortes. No entanto, o domínio do Ative Directory de uma organização ainda pode ser configurado para armazenar hashes do LAN Manager ou senhas criptografadas reversivelmente para oferecer suporte a esses aplicativos. Os aplicativos escritos antes da introdução de sistemas operacionais mais recentes podem não funcionar bem ou não funcionar de todo nos sistemas operacionais atuais, exigindo que as organizações mantenham sistemas cada vez mais antigos e, em alguns casos, hardware e software completamente sem suporte.

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

Para eliminar sistemas e aplicativos herdados, você deve primeiro se concentrar em identificá-los e catalogá-los e, em seguida, em determinar se o aplicativo ou host deve ser atualizado ou substituído. Embora possa ser difícil encontrar substitutos para aplicativos altamente especializados para os quais não há suporte nem um caminho de atualização, você pode aproveitar um conceito chamado "destruição criativa" para substituir o aplicativo herdado por um novo aplicativo que forneça a funcionalidade necessária. O Planning for Compromise é descrito com mais profundidade em "Planning for Compromise" mais adiante neste documento.

Misconfiguration

Lei Número Quatro: Não adianta muito instalar correções de segurança em um computador que nunca foi protegido para começar. - 10 Leis Imutáveis de Administração de Segurança

Mesmo em ambientes onde os sistemas geralmente são mantidos atualizados e corrigidos, geralmente identificamos lacunas ou configurações incorretas no sistema operacional, aplicativos em execução em computadores e Ative Directory. Algumas configurações incorretas expõem apenas o computador local ao comprometimento, mas depois que um computador é "possuído", os invasores geralmente se concentram em propagar ainda mais o comprometimento em outros sistemas e, eventualmente, no Ative Directory. Seguem-se algumas das áreas comuns em que identificamos configurações que introduzem risco.

No Ative Directory

As contas no Ative Directory mais comumente visadas por invasores são aquelas que são membros dos grupos mais privilegiados, como membros dos grupos Administradores de Domínio (DA), Administradores Corporativos (EA) ou Administradores internos (BA) no Ative Directory. O número de membros desses grupos deve ser reduzido ao menor número possível de contas, de modo que a superfície de ataque desses grupos seja limitada. É até possível eliminar a pertença "permanente" a esses grupos privilegiados; ou seja, você pode implementar configurações que permitem preencher temporariamente esses grupos somente quando seus privilégios de domínio e floresta são necessários. Quando contas altamente privilegiadas são usadas, elas devem ser usadas apenas 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 Reduzindo a superfície de ataque do Ative Directory.

Quando avaliamos a associação dos grupos mais privilegiados no Ative Directory, geralmente encontramos associação excessiva em todos os três grupos mais privilegiados. Em alguns casos, as organizações têm dezenas, até centenas de contas em grupos DA. Em outros casos, as organizações colocam contas diretamente em grupos internos de Administradores, pensando que o grupo é "menos privilegiado" do que o grupo de DAs. Não é. Muitas vezes encontramos um punhado de membros permanentes do grupo EA no domínio raiz da floresta, apesar do fato de que os privilégios do EA são raramente 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 Reduzindo a superfície de ataque do Ative Directory, quer uma conta seja um membro permanente de um desses grupos ou de todos eles, a conta pode ser usada para comprometer e até mesmo destruir o ambiente AD DS e os sistemas e contas gerenciados por ele. As recomendações para a configuração segura e o uso de contas privilegiadas no Ative Directory são fornecidas em Reduzindo a superfície de ataque do Ative Directory.

Em controladores de domínio

Quando avaliamos controladores de domínio, muitas vezes os encontramos configurados e gerenciados de forma não diferente dos servidores membros. Os controladores de domínio às vezes executam os mesmos aplicativos e utilitários instalados nos servidores membros, não porque eles são necessários nos controladores de domínio, mas porque os aplicativos fazem parte de uma compilação padrão. Esses aplicativos podem fornecer funcionalidade mínima nos controladores de domínio, mas aumentam significativamente sua superfície de ataque, exigindo definições de configuração que abram portas, criem contas de serviço altamente privilegiadas ou concedam acesso ao sistema por usuários que não devem se conectar a um controlador de domínio para qualquer outra finalidade que não seja autenticação e aplicativo de Diretiva de Grupo. Em algumas violações, os invasores usaram ferramentas que já estavam instaladas nos 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 Ative 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 freeware foram baixados de sites da Internet e instalados nos controladores de domínio. A Configuração de Segurança Reforçada 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 acede à Internet e transfere conteúdo para qualquer computador, esse computador é colocado em grave risco. Quando o computador é um controlador de domínio, toda a instalação do AD DS é colocada em risco.

Protegendo controladores de domínio

Os controladores de domínio devem ser tratados como componentes de infraestrutura crítica, protegidos de forma mais rigorosa e configurados de forma 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 o controlador de domínio funcionar ou que 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 Diretiva de Grupo). Recomendações detalhadas para a instalação, configuração e gerenciamento seguros de controladores de domínio são fornecidas em Protegendo controladores de domínio contra ataques.

Dentro do Sistema Operacional

Lei Número Dois: Se um bandido pode alterar o sistema operacional do seu computador, ele não é mais o seu computador. - Dez Leis Imutáveis de Segurança (Versão 2.0)

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

Desativando recursos de segurança

Às vezes, as organizações desativam o Firewall do Windows com Segurança Avançada (WFAS) por acreditarem que o WFAS é difícil de configurar ou requer configuração de trabalho intensivo. No entanto, a partir do Windows Server 2008, 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 recurso funcione, e o Firewall do Windows é configurado automaticamente para dar suporte à função ou recurso. Ao desativar o WFAS (e não usar outro firewall baseado em host em seu lugar), as organizações aumentam a superfície de ataque de todo o ambiente Windows. Os firewalls de perímetro fornecem alguma proteção contra ataques que visam diretamente um ambiente a partir da Internet, mas não fornecem proteção contra ataques que exploram outros vetores de ataque, como ataques de download drive-by ou ataques originados de outros sistemas comprometidos na intranet.

Às vezes, as configurações do UAC (Controle de Conta de Usuário) são desabilitadas nos servidores porque a equipe administrativa considera os prompts intrusivos. Embora o artigo 2526083 do Suporte da Microsoft descreva cenários nos quais o UAC pode ser desabilitado no Windows Server, a menos que você esteja executando uma instalação Server Core (onde 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 a computadores que executam o Windows Server 2012, Windows Server 2008 R2 ou Windows Server 2008, sem alterar as linhas de base para refletir as alterações no sistema operacional. Em vez de transportar 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.

Concessão de privilégios excessivos

Em quase todos os ambientes que avaliamos, privilégios excessivos são concedidos a contas locais e baseadas em domínio em sistemas Windows. Os usuários recebem direitos de Administrador local em suas estações de trabalho, os servidores membros executam serviços configurados com direitos além do necessário para funcionar e os grupos de Administradores locais em toda a população de servidores contêm dezenas ou até 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 credenciais para propagar o comprometimento para outros sistemas.

Embora o pass-the-hash (PTH) e outros ataques de roubo de credenciais sejam onipresentes atualmente, é porque há ferramentas disponíveis gratuitamente que tornam simples e fácil extrair as credenciais de outras contas privilegiadas quando um invasor obtém acesso no nível de administrador ou sistema a um computador. Mesmo sem ferramentas que permitam a coleta de credenciais de sessões de logon, um invasor com acesso privilegiado a um computador pode instalar com a mesma facilidade registradores 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 desativar o software antimalware, instalar rootkits, modificar arquivos protegidos ou instalar malware no computador que automatiza ataques ou transforma um servidor em um host de download drive-by.

As táticas usadas para estender uma intrusão além de um único computador variam, mas a chave para propagar a violação é a obtençã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 valiosas do computador.

Padronizando credenciais de administrador local

Há muito tempo há debate entre os especialistas em segurança sobre se há valor em renomear contas de administrador locais em computadores Windows. O que é realmente importante sobre as contas de Administrador locais é 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 no nível de Administrador ou SISTEMA tenha sido obtido. O invasor não precisa comprometer inicialmente a conta de administrador; eles só precisam comprometer a conta de um usuário que seja membro do grupo Administradores local ou de uma conta de serviço configurada para ser executada como LocalSystem ou com privilégios de Administrador. O invasor pode então 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) que as credenciais da conta que estão sendo apresentadas, a tentativa de logon será bem-sucedida e o invasor obterá acesso privilegiado ao computador de destino. Nas versões atuais do Windows, a conta de Administrador interna é desabilitada por padrão, mas em sistemas operacionais herdados, a conta é habilitada por padrão.

Note

Algumas organizações configuraram intencionalmente contas de Administrador locais, ativando-as na crença de que isso oferece um "failsafe" (mecanismo de segurança) no caso de todas as outras contas privilegiadas serem bloqueadas no sistema. No entanto, mesmo que a conta de Administrador local esteja desativada 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 pode ser inicializado no modo de segurança e a conta de Administrador local interna pode ser reativada, conforme descrito no artigo 814777 do Suporte da Microsoft. Além disso, se o sistema ainda aplicar GPOs com êxito, um GPO poderá ser modificado para reativar (temporariamente) a conta de Administrador ou os Grupos Restritos poderão ser configurados para adicionar uma conta baseada em domínio ao grupo Administradores local. Os reparos podem ser realizados e a conta de administrador pode ser desativada novamente. Para evitar efetivamente um comprometimento lateral que usa credenciais de conta de Administrador local internas, nomes de usuário e senhas exclusivos devem ser configurados para contas de Administrador locais. Para implantar senhas exclusivas para contas de Administrador locais por meio de um GPO, consulte Solução para gerenciamento de senha de conta de Administrador interna via GPO no technet.  

Permitir a instalação de aplicações não autorizadas

Lei Número Um: Se um bandido pode persuadi-lo a executar seu programa em seu computador, não é mais apenas o seu computador. - Dez Leis Imutáveis de 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 a instalação de software que não faz parte da funcionalidade designada de um servidor, os servidores são expostos à instalação inadvertida ou maliciosa de software que aumenta a superfície de ataque do servidor, introduz vulnerabilidades de aplicativos ou causa instabilidade do sistema.

Applications

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

Falta de práticas seguras de desenvolvimento de aplicativos

A infraestrutura existe para suportar cargas de trabalho de negócios. Quando essas cargas de trabalho são implementadas em aplicativos personalizados, é fundamental garantir que os aplicativos sejam desenvolvidos usando práticas recomendadas seguras. A análise de causa básica de incidentes em toda a empresa geralmente revela que um comprometimento inicial é efetuado por meio de aplicativos personalizados, especialmente aqueles que estão voltados para a Internet. A maioria desses comprometimentos é realizada por meio do comprometimento de ataques bem conhecidos, como ataques de injeção de SQL (SQLi) e cross-site scripting (XSS).

A injeção de SQL é uma vulnerabilidade de aplicativo que permite que a entrada definida pelo usuário modifique uma instrução SQL que é passada 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 caracteres 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. Tomemos, 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 examinar a tabela de usuários e retornar qualquer registro de ID de usuário onde o nome de usuário e a senha correspondam aos fornecidos pelo usuário (presumivelmente por meio de um formulário de login de algum tipo). Naturalmente, a intenção do desenvolvedor, neste caso, é retornar apenas um registro válido se um nome de usuário e senha corretos puderem ser fornecidos pelo usuário. Se um deles estiver incorreto, o servidor de banco de dados não conseguirá encontrar um registro correspondente e retornar um resultado vazio.

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

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 da tabela serão retornadas na consulta porque 1=1 sempre será avaliado como True, portanto, não importa se o nome de usuário e a senha corretos são conhecidos ou fornecidos. O resultado líquido 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, este será o usuário administrativo.

Além de simplesmente fazer logon, instruções SQL malformadas como esta podem ser usadas para adicionar, excluir ou alterar dados, ou até mesmo soltar (excluir) tabelas inteiras de um banco de dados. Nos casos mais extremos em que o SQLi é combinado com privilégios excessivos, os comandos do sistema operacional podem ser executados para permitir a criação de novos usuários, baixar ferramentas de ataque ou tomar quaisquer outras ações escolhidas pelos invasores.

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

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

Embora uma discussão completa sobre scripts entre sites e injeção de SQL esteja fora do escopo deste documento, o Open Web Application Security Project (OWASP) publica uma lista top 10 com discussão aprofundada das vulnerabilidades e contramedidas.

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

O Microsoft Security Development Lifecycle (SDL) é um conjunto de controles de processo estrutural que trabalham para melhorar a segurança, começando no 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 eficazes não é apenas crítica do ponto de vista da segurança, é fundamental para garantir que a segurança do aplicativo seja eficaz em termos de custos e cronograma. Avaliar um aplicativo quanto a problemas de segurança quando ele é efetivamente código completo exige que as organizações tomem decisões sobre a segurança do aplicativo somente antes ou mesmo depois que o aplicativo tiver sido implantado. Uma organização pode optar por resolver as falhas do aplicativo antes de implantá-lo na produção, incorrendo em custos e atrasos, ou o aplicativo pode ser implantado em produção com falhas de segurança conhecidas, expondo a organização a comprometimento.

Algumas organizações colocam o custo total da correção de um problema de segurança no código de produção acima de US$ 10.000 por problema, e os aplicativos desenvolvidos sem um SDL eficaz podem ter uma média de mais de dez problemas de alta gravidade por 100.000 linhas de código. Em aplicações grandes, os custos aumentam rapidamente. Por outro lado, muitas empresas estabelecem uma referência de menos de uma emissão por 100.000 linhas de código no estágio final de revisão de código do SDL e visam zero problemas em aplicativos de alto risco em produção.

A implementação do SDL melhora a segurança ao incluir requisitos de segurança no início da coleta de requisitos e do design de um aplicativo fornece modelagem de ameaças para aplicativos de alto risco; exige formação e acompanhamento eficazes dos promotores; e requer normas e práticas de código claras e consistentes. O efeito líquido de um SDL são melhorias significativas na segurança do aplicativo e, ao mesmo tempo, reduzem o custo de desenvolvimento, implantação, manutenção e desativação de um aplicativo. Embora uma discussão detalhada sobre o design e a implementação do SDL esteja além do escopo deste documento, consulte o Ciclo de Vida do Desenvolvimento de Segurança da Microsoft para obter orientações e informações detalhadas.

  • Última atualização a