Uma história sobre pesquisa e desenvolvimento em 3 partes. A Parte 1 é exploratória.
Existem muitas faias - ainda mais benefícios.
Formulação do problema
Durante pentests e campanhas RedTeam, nem sempre é possível utilizar as ferramentas padrão do Cliente, como VPN, RDP, Citrix, etc. como âncora para entrar na rede interna. Em alguns lugares, uma VPN padrão funciona usando MFA e um token de hardware é usado como segundo fator, em outros é monitorado brutalmente e nosso login VPN torna-se imediatamente visível, como dizem, com tudo o que isso implica, mas em outros há simplesmente não existe tal meio.
Nesses casos, temos que fazer constantemente os chamados “túneis reversos” – conexões da rede interna a um recurso externo ou a um servidor que controlamos. Dentro deste túnel já podemos trabalhar com os recursos internos dos Clientes.
Existem diversas variedades desses túneis de retorno. O mais famoso deles é, claro, o Meterpreter. Túneis SSH com encaminhamento reverso de porta também são muito procurados pelas massas de hackers. Existem vários meios para implementar o tunelamento reverso e muitos deles são bem estudados e descritos.
É claro que, por sua vez, os desenvolvedores de soluções de segurança não ficam de lado e detectam ativamente tais ações.
Por exemplo, sessões MSF são detectadas com sucesso por IPS modernos da Cisco ou Positive Tech, e um túnel SSH reverso pode ser detectado por quase qualquer firewall normal.
Portanto, para passarmos despercebidos em uma boa campanha do RedTeam, precisamos construir um túnel reverso utilizando meios não padronizados e nos adaptarmos o mais próximo possível ao modo real de operação da rede.
Vamos tentar encontrar ou inventar algo semelhante.
Antes de inventar qualquer coisa, precisamos entender qual resultado queremos alcançar, quais funções nosso desenvolvimento deve desempenhar. Quais serão os requisitos do túnel para que possamos trabalhar no modo furtivo máximo?
É claro que para cada caso tais requisitos podem diferir muito, mas com base na experiência profissional, os principais podem ser identificados:
- funciona no sistema operacional Windows-7-10. Como a maioria das redes corporativas usa Windows;
- o cliente se conecta ao servidor via SSL para evitar escuta estúpida usando ips;
- Ao se conectar, o cliente deve suportar o trabalho através de um servidor proxy com autorização, pois Em muitas empresas, o acesso à Internet ocorre através de um proxy. Na verdade, a máquina cliente pode nem saber nada sobre isso, e o proxy é usado em modo transparente. Mas devemos fornecer tal funcionalidade;
- a parte do cliente deve ser concisa e portátil;
É claro que para trabalhar dentro da rede do Cliente, você pode instalar o OpenVPN na máquina do cliente e criar um túnel completo para o seu servidor (felizmente, os clientes openvpn podem trabalhar através de um proxy). Mas, em primeiro lugar, isso nem sempre funcionará, já que podemos não ser administradores locais lá e, em segundo lugar, fará tanto barulho que um SIEM ou HIPS decente nos “denunciará” imediatamente. Idealmente, nosso cliente deve ser um chamado comando inline, já que, por exemplo, muitos shells bash são implementados e iniciados através da linha de comando, por exemplo, ao executar comandos de uma macro do Word. - nosso túnel deve ser multithread e suportar muitas conexões simultaneamente;
- a conexão cliente-servidor deve ter algum tipo de autorização para que o túnel seja estabelecido apenas para o nosso cliente, e não para todos que chegam ao nosso servidor no endereço e porta especificados. Idealmente, uma landing page com gatos ou tópicos profissionais relacionados ao domínio original deveria ser aberta para “usuários terceiros”.
Por exemplo, se o Cliente for uma organização médica, então para um administrador de segurança da informação que decide verificar o recurso acessado por um funcionário da clínica, uma página com produtos farmacêuticos, Wikipedia com uma descrição do diagnóstico ou o blog do Dr. .deve abrir.
Análise de ferramentas existentes
Antes de reinventar a sua própria bicicleta, é preciso fazer uma análise das bicicletas existentes e perceber se realmente precisamos dela e, provavelmente, não somos os únicos que já pensamos na necessidade de uma bicicleta tão funcional.
Pesquisar na Internet (parece que pesquisamos normalmente no Google), bem como pesquisar no Github usando as palavras-chave “meias reversas” não deu muitos resultados. Basicamente, tudo se resume à construção de túneis ssh com encaminhamento reverso de porta e tudo relacionado a ele. Além dos túneis SSH, existem diversas soluções:
Uma implementação de longa data de um túnel reverso do pessoal da Kaspersky Lab. O nome deixa claro a finalidade deste script. Implementado em Python 2.7, o túnel opera em modo de texto simples (como está na moda dizer agora - olá RKN)
Outra implementação em Python, também em texto simples, mas com mais possibilidades. Está escrito em forma de módulo e possui uma API para integração da solução em seus projetos.
O primeiro link é a versão original da implementação sox reversa em Golang (não suportada pelo desenvolvedor).
O segundo link é a nossa revisão com recursos adicionais, também em Golang. Em nossa versão, implementamos SSL, funcionamos através de um proxy com autorização NTLM, autorização no cliente, uma landing page em caso de senha incorreta (ou melhor, um redirecionamento para a landing page), modo multithread (ou seja, várias pessoas pode trabalhar com o túnel ao mesmo tempo), um sistema de ping no cliente para determinar se ele está vivo ou não.
Implementação de sox reverso de nossos “amigos chineses” em Python. Lá, para os preguiçosos e “imortais”, existe um binário (exe) pronto, montado pelos chineses e pronto para uso. Aqui, só Deus chinês sabe o que mais este binário pode conter além da funcionalidade principal, então use por sua própria conta e risco.
Um projeto bastante interessante em C++ para implementar sox reverso e muito mais. Além do túnel reverso, ele pode encaminhar portas, criar um shell de comando, etc.
Medidor MSF
Aqui, como dizem, sem comentários. Todos os hackers ainda mais ou menos instruídos estão familiarizados com isso e entendem como ele pode ser facilmente detectado por ferramentas de segurança.
Todas as ferramentas descritas acima funcionam com uma tecnologia semelhante: um módulo binário executável pré-preparado é lançado em uma máquina dentro da rede, que estabelece uma conexão com um servidor externo. O servidor executa um servidor SOCKS4/5 que aceita conexões e as retransmite ao cliente.
A desvantagem de todas as ferramentas acima é que o Python ou o Golang devem ser instalados na máquina cliente (você já viu o Python instalado com frequência nas máquinas de, por exemplo, um diretor de empresa ou funcionários de escritório?), ou um software pré-montado binário (na verdade python) deve ser arrastado para esta máquina e script em uma garrafa) e executar este binário já lá. E baixar um exe e iniciá-lo também é uma assinatura de um antivírus local ou HIPS.
Em geral, a conclusão sugere-se - precisamos de uma solução PowerShell. Agora os tomates voarão até nós - dizem que o PowerShell já está todo banal, monitorado, bloqueado, etc. e assim por diante. Na verdade, não em todos os lugares. Declaramos com responsabilidade. A propósito, há muitas maneiras de contornar o bloqueio (aqui novamente há uma frase da moda sobre olá RKN 🙂), começando pela renomeação estúpida de powershell.exe -> cmdd.exe e terminando com powerdll, etc.
Vamos começar a inventar
É claro que primeiro vamos procurar no Google e… não vamos encontrar nada sobre esse assunto (se alguém encontrou, poste links nos comentários). Existe apenas Socks5 no PowerShell, mas este é um sox “direto” comum, que tem várias desvantagens (falaremos sobre elas mais tarde). Você pode, é claro, com um leve movimento da mão, transformá-lo no sentido inverso, mas será apenas um sox de thread único, o que não é exatamente o que precisamos para nós.
Então, não encontramos nada pronto, então ainda teremos que reinventar a roda. Tomaremos como base para nossa bicicleta sox reverso em Golang e implementamos um cliente para ele no PowerShell.
RSocksTun
Então, como funciona o rsockstun?
A operação do RsocksTun (doravante denominado rs) é baseada em dois componentes de software - servidor Yamux e Socks5. O servidor Socks5 é um Socks5 local regular, executado no cliente. E a multiplexação de conexões para ele (lembra do multithreading?) é fornecida usando yamux (). Este esquema permite lançar vários servidores clientes Socks5 e distribuir conexões externas para eles, encaminhando-os através de uma única conexão TCP (quase como no meterpreter) de cliente para servidor, implementando assim um modo multithread, sem o qual simplesmente não seremos capaz de trabalhar plenamente nas redes internas.
A essência de como o yamux funciona é que ele introduz uma camada de rede adicional de fluxos, implementando-a na forma de um cabeçalho de 12 bytes para cada pacote. (Aqui usamos deliberadamente a palavra “stream” em vez de thread, para não confundir o leitor com um fluxo de programa “thread” - também usaremos esse conceito neste artigo). O cabeçalho yamux contém o número do stream, sinalizadores para instalar/encerrar o stream, o número de bytes transferidos e o tamanho da janela de transferência.
Além de instalar/encerrar um stream, o yamux implementa um mecanismo de keepalive que permite monitorar o desempenho do canal de comunicação estabelecido. A operação do mecanismo de mensagem keeplive é configurada ao criar uma sessão Yamux. Na verdade, das configurações existem apenas dois parâmetros: ativar/desativar e a frequência de envio de pacotes em segundos. As mensagens Keepalive podem ser enviadas por um servidor yamux ou um cliente yamux. Ao receber uma mensagem de manutenção de atividade, o ponto remoto deve responder enviando exatamente o mesmo identificador de mensagem (na verdade, um número) que recebeu. Em geral, keepalive é o mesmo ping, apenas para o yamux.
Toda a técnica operacional do multiplexador: tipos de pacotes, configuração de conexão e sinalizadores de terminação e o mecanismo de transferência de dados são descritos em detalhes em para Yamux.
Conclusão da primeira parte
Assim, na primeira parte do artigo, conhecemos algumas ferramentas para organização de túneis reversos, analisamos suas vantagens e desvantagens, estudamos o mecanismo de funcionamento do multiplexador Yamux e descrevemos os requisitos básicos para o módulo powershell recém-criado. Na próxima parte desenvolveremos o módulo propriamente dito, praticamente do zero. Continua. Não mude :)
Fonte: habr.com