Poodle PoC 🐩 🐩 🐩

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.

1. 🐩 Conceito do ataque 🐩

SSLv3 e o modo de cifra CBC

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.

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.

Influenciar o padding

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.

HMAC

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.

MAC-then-encrypt

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 :)

2. 🔑 Criptografia 🔑

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.

• Ele salva o comprimento do texto cifrado original
• Ele adiciona um byte no caminho e verifica o comprimento.
  • Se o comprimento não mudar, ele adiciona outro byte, etc.
  • Senão : o comprimento do texto cifrado da requisição muda, ele sabe que o último bloco está cheio de padding.

Como o último bloco, exceto o último byte, está cheio de bytes aleatórios, ele pode substituir este último bloco C_n pelo bloco que deseja descriptografar, C_i. A requisição alterada é enviada ao servidor.

O servidor :

• remove o padding com base no comprimento do último byte
• obtém o hmac da requisição = HMAC
• obtém o texto simples
• compara hmac(texto simples) e HMAC
  • se for igual => bom padding
  • senão => mau padding

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 C_i seguindo esta operação :

P_n = D_k(C_n) ⊕ C_n-1
P_n = D_k(C_i) ⊕ C_n-1
P_n = D_k(C_i) ⊕ C_n-1
xxxxxxx7 = D_k(C_i) ⊕ C_n-1
D_k(C_i) = xxxxxxx7 ⊕ C_n-1
P_i ⊕ C_i-1 = xxxxxxx7 ⊕ C_n-1
P_i = C_i-1 ⊕ xxxxxxx7 ⊕ C_n-1

(xxxxxxx7 ou xxxxxxx15 e x é um byte aleatório)

O último byte do bloco pode ser recuperado: P_i[7] = C_i-1[7] ⊕ xxxxxxx7 ⊕ C_n-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 :

Sobre o TLS1.0

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.

3. 💥 Iniciar o ataque 💥

Há três arquivos neste repositório:

• poodle-poc.py -> Uma Prova de Conceito que não requer nenhum pré-requisito
• parallelization-poodle.py -> Outra Prova de Conceito, mas usando paralelização (realmente rápida)
• poodle-exploit.py -> Um exploit para cenários do mundo real

1. O arquivo poodle-poc.py

Esta 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

2. O arquivo poodle-poc.py

O arquivo parallelization-poodle.py é um projeto, e uma ideia :) veja https://github.com/mpgn/poodle-PoC/issues/1

python3 parallelization-poodle.py

3. O arquivo poodle-exploit.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, se ele usar servidor e navegador antigos. Basta colocar o IP do seu proxy malicioso na configuração do navegador com a porta correta; o proxy cuidará do resto.

Requisitos:

• certifique-se de que o cliente e o navegador podem se comunicar com o protocolo SSLv3 apenas, force apenas SSLv3 no firefox usando security.tls.version.min: 0, por exemplo. Alternativamente, se o cliente também usar TLS, você pode forçar o downgrade
• certifique-se de que o servidor é vulnerável, use a ferramenta testssl.sh
• certifique-se de que você pode injetar Javascript no lado do cliente (XSS)
• certifique-se de que você pode interceptar a conexão entre o cliente e o servidor

💀 Se você tiver esses pré-requisitos, pode iniciar o ataque 💀:

Duas opções estão disponíveis para este exploit:

1. Configurar o endereço IP e a porta do proxy diretamente no lado do cliente e executar o exploit (vá para a parte 3)
2. Configurar um ataque de ARP spoofing para redirecionar todo o tráfego entre o cliente e o servidor para sua máquina

• Habilite o encaminhamento e defina uma regra de Iptable para redirecionar o tráfego do cliente para seu proxy

$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337

• Use a ferramenta arpspoof, ettercap ou bettercap para executar um ataque de ARP spoofing

$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on

3. Execute o proxy

⋊> ~/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 of the proxy
  port                  port of the proxy
  server                ip of the remote server
  rport                 port of the remote server

optional arguments:
  -h, --help            show this help message and exit
  --start-block START_BLOCK
                        start the attack at this block
  --stop-block STOP_BLOCK
                        stop the attack at this block
  --simpleProxy SIMPLEPROXY
                        Direct proxy, no ARP spoofing attack

$> 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. Eu 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. Execute 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 o downgrade para SSLv3.0.

Como funciona? durante o handshake (após o hello client), o exploit envia um handshake_failure 15030000020228; em seguida, 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), veja #4

Vídeo completo da exploração:

Asciinema:

Contribuidor

mpgn

Licença

licença MIT

Referências

• https://en.wikipedia.org/wiki/POODLE
• https://www.openssl.org/~bodo/ssl-poodle.pdf