• Vulnerabilidades no STARTTLS

    Vulnerabilidades na implementação do protocolo STARTTLS, para estabelecer uma conexão criptografada TLS, podem permitir que comandos sejam injetados em uma conexão. De acordo com a descrição feita pelo descobridor da vulnerabilidade, o desenvolvedor de Postfix Wietse Venema, a raiz do problema acontece em uma injeção de comandos antes que a mesma torne-se segura e encriptada, mas é apenas executada uma vez que a conexão tenha sido estabelecida.

    Venema ilustra o problema com um exemplo, envolvendo um protocolo SMTP seguro com TLS. Um cliente envia através do comando STARTTLS\r\n; utilizando um ataque man-in-the-middle, um invasor mal intencionado modifica este comando para STARTTLS\r\nRSET\r\n. O cliente e servidor então iniciam uma conexão TLS. O servidor agora é favorecido com o comando RSET injetado, que foi adicionado durante a fase desprotegida, como se ele tivesse transferindo subsequentemente para a conexão TLS estabelecida. O comando RSET neste exemplo é relativamente inócuo, como se este comando restabelecesse um protocolo inofensivo, mas outros comandos podem ser injetados da mesma maneira.

    Ainda de acordo com Venema, comandos injetados podem ser utilizados para leitura de e-mail ou para descobrir nomes de usuários e as respectivas senhas. Este princípio trabalha para todos os protocolos que utilizam TLS e que a conexão alterna a partir de uma conexão insegura para uma conexão segura. (Exemplos POP3,IMAP,NMTP e FTP). é válido lembrar que nem todas as implementações de STARTTLS são vulneráveis. Conforme uma lista da US-CERT, os produtos IPswitch, Kerio,Postfix,Qmail,Sun e SCO são infectados pela falha. A situação não é clara para muitos fabricantes e produtos. Para Postfix, o problema é corrigido nas versões 2.7.3, 2.6.9, 2.5.12 e 2.4.16.

    Venema ressalta que muitas implementações são vulneráveis ao ataque man-in-the-middle de qualquer forma; isto porque, apesar de se estabelecer uma conexão segura, a validade dos servidores e certificados não é estabelecida ou insuficientemente verificada.


    Saiba Mais:

    [1] US-CERT: http://www.kb.cert.org/vuls/id/555316
    [2] Heise On-line: http://www.h-online.com/security/new...s-1203760.html