{"id":13910,"date":"2020-01-27T16:27:04","date_gmt":"2020-01-27T19:27:04","guid":{"rendered":"https:\/\/www.kaspersky.com.br\/blog\/?p=13910"},"modified":"2020-11-16T11:51:19","modified_gmt":"2020-11-16T14:51:19","slug":"36c3-fake-emails","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com.br\/blog\/36c3-fake-emails\/13910\/","title":{"rendered":"E-mails falsos: por que s\u00e3o poss\u00edveis?"},"content":{"rendered":"

\u00c0s vezes \u00e9 f\u00e1cil descobrir e-mails de phishing<\/a>: basta checar o campo do remetente. No entanto, isso nem sempre \u00e9 o suficiente. Tornar um e-mail falso indistingu\u00edvel de um genu\u00edno \u00e9 realmente poss\u00edvel<\/em>. Se um cibercriminoso sabe fazer isso, a organiza\u00e7\u00e3o alvo de um eventual ataque pode estar em apuros. Isso porque a maioria das pessoas n\u00e3o pensaria duas vezes antes de clicar em um link ou arquivo mal-intencionado que recebeu por e-mail, supostamente do chefe ou de um importante cliente (e \u00e9 dif\u00edcil culp\u00e1-las por isso, especialmente se n\u00e3o h\u00e1 como dizer que o e-mail foi falsificado).<\/p>\n

Mas, em primeiro lugar, por que \u00e9 perfeitamente poss\u00edvel forjar um e-mail falso? A fala de Andrew Konstantinov sobre autentica\u00e7\u00e3o de e-mail para analistas de invas\u00e3o<\/a>, durante o 36\u00ba Chaos Communication Congress<\/a>, responde a quest\u00e3o e nos d\u00e1 algumas pistas sobre a efetividade da prote\u00e7\u00e3o contra e-mails enganosos.<\/p>\n

Problema 1: e-mails seguem o fluxo<\/h2>\n

O e-mail \u00e9 um m\u00e9todo b\u00e1sico de comunica\u00e7\u00e3o dos dias de hoje, e toda organiza\u00e7\u00e3o depende muito dele em suas opera\u00e7\u00f5es di\u00e1rias. Embora n\u00e3o pensemos muito na tecnologia quando tudo corre bem, se todos os e-mails come\u00e7arem a desaparecer repentinamente, voc\u00ea pode ter certeza de que todo mundo vai notar. Por isso, a confiabilidade geralmente \u00e9 a principal prioridade de todo administrador de servidor de e-mail. A mensagem simplesmente precisa ser enviada e entregue, n\u00e3o importa o que aconte\u00e7a.<\/p>\n

A implica\u00e7\u00e3o aqui \u00e9 que o servidor de e-mail, em qualquer organiza\u00e7\u00e3o, deve ser o mais compat\u00edvel poss\u00edvel com os outros. E a\u00ed est\u00e1 o problema: os padr\u00f5es de e-mail est\u00e3o bem desatualizados.<\/p>\n

Problema 2: O protocolo de e-mail sem autentica\u00e7\u00e3o<\/h2>\n

O principal protocolo de e-mail utilizado nas comunica\u00e7\u00f5es \u201ccliente-servidor\u201d e \u201cservidor-servidor\u201d \u00e9 o SMTP. Este protocolo foi introduzido pela primeira vez em 1982 e atualizado pela \u00faltima em 2008 -mais de uma d\u00e9cada atr\u00e1s. E, assim como qualquer outro padr\u00e3o antigo, o SMTP \u00e9 um pesadelo em termos de seguran\u00e7a.<\/p>\n

Primeiro, vamos dar uma olhada no que consiste as mensagens de e-mail mais comuns:<\/p>\n

\u2013 Envelope SMTP: Essa parte \u00e9 utilizada em comunica\u00e7\u00f5es do tipo \u201cservidor-servidor\u201d e nunca \u00e9 mostrada para os clientes de e-mail. Ele especifica os endere\u00e7os do remetente e do destinat\u00e1rio.<\/p>\n

\u2013 Cabe\u00e7alho: os programas de e-mail mostram essa parte. E onde voc\u00ea vai encontrar termos familiares como \u201cDe\u201d, \u201cPara\u201d, \u201cData\u201d e \u201cAssunto\u201d, campos que voc\u00ea v\u00ea em qualquer mensagem.<\/p>\n

\u2013 Corpo da mensagem: O texto do e-mail e outros conte\u00fados.<\/p>\n

\"O

O que existe em uma mensagem de e-mail<\/a><\/p><\/div>\n

\u00a0<\/p>\n

O principal problema \u00e9 que os provedores padr\u00f5es n\u00e3o podem fazer autentica\u00e7\u00f5es. A responsabilidade pelo campo de endere\u00e7o do remetente \u2013 tanto no envelope SMTP quanto no cabe\u00e7alho \u2013 \u00e9 toda do servidor que envia a mensagem. O que \u00e9 pior: o endere\u00e7o do remetente no envelope SMTP n\u00e3o precisa ser o mesmo do que consta no cabe\u00e7alho (e o usu\u00e1rio v\u00ea apenas o \u00faltimo).<\/p>\n

Al\u00e9m disso, embora o padr\u00e3o especifique um cabe\u00e7alho por e-mail, o SMTP na verdade n\u00e3o imp\u00f5e um limite. Se uma mensagem contiver mais de um cabe\u00e7alho, o cliente de e-mail simplesmente escolher\u00e1 um deles para exibir ao usu\u00e1rio.<\/p>\n

N\u00e3o precisa ser um hacker profissional para perceber o tamanho desse problema.<\/p>\n

O protocolo de e-mail n\u00e3o garante que uma mensagem chegou realmente do remetente indicado<\/div>\n

Problema 3: Entra falso, sai falso \u2014 \u00c9 preciso estar atento a ambos<\/h2>\n

Para complicar ainda mais, toda comunica\u00e7\u00e3o por e-mail envolve duas partes. Portanto, falta de autentica\u00e7\u00e3o se desdobra em dois problemas secund\u00e1rios.<\/p>\n

Por um lado, voc\u00ea definitivamente quer ter certeza de que qualquer e-mail recebido seja realmente enviado pelo endere\u00e7o indicado. Por outro lado, voc\u00ea provavelmente deseja impedir que outras pessoas enviem e-mails que parecem vir do seu endere\u00e7o. Infelizmente, o padr\u00e3o n\u00e3o colabora.<\/p>\n

N\u00e3o surpreende, mas o protocolo SMTP tem sido explorado com tanta frequ\u00eancia que as pessoas come\u00e7aram a criar tecnologias para corrigir as falhas mencionadas acima.<\/p>\n

Tentativa de conserto 1: Estrutura de Pol\u00edticas do Remetente (SPF)<\/strong><\/p>\n

A ideia por tr\u00e1s da Estrutura de Pol\u00edticas do Remetente (SPF, na sigla em ingl\u00eas) \u00e9 bastante simples: o servidor que recebe um e-mail deve ser capaz de checar se o endere\u00e7o do servidor que enviou a mensagem bate com o do servidor de e-mail verdadeiro associado \u00e0quele dom\u00ednio.<\/p>\n

Infelizmente, \u00e9 mais f\u00e1cil falar do que fazer. O padr\u00e3o SMTP n\u00e3o tem como realizar essa verifica\u00e7\u00e3o, ent\u00e3o qualquer m\u00e9todo de autentica\u00e7\u00e3o teria de ser adicionado sobre o material existente. Demorou uma d\u00e9cada para que essa tecnologia se tornasse um \u201cpadr\u00e3o proposto\u201d. Atualmente, apenas 55% de um milh\u00e3o dos principais servidores utilizam a SPF, e a maioria utiliza pol\u00edticas bastante flex\u00edveis.<\/p>\n

A SPF tamb\u00e9m enfrenta muitos outros problemas, como sua arquitetura bagun\u00e7ada que facilita a configura\u00e7\u00e3o incorreta. Tamb\u00e9m \u00e9 poss\u00edvel engan\u00e1-la usando outros servidores hospedados no mesmo endere\u00e7o, e assim por diante. Mas a falha fatal desse sistema \u00e9 que ele verifica apenas o endere\u00e7o indicado no envelope SMTP e ignora completamente o campo \u201cDe\u201d no cabe\u00e7alho \u2013 aquele que o usu\u00e1rio realmente v\u00ea.<\/p>\n

Resultado<\/strong><\/p>\n