mpgn/beast-poc💪 Prova de Conceito do ataque BEAST contra SSL/TLS CVE-2011-3389 💪
Esta prova de conceito é focada na criptografia por trás do ataque BEAST (Browser Exploit Against SSL/TLS) apresentado por Thai Duong e Juliano Rizzo em 23 de setembro de 2011. Isto é um ataque de texto simples escolhido e permite recuperar informações sensíveis se a Segurança da Camada de Transporte usada for TLS1.0 ou SSLv3. A prova de conceito original pode ser encontrada aqui: Here come the Ninjas
Nota: Esta é também uma implementação da vulnerabilidade originalmente descoberta por Phillip Rogaway. Descoberta em 2002, nenhum exploit foi lançado até o BEAST em 2011. A OpenSSL já conhecia o problema e foi por isso que eles atualizaram o TLS1.0 para TLS1.1 em abril de 2006.
2 O IV do CBC para cada registro, exceto o primeiro, é o último bloco de texto cifrado do registro anterior. Assim, a criptografia não é segura contra adversários que podem escolher textos simples de forma adaptativa;
SSLv3/TLS1.0 são protocolos para criptografar/descriptografar e proteger seus dados. No nosso caso, ambos usam 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 é adicionado ao final para completar o espaço faltante. Eu recomendo fortemente que você abra estas imagens de e 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 a este vídeo (não eu) https://www.youtube.com/watch?v=0D7OwYp6ZEc.
Vou apresentar o IV no próximo ponto. Lembre-se de que todas essas propriedades nos ajudarão a conduzir nosso ataque.
Quando usamos o CBC, precisamos de um vetor de inicialização chamado IV. Este IV é aleatório (ou fixo), mas em qualquer caso não deve ser previsível por ninguém. No TLS1.0 e SSLv3, o primeiro IV da requisição é aleatório, tudo bem. Mas para ganhar tempo e não gerar um novo IV aleatório toda vez, a implementação do TLS1.0 e SSLv3 usou o último bloco do texto cifrado anterior como IV. Em outras palavras, o IV agora é adivinhável. Vamos assumir que o comprimento de cada bloco será 8 (DES) e que o atacante tem um MiTM para recuperar todo o texto cifrado.
Exemplo:
C0 | C... | Ci-1 | Ci | Ci+1 |Cn
Agora a parte interessante; estes são os diferentes passos criptográficos do ataque para recuperar um byte:
bbbbbbbTHIS_IS_A_SECRET_COOKIE através da vítima.Você pode notar os sete b antes do cookie secreto. Se o comprimento de um bloco é 8, precisamos inserir 7 bytes conhecidos. Essa informação é muito importante: o atacante conhece os 7 primeiros bytes do primeiro bloco.
Mas por quê? Isso nos permite ter apenas 256 possibilidades para encontrar um byte, e não 256^8 para encontrar 8 bytes!
Agora a vítima envia a requisição e ela será criptografada assim:
C0 | C1 | C2 | C3 | C4
Onde C0 = Ek(IV ⊕ bbbbbbbT) = Ek(C²n ⊕ bbbbbbbT)
P'0 = C²n ⊕ C4 ⊕ bbbbbbbX
O único elemento desconhecido é X; há 256 possibilidades, então ele tentará no máximo 256 caracteres.
A requisição é enviada e criptografada assim:
C'0 = Ek(P'0 ⊕ IV')
C'0 = Ek(C²n ⊕ C4 ⊕ bbbbbbbX ⊕ IV') ou C4 ⊕ IV' = 0
C'0 = Ek(C²n ⊕ bbbbbbbX)
C'0 = Ek(IV ⊕ bbbbbbbX)
Agora ele compara C'0 e C0; se forem iguais, ele acabou de encontrar o byte X na posição 8. Se não corresponder, ele tenta novamente com outro caractere e compara de novo, etc.
Agora que temos um byte, podemos obter outro deslocando a requisição anterior em um para a esquerda: bbbbbbTHIS_IS_A_SECRET_COOKIE. Ele agora tem seis b e também sabemos o T, então temos um caractere desconhecido. Construímos um novo P'0 = C0 ⊕ C4 ⊕ bbbbbbTX etc...
Nota: outra maneira com apenas duas requisições é definir o primeiro bloco do texto simples e usar essa informação para os três XOR. Não precisamos mais do último bloco C². C1 = Ek(C0 ⊕ bbbbbbbT) e então P'0 = C0 ⊕ C4 ⊕ bbbbbbbX. Ele também precisa comparar C'0 e C1. Esta é outra maneira de fazer isso; você pode notar que no PoC eu codifiquei as duas possibilidades :)
Agora podemos recuperar todos os caracteres!
python BEAST-poc.py
Um atacante não pode usar o protocolo HTTP porque o primeiro bloco será preenchido com GET / HTTP/1.1\r\n.
... não pode controlar os primeiros bytes de cada requisição porque eles são sempre definidos como uma string fixa, como GET /, POST /, etc. Em vez disso, ele pode usar socket.
Ele também precisa injetar um pouco de javascript em uma página maliciosa. A vítima precisa estar conectada a essa página e permanecer nela até que o ataque seja concluído. Este é um ataque de texto simples escolhido, então o atacante pode enviar, por meio do código javascript, qualquer texto simples que desejar e interceptar o resultado com um Man-in-the-Middle. Este é o diagrama do ataque:
Este ataque precisa de condições importantes para ser bem-sucedido (TLS1.0 ou inferior, modo de cifra CBC, MiTM, javascript malicioso). Mas Thai Duong e Juliano Rizzo provaram que isso é possível e demonstraram seu exploit roubando cookies no site do Paypal.
Tudo está corrigido agora, e este ataque tem pouca probabilidade de ser realizado.