Browse Prior Art Database

Light-weight Runtime Testing of Bad SSL/TLS Hostname Verifiers

IP.com Disclosure Number: IPCOM000246197D
Publication Date: 2016-May-16
Document File: 2 page(s) / 30K

Publishing Venue

The IP.com Prior Art Database

Abstract

A zero false positives invention based on Interactive Application Security Testing (IAST) for finding weak SSL/TLS hostname verifiers. We first instrument the target application on several key areas. Using the instrumentation, we detect that the target app does not use the default hostname verifier, and also receive an instance of that verifier. We then execute the instance with a unique input whose corresponding output can prove that the verifier is vulnerable. Our input is unique in the sense that it does not require heavy instrumentation of the target application in order to prove the existence of a vulnerability.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 01 of 2

Light-

Vulnerabilities in TLS are a rising concern. While many protocol (i.e. implementation-agnostic) vulnerabilities have been detected in recent years and patched (e.g. [POODLE, BEAST, CRIME]), an insecure implementation can still make TLS connections readable (no confidentiality) or writable (no integrity) by a Man-in-the-Middle adversary.

One such an implementation vulnerability is the use of an insecure hostname verifier , for example, one that returns 'true' on any input. In TLS, the connecting client MUST verify that the Common Name listed in the incoming certificate matches (by some criteria) the hostname that the client has connected to, Otherwise the adversary can return his own certificate, which of course can be signed by a legitimate Certificate Authority (CA). Unfortunately recent studies [ANDROIDSSL, TAPIOCA] of Android apps show that many bad implementations do indeed exist.

Our invention is based on Interactive Application Security Testing (IAST). It does not have False Positives and does not require a complex setup. It can also test custom (i.e. developer-created) hostname verifiers.

We first instrument the target application on several key areas. Using the instrumentation, we detect that the target app does not use the default hostname verifier, and also receive an instance of that verifier. We then execute the instance with a unique input whose corresponding output can prove that the verifier is vulnerable. Our input is unique in the sense that it does not require heavy instrumentation of the target application in order to prove the existence of a vulnerability .

The input is described in detail in section 4.

Our invention has the following steps.

1. We instrument the target application using state-of-the-art techniques such as byte/dex code modification or remote debugging. We specifically instrument APIs that are responsible for setting the hostname verifier, such as javax.net.ssl.HttpUrlConnect.setHostnameVerifier or org.apache.http.conn.ssl.SSLSocketFactory.setHostnameVerifier

2. When we detect a call to one of these APIs, we save the instance of the hostname verifier. We will use this instance in later steps.

3. We wait for the verification method of the saved instance to be called. This method usually receives the hostname of connected end (e.g. www.ibm.com) and the incoming certificate (in a non-attack case its Common Name (CN) would usually be www.ibm.com as well). An example of such a method would be org.apache.http.conn.ssl.AllowAllHostnameVerifier.verify(String host, X509Certificate cert). We save any input parameter such as the certificate.


4. We execute the verification method of the saved hostname verifier instance. A vulnerability means that it returns 'true...