BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Researchers Expose SSL Vulnerabilities in Libraries and Their Usage in Popular Non-Browser Services

Researchers Expose SSL Vulnerabilities in Libraries and Their Usage in Popular Non-Browser Services

Leia em Português

This item in japanese

Bookmarks

Research students at The University of Texas at Austin and Stanford University published the results of their research that expose critical vulnerabilities in the usage of  SSL libraries in non-browser applications that we expect to be highly secure. Highly secure and critical services include banking services and merchant SDKs for eCommerce and relatively less critical software include services such as cloud storage services and messaging services. The paper places the blame on the poor state of adversarial testing,  unsafe SSL libraries, unsafe programmatic usage of safe SSL libraries, the complexity in troubleshooting vulnerabilities hidden deep in the stack and the pervasive but unsafe practice of disabling certificate validation by developers.

The threat model used by the team is an active,man-in-the-middle attack. The simulated man-in-the-middle attacks used three certificates: (1) a self-signed certificate with the same common name as the host the client is attempting to connect to, (2) a self-signed certificate with an incorrect common name, and (3) a valid certificate issued by a trusted certificate authority to a domain called AllYourSSLAreBelongTo.us. The man-in-the-middle attacks focuses on chain of trust verification and hostname verification but does not test for certificate revocation and X.509 extensions. The code for the threat model simulation can be downloaded here.

The paper shares relevant implementation details for developers that utilize SSL libraries: OpenSSL and JSSE and data transport libraries: Apache HttpClient, Weberknecht, cURL, PHP's fsockopen method and cURL binding and Python's urllib, urllib2 and httplib. Most of the SSL libraries perform certificate verification but leave some options open around hostname verification to the client which is ignored by most developers. For example, the JSSE low level API, SSLSocketFactory class automatically turns off hostname verification, if the algorithm field is null. Most clients in turn do not implement their own hostname verification scheme including Apache HttpClient which introduces security risks. The following snippet from the certificate verification method in SSLSocketFactory points out to this fact:

private void checkTrusted(X509Certificate[] chain, String authType, Socket socket, boolean isClient)
throws CertificateException {
    ...
    / / che c k e n d p o i n t i d e n t i t y
    String identityAlg = sslSocket.getSSLParameters().
    getEndpointIdentificationAlgorithm();
    if (identityAlg != null && identityAlg.length != 0)
       {
           String hostname = session.getPeerHost();
           checkIdentity(hostname, chain[0], identityAlg);
       }
    }

Such vulnerabilities percolate up the stack for any non-browser application using these libraries. For specific advice around correct implementation of  clients utilizing SSL and data transport libraries refer to the FAQ provided by the authors of the paper.

The latter half of the paper discusses the research results from simulated attacks against cloud client APIs(AWS EC2 and ELB API tools,), Apps(Chase mobile banking app, Rackspace IOS app,Groupon android app, TextSecure), SDKs(Amazon Flexible Payments Service SDK,PayPal Payments Standards SDK,), Web Services middleware(Apache Axis, Axis2, CodeHaus XFire and Pusher) and Mobile Advertising(AdMob). The paper concludes with following recommendations for application developers:

DO use fuzzing (black-box, if necessary) and adversarial testing to see how the application behaves when presented with abnormal SSL certificates. Even when the vulnerabilities are subtle, the symptoms usually are not. In many of our case studies, it is obvious that the software in question has never been tested with any certificates other than those of the intended server. When presented with a certificate issued to AllYourSSLAreBelongTo.us instead of the expected Amazon or PayPal or Chase certificate, these programs eagerly establish SSL connections and spill out their secrets.These vulnerabilities should have manifested during testing.
DON’T modify application code and disable certificate validation for testing with self-signed and/or untrusted certificates. We found in our case studies that developers forget to reverse these modifications even for the production version of the software. Instead, create a temporary keystore with the untrusted CA’s public key in it. While testing your code with self-signed or untrusted certificates, use that keystore as your trusted keystore.
DON’T depend on the library’s defaults to set up the SSL connection securely. Default settings can and do change between different libraries or even different versions of the same library—for example, cURL prior to version 7.10 did not validate certificates by default, but version 7.10 and later do. Always explicitly set the options necessary for secure connection establishment.

and for SSL library developers:

DO make SSL librariesmore explicit about the semantics of their APIs. In many cases, it is obvious that application developers do not understand the meaning of various options and parameters. For example, the PHP libraries for Amazon Flexible Payments Services and PayPal Payments Standard attempt to enable hostname verification in cURL, but instead accidentally override the correct default value and end up disabling it (Sections 7.1 and 7.2). This shows that even safe defaults may be insufficient. Lynx attempts to check for self-signed certificates, but misinterprets the meaning of return values of GnuTLS’s certificate validation function and the check is never executed (Section 7.4). Formalizing the precise semantics of SSL library API and rigorously verifying the “contracts” between the application and the library is an interesting topic for future research and may call for programming language support.
DON’T delegate the responsibility for managing SSL connections to the applications. Existing SSL libraries expose many options to higher-level software. This is fraught with peril. Application developers may not realize that they must explicitly choose certain options in order to enable certificate validation. Therefore,libraries should use safe defaults as much as possible. Furthermore, they should not silently skip important functionality such as hostname verification as JSSE does when the algorithm field is NULL or an empty string (see Section 4.1). Instead, they should raise a runtime exception or inform the application in some other way.
DO design a clean and consistent error reporting interface. Libraries such as OpenSSL and GnuTLS report some errors via return values of functions, while other errors from the same function are reported through a flag passed as an argument. Inconsistent interfaces confuse developers who then mistakenly omit some errorchecks in their applications.

Some of the vendors are working on the bugs pointed out in the paper and are reporting the results back to the researchers which are published in the FAQ. For the benefit of developers dealing with SSL, ISec Partners has released three tools that test for the vulnerabilties exposed in the paper but they cannot be used as a substitute for a complete verification of SSL implementation or for adversarial testing recommended by the authors.

 

Rate this Article

Adoption
Style

BT