Cybernetic Entomology: SMACK attacks and FREAK

When computers communicate, they do so using protocols, so that each knows how to understand the stream of bits it is getting from the other. Common issues that require agreement in order to communicate include Little-endian versus Big-endian, UTF-8 vs. UTF-16, and, in the case of secured communications, what cipher and keys to use. Agreeing on these things, where there is more than one possibility, requires a process of protocol negotiation.

And protocol negotiation can be surprisingly hard to get right.

Case Study: the FREAK vulnerability – 2015, March 5.

FREAK is an acronym for Factoring Attack on RSA-EXPORT Keys. Yes, I know that actually spells FAREK, not FREAK. But FREAK is a word, and FAREK is not so there is some creative license going on.

Up until the year 2000 or so, the USA required American companies to provide versions of their products with stupid encryption modes, in order to facilitate crooks, thieves, foreign spies, stalkers, and the US government breaking the encryption of these products on demand. And these crippled versions of the software were the only versions legal to export from the USA. Among these stupid encryption modes was 512-bit RSA.

The primary result of this was that American products using cryptography were unacceptable in the world market. Any company developing software that required encryption of any kind therefore had to set up shop in countries that were outside the USA. Aside from the billions of dollars in lost business that cost and the billions more that the aforementioned crooks and thieves used it to steal, America therefore also fell behind the rest of the world in its cryptological capabilities as talented researchers and engineers working in the field went elsewhere. But that buggy thinking, while it is one of the root causes of the FREAK vulnerability, is not the specific bug that we’re discussing.

FREAK is a SMACK – that is to say, a State Machine attACK. (Yes, I know, but the acronym was probably chosen by the same sort of person who looked at FAREK and decided it should be spelled FREAK). When negotiating and executing protocols, a series of messages is exchanged, and the choice and sequence of these messages forms a unique path through a state machine – a twisty little maze of passages that, for protocol negotiations, ultimately results in arrival at a set of agreements on the protocol. SMACK means messing with the protocol, or the protocol negotiation, by garbling a message, skipping a message, repeating a message, or providing a message that would normally have been expected only if protocol negotiation up to that point had gone differently. If the machine recieving this bogus message is vulnerable to that particular SMACK, the effect gives the attacker the ability to “teleport” from one passage of the protocol maze to a different passage.

And that brings us to March 5, 2015. In an effort to preserve backward compatibility (and here we mean the word backward in every possible way), many SSL implementations had continued to support so-called “export mode” encryption long after they should have driven a stake through its heart, cut off its head, stuffed its mouth with garlic, and buried it under a huge rock.  Not that I’m biased about this or anything.  But by 2015, it was no longer offered among the choices in protocol negotiation – that part of the maze had been filled in and forgotten.

Except that, for OpenSSL, and Apple’s implementation of SSL, the Apache web server using vulnerable versions of OpenSSL, several other servers, and a whole lot of web browsers, it had not. They had locked the door to that part of the maze, but when someone used a SMACK that allowed them to teleport into that locked part of the maze, they could force an encryption downgrade to the export-mode encryption which had been breakable twenty-five years earlier.

Of these, RSA-512, which was based on the difficulty of factoring a 512-bit number, was particularly vulnerable because in addition to the keys being ridiculously weak, faster factoring algorithms had been discovered in the meantime. And that enabled the FREAK attack.

It turned out that, after a server said, “Pick a ciphersuite; your choices are A, B, C, and D”, if it got a message that said, “Okay, of those choices, I’ll take G,” a vulnerable server would cheerfully provide a connection using ciphersuite G – meaning, in this case, RSA-512. While the insecure cipher was no longer offered as a choice during protocol negotiation, if someone broke protocol and gave the vulnerable server a wrong message, the server would proceed as though protocol negotiation up to that point had gone differently – differently, in this case, than was supposed to even be possible.

If the client was also vulnerable, then after it had told the server, “I request a connection in ciphersuite B,” if it got a SMACK from the server — in this case a cert with an RSA-512 encryption key – it would cheerfully connect using that encryption suite as though it were the one it had requested.

Messages crossing the Internet pass through many machines on the way. Any of these machines can listen in on or even modify traffic passing through it. We don’t usually think about this because we encrypt or at least attach Message Authentication Codes to packets so that they can’t be changed at one of these machines and still accepted on the other end. But at this point we’re talking about negotiating the cryptographic protocols themselves. Before encryption protocol is established, the negotiations are in plaintext and can be modified anywhere along the way. And this is what the FREAK attack did.

An attacker executing the FREAK attack could trigger these bugs on both sides by garbling or intercepting the client’s request for a particular ciphersuite and sending the server a message that requested a stupid encryption suite which the server had not offered and was no longer supposed to support. The server would then send the client a stupid cert that ought not even exist. And the client would accept a cert which was not the cert that the client had requested, and which was furthermore a stupid cert that ought not even exist, without a complaint. The server and client could then establish an “authenticated” connection using such weak encryption that the attacker was able to listen, or in some cases even modify traffic in flight.

At the time it was discovered, this bug affected 37% of all HTTPS servers. The Apache web server using all but the very latest version of OpenSSL was the primary vulnerable server. At that time Apache was serving 58% of all web servers on the Internet, and more than half of these were vulnerable because they had not been updated with the most recent patch of OpenSSL.

Apache mod_ssl, in particular, made this even worse. Because it is computationally expensive to generate RSA keys, mod_ssl, by default, generates a single export-grade RSA key when the server starts up and then re-uses it for all the sessions served until the server shuts down. So an attacker obtaining a 512-bit RSA key could take the few hours to factor it, and the server that used that key would still be up — enabling the attacker to read and modify further traffic on the fly until it reboots.

The uptime for Apache servers running on stable operating systems can reach weeks or months. Essentially, they get started once after a kernel upgrade forces a reboot, and do not shut down until rebooting the machine for the next kernel upgrade or a hardware failure. So, having gotten the key once, an attacker could read and modify the traffic on that server for weeks.

The websites whitehouse.gov, nsa.gov, and fbi.gov (including the FBI anonymous tips website) were all among the sites whose servers were vulnerable, meaning that the buggy security decisions of decades before had resulted in a bug that reduced the security of the very same organizations that had made the decisions. Which goes to show that if you don’t get good decisions, at least you eventually get irony.

Web browsers afflicted included Internet Explorer on Windows, Chrome on MacOS and Android, Safari on MacOS and iOS, Opera on MacOS and Linux, as well as the stock browsers provided with Blackberry and Android devices. FREAK was short-lived after its public announcement, because the web servers afflicted could fix it by downloading a new version of OpenSSL already available, and security patches for the browsers started coming out just a few hours after the attack was announced.

But if it was short-lived after the announcement, there is no way to know how long this bug had been in use by criminals and spies before it was discovered by researchers and disclosed to the public, nor how much it had by that time cost both businesses and governments around the world. There is no way to know how many of the people who used the FBI anonymous tips website and were thereafter killed, were killed because of this bug. There is no way to know whether supposedly secure connections by agents in the field have compromised FBI or NSA investigations, or even sensitive traffic from the White House.

Checklist Items when creating or implementing a protocol:

• Don’t rely on security normally provided by something to protect you during the process of bootstrapping it.
• When you request a cert and get one, make sure it’s the one you requested.
• Check the messages you get back. If they don’t make sense in the context of the protocol so far, DROP THE CONNECTION IMMEDIATELY.
• Don’t rely on the other side of the protocol to detect mistakes you make, don’t rely on them NOT detecting mistakes you make, and don’t rely on them not to make mistakes of their own. You don’t know whether that’s a crook on the other side, and it doesn’t matter. DROP THE CONNECTION IMMEDIATELY. If it’s your customer, he will reconnect and do it the right way.
• Backward compatibility is ACTIVELY HARMFUL in security applications of any kind. Any security software that has a backward compatibility mode also has a security downgrade attack. The existence of such modes and the negotiation required to NOT select them complicates protocols and creates opportunities to make mistakes. It also splits the focus of developers among the many possible results of the protocol. Further, a backward compatibility failure that forces customers to upgrade from insecure software is good for you, good for the customers and in both of your best interests! Finally, if you don’t support an insecure mode and someone requests it, you should DROP THE CONNECTION IMMEDIATELY. Dropping it does less damage than accepting it. It even does less damage than providing an error message.
• When someone whose connection has been dropped reconnects, don’t re-use the same key, nor any information from the previous session, for the new connection. You don’t know whether it’s actually the same connection.
• You don’t get more security by adding stronger ciphers to a system. You get more security by stopping use of the weaker ones.
• Keep your protocols simple. The more complicated something is, the more chances there are to make mistakes.
• Supporting a multiplicity of choices in encryption and security is usually a bad idea. You’d rather have one secure thing, and a very simple resulting protocol, than complex code involving many choices corresponding to messages that could get intercepted, garbled, or replaced.
• When a path is eliminated in the state machine that a protocol represents and some state is no longer supposed to be reachable – especially if it could possibly affect security – REMOVE ALL CODE that supports that state. Don’t just disable it from another part of the protocol, or someone will execute a SMACK. Don’t leave the code in the program, or some clever monkey will invoke when he discovers a buffer overflow bug. If you don’t want to do it, you don’t want the code that does it.
• If you don’t want your server to support some potential protocol choice, then you should not have resources (like 512-bit RSA certificates) available to your server which have no purpose other than supporting that choice, because the software will pick them up and use them if someone comes up with a security downgrade attack. If you have them because you’re getting them from some source like a cert server that has all of them including the ones you don’t want, then make the extra effort to filter them out or get rid of them. You don’t want them available.