Just When You Thought It Was Safe to Use SSL

On June 5th, less than two months after the disclosure of the Heartbleed bug, the OpenSSL Project published a security advisory revealing six new OpenSSL vulnerabilities.[1] The most serious of these vulnerabilities is a ChangeCipherSpec (CCS) injection flaw that affects every version of OpenSSL.

Discovered by researcher Masashi Kikuchi at Lepidum Co. Ltd., the CCS injection flaw (CVE-2014-0224) is a Man-in-the-Middle attack that allows malicious users to decrypt and modify traffic sent between the client and the server. In order for the attack to be successful, both the client and the server must be vulnerable. While all versions of OpenSSL are vulnerable when acting as an SSL client, only OpenSSL versions 1.0.1 and 1.0.2-beta1 are vulnerable when deployed as an SSL server.

Implications of CCS Injection
While not as easy to exploit as the Heartbleed bug, the CCS injection flaw imposes a serious security risk. As a result, IT and security administrators, fresh off of upgrading scores of servers and devices for Heartbleed, will need to repeat their efforts to mitigate CCS injection risks.

Although not related to Heartbleed, the heightened attention that Heartbleed brought to the OpenSSL Project no doubt led to greater scrutiny of OpenSSL and contributed to the host of new vulnerabilities disclosed on June 5th. In fact, Masashi Kikuchi reported, “When Heartbleed arose, everyone talked about how to prevent similar bugs… [I tried to] show the correctness of the implementation at a glance.”

Therefore, the recent OpenSSL security advisory should not surprise most networking and security professionals, and organizations should prepare for future OpenSSL bugs as more researchers turn their sights on OpenSSL.

Take the Risk out of Encryption Management
With the CCS injection flaw following close on the heels of April’s Heartbleed disclosure, organizations have had to invest an inordinate amount of time patching their servers. Because these servers may host different operating systems with different SSL libraries, IT and networking administrators must spend time testing, patching, and retesting their applications.

One way organizations can safeguard their vulnerable applications–and greatly reduce the time associated to fire drills in the future–is to terminate SSL traffic on their application delivery controllers (ADCs). Offloading SSL traffic not only reduces the application server load, it also lowers operations costs because administrators do not to need to manage SSL certificates on each individual server. And in the event of a vulnerability outbreak, administrators can avoid patching each individual server.

Impact to A10 Networks Products
Of the vulnerabilities revealed in the June 5th OpenSSL security advisory, A10 Networks products are only vulnerable to the CCS injection MitM flaw. A10 Thunder and AX ADCs are susceptible to CCS injection when configured in SSL server-side deployments as an SSL client connecting to a vulnerable server. For example, if a Thunder or AX ADC is deployed as a load balancer in front of a web server and re-encrypts traffic sent to the back-end web server, then the device would be susceptible to a Man-in-the-Middle attack if the web server was also vulnerable to the flaw.

Exposure to this vulnerability on Thunder and AX platforms may be limited because most SSL ADC deployments are configured for front-end SSL offload and not for back-end SSL re-encryption.  Also when configured for re-encryption, this may take place on an internal network, not on the public Internet. However, despite potential limited exposure, A10 customers should still promptly patch Thunder and AX platforms.

A10 customers can log into the A10 support portal to review the full security advisory and to download security updates for their A10 products.

Additional Resources

 


[1] The OpenSSL Project issued a total of seven security patches, including a patch for a previously announced vulnerability.

 

Add new comment