secforce/tunnaTunna é um conjunto de ferramentas que encapsula e tunela qualquer comunicação TCP sobre HTTP. Pode ser usado para contornar restrições de rede em ambientes totalmente protegidos por firewalls.
Tunna é um conjunto de ferramentas que encapsula e tunela qualquer comunicação TCP sobre HTTP. Pode ser usado para contornar restrições de rede em ambientes totalmente bloqueados por firewall.
v1.1 Versão Alpha
_____
|_ _| _ _ __ _ __ __ _
| || | | | '_ \| '_ \ / _` |
| || |_| | | | | | | | (_| |
|_| \__,_|_| |_|_| |_|\__,_|
Tunna 0.1, para tunelamento de conexões TCP sobre HTTP por Nikos Vassakis
http://www.secforce.co.uk / nikos.vassakis <at> secforce.com
################################################################################################################
TLDR: Tunela conexões TCP sobre HTTP
Em um ambiente totalmente bloqueado por firewall (conexões de entrada e saída restritas - exceto a porta do servidor web)
A webshell pode ser usada para conectar a qualquer serviço no host remoto. Isso seria uma conexão local em uma porta local no host remoto e deveria ser permitida pelo firewall.
A webshell lerá os dados da porta do serviço, os encapsulará sobre HTTP e os enviará como uma resposta HTTP ao proxy local.
O proxy local irá desencapsular e escrever os dados em sua porta local, onde o programa cliente estará conectado.
Quando o proxy local recebe dados na porta local, ele os enviará para a webshell como um HTTP Post.
A webshell lerá os dados do HTTP Post e os colocará na porta do serviço
e repete --^
Apenas a porta do servidor web precisa estar aberta (normalmente 80/443) Toda a comunicação (Externamente) é feita através do protocolo HTTP
python proxy.py -u <remoteurl> -l <localport> [opções]
--help, -h mostra esta mensagem de ajuda e sai
--url=URL, -u URL URL da webshell remota
--lport=LOCAL_PORT, -l LOCAL_PORT
porta de escuta local
--verbose, -v Modo verboso (exibe o tamanho dos pacotes)
--buffer=BUFFERSIZE, -b BUFFERSIZE*
tamanho da requisição HTTP (algumas webshells têm limitações
no tamanho)
Opções ignoradas se o proxy SOCKS for usado
--no-socks, -n Não usar Proxy SOCKS
--rport=REMOTE_PORT, -r REMOTE_PORT
porta remota do serviço para a webshell se conectar
--addr=REMOTE_IP, -a REMOTE_IP
endereço para a webshell remota se conectar (padrão =
127.0.0.1)
Tunelar a conexão através de um Proxy Local
--up-proxy=UPPROXY, -x UPPROXY
proxy upstream (http://proxyserver.com:3128)
--auth, -A Proxy upstream requer autenticação
--ping-interval=PING_DELAY, -q PING_DELAY
intervalo do thread de ping do webshprx (padrão = 0.5)
--start-ping, -s Iniciar o thread de ping primeiro - alguns serviços enviam
dados primeiro (ex. SSH)
--cookie, -C Cookies de requisição
--authentication, -t Autenticação básica
exemplo de uso:
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v
# Isso iniciará um Servidor Proxy SOCKS Local na porta 8000
# Esta conexão será encapsulada sobre HTTP e desencapsulada no servidor remoto
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v
# Isso iniciará um Servidor Proxy SOCKS Local na porta 8000
# Ele se conectará através de um Proxy Local (https://192.168.1.100:3128) que requer autenticação
# à webshell remota Tunna
python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v --no-socks
# Isso iniciará uma conexão entre a webshell e o serviço RDP (3389) do host remoto
# O cliente RDP pode se conectar na porta localhost 4444
# Esta conexão será encapsulada sobre HTTP
A capacidade de enviar uma webshell no servidor remoto
Este é um código POC e pode causar DoS no servidor.
Todos os esforços para limpeza após execução ou em caso de erro foram feitos (sem garantias)
Com base em testes locais:
* O buffer JSP precisa ser limitado (opção buffer):
4096 funcionou no Linux Apache Tomcat
1024 funcionou no XAMPP Apache Tomcat (lento)
* Mais do que isso causou problemas com bytes faltando no socket remoto
ex: ruby proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v
* Sockets não habilitados por padrão:
php windows (IIS + PHP)
XAMPP Windows
php linux (servidor web embutido PHP / apache + PHP)
Se você tiver o erro Uncaught Error: Call to undefined function socket_create()
veja https://stackoverflow.com/questions/6137823/fatal-error-call-to-undefined-function-socket-create
* Retornos de carro nas webshells (fora do código):
são enviados nas respostas / são escritos no socket local --> corrompem os pacotes
* Webshell PHP para windows: o loop de função DoS no socket remoto:
função sleep adicionada -> funciona mas é um pouco lento
* Webshell PHP precisa que os caracteres de nova linha sejam removidos ao final do arquivo (após "?>")
pois estes serão enviados em cada resposta e confundirão o Tunna
Webshells:
conn.jsp Testado no Apache Tomcat (windows + linux)
conn.aspx Testado no IIS 6+8 (windows server 2003/2012)
conn.php Testado no LAMP + XAMPP + IIS (windows + linux)
Servidor Web:
webserver.py Testado com Python 2.6.5
Proxies:
proxy.py Testado com Python 2.6.5
Os dados são enviados brutos no Corpo do HTTP Post (sem variável post)
Instruções / configuração são enviadas para a webshell como parâmetros de URL (HTTP Get)
Os dados são enviados no corpo HTTP (HTTP Post)
Websockets não utilizados: Não suportados por padrão pela maioria dos servidores web
Respostas HTTP assíncronas não são realmente possíveis
O proxy consulta o servidor constantemente (padrão 0.5 segundos)
1º pacote inicia uma sessão com a webshell - recebe um cookie de volta ex: http://webserver/conn.ext?proxy
2º pacote envia opções de configuração de conexão para a webshell ex: http://webserver/conn.ext?proxy&port=4444&ip=127.0.0.1
IP e porta para a webshell se conectar
Esta é uma requisição com thread:
No php esta requisição entrará em um loop infinito
para manter a conexão do socket da webshell ativa
Em outras webshells [OK] é recebido de volta
Um socket local será criado onde o programa cliente irá se conectar Assim que o cliente estiver conectado, o thread de ping é iniciado e a execução começa. Quaisquer dados no socket (do cliente) são lidos e enviados como uma requisição HTTP Post Quaisquer dados no socket da webshell são enviados como resposta à requisição POST
Como as respostas HTTP não podem ser assíncronas. Este thread fará requisições HTTP Get na webshell com base em um intervalo (padrão 0.5 seg) Se a webshell tiver dados para enviar, ela também os enviará como resposta a esta requisição Caso contrário, envia uma resposta vazia
Em geral: Dados do proxy local são enviados com HTTP Post Há requisições Get a cada 0.5 seg para consultar a webshell por dados Se houver dados no lado da webshell, eles serão enviados como resposta a uma destas requisições
A webshell conecta-se a um socket no host local ou remoto. Quaisquer dados escritos no socket são enviados de volta ao proxy como resposta a uma requisição (POST/GET) Quaisquer dados recebidos com um post são escritos no socket.
Todas as requisições precisam ter o parâmetro de URL "proxy" definido para serem tratadas pela webshell (http://webserver/conn.ext?proxy)
Mata todas as threads e fecha o socket local Envia proxy&close para a webshell: Mata threads remotas e fecha socket
O suporte a SOCKS é um módulo addon para Tunna. Localmente é uma thread separada que gerencia as requisições de conexão e tráfego, adiciona um cabeçalho que especifica a porta e o tamanho do pacote e o encaminha para Tunna. Tunna o envia para o servidor web remoto, remove os cabeçalhos HTTP e encaminha o pacote para o proxy SOCKS remoto. O proxy SOCKS remoto inicia a conexão e mapeia a porta recebida para a porta local. Se o proxy SOCKS remoto receber dados do serviço, ele consulta a tabela de mapeamento e encontra a porta à qual precisa responder, adiciona a porta como cabeçalho para que o proxy SOCKS local saiba para onde encaminhar os dados. Qualquer tráfego da porta recebida será encaminhado para a porta local e vice-versa.
Tunna, Tunelamento TCP Sobre HTTP Nikos Vassakis Copyright (C) 2014 SECFORCE.
Esta ferramenta é apenas para fins legais.
Este programa é software livre: você pode redistribuí-lo e/ou modificá-lo sob os termos da Licença Pública Geral GNU, conforme publicada pela Free Software Foundation, seja a versão 3 da Licença, ou (a seu critério) qualquer versão posterior.
Este programa é distribuído na esperança de que seja útil, mas SEM QUALQUER GARANTIA; sem mesmo a garantia implícita de COMERCIALIZAÇÃO ou ADEQUAÇÃO A UM PROPÓSITO ESPECÍFICO. Consulte a Licença Pública Geral GNU para mais detalhes.
Você deve ter recebido uma cópia da Licença Pública Geral GNU junto com este programa. Caso contrário, veja http://www.gnu.org/licenses/.