It was late Friday afternoon when the email arrived saying he’d won a free cruise. Philip quickly opened the email and clicked the link for more information, but there was nothing there. What he didn’t know is that this cruise offer actually came from a hacker and not Cruise Giveaways of America. This was no ordinary link, either. That link exploited Philip’s home router using cross-site request forgery. Whoever’s in control of the routers is also in control of the traffic, making the hacker the one in control. It wasn’t Philip’s fault exactly; the exploit had been posted to Full Disclosure a full two months ago, but the vendor still hadn’t even released updates. The cruise offer got Philip dreaming about vacations, and a few minutes later, he was wondering about the balance on his Bank of E savings account. Just then, he opened up a new browser tab and started typing being certain to use HTTPS:// for the secure web site. HTTPS is not always as private as you might think it is, though. The request for this site activated malware on the hacked router, which sprang into action impersonating the bank’s secure server. As soon as Philip’s browser started negotiating a “secure” channel, the hacked router relayed information back to the hacker’s command and control infrastructure. Among the information are secret keys Philip’s computer has selected and encrypted with the bank’s 2048-bit RSA public key. Normally, this encryption would be strong enough to resist years of cracking attempts but in this case, the bank’s web site is vulnerable to ROBOT and the encryption can be broken with relative ease. The hacker’s ROBOT attack now instructs an army of hacked routers to get to work breaking the encryption. This process involves repeatedly trying to connect to the server with specially crafted messages. The server will issue an error most of the time, but every so often, it accepts the message, thereby revealing a little bit of information to the attacker’s algorithm. When it was first described back in 1998 by Daniel Bleichenbacher, this attack needed an average of 1 million crafted messages, but advancements to the algorithm have brought this closer to a very reasonable 10,000 messages. Just as Philip was about to complain of poor WiFi speeds, the page loaded and presented him with a login form. Unfortunately for poor Philip though, the padlock icon next to the address bar was a lie. The hacker’s malware was now in possession of his login codes and went to work draining the account balances.
How did this happen?
Ironically, this was all thanks to the fact that Philip’s bank had installed a middle box in front of their web site to protect it from hackers. Rather than relying on one of the tried and tested TLS libraries, the security vendor created their own implementation or modified an existing one. Perhaps they thought this could shave a few bytes of required memory or handle a few more connections per second, but what they had not counted on is that it is notoriously difficult to make a proper and complete TLS stack. In some cases, even a slight deviation from the intended implementation can completely undermine the cryptography. In this case, the problems stemmed from a particularly confusing point of the TLS specification, section 7.4.7.1 regarding countermeasures to the attack on RSA described by Daniel Bleichenbacher. All the way back in 1998, Bleichenbacher had demonstrated that by revealing specific decryption errors, SSLv3 was leaking information an attacker could exploit. An attacker in possession of some secret encrypted information (like SSL key material) could ask the server if it can decrypt a series of carefully chosen encrypted messages. Each time the decryption succeeds, the attacker is able to narrow down the range of possibilities for the unknown encrypted value. In cryptography, this is known as a side-channel attack, and more specifically, it is an adaptive chosen-ciphertext attack leveraging a padding oracle. This is a problem that could have been nipped in the bud if only the TLS designers had, as Bleichenbacher recommended, discontinued use of a broken cryptography standard (PKCS#1 v1.5).
What is ROBOT?
ROBOT is the Return of Bleichenbacher’s Oracle Threat, and it refers to a growing list of Bleichenbacher oracles Hanno Böck, Juraj Somorovsky, and I were able to identify on the Internet with only minor variations to what Bleichenbacher described in 1998.
One of the most interesting features of this vulnerability is that it disproportionately affects bigger sites with larger security budgets. We found that just 2.8 percent of the top 1 million most popular sites on the Internet were affected by ROBOT, but when looking at the top 100, this number shoots up to a 27 percent affected rate.
After our disclosure, other numbers came out, including Dirk Wetter’s scan implicating almost 15 percent of the top 10,000 sites. While at first this relationship may seem counterintuitive, it is in fact perfectly logical in light of the affected product list. Out of the 27,965 affected hosts, we found on the top 1 million sites, almost 97 percent of them exhibited behavior we associated with products from F5 and Citrix. These products do not come cheap, so naturally, they are more commonly found on popular web sites with more money to spend on security. As if to add insult to injury, these larger sites are also more vulnerable due to their scale. Sites with global reach like Facebook must design their systems to quickly handle high volumes of user requests. This is also incidentally exactly what would help an attacker exploit ROBOT. Tripwire IP360 released initial detection for ROBOT in ASPL-753 following F5’s security advisory in November followed by general ROBOT oracle detection in coordination with the public ROBOT attack disclosure. You can read more about ROBOT on the official https://robotattack.org disclosure page as well as in our paper which is available from the International Association for Cryptologic Research’s Cryptology ePrint Archive. The bottom line of all this research, however, is that secure servers in 2018 and beyond should not be using a technology that was already known to be insecure in 1998. Whether or not your systems were impacted by ROBOT, now is the time to close the chapter on static RSA key exchanges in favor of modern ciphers offering perfect forward secrecy.
