Understanding and mitigating a FREAK vulnerability attack


After the discovery that the FREAK vulnerability can affect a wide variety of OSes, enterprises should amp up mitigation efforts. Here’s some background on the attack and how to stop it.

One day an employee logs onto his company-issued computer and visits an HTTPS-protected website to pay a bill while on his lunch break. A month later the employee is notified by his bank that the credit card used in the transaction to pay his bill has been compromised and fraudulent purchases have been identified.

How did this happen when the site was guaranteed to be protected with an encrypted connection? Doesn’t HTTPS ensure the information to/from the site was safe from malcontents listening to traffic on the Internet? This was a FREAK attack. FREAK is short for “Factoring Attack on RSA-EXPORT Keys” and is a known man-in-the-middle (MitM) vulnerability caused by weak website encryption. In this case, a MitM attacker downgraded the key length of an RSA key to EXPORT-grade length in an encrypted transport-level session. Once done, the attacker could then intercept and decrypt this traffic. But again, how could this happen?

The backstory on the FREAK vulnerability

The story starts with understanding the sophistication of U.S. law enforcement agencies’ previous network traffic monitoring capabilities. About 20 years ago the U.S. federal government imposed an international trade policy on the level of encryption that could be supported in products exported to overseas countries. Why did the government do this? In its agenda to capture illegal and terrorist activities, the government needed the ability to break the cipher of any suspicious encrypted network packets leaving or entering U.S. cyberspace. By imposing this weaker encryption cipher, the NSA had the ability to examine any suspicious activity, even if the contents were fully encrypted.

So what does this have to do with the FREAK vulnerability?Even though the NSA long ago enhanced its monitoring capabilities to break down some of the most sophisticated encryption technologies on the wire today, and lifted the export restrictions on weaker ciphers 10 to 15 years ago, the encryption profile for this old, weaker export encryption mechanism is still sitting on many of today’s browsers — a clear example of the impact of not removing outdated code from common applications.

A FREAK attack has the ability to capture any traffic that has accidently or automatically negotiated to use this old, weaker export cipher between a computer and another site on the Internet — in this case, the payment site the employee visited — and can capture sensitive information the user thought was fully encrypted, without authorization.

FREAK isn’t just for old legacy browsers, either. FREAK vulnerabilities have been found on current operating systems like Android, iOS, Mac OS platforms and many flavors of Microsoft operating systems, including Windows Vista, Windows 7, Windows 8/8.1, Windows Server 2003, Windows Server 2008, Windows Server 2012 and Windows RT. While the operating vendors are working hard to remove this old code, there is still a viable chance that workers could accidently fall victim to a FREAK attack, and be unaware it is taking place.

Fixing the FREAK vulnerability

Organizations need ways to mitigate the chance of a FREAK attack. The best way is to examine the certificates used by the company-supported browsers and remove the “RSA key exchange EXPORT ciphers” from the supported ciphers in the browsers’ configuration and registry components. However, this could be a difficult problem, due to lack of resources, size of the organization or the distributed nature of the organization’s various platform support groups.

An alternative is to ensure network edge devices do not allow connections outside the organization that use this cipher. By blocking this traffic, the data never leaves the organization, and thus can’t be intercepted.Finally, the last option is to route all HTTPS traffic through a Web proxy, like Blue Coat, Apache Software Foundation, HAProxy, Squid and others where HTTPS traffic is negotiated on the Internet edge of the Web proxy. This way any HTTPS traffic inside the company boundaries that tries to use the RSA key exchange EXPORT ciphers is only used inside the enterprise to the Web proxy. This allows it to negotiate a stronger cipher between itself and the Internet target to protect the data.

While network edge device blocking and Web proxies can be a quick fix, organizations should not consider the vulnerability closed until the RSA key exchange EXPORT ciphers have been patched by the operating system vendors or by the organization’s support teams.

The future of FREAK attacks

Unfortunately, vulnerabilities like FREAK will continue to be a problem. Software bloat is a common issue and keeping track of all the 20+ year modules in products is difficult since many of the original coders are no longer doing development, or may even be retired. Luckily, the FREAK vulnerability was caught and can be patched to eliminate the risk it imposes. However, for other operating systems and applications, some of the foundational components in use have remained unchanged for decades.

FREAK attacks should be a wake-up call to vendors — not only to quickly patch this vulnerability — but also to take the time and allocate sufficient resources to do a deep inventory of their code to ensure other legacy components that are no longer required are removed.

Finally, this is also a call to organizations that purchase these products to encourage their trusted vendor partners to do these reviews. While cyber insurance and financial liability limits soften the blow, every organization needs to maintain vigilant security practices in the protection of their data and the data of their customers. FREAK will soon be a thing of the past, but who can predict the next big legacy vulnerability to surface? And the next one may be magnitudes worse than FREAK.

One day an employee logs onto his company-issued computer and visits an HTTPS-protected website to pay a bill while on his lunch break. A month later the employee is notified by his bank that the credit card used in the transaction to pay his bill has been compromised and fraudulent purchases have been identified.

How did this happen when the site was guaranteed to be protected with an encrypted connection? Doesn’t HTTPS ensure the information to/from the site was safe from malcontents listening to traffic on the Internet? This was a FREAK attack. FREAK is short for “Factoring Attack on RSA-EXPORT Keys” and is a known man-in-the-middle (MitM) vulnerability caused by weak website encryption. In this case, a MitM attacker downgraded the key length of an RSA key to EXPORT-grade length in an encrypted transport-level session. Once done, the attacker could then intercept and decrypt this traffic. But again, how could this happen?

The backstory on the FREAK vulnerability

The story starts with understanding the sophistication of U.S. law enforcement agencies’ previous network traffic monitoring capabilities. About 20 years ago the U.S. federal government imposed an international trade policy on the level of encryption that could be supported in products exported to overseas countries. Why did the government do this? In its agenda to capture illegal and terrorist activities, the government needed the ability to break the cipher of any suspicious encrypted network packets leaving or entering U.S. cyberspace. By imposing this weaker encryption cipher, the NSA had the ability to examine any suspicious activity, even if the contents were fully encrypted.

FREAK attacks should be a call to vendors to not only quickly patch this vulnerability, but to take this as a shot across the bow warning.

So what does this have to do with the FREAK vulnerability?

Even though the NSA long ago enhanced its monitoring capabilities to break down some of the most sophisticated encryption technologies on the wire today, and lifted the export restrictions on weaker ciphers 10 to 15 years ago, the encryption profile for this old, weaker export encryption mechanism is still sitting on many of today’s browsers — a clear example of the impact of not removing outdated code from common applications.

A FREAK attack has the ability to capture any traffic that has accidently or automatically negotiated to use this old, weaker export cipher between a computer and another site on the Internet — in this case, the payment site the employee visited — and can capture sensitive information the user thought was fully encrypted, without authorization.

FREAK isn’t just for old legacy browsers, either. FREAK vulnerabilities have been found on current operating systems like Android, iOS, Mac OS platforms and many flavors of Microsoft operating systems, including Windows Vista, Windows 7, Windows 8/8.1, Windows Server 2003, Windows Server 2008, Windows Server 2012 and Windows RT. While the operating vendors are working hard to remove this old code, there is still a viable chance that workers could accidently fall victim to a FREAK attack, and be unaware it is taking place.

Fixing the FREAK vulnerability

Organizations need ways to mitigate the chance of a FREAK attack. The best way is to examine the certificates used by the company-supported browsers and remove the “RSA key exchange EXPORT ciphers” from the supported ciphers in the browsers’ configuration and registry components. However, this could be a difficult problem, due to lack of resources, size of the organization or the distributed nature of the organization’s various platform support groups.

Is it time for a DLP system in your enterprise?

An alternative is to ensure network edge devices do not allow connections outside the organization that use this cipher. By blocking this traffic, the data never leaves the organization, and thus can’t be intercepted.

Finally, the last option is to route all HTTPS traffic through a Web proxy, like Blue Coat, Apache Software Foundation, HAProxy, Squid and others where HTTPS traffic is negotiated on the Internet edge of the Web proxy. This way any HTTPS traffic inside the company boundaries that tries to use the RSA key exchange EXPORT ciphers is only used inside the enterprise to the Web proxy. This allows it to negotiate a stronger cipher between itself and the Internet target to protect the data.

While network edge device blocking and Web proxies can be a quick fix, organizations should not consider the vulnerability closed until the RSA key exchange EXPORT ciphers have been patched by the operating system vendors or by the organization’s support teams.

The future of FREAK attacks

Unfortunately, vulnerabilities like FREAK will continue to be a problem. Software bloat is a common issue and keeping track of all the 20+ year modules in products is difficult since many of the original coders are no longer doing development, or may even be retired. Luckily, the FREAK vulnerability was caught and can be patched to eliminate the risk it imposes. However, for other operating systems and applications, some of the foundational components in use have remained unchanged for decades.

FREAK attacks should be a wake-up call to vendors — not only to quickly patch this vulnerability — but also to take the time and allocate sufficient resources to do a deep inventory of their code to ensure other legacy components that are no longer required are removed.Finally, this is also a call to organizations that purchase these products to encourage their trusted vendor partners to do these reviews. While cyber insurance and financial liability limits soften the blow, every organization needs to maintain vigilant security practices in the protection of their data and the data of their customers. FREAK will soon be a thing of the past, but who can predict the next big legacy vulnerability to surface? And the next one may be magnitudes worse than FREAK.

Randall Gamby is an Identity and Access Management (IAM) professional with over 25 years of IAM experience. He is currently the IAM strategist for a Fortune 500 company. Prior to this position he was a Master Security Consultant, a state Information Security officer and the enterprise security architect for an insurance and finance company. His experience also includes many years as an analyst for the Burton Group’s Security and Risk Management Services group. His coverage areas included: secure messaging, security infrastructure, identity and access management, security policies and procedures, credential services and regulatory compliance.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: