Análise passiva (parte 2)

y2h4ck

Nesta segunda parte do artigo sobre análise passiva, iremos conhecer técnicas para passar por filtros de pacotes e entender alguns conceitos de pacotes como payload e padrões para transmissão.

[ Hits: 41.687 ]

Por: Anderson L Tamborim em 22/06/2004 | Blog: http://y2h4ck.wordpress.com

0 0

Denuncie Favoritos Indicar Impressora

Verificando padrões

No Payload temos algumas coisas que são padrões, como por exemplo, a segunda linha, segunda coluna, vamos analisá-la um pouco.

 7f00 0001 0800 4e26 8407 0001 c3ac dd40

Iremos analisar vários pacotes e ver o que ocorre a esta linha:

14:12:08.089911 localhost > localhost: icmp: echo request (DF) 
(ttl 64, id 0, len 84)
    4500 0054 0000 4000 4001 3ca7 7f00 0001      E..T..@.@.<.....
    7f00 0001 0800 619c 9d07 000b 68ae dd40      ......a.....h..@
    c75e 0100 0809 0a0b 0c0d 0e0f 1011 1213      .^..............
    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223      ............ !"#
    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233      $%&'()*+,-./0123
    3435 3637                                    4567
14:12:08.090105 localhost > localhost: icmp: echo reply 
(ttl 64, id 39567, len 84)
    4500 0054 9a8f 0000 4001 e217 7f00 0001      E..T....@.......
    7f00 0001 0000 699c 9d07 000b 68ae dd40      ......i.....h..@
    c75e 0100 0809 0a0b 0c0d 0e0f 1011 1213      .^..............
    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223      ............ !"#
    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233      $%&'()*+,-./0123
    3435 3637                                    4567
... ( muitas linhas )

14:12:07.080130 localhost > localhost: icmp: echo reply 
(ttl 64, id 39566, len 84)
    4500 0054 9a8e 0000 4001 e218 7f00 0001      E..T....@.......
    7f00 0001 0000 55c4 9d07 000a 67ae dd40      ......U.....g..@
    dc37 0100 0809 0a0b 0c0d 0e0f 1011 1213      .7..............
    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223      ............ !"#
    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233      $%&'()*+,-./0123
    3435 3637

Como vimos, apartir da segunda coluna os valores mudam, antes não, isso já pode nos dar um padrão para analisar, vamos ver como ocorre, isso em um tráfego TCP normal:

14:14:50.624177 201.0.11.121.32891 > 192.94.73.21.telnet: 
P [tcp sum ok]
196:203(7) ack 184 win 5808 <nop,nop,timestamp 570078 6> 
(DF) [tos 0x10] (ttl 64, id 944, len 59)
    4510 003b 03b0 4000 4006 5910 c900 0b79      E..;..@.@.Y....y
    c05e 4915 807b 0017 a787 ab3e 99fb 7ab0      .^I..{.....>..z.
    8018 16b0 984d 0000 0101 080a 0008 b2de      .....M..........
    0000 0006 7932 6834 636b 0a                  ....y2h4ck.
14:14:51.147184 192.94.73.21.telnet > 201.0.11.121.32891: 
P [tcp sum ok]
193:205(12) ack 203 win 17520 <nop,nop,timestamp 46 
570078> [telnet WILL
ECHO] [tos 0x10]  (ttl 49, id 39061, len 64)
    4510 0040 9895 0000 3106 1326 c05e 4915      E..@....1..&.^I.
    c900 0b79 0017 807b 99fb 7ab9 a787 ab45      ...y...{..z....E
    8018 4470 0f3f 0000 0101 080a 0000 002e      ..Dp.?..........
    0008 b2de fffb 0150 6173 7377 6f72 643a      .......Password:
14:14:55.497348 64.12.24.192.https > 201.0.11.121.filenet-nch: 
. [tcp sum ok] ack 6 win 16384 (DF) (ttl 104, id 37429, len 40)
    4500 0028 9235 4000 6806 5355 400c 18c0      E..(.5@.h.SU@...
    c900 0b79 01bb 8002 abf8 d80f 5c38 5546      ...y........\8UF
    5010 4000 8b4a 0000                          P.@..J..

Analisem a linha que acabamos de ver nesse caso, viu, elas não permanecem inalteradas, elas vão modificando seu valor juntamente aos outros, então já temos duas conclusões, os Payloads são tratados diferentemente em pacotes com estado e em pacotes ICMP sem estado.

Você se pergunta agora, em que isso me ajudará?
Digamos que você está analisando seu tráfego ICMP e de repente se depara com um padrão alterado, a primeira vista provavelmente você nem sequer se daria conta desse "padrão" diferente. Essa situação seria encontrada em túneis ICMP para serviços de HTTP, como por exemplo o wwwtunel (disponível em www.thc.org), onde o tráfego da backdoor em túnel é encapsulado dentro de chamadas ICMP, passando assim desapercebido (ou quase) pela nossa análise.

Página anterior Próxima página

Páginas do artigo

   1. Introdução: pequena explicação sobre payload
   2. Verificando padrões
   3. Técnicas contra filtros
   4. Considerações finais

Outros artigos deste autor

Seguraça extrema com LIDS

Análise Passiva: Analisando seu tráfego de maneira segura

PaX: Solução eficiente para segurança em Linux

Libsafe: Protegendo Linux contra Smashing Overflow

Security Hacks: Linux & BSD

Leitura recomendada

Linux - Permissões de acesso especiais

Intrusão simples com Metasploit

Rainbow Crack e Rainbow Tables

Política de Segurança para Dispositivos Móveis

Race Condition

Comentários

[1] Comentário enviado por fabio em 22/06/2004 - 10:09h

Excelente artigo! Curti bastante o hping2, esse eu não conhecia.

[]'s

0 0

[2] Comentário enviado por Ragen em 22/06/2004 - 12:41h

Muito massa seu texto =]

Tem um texto que foi escrito por um amigo meu (Sr. dmr) que se encontra disponivel em http://www.frontthescene.com.br/artigos/http_tunnel.txt isso é, acaba sendo mais uma fonte de estudo pra quem quer se aprofundar no assunto

[]'s

Ragen

0 0

[3] Comentário enviado por jllucca em 22/06/2004 - 14:05h

Muito bom o artigo, expos varias coisas que nao conhecia ou que lembrava com outro nome :)

0 0

[4] Comentário enviado por agk em 22/06/2004 - 14:12h

Parabéns, excelente artigo, muito útil para abrir os olhos que quem pensa que é só colocar um firewall na rede e estará 100% protegido.

0 0

[5] Comentário enviado por y2h4ck em 22/06/2004 - 19:00h

Obrigado Pessoal so acrescentando algo que "faltou". Eu iria utilizar o netcat para abrir algumas portas e deixar como listen ... porem decidi usar um exemplo mais real world portanto descarte o netcat para essa função.

Para quem se interessou e muito bom procurar sobre o netcat...
para colocar uma porta como listen:

$nc -l -p porta -vv

:)

Abraços a todos

0 0

[6] Comentário enviado por jeffestanislau em 23/06/2004 - 08:32h

y2h4ck

Novamente torno a parabenizá-lo.... suas explicações são simples e objetivas.... muito bom mesmo!!!

[]´s

0 0

[7] Comentário enviado por n1nj4 em 23/06/2004 - 23:04h

Mais um artigo de qualidade, hein?!
Parabéns, Anderson... Apreciei bastante dessa vez!
;-)

[]'s

n1nj4

0 0

[8] Comentário enviado por Estorb em 24/06/2004 - 23:35h

Mas a Roda já foi inventada!!!

0 0

[9] Comentário enviado por y2h4ck em 25/06/2004 - 08:41h

Estorb é mesmo ?

0 0

[10] Comentário enviado por birilo em 25/06/2004 - 22:35h

Novamente, mandou muito bem...

0 0

[11] Comentário enviado por PgDn em 26/06/2004 - 23:53h

quando vc for lançar um livro sobre analise e segurança .. conte comigo para comprar o primeiiro exemplar... vc é o cara que conhece de proteçao ....
e tem mais..além disso tudo eh uma grande pessoa...abraço

0 0

[12] Comentário enviado por estorb em 27/06/2004 - 13:33h

Milagre!!!! o RE.TAR..DO do wrochal não apareceu aqui falando absurdos!!!!!!!

0 0

[13] Comentário enviado por msmadela em 11/11/2008 - 02:28h

Oi y2h4ck, fiz o teste no meu Fedora C8 e o hping não indicou que a porta estava filtrada, mas o nmpa indica. Minha pergunta é: como o sniffer sabe que uma porta está sendo filtrada? O firewall devolve alguma informação mesmo usando um target DROP no iptables?

0 0

[14] Comentário enviado por y2h4ck em 11/11/2008 - 10:28h

msmadela,

O que acontece é o seguinte, quando você filtra uma porta ... significa que você esta colocando a tag "REJECT" nela e não DROP.
Quando um pacote --tcp-syn encontra uma porta filtrada com REJECT, o firewall devolve para o host que acessa um pacote --icmp-type3
que significa "destination unreachable". Com isso ele consegue deduzir que a porta esta filtered. Caso esteja como DROP, o host não envia nada, dai é necessario efetuar alguma varredura adicional para ajudar você confirmar se esta Down ou esta DROP, um bom exemplo seria uma varredura UDP + ACK. :)

[]s

Bons estudos.

0 0