Breaking NewsWeb Application Security

ROBOT: For When the Metal Ones Decide to Come for You

Clever Name, Derivative Attack

Dust off your Old Glory Insurance policy, ROBOT attack is now a real thing that can happen to you.  Researchers Hanno Böck, Juraj Somorovsky, and Craig Young have a new attack to tell you about, and they have named it Return of Bleichenbacher’s Oracle Threat (ROBOT).  To sum it up in one sentence, their whitepaper says “We didn’t go for the full solution to this problem, and it came back.”

Their main finding is that a specific padding oracle attack from ’98 can still be used against modern TLS stacks.  Transport Layer Security (TLS) is supposed to provide you with confidence that messages you send back and forth with a server are secure.  Only the real server should be able to read your messages, and only they should be able to sign messages back to you so you know they are from the real server not some hacker in between you.  The researchers proved that this classic attack works by forging Facebook’s signature.

To make this work, the attack has to open many thousands (possibly millions) of connections to the server with different cryptographic payloads, and monitoring how the server responds.  There are more efficient ways to exploit this, but the researchers stuck to the original plan of attack.  So, in the coming weeks and months, we can probably expect someone to build a faster ROBOT.

It’s clear that the researchers are trying to emphasize the similarities to the original research done by Bleichenbacher in ’98.  In their whitepaper, they make a compelling case that complicated mitigations are not an effective long-term strategy to fix a basic flaw.  In this case, the basic flaw is using RSA key exchanges to facilitate encryption.  In their words: “In our opinion this shows that it is a bad strategy to counter cryptographic attacks with workarounds. The PKCS #1 v1.5 encoding should have been deprecated after the discovery of Bleichenbacher’s attack.”


Is this a Big Deal?

Being vulnerable to this attack is a sliding scale.  It could take a few thousand connections to decrypt a captured message, or millions, or be impractical to pull off at all.  If you are vulnerable to this in a way that an attack is practical, then a sophisticated attacker could use it to do real harm.  In my opinion, you almost certainly have vulnerabilities that are more easily exploited and can be used to do more widespread harm.  Please fix this if you have it, but don’t forget about your boring old SQL Injection and XSS!

ROBOT is something you should pay attention to, and look for patches to your TLS library.  Better yet, consider dropping all support for RSA key exchange based encryption, if possible.

I would still call this attack a big deal because it has the potential to educate on an overall issue of wallpapering over security weaknesses to close specific vulnerabilities.  This basic problem comes up every day for us at WhiteHat, as we keep overcoming blacklists and workarounds to exploit the underlying vulnerabilities.  We try to always coach the full solution, and it’s great to see hard evidence to support it.

This attack also demonstrates once again that for TLS to remain secure, we need to keep marching forward, removing support for old cipher modes and adding new ones.


What is WhiteHat Doing?

We consider ROBOT worth reporting, and we’re currently working on detection that won’t DoS your server for our DAST and Mobile customers.  We’ll put an update in the Sentinel portal when we have more information.

In most cases, people will be vulnerable to ROBOT because of specific issues with your TLS stack.  If it’s in your code and you have Sentinel Source, we’ll automatically report those once the CVE’s publish.