Last updated at Thu, 22 Aug 2024 18:33:12 GMT

What’s the ROBOT Attack?

On the afternoon of December 12, researchers Hanno Böck, Juraj Somorovskym and Craig Young published a paper, website, testing tool, and CTF at robotattack.org detailing a padding oracle attack that affects the way cryptography is handled on secure websites. ROBOT, which stands for Return Of Bleichenbacher's Oracle Threat, details a weakness in the RSA encryption standard known as PKCS#1v1.5 that can ultimately allow an attacker to learn a secured website’s private key in a relatively short amount of time. Bleichenbacher’s attack is well-known among cryptographers, since it was first described way back in 1998. ROBOT extends this technique and circumvents some of the mitigations put in place by various vendors.

What can attackers do with ROBOT?

Using the techniques described by Böck, Somorovksym, and Young, attackers can extract the private session key used to create an otherwise secure TLS session. Practically, this means that an adversary who can see your encrypted communications, and would normally not be able to read the contents of things like your password and your private messages, could bang on the web server (by repeatedly issuing specially crafted packets) that your browser was talking to in order to shake loose the secret needed to decrypt that session.

Adversaries can also do things like impersonate a web server or a VPN endpoint by using the private key learned this way, and trick victims into believing that signed messages originate from a trusted site.

This is bad news for encrypted communications, since the whole point of SSL/TLS is to prevent eavesdroppers from doing exactly this sort of thing.

No, Seriously. What does this mean?

Any “thing” that uses the padding algorithm in “PKCS#1v1.5” with RSA encryption for SSL/TLS secure sessions is vulnerable to this information disclosure attack. We say “thing” because much of the discussion is in the context of internet-facing web servers and the infrastructure (i.e. load balancers) that make said content available. The authors of the paper even itemized Facebook, Citrix, Radware, and Cisco ACE in their text. But, there are other “things” that expose SSL/TLS endpoints, including VPNs and a plethora of internet-connected “things”, including routers, switches, wireless access points, cameras and more.

As you assess your exposure (personal or organizational) you need to account for all “things” using SSL/TLS that you had marked as secure and, perhaps, do a few more reconnaissance scans to see if you can find devices exposing SSL/TLS endpoints that you weren’t previously aware of. Remember that they may not be on port 443, too. If you have components that need to use SSL/TLS and cannot be updated to thwart this latest vulnerability, it’s time to upgrade. And, if you weren’t maintaining a solid and up-to-date list of your SSL/TLS configurations, take this opportunity to do so.

Also, while the researchers scanned for and identified popular, internet-facing sites with issues, some really important SSL/TLS happens off of subdomains that will not be captured by any of the “top 1 million” site lists and also happen against APIs that mobile device apps use. While there is some comfort in the small exposure percentages, there is potentially more significant exposure where there are fewer prying eyes.

The “Glass Half Full” Take

But, here’s the silver lining: this is the type of work that needs to be published in order to get to a better cryptographic place. As implied above and in the various write-ups of ROBOT, implementations of PKCS#1v1.5, and the related RSA ciphers, are inherently fragile. The underlying padding mechanism has been shored up to resist specific attacks, but the mechanism itself is only as strong as these after-the-fact mitigations. Even if we’re able to come up with a mitigation against ROBOT, it’s only a matter of time and perseverance before ROROBOT (Return of ROBOT) surfaces.

This also a good reminder that SSL/TLS configurations are far from a “set it and forget it” part of your infrastructure. There are fresh attacks against various aspects of these encryption protocols and various recommended standards for baseline settings are regularly updated. Ideally, you should be reviewing the SSL/TLS configurations in your organization at least annually, but more frequent configuration checks could become part of your IT orchestration efforts.

Actions To Take, Right Now.

If you’re relying on a product, like a firewall, load balancer, or proxy that has a vulnerable implementation of PKCS#1v1.5, you have a couple of options. First, you can watch for and apply patches that your vendor provides for the vulnerability. As mentioned earlier, this may leave you open to future variants of these same flaws. Second, you can transition to encryption configurations that don’t use RSA for key exchange. There are multiple alternatives, one being Elliptic Curve Diffie-Hellman Ephemeral (ECDHE), which almost every OS and library released in the last 7 years support already. The most recent versions of common operating systems such as Windows, macOS, iOS, and Android and browsers such as Chrome, Edge, and Safari already prioritize ECDHE so the risk of disruption is low (always test!). The next version of TLS, 1.3, will not support RSA key exchange at all and so this is a direction that standards are moving due to flaws like ROBOT and multiple other reasons. Cryptography experts have warned about Bleichenbacher's Oracle and related flaws forever, and hopefully today is the day to do something about it.

Internet Impact

The ROBOT paper abstract notes that ROBOT “affects almost a third of the top 100 domains,” but only 2.8% of the top 1 million. So, while most websites are in the clear for this, a lot of the most popular websites are, paradoxically, affected as of the time of the authors’ scan. We’re tooling up a Sonar study to go hunting for services that are affected today in order to get some more up-to-the-minute insight into what the internet-wide attack surface looks like. While we can’t directly verify what the ROBOT paper authors saw, we should be able to offer some detailed analysis on who and what are affected, post-disclosure. Keep an eye out for a follow-up blog post on that.

For Rapid7 Customers

After a thorough analysis, we’ve determined that Metasploit (all versions), Nexpose Console and Engine (all versions), InsightVM Console, and AppSpider are not affected by the ROBOT attack. Our initial testing indicates that Rapid7's Insight Platform is also not affected. We are continuing to investigate our exposure to variations of the ROBOT attack across all our products and infrastructure, and will provide updates of our investigation and any remediation efforts that come out of it.

InsightVM and Nexpose checks, as well as Metasploit modules, are in the works, so expect those capabilities for your vulnerability management and penetration testing needs in the next couple days.

Updates

We’ll keep this blog post updated as we learn more about the ROBOT exposures and what Rapid7 customers can do to protect their enterprises.

Dec 14, 2017: Updated and revised the section on what action IT administrators can take right now to avoid exposure to the ROBOT attack flaws.