mpgn/poodle-poc🐩 Ataque Poodle (Padding Oracle On Downgraded Legacy Encryption) CVE-2014-3566 🐩
Uma prova de conceito do Ataque Poodle (Padding Oracle On Downgraded Legacy Encryption) :
um exploit de man-in-the-middle que tira proveito do fallback de clientes de software de Internet e segurança para o SSL 3.0
O ataque Poodle permite recuperar dados criptografados enviados por um cliente a um servidor se a segurança da camada de transporte (Transport Layer Security) usada for SSLv3. Ele não permite recuperar a chave privada usada para criptografar a requisição.
O SSLv3 é um protocolo para criptografar/descriptografar e proteger seus dados. No nosso caso, ele usa o modo de cifra CBC com encadeamento . O texto simples é dividido em blocos de acordo com o algoritmo de criptografia (AES, DES, 3DES) e o comprimento é um múltiplo de 8 ou 16. Se o texto simples não preencher o comprimento, um padding é adicionado ao final para completar o espaço faltante. Eu recomendo fortemente que você abra essas imagens de criptografia e descriptografia para ler este readme.
| Criptografia | Descriptografia |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
Basicamente, isso é apenas um XOR simples; você também pode assistir a este vídeo (não sou eu) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Uma requisição enviada via HTTPS usando SSLv3 será cifrada com AES/DES e o modo CBC. A particularidade do SSLv3 em relação ao TLS1.x é o padding. No SSLv3, o padding é preenchido com bytes aleatórios, exceto o último byte, que é igual ao comprimento do padding.
Exemplo:
T|E|X|T|0xab|0x10|0x02 onde 0xab|0x10|0x02 é o padding.
T|E|X|T|E|0x5c|0x01 onde 0x5c|0x01 é o padding.
Além disso, o último bloco pode ser preenchido com um bloco inteiro de padding, ou seja, o último bloco pode ser preenchido com bytes aleatórios, exceto o último byte.
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 onde |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 é o padding e apenas o 0x07 é conhecido pelo atacante. Portanto, se um atacante conseguir influenciar o bloco de padding, ele poderá saber que o último byte do último bloco é igual ao comprimento de um bloco.
Um atacante deve ser capaz de fazer a vítima enviar requisições (usando javascript ao explorar um XSS, por exemplo). Então ele pode controlar o caminho e os dados de cada requisição:
Exemplo: adicionar um byte "A" ao caminho da requisição
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
Com essa técnica, ele pode influenciar o padding.
O SSLv3 também usa HMAC para verificar a integridade e autenticar o texto simples.
código de autenticação de mensagem baseado em hash (HMAC) é um tipo específico de código de autenticação de mensagem (MAC) que envolve uma função hash criptográfica (daí o 'H') em combinação com uma chave criptográfica secreta
Com isso, um atacante não pode interceptar e alterar a requisição e depois enviá-la de volta. Se o servidor encontrar um problema, ele enviará um erro de HMAC.
O protocolo SSLv3 usa a seguinte rotina: ele recebe os dados do cliente, descriptografa os dados e verifica a integridade com o HMAC.
MAC-then-Encrypt: Não fornece nenhuma integridade ao texto cifrado, pois não temos como saber, até descriptografarmos a mensagem, se ela era de fato autêntica ou forjada. Integridade do texto simples. Se o esquema de cifra for maleável, pode ser possível alterar a mensagem para que pareça válida e tenha um MAC válido. Isso é um ponto teórico, claro, pois na prática o segredo do MAC > deve fornecer proteção. Aqui, o MAC também não pode fornecer informações sobre o texto simples, pois ele é criptografado.
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
Isso significa que podemos alterar o texto cifrado sem que o servidor saiba. Isso é ótimo, de verdade :)
Primeiro, o último bloco precisa estar cheio de padding. Como vimos anteriormente, o atacante usa o caminho da requisição e verifica o comprimento da requisição.
Como o último bloco, exceto o último byte, está cheio de bytes aleatórios, ele pode substituir este último bloco Cn pelo bloco que deseja descriptografar, Ci. A requisição alterada é enviada ao servidor.
O servidor :
Ao substituir o último bloco, o atacante também altera o último byte do último bloco (o comprimento do padding). Há uma probabilidade de 1/256 de o último byte substituído no bloco de padding ser o mesmo que o original; nesse caso, não haverá erro de padding e o atacante poderá usar essa operação XOR para recuperar o último byte do bloco Ci seguindo esta operação :
Pn = Dk(Cn) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
xxxxxxx7 = Dk(Ci) ⊕ Cn-1
Dk(Ci) = xxxxxxx7 ⊕ Cn-1
Pi ⊕ Ci-1 = xxxxxxx7 ⊕ Cn-1
Pi = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1
(xxxxxxx7 ou xxxxxxx15 e x é um byte aleatório)
O último byte do bloco pode ser recuperado: Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] Em caso de padding, o atacante precisa fechar a sessão SSL para fazer outro handshake (nova chave AES) e obter um novo texto cifrado, depois substituir o último bloco, etc. (geralmente são necessários +300 handshakes)
Uma vez que um byte é recuperado, ele obterá todos os outros bytes do bloco adicionando um byte no caminho e removendo um byte dos dados :
| Requisição para recuperar o byte E,I,K,O |
|---|
| GET /a SECRET_COOKIE dataazerty PADDING_7 |
| GET /aa SECRET_COOKIE dataazert PADDING_7 |
| GET /aaa SECRET_COOKIE dataazer PADDING_7 |
| GET /aaaa SECRET_COOKIE dataaze PADDING_7 |
Embora as especificações do TLS exijam que os servidores verifiquem o padding, algumas implementações não o validam corretamente, o que torna alguns servidores vulneráveis ao POODLE mesmo se eles desabilitarem o SSL 3.0
O TLS normalmente é seguro contra o Poodle, mas algumas implementações não verificam o padding; é como se usássemos SSLv3, é por isso que algumas versões do TLS são vulneráveis.