Jump to content

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


teckV
 Share

Recommended Posts

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

Link to comment
Share on other 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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.