• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

teckV

Secure Sockets Layer (SSL) Man-in-the-middle attack

6 mensagens neste tópico

como já referi num outro post há um ataque conhecido que tem sido devastador para muita gente... pois funciona sobre a ilusão de segurança que muitos têm tentado passar...

estamos fartos de ver nos sites de e-commerce e todos os que envolvem valores afirmarem que usam ligações segurastecnicamente falando usam SSL... tudo bem até aqui... o problema é que se desenvolvem técnicas para lidar com as situações especificas e neste caso surgiu uma técnica conhecida como "Man in the middle" ou em PT "O homem no meio"... como o nome diz é alguem ou algo que se coloca no meio de uma comunicação e intercepta/altera os dados da mesma... esta técnica evoluio e assume-se também no mundo SSL...

sslway.gif

um dos procedimento usados neste ataque consiste em "DNS cache poisoning".. isto é... o DNS traduz um nome tipo "www.yahoo.com" para um IP... com  o "DNS cache poisoning" o atacante consegue mapear um nome de um site e-commerce para um servidor seu que finge ser o servidor e-comerce... depois liga-se ao verdadeiro servidor de e-comerce e finge-se ser o cliente... ou seja... o cliente para falar com o site têm de passar pelo servidor do atacante...como o atacante está em ambas as encriptações pode desencriptar os dados lendo calmanente tudo o que é transmitidosejam passwordsnumeros de contacartões de créditoetc...

Think of the Man-in-the-middle attack.

By DNS cache poisoning etc.the client may be led to a rogue site with SSL. SSL certificates are now cheap. Some offers at only $14.95 while average intake by phishers are around $4000 per attack. Although many people argue that phishers will not buy a certificatethat may not be trueas they can easily pay for it. Certificates are cheap compaired to renting a bot-netwhich costs around $1500 a day.

Nowback to man-in-the-middle scenario. Think of something like this:

Client ( C ) – Rogue SSL Proxy (RSP) – Real Server (S)

The client establishes SSL session with RSP. RSP establishes one in turn with RS. Suppose that you were relying on non PKI authentication mechanism like username:password authentication. Thenyou are undone. RSP learns your username and passwordand logs into S and do transactions on behalf of you.

To be safeC has to check the X.509 of S in a particular manner. X.509 itself is a public informationso is prone for replay attack. C has to get something signed by the private key and returned it to it to trust the other end. Luckilyin TLSwe have something like that. During the handshakeC sends out the premaster secret encrypted with S’s public key. (Premaster secret acts as seed for the TLS session establishmentso it cannnot be missed.) Soif C uses preshared public key of S in this phase instead of something C got from the network nowthenthis kind of man-in-the-middle become impossible. In another wordjust establishing SSL/TLS session with somebody is not enough. Some like SAML-bindings documents suggests checking DN or AltName but that is also probably is not enough. Establishing TLS session and the public key being equal to the one used in establishing the session would guarantee the safety.

como podem ver neste recorte o problema pode ser resolvido com as autoridades externas a validar os certificados... dai ser importante que o servidor esteja devidamente registado numa CA (autoridade de certificados) publica e oficial...

normalmente os browsers estão configurados para aceitar certificados mesmo sem estarem "validados/oficializados" e apenas perguntam ao utilizador se aceita o certificado ou não... é aqui que se podem defender... procurando semrpe certificarem-se da originalidade do certificado.. confirmem se o certificado que vos aparece no browser é mesmo da empresa em que estão a visitar... podem ver isso nas propriedade e no nome do certificado... há tambem o fingerprint "impressão digital do certificado para se comprovar se é original/oficial ou não

é muito importante ter atenção a origem dos certificados....

dados sobre o ataque

http://users.tkk.fi/~tkoponen/vaihe2/ssl-mitm.html

DNS Spoofing

http://users.tkk.fi/~tkoponen/dnsspoof.html

dsniff

http://monkey.org/~dugsong/dsniff/

teckV

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Obrigado teckv!!!

Estes teus posts são um autentico serviço publico!!

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

o mundo é uma selva... a internet também...

o melhor que podemos fazer é entender as coisas para nos protegermos...

é claro que se pode dizer que estou a ensinar a isto ou aquilol... não concordo.. é estudando a sério as tecnologias que se aprende, não com pequenos posts... por outro lado... é uma forma de o pessoal se consciencializar para estes problemas, pois conhecendo-os permitenos evita-los... dentro do possivel

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

É nesse sentido que digo que prestas um serviço público. Depende depois do "público" o que faz com a informação...  :) :hmm:

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

cool

obrigado

:thumbsup: :thumbsup:

Epa... podias adaptar um pouco isto... tirar os verbos na segunda pessoa e por isto no wiki. É este tipo de coisas que deve ir para o wiki, na minha opiniao. É importante começar a organizar a informação.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Epa... podias adaptar um pouco isto... tirar os verbos na segunda pessoa e por isto no wiki. É este tipo de coisas que deve ir para o wiki, na minha opiniao. É importante começar a organizar a informação.

ya, concordo.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora