TECNOLOGIA GRATUITA: SEGURANÇA DE SISTEMAS E REDES TÓPICO: FRAGILIDADES DO PROTOCOLO SMTP Ulisses Thadeu Vieira Guedes 2012 1/16
Conteúdo FRAGILIDADES DO SMTP...3 NECESSIDADES ATUAIS NO SMTP...3 REVISÃO DO PROTOCOLO SMTP...4 NOME E IP DO CLIENTE SMTP...5 EHLO ou HELO...6 MAIL FROM...6 RCPT TO...7 RSET...7 QUIT...7 DATA...7 Cabeçalhos de Origem:...8 Campos de endereços de Destinatários...8 Campos de Identificadores de mensagens...9 Campos de Informações...10 CRITÉRIOS SUBJETIVOS DE FILTROS ANTISPAM...11 OPT-OUT, OPT-IN E DOUBLE OPT-IN...13 SPAMTRACKERS...13 SMTP SPOOFING...15 2/16
FRAGILIDADES DO SMTP Quando o protocolo SMTP foi projetado não havia requisitos quanto a garantia da origem da mensagem na camada da aplicação. Jonathan B Postel, autor da RFC 788 e posteriores, em 1981 previu funções e atividades necessárias para atender aos requisitos da época e considerava que a origem poderia ser acreditada baseando-se, apenas, no endereço IP de origem. Naquela época, os computadores eram limitados sob o ponto de vista de hardware e software e o espírito de cooperação entre os sistemas era sempre vem vinda, motivada e acreditada. Nas RFCs 788 (de 1981) e 821 (de agosto de 1982), o protocolo SMTP previa recursos de envio de mensagens diretamente para terminais (comandos SEND, SOML e SAML), pois a arquitetura dos sistemas eram baseadas em mainframes (um computador com vários terminais acoplados à ele). Era admissível expandir listas de endereços (comando EXPN) ou saber se um usuário tinha conta ativa naquele sistema (comando VRFY). Hoje, se tais comandos são implementados pelos MTAs (Mail Transfer Agent) então eles são desabilitados por segurança. Quando um MTA se conectava a outro, havia a educação do primeiro questionar o segundo quanto a existência de alguma mensagem no sentido reverso (comando TURN). Hoje isso não é aceitável, pois o outro lado pode agir de maneira hostil. O protocolo SMTP é, desde a sua concepção, dependente do serviço de tradução de nomes com autoridade delegada, o que é denominado de DNS. Naquela época, devido as limitações, não eram todos os sistemas que podiam executar as duas aplicações. Aquela limitação foi acatada pelo SMTP permitindo que os emails e anúncios de HELO usassem de número IP ao invés dos nomes, em duas formas: fulano@#ip ou fulano@[ip]. Naquela época, o requisito de Mail-Relay (um usuário explorava recursos de envio de outros sistemas) era, como citado, uma prestação de serviço aceitável, caso contrário não haveria formas de troca de mensagens. Hoje tal condição é considerada abuso por qualquer administrador ou grupo de segurança, displicência, negligência e imprudência por quem administra. O tamanho máximo de uma linha de texto da mensagem transmitida era limitada a 1000 (considerando o CRLF) e o número de destinatários era limitado a 100. Tais limitações ainda são acatadas e já foram objetos de ataque em implementações pobres. Na concepção antiga, os cabeçalhos das mensagens não poderiam ter qualquer relação com as informações do envelope pois poderiam ser sobrepostas pelos Mail-Gateways agindo em Mail-Relay (RFC 1123, item 5.2) e Source-Routing. Infelizmente, hoje, tal requisito não é aceitável pois permite a falsificação de endereços. NECESSIDADES ATUAIS NO SMTP Eis algumas necessidades de hoje ainda que não são atendidas pelo SMTP, mas exigidas por 3/16
motivos de segurança e para evitar spam: Anúncio do nome em tempo de EHLO (HELO) com registro de tradução direta e reversa. (tradução reversa é, hoje, facultativa no Brasil). Endereço de E-mail do remetente compatível com o nome do sistema de origem e aquele anunciado em EHLO. (hoje é opcional e a RFC 5821 mantém a independência.) Cabeçalhos e informações de Envelope coerentes entre si quanto a domínios e hosts. (hoje os padrões iniciais são mantidos e considerados independentes. Deveriam ser os mesmos no caso de remetente único para destinatário único.) Condições de verificação se um certo domínio autoriza o envio de mensagens por um certo remetente. Existem recursos de SPF e DKIM (www.dkim.org), mas os recursos não são obrigatórios dada a complexidade de implementação e integração com o SMTP, exigindo pós-processamento da mensagem. Opções mais simples, tais como a classificação inversa da preferencia MX para designar autorização de envio, já foram propostas. A preferência 255 significaria Sistema não autorizado a enviar mensagens. Nenhuma modificação complexa é necessária pois a consulta MX é feita naturalmente. Uma vez que o TCP/IP é um protocolo entre hosts com direito a todos os serviços de forma independente, a ação MX-reversa seria uma medida preventiva pelos detentores de DNS. Assim, qualquer instancia hierarquia superior poderia sobrepor um comportamento indesejado. A consequência de tais exigências seriam: Serviços de Mail-Hosting anunciando OBRIGATORIAMENTE os nomes de domínios contratados e não, apenas, a condição MX para eles (Não o fazem!) Procedimentos de integração WEBxSMTP com critérios mais eficientes. (Não realizado). Agilidade no atendimento e cumprimento de contratos pelos provedores. (Provedores não se preocupam com as vulnerabilidades existentes em suas redes. Usam soluções paliativas e não se comprometem). Legislação quanto às responsabilidades dos ISPs quanto a spam, presença de sistemas zumbis e serviços praticados. (As exigências existentes não são acatadas sendo transferidas para o usuário final, que ficam sem apoio jurídico e explorados por serviços desnecessários). REVISÃO DO PROTOCOLO SMTP A implementação do protocolo SMTP que segue as RFCs atuais (RFCs 5321 e 5322) apresentam alguns indicadores de spam. As primeiras RFCs (RFC 821 e 822, de 1986) estabeleciam algumas regras aplicáveis no início da grande rede. Aquelas regras consideram e motivavam a possibilidade de Mail-Relay e não demonstravam qualquer cuidado quanto à segurança. Na atualização prévia (RFCs 2821 e 2822) indicavam algumas indicações quanto à segurança, que ainda permanecem ultrapassadas para o cenário atual. Uma sessão SMTP corresponde a uma sequencia de VERBOS e complementos que estão inter- 4/16
relacionados entre si. Nas RFCs há termos que designam condições de uso ou de aplicabilidade: MUST (OBRIGATÓRIA) para a obrigatoriedade; SHOULD (RECOMENDADA) para a necessidade e recomendação mas não é obrigatória; CAN (POSSIBILIDADE) uma possibilidade de fornecer, um ato opcional. MUST NOT (ORBIGATORIAMENTE NÃO) Obrigatoriamente não SHOULD NOT (RECOMENDAVELMENTE NÃO) Não é necessário nem recomendável. CAN NOT (OPCIONALMENTE NÃO) Opcionalmente não NOME E IP DO CLIENTE SMTP A primeira informação obtida pelo MTA/MX (sistema que implementa o correio eletrônico e é configurado para receber mensagens) é o endereço IP do sistema remoto (aquele que pretende enviar a mensagem). Aquele IP tem um nome correspondente, informado pelo serviço de DNS-REVERSO. A RFC 5321 cita que a tradução reversa é RECOMENDADA, logo o IP pode não ter nome associado conforme alguma condição. Contudo sistemas MX devidamente configurados fornecem alguma tradução reversa coerente, mesmo que o ISP não ajude nisso. Por outro lado, as RFCs que tratam sobre DNS citam que um nó IP na Internet deve ter, OBRIGATORIAMENTE, um nome e sua tradução reversa. O maior problema de DNS-REVERSO é convencer os profissionais dos provedores que é possível, sim, delegar poucos endereços, conhecido como classless IN-ADDR.ARPA delegation (RFC2317/BCP0020, de 1998). O nome, quando fornecido, deve ser OBRIGATORIAMENTE completo. Em inglês é representado pelo FQHN (Full Qualified Host Name). Nas RFCs mais antigas depara-se com o sigla FQDN (Full Qualified Domain Name) mas quer dizer o nome completo de um nó ou Host. Exemplos: 1. IP: 200.160.4.6 (o correto é 6.4.160.200.in-addr.arpa) tem o nome www.nic.br e este nome (tradução direta) está associado ao mesmo IP. 2. IP: 64.4.56.55 (o correto é 55.56.4.64.in-addr.arpa) tem o nome origin.by148w.bay148.mail.live.com e este nome está associado ao IP. Contudo, ao verificar o nome www.hotmail.com, este tem a tradução direta para aquele IP mas 5/16
também para o IP 64.4.56.71. Neste caso, a configuração mais correta para o anúncio de HELO (a seguir) será origin.by148w.bay148.mail.live.com embora www.hotmail.com também seja RECOMENDADO. Os dois casos atendem as RFCs de DNS e SMTP. 3. IP: 189.127.6.234 (o nome correto é 234.6.127.189.in-addr.arpa) tem o nome 189.127.6.234.nipcable.com. O SMTP/HELO está anunciando como mail.uligue.co.cc, que está associado ao IP informado, contudo o reverso não por puro desinteresse do provedor. EHLO ou HELO O verbo HELO (ou EHLO) exige um nome do sistema que pretende enviar uma mensagem. O nome anunciado deve ter OBRIGATORIAMENTE uma tradução direta para o IP caso seja fornecido. Nomes internos (exemplo: PCa159) não acatam a condição FQDN ou FQHN e OBRIGATORIAMENTE NÃO devem ser usados. No caso de impossibilidade de tradução (se realmente não for possível e não existir qualquer tradução), RECOMENDA-SE o uso do endereço IP do sistema cliente entre colchetes ([IP]). No caso 3, acima, conforme a RFC atual, o anúncio em HELO PODE SER mail.uligue.co.cc enquanto que o RECOMENDADO é 189.127.6.234.nipcable.com. Qual escolher será definido a seguir. MAIL FROM O estado da sessão MAIL FROM exige o endereço eletrônico entre os caracteres '<' e '>', na forma alias@fqdn ou alias@fqhn, ou seja <alias@fqdn> ou <alias@fqhn>. O FQDN, neste caso é, OBRIGATORIAMENTE, o nome de um HOST (tendo a tradução direta para o IP do sistema cliente) ou de um DOMÍNIO desde que tenha um DNS-RR MX apontando para preferencias e FQHNs. As RFCs mais antigas (RFC821 e 822) citavam que as partes do domínio do FQDN de MAIL FROM e o FQDN do HELO (EHLO) OPCIONALMENTE NÃO precisavam de apresentar qualquer vínculo entre eles, uma vez que havia a condição de MAIL-RELAY. Contudo, hoje não há mais limitações que impeçam ou dificultem a implementação de um MTA completo, o que modificou a citação para RECOMENDADA que tenha algum vínculo. Em outras palavras, é INACEITÁVEL: HELO abacaxi.empresa.com.br MAIL FROM: fulano@abobrinha.com.br tendo abobrinha.com.br IN MX N bla.outrodominio.com.br sendo que outrodominio.com.br não apresenta qualquer vínculo DNS com empresa.com.br. As RFCs preveem e indicam que é possível ter vários e-mails como remetente. Neste caso, o primeiro deles deve, OBRIGATORIAMENTE, acatar as condições citadas. 6/16
Para resolver este pequeno problema, cita-se os recursos de DKIM (RFC 4686) e SPF (RFC 4408). As mesmas RFCs ainda preveem a possibilidade desse e-mail ser vazio. Isso só é permitido SE e SOMENTE SE, a mensagem for uma mensagem de erro e o destinatário for único. Ainda, neste caso, o cabeçalho From: deve apresentar, OBRIGATORIAMENTE, um indicador de retorno de MAILER-DAEMON, representando que a resposta foi gerada pelo MTA e não por um indivíduo. RCPT TO O estado RCPT TO indica o(s) destinatário(s) da mensagem, seguindo a mesma sintaxe do MAIL FROM. Se os destinatários seguem 'com cópia' (CC) ou 'com cópia oculta' (bcc) isso será discutido nos cabeçalhos. RSET O estado RSET sinaliza que a sessão deve ser completamente reiniciada. Todos os estados anteriores devem OBRIGATORIAMENTE ser removidos. Contudo, nas implementações antigas do SMTP, alguns MTAs mantinham os complementos informados de forma equivocada. QUIT O estado QUIT encerra a transmissão da mensagem. O fechamento voluntário pelo MTA de serviço SMTP é considerado um QUIT. DATA O estado DATA coloca a sessão SMTP em estado de transferência dos cabeçalhos e do corpo da mensagem. Os campos são preenchidos sob a responsabilidade da aplicação que criou a mensagem e o MTA deve copiá-los para o envelope. Alguns MTAs copiam os valores dos estados MAIL FROM para o campo From: e RCPT TO: para o campo To:, ou seja, fazem exatamente o contrário. Segundo as RFCs mais recentes, os campos resultantes do envelope e do cabeçalho são independentes. Os campos gerados pelos estados são de responsabilidade do sistema que ENVIA a mensagem, o MTA (Mail Transfer Agent), enquanto que os campos do cabeçalho são de responsabilidade do sistema que criou a mensagem, o MUA (Mail User Agent). É esta a independência explicita. Contudo, sob o ponto de vista operacional há alguma dependência implícita entre os campos. Quando um MUA envia a mensagem para um MTA em Mail-Relay, o MTA copia os campos lá informados e os utiliza para os campos do envelope. Se o MTA autoriza o envio aparecerá uma relação de confiança entre a origem do MUA e a do MTA, pois hoje a condição de Mail-Relay aberto é indesejável. Tal confiança também se reflete no bloco IP alocado e nos FQDNs. Uma forma de verificar isso é o questionamento de DNS-RR SPF e DKIM, mas não são todos os domínios que aderiram a tais configurações e recursos. Uma segunda forma é verificar o traço 7/16
lógico entre do MTA até o sistema remoto, observando se é encontrado alguma dependência lógica. Numa terceira condição, pode-se verificar a confiança por delegação de nomes ou de tradução. Para efeito didático, considere uma empresa que não tem interesse ou recurso para administrar um serviço SMTP individualmente e contrata o serviço de Web-Host de um ISP. Tecnicamente, isso reflete na condição MX. Ou seja, empresa.com.br IN MX n mta.isp.com.br. Aquela empresa também poderá instalar um MTA completo em sua infra estrutura, apenas para o envio de mensagens (mta.empresa.com.br). Assim, mensagens com remetente @empresa.com.br podem ocorrer tanto vindas de algum.isp.com.br quanto de mta.empresa.com.br. Qualquer mensagem com aquele remetente vindo de qualquer outra origem IP e domínio (ex. google.com) tem impacto negativo, levantando suspeitas de um remetente falso. Cabeçalhos de Origem: Os cabeçalhos sinalizadores de origem são identificados por From:, Sender: e Reply-To:, devendo ser escrito com letras nos tamanhos de caixas mostrados. Ou seja: from:, sender: ou reply-to: retratam que o MUA não segue as especificações da RFC 5322. O cabeçalho From: especifica o(s) autor(es) da mensagem, ou seja os responsáveis pela escrita. O campo Sender: especifica a caixa postal do agente responsável pelo envio da mensagem. Quando os dois endereços são iguais então o campo Sender: deve ser omitido. Muitas mensagens spam apresentam os dois cabeçalhos com valores iguais. O campo Reply-To: contém a caixa postal que o autor sugere para uma resposta. Dentro de uma empresa ou instituição, a inclusão de Reply-To e From: deveriam pertencer ao mesmo domínio base. Exemplo: From: barbosa@adm.empresa.com.br Reply-To: Augusto.Barbosa@empresa.com.br A presença de outros domínios não necessariamente indicam spam, porém insinuam caso algum dos endereços não exista. Campos de endereços de Destinatários As mensagens podem conter os campos To:, Cc: e Bcc:, contudo este último, OBRIGATÓRIAMENTE, não deve aparecer na mensagem que é entregue à caixa Postal. O campo To: contém o endereço do primeiro destinatário. O campo Cc: contém os endereços de destinatários a qual a mensagem é copiada. Se o campo Bcc: aparecer ele não deve conter qualquer endereço de email identificável (Undisclosed-Recipient). Neste caso ele apenas sinaliza que outros destinatários não listados receberão a mensagem. Caso apareça fora de tais condições é um indicador de spam. 8/16
Se o o destinatário é uma lista oculta então o campo To: OBRIGATORIAMENTE deverá aparecer o valor undisclosed-recipients. Não existem mensagens criadas por MUAs (Mail User Agents), MDAs (Mail Delivery Agents), MTAs (Mail Transfer Agents) com os campos To: e From: ausentes ou vazios. Caso não existam é sinalizador de spam. Campos de Identificadores de mensagens Os campos identificadores de mensagens são: Message-ID:, In-Reply-To: e References:. Toda mensagem deve ter, no máximo, 1 cabeçalho Message-ID: ou não ter. Não existe mensagem enviada por MTAs, MUAs, MDAs com mais de um identificador Message-ID:. Na ocorrência de mais de um deste cabeçalho é um grande indicador de spam. A presença de cabeçalhos semelhantes que não seguem a sintaxe das caixas também é indicador de spam. A ausência do Message-ID indica que a origem da mensagem não tem interesse em continuar com o diálogo, pois a mensagem deve ser tratada como informacional. Uma mensagem de notificação de ações dentro de um empresa ou de uma rede específica, originada naquela mesa rede por um administrador ou script interno, é um exemplo onde o Message-ID não tem recomendação de existência. A mensagem criada por um usuário de uma rede externa não pode ser considerada como informacional. Neste caso, a ausência do Message-ID é sinalizador de spam. O campo In-Reply-To: deve conter o valor de todos os Message-ID: de mensagens que originaram aquela resposta. Ou seja, é preciso que tenha ocorrido um identificador com aquele valor em Message-ID parra que exista um campo In-Reply-To:. Em algumas mensagens spam foram observados as seguintes situações (considere a o sistema que iniciou a conversa seja mx.empresa.com.br e que a resposta seja bla.sem.br: Exemplo 1: Em HELO bla.sem.br Message-ID: <jakakjdfakj.aajhsjhfasjh@empresa.com.br> In-Reply-To: <123456.6552434365@bla.sem.br> Isso é uma evidencia clara de spam. Exemplo 2: Em HELO bla.sem.br Message-ID: <jakakjdfakj.aajhsjhfasjh@empresa.com.br> Message-ID: <jakakjdfakj.aajxxxuiold@empresa.com.br>... É outra evidência clara de spam. 9/16
Exemplo 3 (correto): Em HELO bla.sem.br Message-ID: <jakaahshshgga.aajhsjhfasjh@bla.sem.br> In-Reply-To: <jakakjdfakj.aajhsjhfasjh@empresa.com.br> As RFCs 5322, 2822 e 822 RECOMENDAM que a parte do domínio do Message-ID (após o @) identifique o sistema que criou a mensagem por um FDQN, quando existir aquele campo. Por incrível que pareça os sistemas do HOTMAIL não acatam tal recomendação e inserem nomes da rede interna como se aqueles nomes fossem únicos na Internet. A relação explicita (dedutível mas não garantida) é que o domínio informado no Message-ID pertença à rede de origem da mensagem ou que use serviços daquela rede. Neste último caso, o tipo de serviço contratado é revelado nos testes de rotas, DNS-RR NS e/ou MX. A realização de daqueles testes em tempo de transferência de mensagem podem extrapolar os tempos de resposta ao longo dos estados de uma sessão SMTP. Campos de Informações As RFCs 5322, 2822 e 822 preveem 3 campos de informação: Subject:, Comments: e Keywords:. O campo Comments usado é o Subject:, contendo a finalidade/assunto da mensagem. O campo Comments: contém comentários adicionais no texto do corpo da mensagem. O campo Keywords: contém uma lista de palavras importantes ou frases que podem ser de interesse do destinatário. A tabela mostra os campos citados e número de campos permitidos por mensagem. A tabela completa está na RFC 5322, página 21. +----------------+--------+------------+----------------------------+ Field Min Max number Notes number +----------------+--------+------------+----------------------------+ from 1 1 See sender and 3.6.2 sender 0* 1 MUST occur with multi-address from - see 3.6.2 reply-to 0 1 to 0 1 cc 0 1 bcc 0 1 message-id 0* 1 SHOULD be present - see 3.6.4 in-reply-to 0* 1 SHOULD occur in some replies - see 3.6.4 references 0* 1 SHOULD occur in some replies - see 3.6.4 subject 0 1 comments 0 unlimited keywords 0 unlimited +----------------+--------+------------+----------------------------+ 10/16
CRITÉRIOS SUBJETIVOS DE FILTROS ANTISPAM Nem sempre é possível identificar, supor, ou mesmo garantir, que uma mensagem é ou não spam, e muito menos se o teor é malicioso baseando-se, exclusivamente, nos cabeçalhos. Felizmente o ser humano, tanto o administrador quanto o usuário e um spammer, são dotados de inteligência lógica e perspicácia. Em condições normais, quando alguém contata outro formalmente (ou mesmo informalmente), usando um MUA devidamente programado, então todas as regras de montagem de uma mensagem são acatadas. Porém, quando as aplicações MUAs visam alto desempenho no envio, algumas regras devem ser neglicenciadas pois consomem tempo na montagem de cada mensagem, o que compromete o desempenho esperado. A análise de conteúdos utiliza, normalmente, frases críticas, jargões do mercado e do produto. O perfil de uma mensagem spam nem sempre reflete o perfil de compra e ou de visitas de portais um usuário, uma vez que as listas de endereços são compradas, alugadas, disponibilizadas temporariamente ou permanentemente. Então, com tal estratégia é preciso avaliar os pontos fracos: Um spammer não quer ser identificado através da mensagem. Logo o endereço de remetente é forjado e ele usa sistemas que enviam as mensagens de forma autorizada ou não. Se é forjado não adianta verificar a existência do e-mail, pois ele pode usar algum de sua lista. Se ele usa qualquer sistema então o remetente não deve ser coerente com a origem IP e domínio. O Message-ID não indicará diferenças entre o sistema gerador e o enviador. Vários provedores oferecem serviços de Mail-Hosting e Web-Hosting voltados para o Comércio Eletrônico. a parte do usuário do e-mail do remetente é forjada enquanto o domínio não. Neste tipo de mensagem os spammers simulam listas de subscrição com links de remoção normalmente inoperantes e utilizados para a confirmação do e- mail. As mensagens vindas daquela falsa lista sempre apresentarão os links. Para ocultarem a identidade real, os provedores criam e registram outros domínios. Exemplo: [root@torrinha]# nslookup -q=ns whservidor.com.br Server: 127.0.0.1 Address: 127.0.0.1#53 [root@torrinha]# nslookup -q=soa whservidor.com.br Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: whservidor.com.br nameserver = ns3.host.uol.com.br. whservidor.com.br nameserver = ns1.host.uol.com.br. whservidor.com.br nameserver = ns2.host.uol.com.br. Authoritative answers can be found from: Non-authoritative answer: whservidor.com.br origin = ns1.host.uol.com.br mail addr = admin.uolhost.com.br serial = 2010120708 refresh = 43200 11/16
ns1.host.uol.com.br internet address = 200.98.199.195 ns2.host.uol.com.br internet address = 200.98.199.196 ns3.host.uol.com.br internet address = 187.17.102.209 [root@torrinha]# whois whservidor.com.br domain: whservidor.com.br owner: Universo Online S.A. ownerid: 001.109.184/0004-38 responsible: Contato da Entidade UOL country: BR owner-c: CAU12 admin-c: CAU12 tech-c: CTU6 billing-c: CCU10 nserver: ns1.host.uol.com.br nsstat: 20111018 AA nslastaa: 20111018 nserver: ns2.host.uol.com.br nsstat: 20111018 AA nslastaa: 20111018 nserver: ns3.host.uol.com.br nsstat: 20111018 AA nslastaa: 20111018 retry = 3600 expire = 604800 minimum = 86400 Authoritative answers can be found from: whservidor.com.br nameserver = ns1.host.uol.com.br. whservidor.com.br nameserver = ns2.host.uol.com.br. whservidor.com.br nameserver = ns3.host.uol.com.br. ns1.host.uol.com.br internet address = 200.98.199.195 ns2.host.uol.com.br internet address = 200.98.199.196 ns3.host.uol.com.br internet address = 187.17.102.209 created: 20071116 #4076310 expires: 20131116 changed: 20100626 status: published nic-hdl-br: CAU12 person: Contato Administrativo - UOL e-mail: l-registrobr-uol@corp.uol.com.br created: 20031202 changed: 20100106 nic-hdl-br: CCU10 person: Contato de Cobranca - UOL e-mail: l-adm-dns@uolinc.com created: 20031202 changed: 20070301 nic-hdl-br: CTU6 person: Contato Tecnico - UOL e-mail: l-adm-dns@uolinc.com created: 20031202 changed: 20070301 Spammers usam aplicações de envio desenvolvidas por terceiros, denominadas empresas parceiras tanto do provedor quanto do spammer, pois são, na maioria dos casos, incapazes de desenvolver as próprias ferramentas. Por questões comerciais de seus produtos, as empresas implementam assinaturas em campos opcionais, tais como: Mailer: ou X-Mailer: seguido do nome do produto, versão, idioma, etc. Exceto OutLook, nenhum MUA insere o X-Mailer. Logo, a simples existência dele sinaliza spam. Vários desses produtos são desenvolvidos para o ambiente Windows, apresentando versões próprias da biblioteca de envio e/ou baseadas na biblioteca MIME do OutLook existente ou forjada. Provedores de Email-Marketing instruem como o spammer deve proceder quanto a conteúdos, modos de envio, aluguel e venda de listas de e-mail. Alegam, inclusive, a existência de uma legislação federal sobre o envio de mensagens, o que ainda não existe (final de 2011) quando se referem a um código de conduta da Associação Brasileira de Email-Marketing. As mensagens enviadas segundo aquelas orientações são em HTML. A inclusão de figuras auxiliam na validação de endereços, ocultar textos normalmente usados em sistemas anti-spam através de figuras e formulários em Javascript. 12/16
conteúdos gráficos e comprometedores são anexados, resultando em conteúdos codificados em base64. Não há qualquer legislação de spam vigente no Brasil. Há, sim, um acordo entre empresas e provedores que exploram email-marketing tentando estabelecer uma política de boas práticas e éticas para não prejudicar o negócio. É antagônico! Spam não é uma boa política e muito menos concede boas práticas. OPT-OUT, OPT-IN E DOUBLE OPT-IN São técnicas de Confirmação e Coleta de Endereços de Correio Eletrônico usados pelo E-mail Marketing. Na técnica Opt-Out, o e-mail do usuário já foi coletado anteriormente por alguma outra estratégia, como por exemplo, e-mail de contato que consta em publicações técnicas, páginas pessoais, cadastros em lojas e hotéis com atendimento pessoal. O usuário é contactado pela empresa de marketing para oferecer seus produtos e serviços. Na oportunidade é inserido um link para uma URL sugerindo a remoção, o que NÃO é acatada em 95% dos casos. Alias, quando acontece, o e-mail que solicitou a remoção é transferido para outra lista de endereços de outros produtos e serviços para novas tentativas. Logo é uma forma de spam contínua. Na técnica Opt-In, conforme a ética de e-mail marketing, o visitante do portal é convidado (em contra partida de alguma informação) a informar o e-mail, ficando sujeito à mensagens de propaganda de serviços e produtos. A página é feita, muitas vezes, para desconsiderar a opção de não receber o futuro lixo eletrônico. A técnica Double-Opt-In é um aprimoramento da Opt-IN. Uma vez que na Opt-In é a presença de qualquer e-mail e que pode ser falsificado, a Double-Opt-IN exige um e-mail real, pois será confirmado através do envio de links dedicados para o acesso àquela informação. A solução para as três estratégias são igualmente simples: Para evitar o Opt-Out jamais informe um e-mail de contato direto. Use um e-mail alias e estipule regras para considerar as mensagens para aquele destino como suspeitas. Quando tiver tempo avalie o conteúdo daquela caixa postal. Para a técnica do Opt-IN não informe um e-mail válido ou informe um spamtrap. Para a técnica de Double-Opt-In ative um e-mail alias temporário, informe-o, consiga a informação desejada que deveria estar disponível pois é de interesse do portal e a desative. É o caso, por exemplo, de especificações técnicas de produtos. É um direito do consumidor e não exige nada em troca, muito menos e-mail. Para seguir uma ética envie uma mensagem para o o portal visitado a partir daquele alias informando que aquele alias será desativado. SPAMTRACKERS Como observado, há infinitas formas de explorar o e-mail marketing. Em todos os casos as estratégias adotadas envolvem grande infraestrutura que se aprimoram a cada dia e o usuário 13/16
sempre termina no prejuízo. Todas elas giram num único elemento que, até então, é tido como verdadeiro : O EMAIL DO DESTINATÁRIO. Alguns portais chegam a exigir o e-mail como moeda para passar a informação. Por ética, sempre há uma opção para receber anúncios de serviços, produtos e novidades técnicas, como se aquela informação custasse a caixa postal cheia de mensagens. Se o e-mail do destinatário for falso as listas de endereços perderão o valor comercial. A condição piora ainda mais quando os falsos e-mails são armadilhas (spamtraps). A ação de combate é denominado de spamtracking. O processo não tem efeito imediato, mas tem efeito a médio e longo prazo. Se para cada e- mail disponibilizado na rede for também disponibilizado pelo menos um spamtrap então os alarmes de spam podem acionar em cada recebimento e aquele IP comporá listas-negras locais, o que ajudará a colocar mensagens vindas daqueles endereços sob suspeita, em quarentena ou mesmo removidas. Se não existem regras para spam também não existem regras para o anti-spam. Se as regras de spam citam que deve ter uma opção para opt-in então o e-mail fornecido deve ser configurado para aceitar aquela origem e ser um spamtrap para outras origens. Se o e-mail exclusivo foi violado então aquela origem foi a responsável pela transferência não autorizada e, portanto, também ele vira um spamtrap. Se os coletores são automatizados então o fornecimento de e-mails spamtraps pode assumir alguma automatização. Normalmente, as empresas de coletas possuem equipes que visitam sítios diversos em busca de páginas com e-mails. As visitas são individuais, usam de navegadores normais e a partir de redes quaisquer. As URLs das páginas visitadas de interesse são gravadas em bookmarks e restauradas posteriormente por robôs cibernéticos que varrem os locais em busca de endereços. O robô não sabe se a página recebida é a mesma que a página que foi lida pelo inspetor humano. Então ele acreditará e catalogará os e-mails ali existentes. Se o domínio do e-mail é verdadeiro não se pode dizer o mesmo para a parte do usuário. Logo, a etapa seguinte é a verificação dos endereços coletados. É aí que inicia o spamtracking. Páginas pessoais e institucionais são as principais fontes de busca. O uso de formulários para contato é recomendado quando o Agente Navegador do usuário (User-Agent) fornecer o sistema operacional, o tipo de navegador, versão, compatibilidade etc. Tais informações são inseridas na página através de javascript ou nas URLs com a ajuda de PhP ou ASP, em tempo de atendimento da requisição. Caso não sejam forneça página alternativa, contendo várias tags MAILTO explícitas com os spamtraps. A técnica pode ser ainda melhorada inserindo spamtraps dinâmicos. A primeira mensagem recebida para um spamtrap deve ser mantida em quarentena e a origem (domínio e IP) registrados e inserido na lista negra, marcado para ter a mensagem suspensa e aplicada para todo o domínio (nome) e bloco IP. Recomenda-se investigação posterior quanto ao responsável pelo bloco de origem via serviço whois. Os MTAs disponíveis (freeware, GPL, etc) não contemplam recursos de spamtracker. Contudo, os MTAs GPLs disponibilizam os códigos fontes (Qmail, Postfix, Sendmail, Vmail, etc) e permitem extensões. 14/16
O algoritmo de um spamtracking consiste na coleta dos endereços IPs e domínios dos sistemas que estão permitindo o envio e que apresentam o spamtrap como endereço de destino, ou seja, estabelece-se um filtro de busca dos spamtraps nos arquivos de log e coletam-se os endereços IPs e nomes de domínios que estão operando como relays. Tais domínios são coniventes com o envio, mesmo que os sistemas sejam zumbies. SMTP SPOOFING SMTP SPOOFING é uma forma de ataque com o objetivo de exaurir os recursos do computador que executa um serviço de SMTP (ou MTA - Mail Transfer Agent) acessível pelo atacante. O ataque SMTP SPOOFING pode resultar em negação de serviço (DoS - Deny of Service) mesmo que a aplicação controle o número de conexões para evitar a exaustão de memória. Alguns MTAs implementam, além do controle de conexões, o recurso de contabilizar o número de conexões requisitadas por um único IP num certo intervalo de tempo. Porém, o que se tem observado, é que os ataques partem de um grande número de nós (vários IPs) o que exige, além do controle de conexões e controle de origem, a monitoração da taxa de variação do número de conexões independentemente da origem e o disparo de medidas preventivas onde se analisa o progresso das sessões SMTP. Tal estratégia de ataque fragiliza o MTA mesmo que não resulte em vulnerabilidade assim como as conexões com as mensagens importantes. O procedimento de ataque consiste em estabelecer a conexão, iniciar a sessão de HELO (ou EHLO) e entrar em hibernação. Após o período ocorre a continuidade daquela sessão e nova hibernação. Enquanto isso várias outras origens iniciam novas sessões, culminando com período em tempo da sessão DATA. Uma vez naquela sessão, o atacante sabe que o limite da linha de dados é de mil octetos. É hora de tentar, além do spoofing, um buffer-overflow e a exaustão de memória. Observando os cenários de ataque observa-se que: o atacante considera um único sistema MX para entrada e saída de mensagens. Neste cenário, o spoofing resulta num DoS de isolamento completo daquele sistema, ou seja, impede o recebimento e o envio de mensagens. as hibernações devem ocorrer para que o número de máquinas comprometidas e participantes do ataque seja suficiente. O ataque pode ocorrer de forma isolada ou combinado com spoofing de DNS, via requisições contínuas de MX. A Defesa deve ser preparada observando o cenário do ataque: Se há um único sistema MX então que seja inserido um segundo MX com prioridade menor, ou seja com índice de prioridade da cláusula maior MX do DNS. O tempo de vida da informação para o menor tempo possível. Se o ataque é por IP, a defesa é mais simples. Basta mudar o endereço IP do sistema MX para outro e estabelecer o bloqueio para o IP anterior em filtro de pacotes da entrada da rede. 15/16
Por precaução, é desejável que os sistemas MX de envio e resposta operem em nós distintos e as caixas postais efetivas dos usuário sejam alocadas num terceiro nó. Sob ataque, a primeira ação é reduzir os tempos de latência da sessão SMTP e de cada estado. Conforme as RFCs, o período de timeout do estado HELO é de 5 minutos. Sob ataque o período deve ser reduzido para 5 segundos. Uma vez feito, o MTA inicia o registro de LOG de encerramento de sessão por timeout. É hora da captura dos endereços em intervalos naquele intervalo. Os sistemas normais entrarão em estado de espera pelo período padrão (5 minutos), mas os elementos sob ataque continuarão com a missão de spoofing, o que gerará repetições. Uma contagem do número de IPs repetidos no período de 15 segundos constantes no arquivo de log, por exemplo, fornecerá os endereços IPs suspeitos de participação de ataque. É hora de estabelecer o bloqueio local daqueles IPs. Embora possa ocorrer falsos-positivos, será possível manter o sistema MX operando. Não há ferramentas prontas para uso disponíveis para isso. É necessário um trabalho just-in-time e específico para o sistema. Nos tempo da brilhantina da Internet, os ataques eram minimizados pelo efeito de baixo desempenho das redes e do espírito de colaboração entre os administradores. Hoje as redes apresentam-se com grandes velocidades e o individualismo é predominante. 16/16