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
Beyond ACORN: Cracking the infosec skills nut
[Blog post] Could the Government's cybercrime focus be a catalyst for change?
 
The iTnews Benchmark Awards
Meet the best of the best.
 
Telstra hands over copper, HFC in new $11bn NBN deal
Value of 2011 deal remains intact.
 
 
Sign up to receive iTnews email bulletins
   FOLLOW US...
Latest Comments
Polls
Who do you trust most to protect your private data?







   |   View results
Your bank
  39%
 
Your insurance company
  4%
 
A technology company (Google, Facebook et al)
  8%
 
Your telco, ISP or utility
  8%
 
A retailer (Coles, Woolworths et al)
  2%
 
A Federal Government agency (ATO, Centrelink etc)
  19%
 
An Australian law enforcement agency (AFP, ASIO et al)
  14%
 
A State Government agency (Health dept, etc)
  6%
TOTAL VOTES: 1841

Vote
Do you support the abolition of the Office of the Information Commissioner?