Escalonamento de privilégios do Windows

Prática de gerenciamento de segurança da informação: pentest

Aumentando os privilégios do usuário para o nível de administrador de domínio do Windows

1. Introdução

Um bom sistema de gerenciamento de segurança da informação (SGSI) exige avaliação regular de sua eficácia. Existem diferentes métodos para essas avaliações, uma das variedades denominada. "Teste de penetração" ou teste - uma simulação autorizada de um ataque de hackers a um sistema de informações para identificar vulnerabilidades em sua proteção antes que elas sejam detectadas por um invasor real. Nesse caso, quaisquer ferramentas, explorações, métodos etc. disponíveis na vida real podem ser usadas.

Este artigo descreve uma dessas práticas anti-hackers, cujo objetivo era aumentar os privilégios de um usuário de domínio comum do Microsoft Windows para o nível de administrador de domínio. O artigo foi baseado em um relatório sobre os resultados de um teste que foi colocado em prática. Por razões de confidencialidade, todas as informações que permitem identificar o local (nomes de domínio e host, contas etc.) são excluídas ou alteradas. O artigo mostra as técnicas básicas, para uma melhor compreensão, forneci os fundamentos e vulnerabilidades teóricos usados ​​para versões específicas de sistemas operacionais, bem como recomendações gerais de proteção. E embora a maioria dessas versões do Windows seja considerada obsoleta no momento da publicação, este artigo pode ser útil para administradores de sistema iniciantes entenderem melhor como proteger as credenciais do usuário no Windows.

Descrição do objeto de teste

O objeto de teste é bastante padrão - o sistema de informações de uma pequena empresa (com menos de 200 funcionários) especializada em desenvolvimento de software. A rede interna da empresa também é típica: Gigabit Ethernet de discagem, domínio do Microsoft Windows (vamos chamá-lo de CORP.LOCAL). Os hosts internos são divididos em sub-redes IP com base em sua afiliação funcional (como: um grupo de desenvolvedores, engenheiros de qualidade, departamento de recursos humanos, contabilidade, marketing, alta gerência, instalações etc.), toda a segmentação é feita no switch L3 . Há também um parque de servidores internos dedicados a uma sub-rede IP separada e contém: dois controladores de domínio do Windows Server 2008 com DNS integrado, um servidor de email interno executando o Exchange, um servidor de arquivos, um servidor de terminal e alguns outros servidores auxiliares executando o Windows e Linux. Separadamente, vale a pena observar um laboratório de teste com uma frota de máquinas executando versões diferentes do Microsoft Windows (desktop e servidor) e projetadas para testar o software desenvolvido. O acesso aos hosts do laboratório de teste está disponível para todos os funcionários. A versão principal do sistema operacional da área de trabalho é o Windows 7. Software antivírus mal configurado de diferentes fabricantes é instalado em computadores e servidores de mesa (da Symantec, Kaspersky e Trend Micro, por que um mal configurado será discutido mais adiante).

Intruder Model

Intruso - um funcionário interno que possui uma conta de usuário sem privilégios no domínio, um computador de mesa, acesso físico a computadores de teste (possivelmente possui um laptop corporativo), mas não possui privilégios de administrador local em nenhum deles. Além disso, a conta do invasor não tem a capacidade de alterar as configurações do software antivírus. A intenção do invasor é obter acesso equivalente ao acesso do administrador ao controlador de domínio e / ou servidor de arquivos.

Como vemos, tanto o modelo do intruso quanto a descrição da empresa são bastante típicos.

Implementação de ataque

Etapa 0. Coleta de informações sobre a rede interna

Então, agimos em nome do ofensor. Nesta etapa, precisamos coletar informações sobre:

• endereçamento interno e sub-rede
• nomes de host e endereços IP, antes de tudo, estamos interessados ​​em uma lista de servidores
• usando o protocolo NetBIOS.

Primeiro, usando o utilitário ipconfig, obtemos os endereços IP dos servidores DNS: 192.168.12.1 e 192.168.12.2. Porque O DNS está integrado ao Active Directory, o que nos dá motivos para acreditar que conhecemos os endereços IP dos controladores de domínio. Em seguida, usando o utilitário nslookup no modo interativo, tentamos obter uma lista de todos os hosts na zona corp.local:

> ls –d corp.local> arquivo

De fato, este comando inicia uma transferência completa da zona DNS, salvando-a em arquivo. Muitos administradores esquecem-se de definir restrições na transferência de zona para a rede interna, o que facilita a um invasor em potencial coletar informações sobre a infraestrutura da empresa, para obter mais detalhes, consulte [12].

Resultado. Sucesso. Uma transferência de zona desprotegida nos deu uma lista completa de nomes de host internos, incluindo servidores e seus endereços IP. Usando os utilitários nbtstat, telnet, bem como qualquer um dos scanners de vulnerabilidade comuns, um invasor pode coletar informações sobre a plataforma, serviços em execução e versões do SO nos hosts de seu interesse.

Etapa 1. Obtendo privilégios de administrador local

Teoria Para obter a senha do administrador local, um ataque é aplicado ao valor do hash dessa senha armazenada no registro do sistema. Apesar do fato de a função hash ser matematicamente irreversível, o cálculo da senha é possível pela enumeração direta de seus valores, juntamente com um ataque de dicionário. O Windows historicamente usou dois algoritmos para calcular uma função de hash de senha: o algoritmo LM herdado e o algoritmo NT mais recente (às vezes também chamado de NTLM). A função hash LM é vulnerável devido à sua baixa complexidade computacional, o que torna possível enumerar seus valores mesmo em um computador fraco. A presença de hashes de senha LM e NT no registro do sistema garante que o invasor possa decifrá-lo em um período de tempo aceitável. O valor do hash LM nas configurações padrão é armazenado no registro do Windows XP / 2003, o que torna esses sistemas especialmente atraentes para o hacker. A função hash NT é computacionalmente mais complexa, no entanto, enumerar seus valores é bastante simplificada pelo fato de existirem tabelas de valores pré-calculados disponíveis (as chamadas tabelas Rainbow) para elas - elas reduzem o cálculo do valor hash à pesquisa do hash desejado entre valores pré-calculados.

Objeto de ataque. Hash de senha no banco de dados SAM (registro). No nosso caso, são todas as máquinas às quais temos acesso físico. Primeiro, este é o nosso desktop de trabalho e, em segundo lugar, os hosts para a realização de testes.

Implementação. Com máquinas com acesso físico, realizamos a seguinte operação: inicialize a partir de uma mídia externa (usando um CD do ambiente de pré-instalação do Windows ou Linux Live CD), monte a partição do sistema NTFS e copie os ramos do registro HKLM \ SYSTEM e HKLM \ SAM (arquivos% WINDIR % \ System32 \ Config \ System e% WINDIR% \ System32 \ Config \ Sam, respectivamente). Prestamos atenção especial às máquinas que executam o Windows XP \ Windows 2003, nas quais é provável que o hash LM seja encontrado. Para despejar senhas dos arquivos de registro copiados, usamos as ferramentas [1], [2] (todos os links no final do artigo). Resultado:



A última linha contém o hash NT necessário do administrador local. Nos hosts do laboratório de teste (vamos chamar esses hosts de LAB1 e LAB2), encontramos um hash LM diferente de zero:





Então, temos hashes NT e LM. Mas como recuperar a senha deles? Para fazer isso, usaremos as mesmas ferramentas [1], [2], bem como os serviços de reversão de hash online [8] - [11]:



Nota: a senha real consistia no nome da empresa com um pequeno modificador e quebrou rapidamente sob um ataque de dicionário).

Resultado. Sucesso. As senhas (sejam "Pa $$ word1" e "Pa $$ word2") da conta do administrador local de nossa área de trabalho e dois computadores de teste foram recebidos. Mas eles ajudarão a obter direitos de administrador de domínio? Sobre isso mais.

Etapa 2. Obtendo credenciais de administrador de domínio

Teoria Na maioria dos casos, é suficiente obter o valor do hash NT da senha para o administrador do domínio. Isso ocorre porque, quando um usuário é verificado usando o protocolo NTLM, o sistema autenticado apresenta apenas o hash NT para o autenticador e a verificação de senha não ocorre. O hash NT pode ser obtido no chamado Armazenamento LSA, consultando os chamados Sessões de logon do administrador (a sessão de logon é uma área de dados especial criada pelo processo Winlogon em que o nome de usuário, o domínio de login e o valor do hash da senha do NT são armazenados, coletivamente, isso é chamado de segredo LSA). Esse hash NT é usado pelo processo NTLMSSP para autenticação NTLM. A sessão de logon é salva o tempo todo enquanto a conta está conectada ao sistema. Você também pode interceptar um hash do NT de uma sessão de autenticação de administrador do NTLM. Além disso, é possível obter uma senha de administrador no cache DCC (Credenciais em cache do domínio). DCC é um cache local que preenche quando um usuário faz logon com êxito em um domínio. O objetivo do cache do DCC é poder autenticar o usuário quando o controlador de domínio não estiver disponível.

Objetos de ataque:

• Hashes DCC (filial do registro HKLM \ Security).
• Sessão de logon do administrador de domínio (segredo LSA).
• Interceptação de sessões NTLM (não consideradas devido à maior complexidade prática).

Prática. Muitos administradores do Windows usam uma conta de administrador de domínio para executar vários tipos de operações nos computadores dos usuários. Ao mesmo tempo, seus dados caem no cache do DCC. Portanto, primeiro tente obter a senha do cache do DCC. Nós vamos para nossa estação de trabalho, salvamos o ramo de registro HKLM \ Security e importamos para [1]. Porque temos uma senha de administrador local, não precisamos mais inicializar a máquina a partir de mídia externa para salvar o registro:



O cache contém os dados da senha de três contas. A última conta (*** usuário) não nos interessa, a segunda conta não possui os privilégios necessários, mas o usuário shadmin se parece com o administrador que você está procurando. Infelizmente, o algoritmo MS-CACHE2 possui grande complexidade computacional e um ataque direto de força bruta é ineficiente. A função MS-CACHEv2 contém um "segredo computacional" - salt (o nome da conta é usado como "salt"), que a protege contra ataques nas tabelas Rainbow. No entanto, no futuro, tabelas de valores de hash podem aparecer para contas padrão - "Administrador", "Administrador" etc. Por uma questão de interesse, enviamos o “hash de cache” encontrado para o serviço em nuvem [8] - [11] (sobre os resultados e a eficácia de tais serviços no final do artigo). Enquanto a nuvem está pensando, estamos tentando encontrar outros DCCs. Analisamos a lista de hosts obtidos na etapa 0, verificamos quais servidores podemos acessar no administrador local usando as senhas obtidas na etapa 1. Como no controlador de domínio, o administrador local é bloqueado e o servidor de email geralmente é mais protegido, você precisa experimentar servidores secundários. No nosso caso, um servidor com o nome discreto Upd foi encontrado na lista de servidores. O login com a senha “Pa $$ word2” encontrada na etapa 1 foi bem-sucedida. Concluímos que no host Upd:

1. Nenhum software antivírus instalado.
2. Ele executa o Apache, que é o servidor de gerenciamento de antivírus corporativo (isso significa que também há uma senha para a conta usada para instalar o software antivírus remotamente e, teoricamente, você pode tirá-lo de lá).
3. O host não audita as tentativas de logon com falha.
4. Versão do sistema operacional - Windows 2008 R2.

Após despejar o registro HKLM \ Security, obtemos o hash DCC da conta CORP.LOCAL \ Administrator (e várias outras):



Teoricamente, você pode tentar encontrar a senha do administrador através de um serviço em nuvem. No entanto, como mencionei acima, um ataque de força bruta ao MS-CACHEv2 é inútil (embora, talvez, em alguns anos a situação mude). Deixe o DCC em paz e passe a procurar sessões de logon. Verifique qual usuário fez logon no host Upd:



Vemos que duas sessões inativas ficam penduradas na máquina Upd - o administrador e o usuário Shadmin, que já conhecemos, o que significa que podemos obter hashes NT de suas senhas roubando o segredo da LSA. Essa é a chave para determinar o sucesso de todo o ataque. Para roubar um hash, use a exploração Lslsass [3]. Para executá-lo, você precisa de direitos de administrador local (ou melhor, direitos para processos de depuração), que já temos. Nós obtemos a lista de segredos do LSA (no formato "domínio \ conta: LM hash: NT hash :::"):

lslsass v1.0 - Copyright (C) 2010 Bjorn Brolin, Truesec (www.truesec.com) Found Lsass pid: 520 Lsass process open Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:<i>8833c58febc977799520e7536bb2011e</i>::: Found possible primary token Found possible primary token Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Found real token CORP.LOCAL\UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \Administrator::00000000000000000000000000000000: <b> c690e441dc78bc5da8b389e78daa6392 </b>::: Found possible primary token Found real token CORP.LOCAL \shadmin::00000000000000000000000000000000: <b> 5794cba8b464364eacf366063ff70e78 </b> ::: 

As linhas destacadas em negrito contêm os hashes de senha necessários. Observe também o hash em itálico na sexta linha. Já o vimos em algum lugar, certo?

Resultado. Sucesso. Temos o hash de senha do NT da conta de administrador do domínio em nossas mãos. Mas qual é o uso de um hash se a restauração da senha original em um tempo aceitável não for possível? Sobre isso na próxima etapa.

Etapa 3. Engane a sessão de autenticação NTLM

Teoria O Windows nunca usa uma senha pura para autenticação, o sistema autenticado sempre apresenta um hash. Isso dá origem à ideia: substituindo o nome de usuário, o domínio de login e o hash do NT na sessão de Logon do usuário conectado pelos valores apropriados de administrador de domínio, podemos autenticar usando o protocolo NTLM antes do sistema remoto como administrador de domínio. Este ataque [7] é possível apenas com autenticação usando o protocolo NTLM. Apesar do amplo uso do protocolo Kerberos, o NTLM é a única maneira possível de autenticar um cliente ao acessar um compartilhamento de rede, não pelo nome simbólico, mas pelo endereço IP [13].

Objeto de ataque. Sessão de logon do administrador local.

Prática. Existem várias explorações disponíveis que permitem implementar um ataque nas plataformas Windows Server 2008 x86 e x64. A principal exploração é o Editor de credenciais do Windows [4]. Para realizar o ataque, vamos ao host do LAB2 usando as credenciais "Administrador" \ "Pa $$ word2". Usando [4], substituímos o nome da conta, o domínio de login e os dados de hash do NT na sessão de Logon pelos valores correspondentes do Shadmin que obtivemos na etapa anterior:



O nome da conta do administrador do domínio e seu hash NT são passados ​​para o comando wce como um argumento na linha de comando. Resultado - o hash foi alterado com sucesso. Observo que a participação do usuário no grupo e o token de acesso não são alterados durante o ataque:



Ainda somos o administrador local, o nome do host em verde na captura de tela acima está manchado de verde - LAB2. No entanto, durante a autenticação NTLM, o sistema remoto será apresentado com o nome de domínio CORP.LOCAL, nome de usuário Shadmin e hash de senha Shadmin. Aqui está um despejo de um único pacote de rede que contém a sessão de blob de segurança NTLM:



O nome do domínio (CORP.LOCAL) e o nome do host (LAB2) estão acinzentados em verde), uma conta é apresentada - Shadmin. Agora tentamos conectar-se à partição raiz do volume do sistema no controlador de domínio com o comando net use usando o endereço IP do controlador de domínio:



Com sucesso. Para verificar o acesso, criei um arquivo de texto na raiz (localize-o na captura de tela). Depois de criar um arquivo em lote no disco do controlador de domínio com a sequência de comandos que precisamos, usando [5], podemos executar a operação necessária no controlador de domínio (por exemplo, adicionar o usuário ao grupo de administradores de domínio). A operação será realizada com os direitos da conta Shadmin. Para ilustrar, crie um arquivo em lotes simples em um host remoto que adicione um usuário local:

usuário líquido Pa TstUsr $$ word / add

Execute-o remotamente a partir do host LAB2:



Ele será executado no sistema remoto 192.168.13.125 com os privilégios do usuário da nossa sessão atual - shadmin (ou seja, administrador de domínio). Verificamos:



A segunda saída do comando net user mostra o novo usuário. Apesar da impossibilidade de iniciar aplicativos que requerem interação interativa do usuário dessa maneira (por exemplo, snap-ins do MMC), uma ampla gama de ações pode ser executada usando scripts.

Resultado. Sucesso. Obteve acesso ao sistema de arquivos e ao shell do controlador de domínio.

Sumário

Resumidamente, a cadeia de ataques ficou assim: Reunindo informações sobre a estrutura da rede -> Obtendo uma senha de administrador local -> Usando esta senha para efetuar login em um dos servidores secundários -> Roubo de credenciais de administrador de domínio "deixadas sem vigilância" -> Modificando sua sessão de Logon e escalação de privilégios.

O sucesso do ataque foi facilitado por:

1. Proteção fraca da zona DNS da transferência para hosts não confiáveis.
2. Política de senha fraca. A maioria dos computadores do domínio usava a mesma senha para a conta de administrador local, vulnerável a um ataque de dicionário.
3. A ausência ou configuração fraca do software antivírus em hosts críticos.
4. Proteção de hashes de senha fraca - duas sessões de Logon de administrador inativas no host Upd, hashes de LM no banco de dados SAM.
5. Política de auditoria ruim.

Com base nisso, podem ser derivadas recomendações gerais de proteção:

0. Esconda completamente a estrutura interna da rede dos possíveis invasores. Portanto, os usuários não devem conseguir obter o conteúdo completo do arquivo de zona DNS. Usuários não confiáveis ​​(por exemplo, estagiários, funcionários que não concluíram o período de avaliação etc.), faz sentido transferir para uma sub-rede separada usando NAT para falsificar endereços (incluindo, por exemplo, modificar respostas de DNS).

1. A política correta para atribuir senhas ao administrador local. A senha do administrador local deve ser diferente nos hosts com diferentes graus de proteção contra acesso não autorizado. Comprometer a senha do administrador local em qualquer um dos hosts do domínio deve minimizar a possibilidade de um invasor usar essa senha.

2. O armazenamento do hash LM no SAM deve ser proibido pelas políticas de segurança.

3. Não use o nome da empresa ou seu domínio como parte da senha do administrador) Isso tornará difícil para um invasor atacar o dicionário. Mas, mesmo usando uma senha complexa, não se esqueça e verifique regularmente seu hash quanto à durabilidade usando serviços online.

4. Não é recomendável executar operações de rotina nos computadores do domínio na conta de administrador do domínio. Isso protegerá a conta de interceptar os dados da sessão de logon e de obter o hash da senha no cache do DCC.

5. Crie uma regra para não deixar a sessão de Logon do administrador do domínio sem supervisão. Prática recomendada: trabalho finalizado - efetue logout.

6. Os utilitários de falsificação de LSA são bastante pequenos. Faz sentido acompanhar sua evolução e verificar sua detecção bem-sucedida por software antivírus corporativo.

7. Um usuário, mesmo com direitos de administrador local, não poderá alterar as configurações de um antivírus corporativo. Desativar o serviço antivírus nas estações de trabalho do domínio deve resultar em uma notificação ao administrador do domínio (nesse sentido, o Symantec Endpoint Protection funcionou bem durante o teste).

Apêndice 1. Comportamento antivírus

Os computadores da empresa usavam três tipos de antivírus: KAV, atual no momento do teste do Symantec Endpoint Protection, e um produto desatualizado da Trend Micro. Na maioria dos casos, as ferramentas usadas durante o ataque foram identificadas como a Hack Tool / Rootkit / Trojan. O KAV os excluiu sem aviso e o SEP (mesmo desligado) emitiu um aviso e o moveu para a quarentena, impedindo o início. No entanto, ter direitos de administrador local permite desativar o KAV, e a proteção do SEP foi ignorada definindo manualmente um caminho de exceção para verificação, novamente usando a conta de administrador local. O antivírus da Trend Micro instalado em alguns hosts não reagiu de forma alguma ao lançamento de explorações.

Adenda 2. Eficiência no uso de serviços de verificação de hash online

Existem muitos serviços online disponíveis para testar a força dos hashes de senha. Eles permitem que você trabalhe com os hashes mais comuns - LM, NTLM, MD4, MD5, WPA, com hashes usando sal, etc. Para verificar o hash, a enumeração direta é usada usando o poder de processamento das GPUs modernas, enumeração de dicionário, ataques híbridos etc. Uma vez aberto, o hash pode reabastecer o banco de dados e ser usado no futuro. O serviço pode ser gratuito para verificar uma senha curta (menos de 8 caracteres) ou cobrar uma pequena taxa. Durante o teste, usei quatro desses serviços, os links são fornecidos no final do artigo. Enviei vários hashes encontrados na etapa 2 e após 15 meses recebi uma notificação do serviço On-line Hash Crack [9] sobre a restauração bem-sucedida de um deles)

Referências

Ferramentas usadas

[1] Cain & Abel - uma ferramenta de recuperação de senha para os sistemas operacionais da Microsoft. Ele permite a recuperação fácil de vários tipos de senhas, detectando a rede, decifrando senhas criptografadas usando ataques Dictionary, Brute-Force e Cryptanalysis, gravando conversas VoIP, decodificando senhas codificadas, recuperando chaves de rede sem fio, revelando caixas de senhas, revelando caixas de senhas, descobrindo senhas em cache e analisando o roteamento protocolos.
[2] Rachadura de 0pht.
[3] Exploração de Lslsass. Despeja hashes de senha de sessão de logon ativo do processo lsass.
[4] Pós-exploração do Windows Credentials Editor . Ferramenta para alterar credenciais de logon.
[5] PsExec da PS Tools

Descrições detalhadas da vulnerabilidade

[6] Série de artigos "Obtendo efetivamente um hash de senha no Windows" em www.securitylab.ru
[7] Pass-the-Hash, uma descrição de um ataque a um sistema remoto, fornecendo um hash comprometido.

Serviços de hackers em Hash na nuvem
[8] Question-defense.com (parece estar fora de ordem no momento da publicação ()
[9] www.onlinehashcrack.com
[10] www.cloudcracker.com
[11] Assassino de hash on-line

Materiais adicionais

[12] Segurança e ajuste de DNS no Windows Server
[13] O Kerberos não é usado quando você se conecta a compartilhamentos SMB usando o endereço IP.