Quão seguro é navegar na WEB e realizar as atividades cotidianas que conhecemos? Embora reconheçamos que alcançar 100% de garantia com as tecnologias e os protocolos disponíveis seja algo muito difícil, ao menos podemos ter o conforto de saber que será algo bem improvável, ser vítima de ações criminosas no mundo digital. O que não quer dizer necessariamente que devemos relaxar quanto as nossas ações e por isso, adotar medidas de segurança mais restritivas sempre que possível…
“When you visit an HTTPS-protected website, your browser doesn’t exchange data with the webserver until it has ensured that the site’s digital certificate is valid. That prevents hackers with the ability to monitor or modify data passing between you and the site from obtaining authentication cookies or executing malicious code on the visiting device. But what would happen if a man-in-the-middle attacker could confuse the browser into accidentally connecting to an email server or FTP server that uses a certificate that’s compatible with the one used by the website?”
— by Ars Technica.
A Ars Technica publicou um artigo bem interessante, no qual ela discute os problemas de segurança em relação ao uso de diferentes protocolos com suporte para a certificação digital (como o HTTPS), para acessar servidores de e-mail, através da possibilidade de um cookie de autenticação descriptografado ser enviado para um invasor. Isto pode ocorrer devido a uma falha do TLS em proteger a integridade da própria conexão TCP. Neste cenário, o invasor tiriaria proveito desta vulnerabilidade, para executar um ataque do tipo MITM (man-in-the-middle), no qual o tráfego TLS seria redirecionado para outro destinatário, que por sua vez utilizaria um serviço diferente para interpretar estas informações (FTP, IMAP/POP3/SMTP), já que não há como proteger informações como o endereço IP e o número da porta de aplicação.
Batizado de ALPACA (Application Layer Protocol Confusion-Analyzing and Mitigating Cracks in TLS Authentication), os principais elementos envolvidos neste tipo de ataque são: um aplicativo cliente utilizado pelo usuário, o servidor de e-mails com suporte a conexões HTTPS e o servidor do atacante, o qual suporta protocolos como os acima citados, além do mesmo domínio listado em seu certificado TLS. A partir daí, o atacante pode se valer de diferentes métodos para executar o ataque, onde um deles (upload) se vale da utilização de informações provenientes de cookies, ao passo que outros (download e reflection) se valem da execução de scripts maliciosos na máquina do usuário (Cross-site scripting ou XSS).
Para evitar este tipo de ataque, os pesquisadores propõem uma aplicação mais rígida de proteções já existentes. Uma delas é a negociação de protocolo da camada de aplicativo (ALPN), uma extensão TLS que permite a um protocolo da camada de aplicação negociar qual protocolo deve ser usado em uma conexão segura, sem envolver o estabelecimento de conexões adicionais. A outra proteção se baseia na utilização de uma extensão TLS separada chamada Server Name Indication (SNI), a qual permite o servidor apresentar múltiplos certificados digitais sob o mesmo endereço IP e porta de aplicação e assim, pode proteger contra ataques de nome de host cruzado se estiver configurado para encerrar a conexão quando nenhum host correspondente for encontrado.
Que confusão, não? Literalmente, em todos os sentidos! &;-D