Researchers detail SSL implementation holes

A team of US researchers has revealed how the use of Secure Sockets Layer (SSL) in a large range of big ticket applications could allow for man-in-the-middle interception.

In a paper dubbed "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software", researchers from Stanford University and the University of Texas found vulnerabilities in how SSL was handled in Android, Amazon’s EC2 Java library and software development kit, and instant message clients Trillian and AIM.

The root cause of the flaws was the "terrible design" of application program interfaces (APIs) to the underlying SSL libraries, they wrote.

"As a consequence, developers often use SSL APIs incorrectly, misinterpreting and misunderstanding their manifold parameters, options, side effects, and return values," they wrote.

"Our main conclusion is that SSL certificate validation is completely broken in many critical software applications and libraries.

"When presented with self-signed and third-party certificates — including a certificate issued by a legitimate authority to a domain called AllYourSSLAreBelongTo.us — they establish SSL connections and send their secrets to a man-in-the-middle attacker."

The attacks did not use malicious or forged certificates, nor compromised private keys of legitimate servers. Instead, attackers exploited only logic errors in client-side SSL certificate validation.

Vulnerabilities were discovered during tests in which DNS cache poisoning and certificate impersonation were used.

Trillian and AIM were found to be susceptible to man-in-the-middle attacks because they failed to properly validate certificates before establishing a secured connection. Attacks against Trillian also could reveal authentication details for accounts such as Google and Yahoo.

Apache Libcloud, Rackspace's iOS client, and cloud storage clients ElephantDrive and FilesAnywhere were also listed as vulnerable.

Credentials used in a mobile Android application for US bank Chase could be harvested in simple attacks from attackers in control of a malicious wireless access point.

Daniel Stenberg, the developer of Curl, hit back at the researchers for publishing the research without first disclosing the flaws to affected developers.

“What did the authors do to try to fix the problem before posting rude comments in a report? Nothing at all. They could have emailed, tweeted or posted a bug report or patch but none of that happened,” Stenberg wrote in a blog.

The paper points out that libcurl uses confusing parameters to establish SSL and labelled the interface “almost perversely bad”.

“This functionality is controlled by parametersCURLOPT_SSL_VERIFYPEER (default value: true) and CURLOPT_SSL_VERIFYHOST (default value: 2). This interface is almost perversely bad. The VERIFYPEER parameter is a boolean, while a similar-looking VERIFYHOST parameter is an integer.” 

“Well-intentioned developers not only routinely misunderstand these parameters, but often set CURLOPT_SSL_VERIFY HOST to true, thereby changing it to 1 and thus accidentally disabling hostname verification with disastrous consequences”.

User discussion centred on the need for developers to read documentation to understand how to properly enable verification.

The researchers said the API for SSL libraries required a “complete redesign”.

Copyright © SC Magazine, Australia