## https://sploitus.com/exploit?id=C480B610-211B-53F0-A7F7-38A0FB8F952B
# CRIME-poc
CRIME attack : a compression oracle attacks [CVE-2012-4929](https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2012-4929) discovered by Juliano Rizzo and Thai Duong;
> In a compression oracle attack the use of adaptive data compression on a mixture of chosen plaintext and unknown plaintext can result in content-sensitive changes in the length of the compressed text that can be detected even though the content of the compressed text itself is then encrypted. This can be used in protocol attacks to detect when the injected known plaintext is even partially similar to the unknown content of a secret part of the message, greatly reducing the complexity of a search for a match for the secret text. The CRIME and BREACH attacks are examples of protocol attacks using this phenomenon.
The CRIME attack allows you to retrieve encrypted data send by a client to a server using the length of the encrypted data. It does not allow you to retrieve the private key used to encrypt the message or the HTTP request.
## Table of Contents
1. [Explanation](#explanation)
2. [Proof Of Concept](#proof-Of-Concept)
1. [RC4 stream cipher](#rc4-stream-cipher)
2. [CBC cipher mode](#cbc-cipher-mode)
3. [Exploit](#exploit)
## Explanation
Many articles explain how the CRIME attack works, but this is the best explanations I found on the internet :
1. [this answer: Crime how to beat the beast successor](https://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor/19914#19914)
2. [SSL Attacks Survey from NCC Group](https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/ssl_attacks_survey.pdf)
This attack is really not complex, the really interesting part is the implementation that is a bit different from the 'theory'.
Let's check the naive method as described in the article, it's a good way to understand how it works :
The attacker can control request send by the client (using javascript for example). The goal is to retrieve secret cookie. The attacker sends multiple requests like this and check the length of the encrypted data :
| Reques | length
|---|---|
| GET /cookie= DATA cookie=quokkalight | **80** |
| GET /cookie=a DATA cookie=quokkalight | 81 |
| GET /cookie=b DATA cookie=quokkalight | 81 |
| GET /cookie=. DATA cookie=quokkalight | 81 |
| GET /cookie=**q** DATA cookie=quokkalight | **80** |
Since `cookie=q` match `cookie=quokkalight` from the secret cookie, the length of the encrypted data will be the same and the attacker know he found a byte.
But this method failed some times and cannot be trusted so instead we will use another method.
First we send a request with the char we want to find followed by multiple caracters that cannot be found in the initial request like some specials chars :`chr(i) + "#:/[@/&"`. Then we send a second request but we invert the payload like this: `"#:/[@/&" + chr(i)` and we compare the two length. If `len(enc(req1)) coming really soon...
```
\ /
\ _ /
----/_\----
x--------------( . )--------------x
x|x | |_|\_/|_| | x|x
x x x x
```
## References
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/ssl_attacks_survey.pdf
https://github.com/cloudflare/cf-nocompress
https://www.ekoparty.org/archive/2012/CRIME_ekoparty2012.pdf
https://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor/19914#19914