mpgn/poodle-poc🐩 Ataque Poodle (Oracle de Preenchimento em Criptografia Legada Rebaixada) CVE-2014-3566 🐩
Uma prova de conceito do Ataque Poodle (Padding Oracle On Downgraded Legacy Encryption) :
um exploit de homem-no-meio que tira vantagem da queda de clientes de software de Internet e segurança para SSL 3.0
O ataque Poodle permite recuperar dados criptografados enviados por um cliente para um servidor se a camada de segurança de transporte usada for SSLv3. Ele não permite recuperar a chave privada usada para criptografar a requisição.
SSLv3 é um protocolo para criptografar/descriptografar e proteger seus dados. No nosso caso, ele usa o encadeamento de modo de cifra CBC. O texto plano é 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 plano não preencher o comprimento, um padding é adicionado ao final para completar o espaço faltante. Recomendo fortemente que você abra estas imagens de criptografia e descriptografia para ler este readme.
| Criptografia | Descriptografia |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), e C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, e C0 = IV |
Basicamente isso é apenas um XOR simples, você também pode assistir 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, significando que o último bloco pode ser completamente 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. Então, 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, por exemplo, explorando um XSS). Então ele pode controlar o caminho e os dados de cada requisição:
Exemplo: adicionar o 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 esta técnica, ele pode influenciar o padding.
SSLv3 também usa HMAC para verificar a integridade e autenticar o texto plano.
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 reenviá-la. 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, verifica a integridade com o HMAC.
MAC-then-Encrypt: Não fornece nenhuma integridade ao texto cifrado, pois não temos como saber até descriptografar a mensagem se ela é realmente autêntica ou falsificada. Integridade do texto plano. Se o esquema de cifra for maleável, pode ser possível alterar a mensagem para parecer válida e ter um MAC válido. Isso é um ponto teórico, claro, já que na prática o segredo do MAC deve fornecer proteção. Aqui, o MAC também não pode fornecer nenhuma informação sobre o texto plano, pois está 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. É ótimo, realmente :)
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 ele quer 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á 1/256 de chance do último byte substituído no bloco de padding ser igual ao original; neste caso, não haverá erro de padding e o atacante pode usar esta 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 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 cifrado, então substituir o último bloco novamente, etc. (geralmente +300 handshakes necessários)
Uma vez que um byte é recuperado, ele obterá todos os outros bytes do bloco adicionando um byte no caminho e removendo um byte nos dados:
| Requisição para recuperar 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 |
Mesmo que as especificações 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 que desabilitem o SSL 3.0
O TLS normalmente é seguro contra Poodle, mas algumas implementações não verificam o padding; é como se estivéssemos usando SSLv3. É por isso que algumas versões do TLS são vulneráveis.
Há três arquivos neste repositório:
Este PoC explora a criptografia por trás do ataque. Este arquivo nos permite entender como o ataque funciona de forma simples.
python3 poodle-poc.py
O arquivo parallelization-poodle.py é um projeto e uma ideia :) confira https://github.com/mpgn/poodle-PoC/issues/1
python3 parallelization-poodle.py
Este é o exploit real. Muito útil se você quiser fazer uma prova de conceito sobre o Ataque Poodle para um cliente durante um pentest, caso ele use servidores e navegadores antigos. Basta colocar o IP do seu proxy malicioso na configuração do navegador com a porta correta; o proxy cuidará do resto.
Requisitos:
security.tls.version.min: 0, por exemplo. Alternativamente, se o cliente também usar TLS, você pode forçar o downgrade.
💀 Se você tiver esses pré-requisitos, pode iniciar o ataque 💀:
Duas opções estão disponíveis para este exploit:
$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337
arpspoof, ettercap ou bettercap para executar um ataque de ARP spoofing$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on
⋊> ~/T/poodle-Poc on master ⨯ python3 poodle-exploit.py -h 13:10:24
usage: poodle-exploit.py [-h] [--start-block START_BLOCK]
[--stop-block STOP_BLOCK] [--simpleProxy SIMPLEPROXY]
proxy port server rport
Poodle Exploit by @mpgn_x64
positional arguments:
proxy ip do proxy
port porta do proxy
server ip do servidor remoto
rport porta do servidor remoto
optional arguments:
-h, --help mostra esta mensagem de ajuda e sai
--start-block START_BLOCK
inicia o ataque neste bloco
--stop-block STOP_BLOCK
para o ataque neste bloco
--simpleProxy SIMPLEPROXY
Proxy direto, sem ataque de ARP spoofing
$> python3 poodle-exploit.py 192.168.13.1 4443 192.168.13.133 443 --start-block 46 --stop-block 50
Escolhendo um bloco: se você não especificar a opção de bloco, todos os blocos serão descriptografados, mas isso pode levar muito tempo. Recomendo fortemente que você 'saiba' como a requisição será formatada e use o script request-splitter.py para saber qual bloco deseja descriptografar (idealmente o bloco do cookie!).
Em seguida, insira o código JavaScript malicioso (poodle.js) no site vulnerável usando um XSS, por exemplo. Inicie o script Python e digite help, depois search, e finalmente active. Durante esse tempo, apenas duas interações com o JavaScript serão necessárias (comandos search e active).
Atualização 01/04/2018: a opção de downgrade foi adicionada ao exploit. Quando o exploit detectar o protocolo TLS, digite o comando downgrade para fazer downgrade para SSLv3.0.
Como funciona? Durante o handshake (após o hello client), o exploit envia um handshake_failure 15030000020228; então o navegador deve reenviar um hello client com SSLv3.0 como protocolo padrão. Testado no Chrome versão 15, mas não funciona no Firefox (acho que ele não suporta renegociação de protocolo), confira #4
Vídeo completo da exploração:
Asciinema:
