Este artigo foi escrito com base em um pentest de muito sucesso realizado por especialistas do Grupo-IB há alguns anos: aconteceu uma história que poderia ser adaptada para o cinema em Bollywood. Agora, provavelmente, seguirá a reação do leitor: “Ah, outro artigo de RP, mais uma vez estes estão sendo retratados, como são bons, não se esqueça de comprar um pentest”. Bem, por um lado, é. No entanto, existem vários outros motivos pelos quais este artigo apareceu. Eu queria mostrar o que exatamente os pentesters fazem, quão interessante e não trivial esse trabalho pode ser, que circunstâncias engraçadas podem surgir em projetos e, o mais importante, mostrar material ao vivo com exemplos reais.
Para restaurar o equilíbrio da modéstia no mundo, depois de um tempo escreveremos sobre um pentest que não deu certo. Mostraremos como processos bem desenhados em uma empresa podem proteger contra toda uma gama de ataques, mesmo os bem preparados, simplesmente porque esses processos existem e realmente funcionam.
Para o cliente neste artigo, tudo também foi geralmente excelente, pelo menos melhor que 95% do mercado na Federação Russa, de acordo com nossos sentimentos, mas houve uma série de pequenas nuances que formaram uma longa cadeia de eventos, que primeiro levou a um longo relatório sobre o trabalho e depois a este artigo.
Então, vamos estocar pipoca e bem-vindos à história de detetive. Palavra - Pavel Suprunyuk, responsável técnico do departamento “Auditoria e Consultoria” do Grupo-IB.
Parte 1. Médico Pochkin
2018 Existe um cliente - uma empresa de TI de alta tecnologia, que atende muitos clientes. Quer obter uma resposta à pergunta: é possível, sem qualquer conhecimento e acesso inicial, trabalhando através da Internet, obter direitos de administrador de domínio do Active Directory? Não estou interessado em nenhuma engenharia social (), eles não pretendem interferir propositalmente no trabalho, mas podem acidentalmente - recarregar um servidor que esteja funcionando de maneira estranha, por exemplo. Um objetivo adicional é identificar o maior número possível de outros vetores de ataque contra o perímetro externo. A empresa realiza regularmente esses testes e agora chegou o prazo para um novo teste. As condições são quase típicas, adequadas, compreensíveis. Vamos começar.
Existe um nome do cliente - seja “Empresa”, com o site principal . Claro que o cliente tem um nome diferente, mas neste artigo tudo será impessoal.
Eu faço reconhecimento de rede - descubro quais endereços e domínios estão registrados no cliente, desenho um diagrama de rede, como os serviços são distribuídos para esses endereços. Recebi o resultado: mais de 4000 endereços IP ativos. Olho para os domínios destas redes: felizmente, a grande maioria são redes destinadas aos clientes do cliente e não estamos formalmente interessados nelas. O cliente pensa o mesmo.
Resta uma rede com 256 endereços, para a qual neste momento já existe um entendimento da distribuição de domínios e subdomínios por endereços IP, há informações sobre as portas escaneadas, o que significa que você pode procurar nos serviços por outras interessantes. Paralelamente, todos os tipos de scanners são lançados nos endereços IP disponíveis e separadamente nos sites.
Existem muitos serviços. Geralmente isso é alegria para o pentester e a expectativa de uma vitória rápida, pois quanto mais serviços houver, maior será o campo de ataque e mais fácil será encontrar um artefato. Uma rápida olhada nos sites mostrou que a maioria deles são interfaces web de produtos conhecidos de grandes empresas globais, que aparentemente dizem que não são bem-vindos. Eles pedem nome de usuário e senha, agitam o campo para inserir o segundo fator, pedem um certificado de cliente TLS ou enviam para o Microsoft ADFS. Alguns são simplesmente inacessíveis pela Internet. Para alguns, obviamente você precisa ter um cliente especial pago por três salários ou saber o URL exato para entrar. Vamos pular mais uma semana de desânimo gradual no processo de tentar “romper” versões de software em busca de vulnerabilidades conhecidas, procurando por conteúdo oculto em caminhos da web e contas vazadas de serviços de terceiros como o LinkedIn, tentando adivinhar senhas usando-os, também como escavar vulnerabilidades em sites de autoria própria – aliás, de acordo com as estatísticas, este é o vetor de ataque externo mais promissor hoje. Notarei imediatamente a arma do filme que disparou posteriormente.
Assim, encontramos dois sites que se destacaram entre centenas de serviços. Esses sites tinham uma coisa em comum: se você não realizar um reconhecimento meticuloso da rede por domínio, mas procurar de frente por portas abertas ou direcionar um scanner de vulnerabilidade usando um intervalo de IP conhecido, esses sites escaparão da verificação e simplesmente não serão visível sem saber o nome DNS. Talvez eles tenham passado despercebidos antes, pelo menos, e nossas ferramentas automáticas não encontraram nenhum problema com eles, mesmo que tenham sido enviados diretamente para o recurso.
A propósito, sobre o que os scanners lançados anteriormente encontraram em geral. Deixe-me lembrá-lo: para algumas pessoas, “pentest” equivale a “scan automatizado”. Mas os scanners deste projeto não disseram nada. Bem, o máximo foi mostrado pelas vulnerabilidades Médias (3 de 5 em termos de gravidade): em alguns serviços, um certificado TLS ruim ou algoritmos de criptografia desatualizados e, na maioria dos sites, Clickjacking. Mas isso não o levará ao seu objetivo. Talvez os scanners fossem mais úteis aqui, mas deixe-me lembrá-lo: o próprio cliente pode comprar esses programas e testar-se com eles e, a julgar pelos resultados desanimadores, ele já os verificou.
Voltemos aos sites “anômalos”. O primeiro é algo como um Wiki local em um endereço fora do padrão, mas neste artigo seja wiki.company[.]ru. Ela também pediu imediatamente login e senha, mas através do NTLM no navegador. Para o usuário, isso parece uma janela ascética pedindo para inserir um nome de usuário e uma senha. E isso é uma má prática.
Uma pequena nota. NTLM em sites de perímetro é ruim por vários motivos. A primeira razão é que o nome de domínio do Active Directory é revelado. Em nosso exemplo, também era company.ru, assim como o nome DNS “externo”. Sabendo disso, você pode preparar cuidadosamente algo malicioso para que seja executado apenas na máquina de domínio da organização, e não em alguma sandbox. Em segundo lugar, a autenticação passa diretamente pelo controlador de domínio via NTLM (surpresa, certo?), com todos os recursos das políticas de rede “internas”, incluindo o bloqueio de contas para que não excedam o número de tentativas de entrada de senha. Se um invasor descobrir os logins, ele tentará senhas para eles. Se você estiver configurado para impedir que contas insiram senhas incorretas, isso funcionará e a conta será bloqueada. Terceiro, é impossível adicionar um segundo fator a tal autenticação. Se algum dos leitores ainda souber como, por favor me avise, é muito interessante. Quarto, vulnerabilidade a ataques pass-the-hash. O ADFS foi inventado, entre outras coisas, para proteger contra tudo isso.
Há uma propriedade ruim dos produtos Microsoft: mesmo que você não tenha publicado especificamente esse NTLM, ele será instalado por padrão no OWA e no Lync, pelo menos.
A propósito, o autor deste artigo uma vez bloqueou acidentalmente cerca de 1000 contas de funcionários de um grande banco em apenas uma hora usando o mesmo método e depois pareceu um tanto pálido. Os serviços de TI do banco também foram pálidos, mas tudo terminou bem e de forma adequada, fomos até elogiados por sermos os primeiros a encontrar este problema e provocar uma solução rápida e decisiva.
O segundo site tinha o endereço “obviamente algum tipo de sobrenome.empresa.ru”. Encontrei no Google, algo assim na página 10. O design era do início de meados dos anos XNUMX, e uma pessoa respeitável estava olhando para ele na página principal, mais ou menos assim:
Aqui tirei um still de “Heart of a Dog”, mas acredite, era vagamente parecido, até o desenho das cores era em tons parecidos. Deixe o site ser chamado preobrazhensky.company.ru.
Era um site pessoal... de um urologista. Fiquei me perguntando o que o site de um urologista estava fazendo no subdomínio de uma empresa de alta tecnologia. Uma rápida pesquisa no Google mostrou que esse médico era cofundador de uma das pessoas jurídicas de nosso cliente e até contribuiu com cerca de 1000 rublos para o capital autorizado. O site provavelmente foi criado há muitos anos e os recursos do servidor do cliente foram usados como hospedagem. O site há muito perdeu relevância, mas por algum motivo ficou funcionando por muito tempo.
Em termos de vulnerabilidades, o próprio site era seguro. Olhando para o futuro, direi que era um conjunto de informações estáticas - páginas HTML simples com ilustrações inseridas em forma de rins e bexigas. É inútil “quebrar” um site assim.
Mas o servidor web abaixo era mais interessante. A julgar pelo cabeçalho do servidor HTTP, ele tinha IIS 6.0, o que significa que usava o Windows 2003 como sistema operacional. O scanner já havia identificado que esse site específico do urologista, diferentemente de outros hosts virtuais no mesmo servidor web, respondia ao comando PROPFIND, o que significa que estava executando o WebDAV. A propósito, o scanner retornou essas informações com a marca Info (na linguagem dos relatórios do scanner, esse é o perigo mais baixo) - essas coisas geralmente são simplesmente ignoradas. Em combinação, isto deu um efeito interessante, que só foi revelado após outra escavação no Google: uma rara vulnerabilidade de buffer overflow associada ao conjunto Shadow Brokers, nomeadamente CVE-2017-7269, que já tinha uma exploração pronta. Em outras palavras, haverá problemas se você tiver o Windows 2003 e o WebDAV estiver sendo executado no IIS. Embora executar o Windows 2003 em produção em 2018 seja um problema em si.
A exploração acabou no Metasploit e foi imediatamente testada com uma carga que enviou uma solicitação de DNS para um serviço controlado – o Burp Collaborator é tradicionalmente usado para capturar solicitações de DNS. Para minha surpresa, funcionou da primeira vez: foi recebido um nocaute de DNS. Em seguida, houve uma tentativa de criar um backconnect via porta 80 (ou seja, uma conexão de rede do servidor para o invasor, com acesso ao cmd.exe no host da vítima), mas aconteceu um fiasco. A conexão não foi estabelecida e após a terceira tentativa de utilização do site, junto com todas as fotos interessantes, desapareceram para sempre.
Geralmente isso é seguido por uma carta no estilo “cliente, acorde, deixamos cair tudo”. Mas fomos informados de que o site não tem nada a ver com processos de negócios e funciona ali sem motivo algum, como todo o servidor, e que podemos utilizar esse recurso como quisermos.
Cerca de um dia depois, o site de repente começou a funcionar sozinho. Tendo construído um banco de dados WebDAV no IIS 6.0, descobri que a configuração padrão é reiniciar os processos de trabalho do IIS a cada 30 horas. Ou seja, quando o controle saiu do shellcode, o processo de trabalho do IIS foi encerrado, reiniciado algumas vezes e depois colocado em repouso por 30 horas.
Como o backconnect ao tcp falhou na primeira vez, atribuí esse problema a uma porta fechada. Ou seja, ele presumiu a presença de algum tipo de firewall que não permitia a passagem de conexões de saída para fora. Comecei a executar shellcodes que pesquisavam em muitas portas tcp e udp, mas não houve efeito. Cargas de conexão reversa via http(s) do Metasploit não funcionaram - meterpreter/reverse_http(s). De repente, uma conexão com a mesma porta 80 foi estabelecida, mas caiu imediatamente. Atribuí isso à ação do ainda imaginário IPS, que não gostou do tráfego meterpreter. Considerando o fato de que uma conexão tcp pura com a porta 80 não foi realizada, mas uma conexão http sim, concluí que um proxy http estava de alguma forma configurado no sistema.
Eu até tentei meterpreter via DNS (obrigado pelos seus esforços, salvou muitos projetos), relembrando o primeiro sucesso, mas nem funcionou no estande - o shellcode era muito volumoso para esta vulnerabilidade.
Na realidade, era assim: 3-4 tentativas de ataque em 5 minutos e depois espera por 30 horas. E assim por diante durante três semanas seguidas. Até coloquei um lembrete para não perder tempo. Além disso, houve uma diferença no comportamento dos ambientes de teste e produção: para esta vulnerabilidade houve dois exploits semelhantes, um do Metasploit, o segundo da Internet, convertido da versão Shadow Brokers. Assim, apenas o Metasploit foi testado em combate, e apenas o segundo foi testado em bancada, o que tornou a depuração ainda mais difícil e avassaladora.
No final, um shellcode que baixou um arquivo exe de um determinado servidor via http e o lançou no sistema de destino provou ser eficaz. O shellcode era pequeno o suficiente para caber, mas pelo menos funcionou. Como o servidor não gostou nada do tráfego TCP e o http(s) foi inspecionado quanto à presença do meterpreter, decidi que a maneira mais rápida era baixar um arquivo exe que continha o DNS-meterpreter por meio deste shellcode.
Aqui novamente surgiu um problema: ao baixar um arquivo exe e, como mostraram as tentativas, não importa qual, o download foi interrompido. Novamente, algum dispositivo de segurança entre meu servidor e o urologista não gostou do tráfego http com um exe dentro. A solução “rápida” parecia ser alterar o shellcode para ofuscar o tráfego http em tempo real, para que dados binários abstratos fossem transferidos em vez de exe. Finalmente, o ataque foi bem sucedido, o controle foi recebido através do canal DNS fino:
Imediatamente ficou claro que tenho os direitos mais básicos de fluxo de trabalho do IIS, que não me permitem fazer nada. Esta é a aparência no console do Metasploit:
Todas as metodologias de pentest sugerem fortemente que você precisa aumentar os direitos ao obter acesso. Normalmente não faço isso localmente, pois o primeiro acesso é visto simplesmente como um ponto de entrada na rede, e comprometer outra máquina na mesma rede geralmente é mais fácil e rápido do que escalar privilégios em um host existente. Mas este não é o caso aqui, pois o canal DNS é muito estreito e não permitirá a liberação do tráfego.
Supondo que este servidor Windows 2003 não tenha sido reparado para a famosa vulnerabilidade MS17-010, eu tunelo o tráfego para a porta 445/TCP através do túnel DNS meterpreter no localhost (sim, isso também é possível) e tento executar o exe baixado anteriormente através a vulnerabilidade. O ataque funciona, recebo uma segunda conexão, mas com direitos SYSTEM.
É interessante que eles ainda tentaram proteger o servidor do MS17-010 - ele tinha serviços de rede vulneráveis desabilitados na interface externa. Isso protege contra ataques pela rede, mas o ataque interno no localhost funcionou, já que você não pode simplesmente desligar rapidamente o SMB no localhost.
A seguir, novos detalhes interessantes são revelados:
- Tendo direitos SYSTEM, você pode facilmente estabelecer uma backconnection via TCP. Obviamente, desabilitar o TCP direto é estritamente um problema para o usuário limitado do IIS. Spoiler: o tráfego do usuário IIS foi de alguma forma agrupado no proxy ISA local em ambas as direções. Como exatamente funciona, não reproduzi.
- Estou em uma certa “DMZ” (e este não é um domínio do Active Directory, mas um GRUPO DE TRABALHO) - parece lógico. Mas em vez do endereço IP privado (“cinza”) esperado, tenho um endereço IP completamente “branco”, exatamente igual ao que ataquei anteriormente. Isto significa que a empresa é tão antiga no mundo do endereçamento IPv4 que pode manter uma zona DMZ para 128 endereços “brancos” sem NAT de acordo com o esquema, conforme descrito nos manuais da Cisco de 2005.
Como o servidor é antigo, é garantido que o Mimikatz funcione diretamente da memória:
Recebo a senha do administrador local, túnel o tráfego RDP por TCP e faço login em uma área de trabalho aconchegante. Como eu poderia fazer o que quisesse com o servidor, removi o antivírus e descobri que o servidor estava acessível pela Internet apenas pelas portas TCP 80 e 443, e a 443 não estava ocupada. Configurei um servidor OpenVPN no 443, adicionei funções NAT ao meu tráfego VPN e obtive acesso direto à rede DMZ de forma ilimitada através do meu OpenVPN. Vale ressaltar que o ISA, possuindo algumas funções IPS não desabilitadas, bloqueou meu tráfego com varredura de portas, para o qual teve que ser substituído por um RRAS mais simples e compatível. Então, às vezes, os pentesters ainda precisam administrar todo tipo de coisa.
Um leitor atento perguntará: “E o segundo site - um wiki com autenticação NTLM, sobre o qual tanto foi escrito?” Mais sobre isso mais tarde.
Parte 2. Ainda não está criptografando? Então já estamos vindo até você aqui
Portanto, há acesso ao segmento da rede DMZ. Você precisa ir ao administrador do domínio. A primeira coisa que vem à mente é verificar automaticamente a segurança dos serviços dentro do segmento DMZ, especialmente porque muitos mais deles estão agora abertos para pesquisa. Uma imagem típica durante um teste de penetração: o perímetro externo é mais bem protegido do que os serviços internos, e ao obter qualquer acesso dentro de uma grande infraestrutura, é muito mais fácil obter direitos estendidos em um domínio apenas porque este domínio começa a ser acessível a ferramentas e, em segundo lugar, numa infra-estrutura com vários milhares de anfitriões, existirão sempre alguns problemas críticos.
Carrego os scanners via DMZ por meio de um túnel OpenVPN e espero. Abro o relatório - novamente nada sério, aparentemente alguém passou pelo mesmo método antes de mim. A próxima etapa é examinar como os hosts da rede DMZ se comunicam. Para fazer isso, primeiro execute o Wireshark normal e ouça as solicitações de transmissão, principalmente ARP. Pacotes ARP foram coletados o dia todo. Acontece que vários gateways são utilizados neste segmento. Isso será útil mais tarde. Ao combinar dados sobre solicitações e respostas ARP e dados de varredura de portas, encontrei os pontos de saída do tráfego de usuários de dentro da rede local, além dos serviços que eram anteriormente conhecidos, como web e correio.
Como no momento eu não tinha acesso a outros sistemas e não possuía uma única conta de serviços corporativos, optou-se por pescar pelo menos alguma conta do tráfego utilizando ARP Spoofing.
Cain&Abel foi lançado no servidor do urologista. Levando em consideração os fluxos de tráfego identificados, foram selecionados os pares mais promissores para o ataque man-in-the-middle e, em seguida, algum tráfego de rede foi recebido por lançamento de curto prazo por 5 a 10 minutos, com um cronômetro para reinicializar o servidor em caso de congelamento. Assim como na brincadeira, foram duas novidades:
- Bom: muitas credenciais foram capturadas e o ataque como um todo funcionou.
- O ruim: todas as credenciais eram dos próprios clientes do cliente. Ao prestarem serviços de suporte, os especialistas do cliente se conectaram aos serviços de clientes que nem sempre tinham a criptografia de tráfego configurada.
Como resultado, adquiri muitas credenciais que eram inúteis no contexto do projeto, mas definitivamente interessantes como demonstração do perigo do ataque. Roteadores de fronteira de grandes empresas com telnet, portas http de depuração encaminhadas para CRM interno com todos os dados, acesso direto ao RDP do Windows XP na rede local e outros obscurantismos. Aconteceu assim .
Também encontrei uma oportunidade engraçada de coletar cartas do trânsito, algo assim. Este é um exemplo de carta pronta que foi do nosso cliente para a porta SMTP do cliente dele, novamente, sem criptografia. Um certo Andrey pede ao seu homônimo que reenvie a documentação, e ela é carregada em um disco na nuvem com login, senha e link em uma carta de resposta:
Este é outro lembrete para criptografar todos os serviços. Não se sabe quem e quando irá ler e usar seus dados especificamente - o provedor, o administrador do sistema de outra empresa ou um pentester. Não digo nada sobre o fato de que muitas pessoas podem simplesmente interceptar tráfego não criptografado.
Apesar do aparente sucesso, isso não nos aproximou do objetivo. É claro que era possível ficar sentado por muito tempo pescando informações valiosas, mas não é fato que elas aparecessem ali, e o ataque em si é muito arriscado em termos de integridade da rede.
Depois de mais uma pesquisa nos serviços, uma ideia interessante me veio à mente. Existe um utilitário chamado Responder (é fácil encontrar exemplos de uso com esse nome), que, ao “envenenar” solicitações de transmissão, provoca conexões por meio de diversos protocolos, como SMB, HTTP, LDAP, etc. de diferentes maneiras, então pede a todos que se conectam para autenticar e configura para que a autenticação ocorra via NTLM e de forma transparente para a vítima. Na maioria das vezes, um invasor coleta handshakes NetNTLMv2 dessa maneira e, a partir deles, usando um dicionário, recupera rapidamente as senhas de domínio do usuário. Aqui eu queria algo parecido, mas os usuários ficavam “atrás de uma parede”, ou melhor, estavam separados por um firewall, e acessavam a WEB através do cluster proxy Blue Coat.
Lembre-se, especifiquei que o nome de domínio do Active Directory coincidia com o domínio “externo”, ou seja, era company.ru? Assim, o Windows, mais precisamente o Internet Explorer (e Edge e Chrome), permitem que o usuário se autentique de forma transparente em HTTP via NTLM caso considere que o site está localizado em alguma “Zona da Intranet”. Um dos sinais de uma “Intranet” é o acesso a um endereço IP “cinza” ou a um nome DNS curto, ou seja, sem pontos. Como eles tinham um servidor com IP “branco” e nome DNS preobrazhensky.company.ru, e as máquinas de domínio geralmente recebem o sufixo de domínio do Active Directory via DHCP para entrada simplificada do nome, eles só precisavam escrever o URL na barra de endereço , para que encontrem o caminho certo para o servidor do urologista comprometido, sem esquecer que agora se chama “Intranet”. Isto é, ao mesmo tempo, dando-me o aperto de mão NTLM do usuário sem o seu conhecimento. Resta apenas forçar os navegadores clientes a pensar na necessidade urgente de entrar em contato com este servidor.
O maravilhoso utilitário Intercepter-NG veio em socorro (obrigado ). Ele permitia alterar o tráfego rapidamente e funcionava muito bem no Windows 2003. Ele ainda tinha uma funcionalidade separada para modificar apenas arquivos JavaScript no fluxo de tráfego. Uma espécie de Cross-Site Scripting massivo foi planejado.
Os proxies da Blue Coat, por meio dos quais os usuários acessavam a WEB global, armazenavam periodicamente conteúdo estático em cache. Ao interceptar o tráfego, ficou claro que eles estavam trabalhando XNUMX horas por dia, solicitando incessantemente estática usada com frequência para acelerar a exibição de conteúdo durante os horários de pico. Além disso, o BlueCoat possuía um User-Agent específico, que o distinguia claramente de um usuário real.
Foi elaborado Javascript que, utilizando Intercepter-NG, foi implementado durante uma hora à noite para cada resposta com arquivos JS para Blue Coat. O script fez o seguinte:
- Determinado o navegador atual pelo User-Agent. Se fosse Internet Explorer, Edge ou Chrome, continuava funcionando.
- Esperei até que o DOM da página fosse formado.
- Inseriu uma imagem invisível no DOM com um atributo src do formulário :8080/NNNNNNN.png, onde NNN são números arbitrários para que o BlueCoat não os armazene em cache.
- Defina uma variável de flag global para indicar que a injeção foi concluída e não há mais necessidade de inserir imagens.
O navegador tentou carregar esta imagem; na porta 8080 do servidor comprometido, um túnel TCP estava esperando por ela para o meu laptop, onde o mesmo Responder estava rodando, exigindo que o navegador fizesse login via NTLM.
A julgar pelos registros do Responder, as pessoas vieram trabalhar pela manhã, ligaram suas estações de trabalho e, em massa e despercebidas, começaram a visitar o servidor do urologista, sem esquecer de “drenar” os apertos de mão NTLM. Choveram apertos de mão o dia todo e claramente acumulou material para um ataque obviamente bem-sucedido de recuperação de senhas. Esta é a aparência dos logs do Respondente:
Visitas secretas em massa ao servidor do urologista por usuários
Você provavelmente já percebeu que toda essa história é construída sobre o princípio “estava tudo bem, mas depois houve uma chatice, depois houve uma superação e então tudo deu certo”. Então, houve uma chatice aqui. Dos cinquenta apertos de mão únicos, nenhum foi revelado. E isso leva em conta o fato de que mesmo em um laptop com processador morto, esses handshakes NTLMv2 são processados a uma velocidade de várias centenas de milhões de tentativas por segundo.
Tive que me munir de técnicas de mutação de senha, uma placa de vídeo, um dicionário mais grosso e esperar. Depois de muito tempo, várias contas com senhas no formato “Q11111111....1111111q” foram reveladas, o que sugere que todos os usuários já foram forçados a criar uma senha muito longa com letras maiúsculas e minúsculas diferentes, o que também deveria ser complexo. Mas você não pode enganar um usuário experiente, e foi assim que ele tornou mais fácil lembrar. No total, cerca de 5 contas foram comprometidas e apenas uma delas tinha direitos valiosos sobre os serviços.
Parte 3. Roskomnadzor contra-ataca
Assim, as primeiras contas de domínio foram recebidas. Se você ainda não adormeceu depois de uma longa leitura, provavelmente se lembrará que mencionei um serviço que não exigia um segundo fator de autenticação: é um wiki com autenticação NTLM. Claro, a primeira coisa a fazer foi entrar lá. Explorar a base de conhecimento interna trouxe resultados rapidamente:
- A empresa possui uma rede WiFi com autenticação através de contas de domínio com acesso à rede local. Com o conjunto atual de dados, esse já é um vetor de ataque funcional, mas você precisa ir até o escritório com os pés e estar localizado em algum lugar do território do escritório do cliente.
- Encontrei uma instrução segundo a qual havia um serviço que permitia... registrar de forma independente um dispositivo de autenticação de “segundo fator” se o usuário estiver dentro de uma rede local e se lembrar com segurança de seu login e senha de domínio. Neste caso, “dentro” e “fora” foram determinados pela acessibilidade do porto deste serviço ao utilizador. A porta não era acessível pela Internet, mas era bastante acessível através da DMZ.
Claro, um “segundo fator” foi imediatamente adicionado à conta comprometida na forma de um aplicativo no meu telefone. Havia um programa que podia enviar em voz alta uma solicitação push para o telefone com botões “aprovar”/“reprovar” para a ação ou mostrar silenciosamente o código OTP na tela para posterior entrada independente. Além disso, as instruções supunham que o primeiro método era o único correto, mas não funcionou, ao contrário do método OTP.
Com o “segundo fator” quebrado, consegui acessar o correio do Outlook Web Access e o acesso remoto no Citrix Netscaler Gateway. Houve uma surpresa no e-mail do Outlook:
Nesta foto rara você pode ver como Roskomnadzor ajuda os pentesters
Foram os primeiros meses após o famoso bloqueio dos “fãs” do Telegram, quando redes inteiras com milhares de endereços desapareceram inexoravelmente do acesso. Ficou claro por que o push não funcionou imediatamente e por que minha “vítima” não soou o alarme porque começou a usar a conta dela durante o horário de funcionamento.
Quem conhece o Citrix Netscaler imagina que ele costuma ser implementado de forma que apenas uma interface de imagem possa ser transmitida ao usuário, tentando não lhe dar ferramentas para lançar aplicativos de terceiros e transferir dados, limitando de todas as formas possíveis as ações através de shells de controle padrão. Minha “vítima”, devido à sua ocupação, só obteve 1C:
Depois de percorrer um pouco a interface 1C, descobri que existem módulos de processamento externos lá. Eles podem ser carregados a partir da interface e serão executados no cliente ou servidor, dependendo dos direitos e configurações.
Pedi aos meus amigos programadores 1C que criassem um processamento que aceitasse uma string e a executasse. Na linguagem 1C, iniciar um processo é mais ou menos assim (retirado da Internet). Você concorda que a sintaxe da linguagem 1C surpreende os falantes de russo com sua espontaneidade?
O processamento foi executado perfeitamente; acabou sendo o que os pentesters chamam de “shell” - o Internet Explorer foi lançado através dele.
Anteriormente, foi encontrado no correio o endereço de um sistema que permite solicitar passes para o território. Encomendei um passe caso precisasse usar um vetor de ataque WiFi.
Fala-se na Internet que ainda havia um delicioso catering gratuito no escritório do cliente, mas ainda assim preferi desenvolver o ataque remotamente, é mais tranquilo.
O AppLocker foi ativado no servidor de aplicativos que executa o Citrix, mas foi ignorado. O mesmo Meterpreter foi carregado e iniciado via DNS, pois as versões http(s) não queriam se conectar e eu não sabia o endereço do proxy interno naquele momento. A propósito, a partir deste momento, o pentest externo se transformou completamente em um interno.
Parte 4. Direitos de administrador para usuários são ruins, ok?
A primeira tarefa de um pentester ao obter o controle de uma sessão de usuário de domínio é coletar todas as informações sobre os direitos no domínio. Existe um utilitário BloodHound que permite baixar automaticamente informações sobre usuários, computadores, grupos de segurança por meio do protocolo LDAP de um controlador de domínio e por meio de SMB - informações sobre qual usuário efetuou login recentemente, onde e quem é o administrador local.
Uma técnica típica para obter direitos de administrador de domínio parece simplificada como um ciclo de ações monótonas:
- Vamos para computadores de domínio onde existem direitos de administrador local, com base em contas de domínio já capturadas.
- Lançamos o Mimikatz e obtemos senhas em cache, tickets Kerberos e hashes NTLM de contas de domínio que efetuaram login recentemente neste sistema. Ou removemos a imagem da memória do processo lsass.exe e fazemos o mesmo do nosso lado. Isso funciona bem com Windows anterior a 2012R2/Windows 8.1 com configurações padrão.
- Determinamos onde as contas comprometidas têm direitos de administrador local. Repetimos o primeiro ponto. Em algum momento, ganhamos direitos de administrador para todo o domínio.
“Fim do Ciclo;”, como escreveriam aqui os programadores 1C.
Assim, nosso usuário acabou sendo um administrador local em apenas um host com Windows 7, cujo nome incluía a palavra “VDI”, ou “Virtual Desktop Infrastructure”, máquinas virtuais pessoais. Provavelmente, o projetista do serviço VDI quis dizer que, como o VDI é o sistema operacional pessoal do usuário, mesmo que o usuário altere o ambiente de software como desejar, o host ainda poderá ser “recarregado”. Também achei que no geral a ideia era boa, fui até esse host VDI pessoal e fiz um ninho lá:
- Instalei lá um cliente OpenVPN, que fez um túnel pela Internet até o meu servidor. O cliente teve que ser forçado a passar pelo mesmo Blue Coat com autenticação de domínio, mas o OpenVPN fez isso, como dizem, “pronto para usar”.
- OpenSSH instalado no VDI. Bem, realmente, o que é o Windows 7 sem SSH?
Foi assim que pareceu ao vivo. Deixe-me lembrá-lo de que tudo isso deve ser feito através do Citrix e 1C:
Uma técnica para promover o acesso a computadores vizinhos é verificar se há correspondência nas senhas do administrador local. Aqui a sorte o esperava imediatamente: o hash NTLM do administrador local padrão (que de repente foi chamado de Administrador) foi abordado por meio de um ataque de passagem de hash para hosts VDI vizinhos, dos quais havia várias centenas. Claro, o ataque os atingiu imediatamente.
Foi aqui que os administradores de VDI deram dois tiros no pé:
- A primeira vez foi quando as máquinas VDI não foram colocadas no LAPS, mantendo essencialmente a mesma senha de administrador local da imagem que foi implantada massivamente no VDI.
- O administrador padrão é a única conta local vulnerável a ataques de passagem de hash. Mesmo com a mesma senha, seria possível evitar o comprometimento em massa criando uma segunda conta de administrador local com uma senha aleatória complexa e bloqueando a senha padrão.
Por que o serviço SSH nesse Windows? Muito simples: agora o servidor OpenSSH não só fornece um shell de comando interativo conveniente sem interferir no trabalho do usuário, mas também um proxy Socks5 em VDI. Através dessas meias, conectei-me via SMB e coletei contas em cache de todas essas centenas de máquinas VDI e, em seguida, procurei o caminho para o administrador do domínio usando-as nos gráficos do BloodHound. Com centenas de hosts à minha disposição, descobri esse caminho rapidamente. Os direitos de administrador de domínio foram obtidos.
Aqui está uma foto da Internet mostrando uma pesquisa semelhante. As conexões mostram quem está onde o administrador está e quem está logado e onde.
A propósito, lembre-se da condição desde o início do projeto - “não usar engenharia social”. Então, proponho pensar em quanto todo esse Bollywood com efeitos especiais seria cortado se ainda fosse possível usar o phishing banal. Mas pessoalmente foi muito interessante para mim fazer tudo isso. Espero que você tenha gostado de ler isso. É claro que nem todo projeto parece tão intrigante, mas o trabalho como um todo é muito desafiador e não permite estagnar.
Provavelmente alguém terá uma dúvida: como se proteger? Até mesmo este artigo descreve muitas técnicas, muitas das quais os administradores do Windows nem conhecem. No entanto, proponho analisá-los da perspectiva de princípios banais e medidas de segurança da informação:
- não use software desatualizado (lembra do Windows 2003 no começo?)
- não mantenha sistemas desnecessários ligados (por que existia o site de um urologista?)
- verifique você mesmo a força das senhas dos usuários (caso contrário, soldados... pentesters farão isso)
- não ter as mesmas senhas para contas diferentes (comprometimento VDI)
- e outro
Claro que isso é muito difícil de implementar, mas no próximo artigo mostraremos na prática que é bem possível.
Fonte: habr.com