Researchers detail laundry list of dodgy crypto deployments

Powered by SC Magazine
 

Developer hits back at 'rude' research.

A team of university 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


Researchers detail laundry list of dodgy crypto deployments
 
 
 
Top Stories
Westpac interim CIO resigns
Group CIO yet to be appointed.
 
Earning the right to innovate
Breaking down the barriers to innovation is a long, but rewarding process, says Bank of Queensland Group CIO, Julie Bale.
 
Telstra prepares to shut down 2G network
Update: Will farewell "old friend" by end of 2016.
 
 
Sign up to receive iTnews email bulletins
   FOLLOW US...
Latest Comments
Polls
What is delaying adoption of public cloud in your organisation?







   |   View results
Lock-in concerns
  26%
 
Application integration concerns
  3%
 
Security and compliance concerns
  28%
 
Unreliable network infrastructure
  9%
 
Data sovereignty concerns
  23%
 
Lack of stakeholder support
  3%
 
Protecting on-premise IT jobs
  5%
 
Difficulty transitioning CapEx budget into OpEx
  3%
TOTAL VOTES: 906

Vote