Ataque POODLE – Quebrando o TLS com SSL 3

Por: Andre “Dexter” Bereza / Conrado Gouvêa

O protocolo SSL e seu sucessor TLS protegem grande parte das comunicações seguras através da internet. Em 14 de outubro de 2014, pesquisadores do Google divulgaram uma vulnerabilidade na versão 3.0 do SSL que permite a execução de um ataque denominado POODLE.

O Ataque

O ataque tem o nome de Padding Oracle On Downgraded Legacy Encryption, ou apenas POODLE. O ataque permite o roubo de cookies em conexões HTTPS, o que permite um atacante logar em sites como se fosse a vítima.

O POODLE se aplica somente no protocolo SSL 3.0, que foi lançado em 1996. O SSL 3.0 já se tornou obsoleto quando o TLS 1.0 foi lançado em 1999, e o protocolo mais novo é o TLS 1.2 (2008). Existe também um draft para o TLS 1.3 (possivelmente será lançado em 2015). O SSL 3.0 utiliza criptografia RC4 (cifrador de fluxo) ou criptografia com cifrador de bloco no modo CBC. O RC4 possui fragilidades conhecidas que resultaram em ataques práticos no ano passado. O modo CBC, como usado no SSL 3.0, já era problemático e resultou em ataques em 2013. O POODLE explora outra falha no CBC como usado no SSL 3.0, porém é um ataque mais fácil de se executar do que os anteriores. Além disso, ao contrário dos ataques anteriores, o POODLE é uma falha no protocolo em si e não na sua implementação, portanto o SSL 3.0 pode ser considerado quebrado. O problema é que vários sistemas legados utilizam esse protocolo, então simplesmente desabilitá-lo é complicado.

Os protocolos SSL/TLS possuem um mecanismo de negociação de versão, permitindo que um servidor suporte tanto SSL 3.0 quanto TLS 1.2. Desta forma, em tese, seria possível usar SSL 3.0 somente com os clientes que necessitam dele. Contudo, muitos servidores possuem falhas de implementação e que impedem o correto funcionamento do mecanismo de negociação de versão, especialmente servidores antigos com conexões de clientes modernos. Desta forma, muitos clientes foram modificados de forma que, ao falhar na comunicação com TLS 1.2, eles automaticamente tentam novamente usando SSL 3.0.

O problema desta abordagem é que um man-in-the-middle (um atacante que esteja intermediando a conexão entre cliente e servidor) pode intencionalmente bloquear a primeira conexão TLS 1.2, forçando o cliente a tentar novamente usando SSL 3.0. Assim, um atacante pode forçar o uso de SSL 3.0 mesmo quando TLS 1.2 deveria ser suportado. Esse ataque, já conhecido antes, tem o nome de “downgrade attack”.

Solução

É importante notar que o SSL 3.0 pode ser considerado quebrado. Então o ideal é não usá-lo mais.

Se mesmo assim for necessário suportar SSL 3.0 na comunicação do cliente com servidores antigos, então pode-se proteger de “downgrade attacks” utilizando o SCSV (Signaling Cipher Suite Value) no cliente.

Digamos que um cliente possui várias versões de protocolo até TLS 1.2 e possui o SCSV implementado. Quando esse cliente tenta conectar com uma versão antiga do protocolo, envia uma mensagem do tipo:

“Estou me comunicando com você com SSL 3.0, mas na verdade eu suporto SSL 3.0, TLS 1.0, TLS 1.1 e TLS 1.2”

Se o servidor for antigo (SSL 3.0), ele aceita a conexão SSL 3.0 normalmente. Se o servidor for novo (TLS 1.2) mas não suportar SCSV, ele aceita a conexão SSL 3.0, mas isso pode estar acontecendo devido a um “downgrade attack”. Se o servidor for novo (TLS 1.2) E suportar SCSV, então ele sabe que o cliente foi forçado a fazer um downgrade por um atacante, e então irá bloquear a comunicação indicando que ocorreu um erro fatal.

Nos exemplos acima citamos TLS 1.2, mas poderia ser qualquer versão de protocolo superior a SSL 3.0. A recomendação é a utilização do protocolo TLS 1.2, por ser o mais novo e possuir mecanismos de proteção mais avançados.

Notem que o man-in-the-middle não pode suprimir o SCSV. O adversário pode bloquear a comunicação, mas ele não pode modificar o conteúdo das mensagens. Portanto o SCSV irá junto da mensagem, ou a mensagem jamais chegará do outro lado.

O problema dessa solução é em sistemas que só suportam SSL 3.0 ou sistemas que não possuem o SCSV implementado (ou não tem interesse em implementar). Nesses casos não existe milagre, não existe solução para o problema e os sistemas estarão vulneráveis.

Resumo

Como desenvolvedores:
– Não usar SSL 3.0
– Em clientes TLS, suportar SCSV.
– Em servidores TLS, suportar SCSV.

No OpenSSL foi adicionado suporte ao SCSV nas versões 1.0.1j, 1.0.0o e 0.9.8zc.

Como usuários:
– Esperar programas desativarem SSL 3.0, ou desativar manualmente (ver [5])

https://www.openssl.org/~bodo/ssl-poodle.pdf
https://securityblog.redhat.com/2014/10/15/poodle-a-ssl3-vulnerability-cve-2014-3566/
http://crypto.stackexchange.com/questions/19673/how-does-tls-fallback-scsv-help
https://security.stackexchange.com/questions/70719/ssl3-poodle-vulnerability
https://poodle.io/browsers.html