Researchers Resurrect and Improve CRIME Attack Against SSL
New techniques bypass existing mitigations and make the attack easier to pull off
Thu, March 14, 2013
IDG News Service — Two researchers from security firm Imperva have devised new techniques that could allow attackers to extract sensitive information from users' encrypted Web traffic.
The new methods build on those used in an attack called CRIME revealed last year that abuses the compression feature of SSL to achieve the same goal.
The attacker needs to have an eavesdropping position on the network that allows him to see the size of the encrypted requests in transit. The trick is that if one of the rogue requests includes a character present in the cookie, it will compress better, since compression works by removing duplicate characters.
By adapting subsequent requests and watching for the compression differences between them, the attacker can determine the whole encrypted cookie one character at a time.
The CRIME attack was mitigated by removing support for SSL compression in the browsers that supported it, for example Google Chrome.
The new attack methods that Imperva researchers Tal Be'ery and Amichai Shulman have devised follow the same principles as CRIME, but target information stored in server responses -- the actual Web content served to the users -- rather than in the users' requests.
The vast majority of sites, SSL enabled or not, compress responses by default, Be'ery said. HTTP compression is supported by most Web servers and is actually recommended for server administrators to have it enabled because it saves bandwidth.
SSL compression is a second compression layer applied to the whole channel -- both requests and responses -- but even with it disabled, HTTP compression is applied to Web server responses in most cases.
This means that secret information stored in encrypted responses is vulnerable to CRIME-like attacks, if some additional CRIME requirements are met.
First the targeted information needs to be prefixed or suffixed with a string that never changes. There are many examples of this, Be'ery said. For example, "Account balance:" or "Credit card:" on an online banking website.
Then, the attacker needs to be able to embed specific data into the response by passing it through URL parameters. Not all websites support this, but many do, he said.
If these conditions are met CRIME can be used to recover secret information from encrypted responses, information that can be something valuable like credit card numbers or personal details.
However, the Imperva researchers did not only make the CRIME attack possible again; they developed a new attack based on it that's easier to pull off and doesn't require network eavesdropping.
In order to do that, they started from the CRIME premise that knowing that a compressed payload -- in this case a HTTP response -- is smaller in size than another one is enough to guess the characters that make up the targeted information.
However, in order to determine this the attacker doesn't need to actually know the response sizes, Be'ery said. They can simply compare the time it takes for different responses to reach the user's browser. Smaller responses will travel faster.
The Imperva researchers dubbed the new attack TIME, which stands for "Timing Info-leak Made Easy," and will present it on Thursday at the Black Hat Europe 2013 security conference in Amsterdam.
In order to account for any network interference that could skew the timing, the researchers developed a statistical analysis algorithm that requires for the same server response to be received multiple times.
Depending on the case, this can be 5 times, 10 times, 20 times or more, Be'ery said. This means that the TIME attack is easier to execute than CRIME, because it doesn't require network eavesdropping, but is slower because it requires a larger number of requests to be sent.
In their presentation at Black Hat Europe the researchers will also discuss possible mitigation techniques for the attack. Those include implementing cross-site request forgery (CSRF) protection, making sure the Web application doesn't accept unknown parameters or deploying anti-automation measures that would detect and block an unusually large number of requests from the same user.