Tracking Web Application Hacking 2008 May 31, 2008
Posted by y2h4ck in Trackings.Tags: curso, Hacking, Pentesting, segurança, tracking segurança, treinamento, treinamento hacking, treinamento pentesting, web application hacking
add a comment
Convido todos os visitantes deste blog de São Paulo/Capital e região à participar de um Tracking de Segurança cujo tema é Web Application Hacking. O tracking consiste de um curso com a duração de um Sábado (das 9:00 as 19:00) com conteúdo voltado a testes de penetração em aplicações Web. Totalmente interativo e dinámico, todos os tópicos serão abordados utilizando alto conteúdo teórico, challenges e laboratórios utilizando exemplos que visam adequar todo o conteúdo a realidade.
Entre os Tópicos abordados teremos:
- Code Quality Audit
- SQL Injection (sql/mysql)
- XSS
- XSFR
- Session Hijacking
- Remote File Injections
- Local File injections
- Data Tampering
- Veb Tampering
- Ajax Hacking
- HTTP Splitting Attacks
- Cookies Stealt
Entre muitos outros.
Para o conteúdo programático completo, datas e conteúdo utilizado assim como valor, favor entrar em contato com pelo email anderson@rootsecurity.com.br
As datas serão divulgadas assim que as turmas de 15 pessoas estiverem completas. O valor é acessível e acredito que seja uma grande adição ao curriculum de profissionais de segurança.
Aguardo.
Ping Tunnel – Where everything else is blocked May 23, 2008
Posted by y2h4ck in General Hacking, Network Security, Pentesting.Tags: Ethical Hacking, Hacking, icmp tunnel, icmp tunneling, network piercing, Pentest, ping tunnels, ptunnel
add a comment
Ptunnel é uma aplicação que permite que você estabeleça tuneis de comunicação TCP para um host remoto usando ICMP echo request e reply packets, comumente conhecidos como ping quest e replie. A primeira vista pode parecer algo totalmente inútil e fora de mão, mas posso garantir que muitas vezes pode salvar sua vida. O exemplo abaixo ilustra bem a principal motivação para utilizar o ptunnel.
Exemplo: Você esta conectado através de uma rede wireless aberta. A rede dá a você um endereço IP, porém o firewall não permite que você envie pacotes TCP ou UDP para o resto da internet, assim você não consegue conectar-se ao seu servidor de e-mail. O que fazer? Você percebe que os pacotes ICMP estão liberados no firewall e você consegue pingar qualquer host na internet. Com o Ptunnel você pode utilizar esta falha na configuração do firewall e acessar o seu email, ou fazer qualquer outra coisa que necessidade de comunicação TCP.
Esta é uma descrição técnica sobre como o ptunnel funciona. Se você não está interessado em low-level networking hacking você pode pular esta sessão. Ptunnel trabalha tunelando conexões TCP através de pacotes ICMP. Neste sentido vamos falar um pouco sobre o proxy, o client e os acessos de Destino. O proxy é o “endpoint” de nossos pacotes ICMP, exemplo, o computador para onde enviamos os Pings. O client é o computador que irá tentar surfar através do tunnel e o Destination é o computador que queremos acessar através da comunicação TCP (um web site ou um servidor SSH em algum lugar).
Desta forma esclarecido, para efetuarmos a comunicação desejada precisamos ter a habilidade de enviar e receber pacotes icmp. Muitos sistemas operacionais permite que façamos isto utilizando raw-sockets. Raw Sockets é o mecanismo mais interessante para enviar pacotes ICMP, e é utilizado tanto pelo Proxy quanto pelo Client. Infelizmente raw sockets precisam que você tenha acesso de root. Caso você não tenha acesso root poderá utilizar o standard datagram sockets. Ptunnel suporta o uso do standard datagram porém não é recomendado para uso.
O cliente irá efetuar todas suas comunicações utilizando ICMP echo request (ping) packet (tipo 8), o qual o proxy irá echo reply packet (tipo 0). Em teoria, é possivel utilizar o proxy usando apenas pacotes echo request , mas estas requisições não necessariamente encaminhadas para o cliente através da rede, sendo assim não são utilizadas.
![]()
Múltiplas Conexões
O proxy pode gerenciar multiplas diferente conexões utilizando o ICMP identifier field. O cliente irá randomicamente gerar um identificar quando a sessão iniciar, e o host remoto irá utilizar este identificar para associar os pacotes com esta conexão. O mecanismo não é totalmente a prova de falhas, mas funciona razoavelmente bem, desde que duas instancias de conexão não utilizem o mesmo identificador (o ICMP não tem mecanismos para reportar este tipo de erro).
Perda de pacotes
O Ptunnel gerencia a perda de pacotes re-enviando os pacotes perdidos. Conforme ele envia os pacotes ele irá incrementar o sequence number. Tanto o client quanto o proxy mantem suas proprias sequencias, e também um número indicando o ultimo numero de sequencia que foi obtido pelo host remoto.
Veja que o proxy irá somente enviar o primeiro pacote que falta. Quando o pacote é recebido, ele pode re-enviar o próximo pacote, dependendo de quantos pacotes serão recebidos.
Usando o Ptunnel
Client: ./ptunnel -p <proxy address> -lp <listen port> -da <destination address> -dp <destination port> [-c <network device>] [-v <verbosity>] [-f <logfile>] [-u] [-x password]
Proxy: ./ptunnel [-c <network device>] [-v <verbosity>] [-f <logfile>] [-u] [-x password]
A opção –s seta o endereço do host onde o proxy está rodando. Um rápido teste para verificar se o proxy está funcionando e simplesmentes pingar o host, se receber os replies você está pronto para fazer o tunnel funcionar.
As opções –lp, -da e –dp irão se referir para a porta local que ficará escutando, o destination address e a destination port. Vamos supor que você deseja tunelar conexões SSH da máquina cliente via proxy que roda em proxy.pingtunnel.com para o computador login.domain.com, você pode utilizar esta forma:
sudo ./ptunnel -p proxy.pingtunnel.com -lp 8000 -da login.domain.com -dp 22
Uma conexão ssh para login.domain.com pode agora ser estabelicida assim:
ssh -p 8000 localhost
Caso o ssh reclame de potencial ataque de man-in-the-middle, simplesmente remova a chave de know_hosts. Este erro irá acontecer caso você ja tenha acessado o “localhost” via ssh, ou tenha utilizado o ptunnel para conexões com outros hosts.
É claro que para que tudo isto acima funcione você deve iniciar o proxy em seu computador remoto (proxy.pigtunnel.com) fazendo simplesmente:
sudo ./ptunnel
Para proteger você mesmo de que outros utilizem seu proxy, você pode proteger o acesso com uma senha usando a opção –x. A senha nunca é enviada em clear text, mas tenha em mente que ela poderá ser vista por ferramentas como top ou ps que podem mostrar a command line usada para iniciar a aplicação.
Finalizando, a opção –u irá tentar rodar o proxy no modo não privilegiado (quando não se tem root access).
Download
A versão atual do ptunnel é a 0.61, o source pode ser baixado aqui.
Good Hacking 4 All
TMin: Fuzzing Test Case Optimizer May 8, 2008
Posted by y2h4ck in General Hacking, Pentesting.Tags: case optimizer, delta, Ethical Hacking, fuzzing, General Hacking, General Security, Hacking, local fuzzing, Pentesting, remote fuzzing, tmin
add a comment
Tmin é um simples utilitário para facilitar a depuração de test cases complexos efetuados atraves de fuzzing. Ele é muito parecido com outra ferramenta deste tipo, delta, mas ele é melhor especialmente em caso de depurações de saídas desconhecidas, fora de padrão ou que o parse format seja difícil de lidar (sem a necessidade de utilizar tokens para re-serializar os dados), e por sua facil integração com UI externas para automatizar os testes.
Uma das features interessantes nele é a normalização alfabética para simplificar os test cases que não podem ser abreviados.
Exemplo de uso:
$ cat testcase.in
This is a lengthy and annoying hello world testcase.
$ cat testme.sh
#!/bin/bash
grep “el..*wo” || exit 0
exit 1
$ ../tmin -x ./testme.sh
tmin – complex testcase minimizer, version 0.03-beta (lcamtuf@google.com)
[*] Stage 0: loading ‘testcase.in’ and validating fault condition…
[*] Stage 1: recursive truncation (round 1, input = 53/53)
[*] Stage 1: recursive truncation (round 2, input = 27/53)
[*] Stage 1: recursive truncation (round 3, input = 14/53)
[*] Stage 1: recursive truncation (round 4, input = 10/53)
[*] Stage 1: recursive truncation (round 5, input = 8/53)
[*] Stage 1: recursive truncation (round 6, input = 7/53)
[*] Stage 2: block skipping (round 1, input = 7/53)
[*] Stage 2: block skipping (round 2, input = 6/53)
[*] Stage 2: block skipping (round 3, input = 5/53)
[*] Stage 3: alphabet normalization (round 1, charset = 5/5)
[*] Stage 3: alphabet normalization (round 2, charset = 5/5)
[*] Stage 4: character normalization (round 1, characters = 4/5)
[*] All done – writing output to ‘testcase.small’…
== Final statistics==
Original size : 53 bytes
Optimized size : 5 bytes (-90.57%)
Chars replaced : 1 (1.89%)
Efficiency : 9 good / 49 bad
Round counts : 1:6 2:3 3:2 4:1
$ cat testcase.small
el0wo
Detalhes
A ferramenta procura por um arquivo chamado testcase.in no mesmo diretório, e irá escrever um testcase.small minimo para aquele teste em especial. Para otimizar o test case para uma aplicação alvo, você pode simplesmente executar:
./tmin /path/to/program
Deste modo, tmin irá executar /path/to/program a cada ciclo, alimentando com o test case modificado o stdin do programa, e examinando a saída. O programa saindo com um sinal igual SIGSEGV será interpretado que o test case ainda esta funcionando. Você pode também utilizar –x command-line switch para modificar a lógica e tratar non-zero return codes como condições de erro.
non-zero return codes as fault conditions likewise, and -w file to save data to a specified location to be read by the tested application, instead of supplying it on stdin.
Para testes remotes, tmin suporta o –s command-line switch. Neste modo, o comportamento do programa especificado é ignorado e o tool espera por um sinal SIGUSR1 (clean execution) e SIGUSR2 (fault execution). Dois exemplos comuns são os abaixo:
./tmin -s -w local_file.txt /bin/true
./tmin -s nc 127.0.0.1 1234
Como mostrado acima, o nc será utilizado como um wrapper para a interação com o network service, e /bin/true será utilizado como um “decoy” enquanto o tmin escreve em arquivos locais.
Download:
Pode ser baixado aqui.
Book of Month: May May 2, 2008
Posted by y2h4ck in Pentesting, security books.Tags: Book of Month, hacking books, Hacking Exposed, Pentesting Books
add a comment

| Hacking Exposed Windows Server 2003 |
| Author: Joel Scambray, Stuart McClure |
| Publisher: McGraw-Hill Osborne Media |
| Year: 2006 |
| Pages: 628 |
| Amazon’s book description: Protect your Windows Server 2003 systems from the latest widespread and devastating attacks the tried-and-true Hacking Exposed way. You’ll learn, step-by-step, how intruders locate targets, gain super-user access, and ransack compromised networks. Fully updated chapters detail all-new Windows Server 2003 footprinting and scanning methods, IIS6 security flaws, buffer overflow exploits, Terminal Services hacks, and DoS/DDoS vulnerabilities. Real-world cases and code examples demonstrate the most current dangers and spell out countermeasures to stonewall malicious intruders every time. |
SSLDump: Dump SSL Traffic on Network May 1, 2008
Posted by y2h4ck in Ethical Hacking, General Hacking, General Security, Network Security, Pentesting.Tags: Ethical Hacking, General Hacking, General Security, Hacking, Network Security, penetration test, Pentest, ssldump
1 comment so far
SSLdump e um SSL/TLS network protocol analyzer. Ele analisa as conexões TCP na rede onde você está coletando o tráfego e tenta interpretar o tráfego SSL/TLS. Quando ele identifica o tráfego SSL/TLS, ele decodifica os pacotes gravados e depois mostra eles em forma de saída de texto no stdout.
Caso o atacante tenha uma copia dos certificados que estão sendo utilizados na comunicação, o ssldump consegue inclusive descriptografar as conexões e mostrar o data traffic da aplicação.
ssldump 0.9b3
A versão atual do ssldump é a 0.9b3
Download disponível aqui
Documentação Extra aqui.
Exemplos de utilização
|
|
Escuta o tráfego na interface le0 na porta 443 |
|
|
ssldump -i le0 port 443 |
|
|
Escuta o tráfego do server romeo na porta 443. |
|
|
ssldump -i le0 port 443 and host romeo
|
|
|
Descriptografar o tráfego do host romeo usando o certificado server.pm com senha foobar |
|
|
ssldump -Ad -k ~/server.pem -p foobar -i le0 host romeo
|
Exemplo de saída
Abaixo segue um exemplo do trace gerado pelo ssldump.
New TCP connection #3: localhost(3638) <-> localhost(4433) 3 1 0.0738 (0.0738) C>S Handshake ClientHello 3 2 0.0743 (0.0004) S>C Handshake ServerHello 3 3 0.0743 (0.0000) S>C Handshake Certificate 3 4 0.0743 (0.0000) S>C Handshake ServerHelloDone 3 5 0.0866 (0.0123) C>S Handshake ClientKeyExchange 3 6 0.0866 (0.0000) C>S ChangeCipherSpec 3 7 0.0866 (0.0000) C>S Handshake Finished 3 8 0.0909 (0.0043) S>C ChangeCipherSpec 3 9 0.0909 (0.0000) S>C Handshake Finished 3 10 1.8652 (1.7742) C>S application_data 3 11 2.7539 (0.8887) C>S application_data 3 12 5.1861 (2.4321) C>S Alert warning close_notify 3 5.1868 (0.0007) C>S TCP FIN 3 5.1893 (0.0024) S>C TCP FIN
Este exemplo usa a flag para decodificação minima. SSLdump tem flags que permitem decodificar todas as mensagens, incluindo o application protocol data.
O SSLdump consegue descriptografar o tráfego entre 2 hosts se as seguintes condições ocorrem:
|
|
1. ssldump tem as chaves. 2. Static RSA foi usado. |
|
|
Em ambos os casos, quando a encriptação inicial, ssldump irá somente estar apto à determinar o tipo de record. Considere a seguinte sessão de um trace: |
|
|
1 5 0.4129 (0.1983) C>S Handshake ClientKeyExchange 1 6 0.4129 (0.0000) C>S ChangeCipherSpec 1 7 0.4129 (0.0000) C>S Handshake 1 8 0.5585 (0.1456) S>C ChangeCipherSpec 1 9 0.6135 (0.0550) S>C Handshake 1 10 2.3121 (1.6986) C>S application_data 1 11 2.5336 (0.2214) C>S application_data 1 12 2.5545 (0.0209) S>C application_data 1 13 2.5592 (0.0046) S>C application_data 1 14 2.5592 (0.0000) S>C Alert Perceba que o ClientKeyExchange mesage type é mostrado mas o resto do HandShake messages não tem os types mostrados. |
O SSLdump consegue trabalhar com SSLv1, SSLv2 e SSLv3 e TLS.
Espero que tenham gostado.
Good Hacking 4 All.





















