História sobre pesquisa e desenvolvimento em 3 partes. Parte 1 — pesquisa.
Existem muitas letras — mas ainda mais benefícios.
Formulação do problema
Durante a realização de testes de penetração e campanhas de Red Team, nem sempre conseguimos utilizar as ferramentas padrão dos Clientes, como VPN, RDP, Citrix, etc., como um recurso para acessar a rede interna. Em alguns casos, a VPN padrão funciona com MFA e um token gerador de hardware é usado como segundo fator, em outros, a monitorização é tão rigorosa que nosso acesso via VPN logo se torna perceptível, como se costuma dizer — com todas as consequências, e em outros lugares não há tais recursos.
Nesses casos, é necessário constantemente criar os chamados "túneis reversos" — conexões da rede interna a um recurso externo ou a um servidor controlado por nós. Dentro desse túnel, já podemos trabalhar com os recursos internos dos Clientes.
Existem várias variedades desses túneis reversos. O mais conhecido, sem dúvida, é o Meterpreter. Os túneis SSH com redirecionamento de porta também são muito procurados nas massas de hackers. Existem muitos meios para realizar o tunelamento reverso, e muitos deles são bem estudados e documentados.
Claro que, por sua parte, os desenvolvedores de soluções de segurança não ficam parados e detectam ativamente tais ações.
Por exemplo, sessões MSF são detectadas com sucesso pelos modernos IPS da Cisco ou Positive Tech, enquanto um túnel SSH reverso pode ser detectado por praticamente qualquer firewall decente.
Portanto, para permanecer despercebido em uma boa campanha de Red Team, precisamos construir túneis reversos com meios não convencionais e nos aproximar o máximo possível do modo de operação real da rede.
Vamos tentar encontrar ou inventar algo semelhante.
Antes de inventar algo, é necessário entender qual resultado queremos alcançar e quais funções nosso desenvolvimento deve desempenhar. Quais seriam os requisitos para o túnel, para que pudéssemos operar em um modo de máxima discrição?
É claro que, para cada caso, esses requisitos podem variar bastante, mas com base na experiência é possível destacar os principais:
- funcionar em sistemas operacionais Windows 7-10, uma vez que a maioria das redes corporativas utiliza o Windows.
- O cliente conecta-se ao servidor via SSL para evitar escuta passiva por meio de IPS;
- Ao se conectar, o cliente deve suportar operações através de um servidor proxy com autenticação, pois em muitas empresas, o acesso à internet ocorre através de proxy. Na verdade, a máquina do cliente pode não saber disso, e o proxy é usado em modo transparente. No entanto, essa funcionalidade deve ser prevista;
- A parte cliente deve ser concisa e portátil;
É claro que, para operar dentro da rede do Cliente, é possível instalar o OpenVPN na máquina do cliente e criar um túnel completo até seu servidor (ainda bem que os clientes OpenVPN podem operar através de proxy). Mas, em primeiro lugar, pode não ser sempre possível, já que não podemos ser administradores locais, e em segundo lugar, isso pode gerar tanto alvoroço que um SIEM ou HIPS decente imediatamente acionará um alerta. Idealmente, nosso cliente deve ser uma chamada inline, como por exemplo, muitos shells bash são implementados, e deve ser executado a partir da linha de comando, por exemplo, ao executar comandos de um macro do Word. - Nosso túnel deve ser multithreaded e suportar múltiplas conexões simultaneamente;
- A conexão cliente-servidor deve ter algum tipo de autenticação, para que o túnel seja estabelecido apenas para nosso cliente, e não para todos que acessarem nosso servidor pelo endereço e porta especificados. O ideal seria que, para 'usuários externos', uma página de destino com gatos ou algum tema profissional relacionado ao domínio de origem fosse exibida.
Por exemplo, se o Cliente for uma organização médica, ao administrador de segurança da informação que decidir verificar o recurso acessado pelo funcionário da clínica, deve ser exibida uma página com produtos farmacêuticos, uma Wikipedia com a descrição de um diagnóstico ou um blog do Dr. Komarovsky, etc.
Análise das ferramentas existentes
Antes de inventar sua própria bicicleta, é necessário analisar as bicicletas existentes e entender se realmente precisamos delas e, muito provavelmente, não somos os únicos a pensar na necessidade de tal funcionalidade.
Pesquisar na internet (parece que estamos pesquisando normalmente) e também procurar no GitHub por palavras-chave "reverse socks" não trouxe muitos resultados. No geral, tudo se resume à construção de túneis SSH com encaminhamento reverso de portas e tudo relacionado a isso. Além dos túneis SSH, podemos destacar algumas soluções:
Uma implementação antiga de túnel reverso feita pela equipe do Kaspersky Lab. Pelo nome, é fácil entender para que esse script serve. É implementado em Python 2.7, e o túnel opera em modo cleartext (como se diz atualmente — olá, RKN)
Mais uma implementação em Python, também em cleartext, mas com mais funcionalidades. Foi escrito como um módulo e possui uma API para integrar a solução em seus projetos.
O primeiro link é a versão original da implementação de reverse socks em Go (não é mais mantida pelo desenvolvedor).
O segundo link é a nossa versão aprimorada com funcionalidades adicionais, também em Go. Na nossa versão, implementamos SSL, trabalho através de proxy com autenticação NTLM, autenticação no cliente, uma página de destino em caso de senha incorreta (na verdade — redirecionamento para a página de destino), modo multi-thread (ou seja, o túnel pode ser utilizado por várias pessoas ao mesmo tempo), sistema de pings do cliente para verificar se está ativo ou não.
Implementação de reverse socks dos nossos "amigos chineses" em Python. Também está disponível para os preguiçosos e "imortais" um binário já compilado (exe), feito pelos chineses e pronto para uso. Aqui, só um deus chinês sabe o que mais pode haver neste binário, além da funcionalidade principal, então use por sua conta e risco.
Um projeto bastante interessante em C++ para implementação de reverse socks e muito mais. Além do túnel reverso, ele pode realizar encaminhamento de portas, criação de shell de comando etc.
MSF meterpreter
Aqui, como dizem, sem comentários. Todos os hackers minimamente educados estão bem familiarizados com essa ferramenta e entendem o quão fácil é sua detecção por ferramentas de proteção.
Todas as ferramentas mencionadas funcionam com uma tecnologia semelhante: um módulo binário executável previamente preparado é iniciado em uma máquina dentro da rede, que estabelece conexão com um servidor externo. No servidor, um servidor SOCKS4/5 é iniciado, aceitando conexões e as retransmitindo para o cliente.
A desvantagem de todas as ferramentas listadas é que, ou é necessário ter Python ou Golang instalado na máquina do cliente (você já viu Python instalado em máquinas como, por exemplo, na do diretor da empresa ou de funcionários de escritório?), ou é preciso trazer um binário pré-compilado para essa máquina (basicamente, Python e o script em um só pacote) e executar esse binário lá. E baixar um exe para executá-lo é um verdadeiro sinalizador para o antivírus local ou HIPS.
Em geral, a conclusão é clara — precisamos de uma solução em PowerShell. Agora virão os tomates — dizendo que PowerShell já está ultrapassado, que é monitorado, bloqueado, etc. Na verdade, isso não ocorre em todo lugar. Afirmamos isso com responsabilidade. Aliás, há várias maneiras de contornar bloqueios (aqui vem a famosa frase sobre um cumprimento ao RKN 🙂), desde renomear powerhell.exe para cmdd.exe até powerdll, e assim por diante.
Começamos a inventar
É claro que primeiro vamos dar uma olhada no Google e… não encontraremos nada sobre este assunto (se alguém encontrou, envie os links nos comentários). Há apenas Socks5 em PowerShell, mas é um SOCKS "direto" comum, que possui uma série de desvantagens (falaremos sobre elas mais tarde). Claro, é possível transformá-lo em um SOCKS reverso com um simples movimento, mas isso será apenas um SOCKS de thread única, que não é exatamente o que precisamos.
Então, não encontramos nada pronto, por isso teremos que realmente inventar nossa própria solução. A base da nossa solução será de um SOCKS reverso em Golang, e implementaremos o cliente para isso em PowerShell.
RSocksTun
Então, como funciona o rsockstun?
Na base do funcionamento do RsocksTun (daqui em diante — rs) estão dois componentes de software — Yamux e o servidor Socks5. O servidor Socks5 é um SOCKS5 local comum, que é iniciado no cliente. E a multiplexação de conexões para ele (lembra-se da multithreadding?) é garantida através do yamux (). Este esquema permite iniciar vários servidores socks5 clientes e distribuir as conexões externas para eles, roteando-as através de uma única conexão TCP (quase como no meterpreter) do cliente para o servidor, implementando assim um modo multithread, sem o qual não conseguimos operar plenamente na rede interna.
A essência do funcionamento do yamux é que ele introduz um nível adicional de stream de rede, implementando-o como um cabeçalho de 12 bytes para cada pacote. (Aqui usamos intencionalmente a palavra “stream”, e não fluxo, para não confundir o leitor com o fluxo de programação “thread” — este conceito também será utilizado neste artigo). Dentro do cabeçalho yamux estão o número do stream, flags para iniciar/encerrar o stream, a quantidade de bytes transmitidos e o tamanho da janela de transmissão.
Além da inicialização/encerramento do stream, o yamux implementa um mecanismo de keepalives, permitindo monitorar a funcionalidade do canal de comunicação estabelecido. O funcionamento do mecanismo de keepalive-message é configurado ao criar a sessão Yamux. De fato, nas configurações existem apenas dois parâmetros: habilitar/desabilitar e a periodicidade de envio dos pacotes em segundos. Mensagens de keepalive podem ser enviadas tanto pelo servidor yamux quanto pelo cliente yamux. Ao receber uma mensagem keepalive, a parte remota deve responder com uma mensagem exatamente idêntica ao identificador da mensagem (de fato — um número) que ela recebeu. Em geral, keepalive é o mesmo que ping, apenas para yamux.
Detalhadamente, toda a técnica de funcionamento do multiplexador: tipos de pacotes, flags para iniciar e encerrar conexões, mecanismos de transmissão de dados estão descritos em em yamux.
Conclusão da primeira parte
Assim, na primeira parte do artigo, conhecemos algumas ferramentas para organizar túneis reversos, discutimos suas vantagens e desvantagens, estudamos o mecanismo de funcionamento do multiplexador Yamux e descrevemos os principais requisitos para o novo módulo do PowerShell a ser criado. Na próxima parte, estaremos focados no desenvolvimento do módulo propriamente dito, praticamente desde o início. Continua… Não mude de canal 🙂
Fonte: habr.com
