The death knell for SSL is getting louder.
Researchers at the University of Texas at Austin and Stanford University have discovered that poorly designed APIs used in SSL implementations are to blame for vulnerabilities in many critical non-browser software packages.
Serious security vulnerabilities were found in programs such as Amazon’s EC2 Java library, Amazon’s and PayPal’s merchant SDKs, Trillian and AIM instant messaging software, popular integrated shopping cart software packages, Chase mobile banking software, and several Android applications and libraries. SSL connections from these programs and many others are vulnerable to a man in the middle attack.
“This is exactly the attack that SSL is intended to protect against,” according to the research paper “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software.“ It does not involve compromised or malicious certificate authorities, nor forged certificates, nor compromised private keys of legitimate servers. The only class of vulnerabilities we exploit are logic errors in client-side SSL certificate validation.”
SSL encrypts network communications between clients and servers. The research, done by Martin Georgiev, Suman Jana and Vitaly Shmatikov of the University of Texas at Austin and Subodh Iyengar, Dan Boneh and Rishita Anubhai of Stanford University, focuses on SSL connection authentication in non-browser software. The team looked at a number of applications and libraries supported on Linux, Windows, Android and Mac iOS platforms, and how they validate SSL certificates. All of the applications and libraries tested failed to reject self-signed and third-party digital certificates and instead established SSL connections initiated by a man in the middle who siphoned the transaction information.
“SSL certificate validation is completely broken in many critical software applications and libraries,” the report concluded.
Non-browser software often requires a secure Internet connection, and SSL is deployed as the preferred encryption protocol. Some of the critical applications tested by the researchers included instances where SSL was used to send local data to cloud-based storage, transmit payment data to processors such as PayPal and Amazon, establish connections between IM clients and the respective service, and authenticate servers to Android and iOS mobile applications, the research paper said.
“The root cause of most of these vulnerabilities is the terrible design of the APIs to the underlying SSL libraries. Instead of expressing high-level security properties of network tunnels such as confidentiality and authentication, these APIs expose low-level details of the SSL protocol to application developers,” the paper said. “As a consequence, developers often use SSL APIs incorrectly, misinterpreting and misunderstanding their manifold parameters, options, side effects, and return values.”
Developers, meanwhile, may incorrectly use legitimate SSL libraries that don’t validate certificates, or inadvertently turn off certificate validation.
In addition to certificate validation vulnerabilities in a number of cloud-based storage management programs, Java-based Web services middleware, merchant software development kits and IM authentication instances that could lead to various types of data leakage (lost credentials, payment information and more), the researchers were most disturbed with issues discovered on the Chase mobile banking application for Android devices. The researchers discovered that the mobile app overrides default x509 code which causes the app to fail to check the requesting server’s certificate.
“Perhaps the most devastating (because of the ease of exploitation) bug is the broken certificate validation in the Chase mobile banking app on Android,” the report said. “Even a primitive network attacker—for example, someone in control of a malicious Wi-Fi access point—can exploit this vulnerability to harvest the login credentials of Chase mobile banking customers.”
The researchers point out that the SSL libraries (JSSE, OpenSSL, GnuTLS and others) are often correct, but developers misunderstand the security options, parameters and return values. By incorrectly setting a return value in Amazon’s Flexible Payments Service PHP library, for example, a developer can accidently turn off certificate validation functionality. PayPal Payments Standard PHP library contains the same bug, the researchers said.
The research team said a number of factors contribute to the poor security of SSL implementations: a lack of testing for vulnerabilities during development; unsecure SSL libraries by default; misuse or misinterpretation of security options in secure libraries by developers; SSL vulnerabilities are often not present on the application layer, but in middleware—out of a developers’ purview; and some cases where developers deliberately turn off validation.
“A principled solution to the problem must involve a complete redesign of the SSL libraries’ API,” the report said. “Instead of asking application developers to manage incomprehensible options such as CURLOPT_SSL_VERIFYPEER or SSL_get_verify_result, they should present high-level abstractions that explicitly express security properties of network connections in terms that are close to application semantics.”
