14/10/2014

SSL validation vulnerabilities and mobile banking in 2014

Introduction
The starting point for this research project was CVE-2014-1266, Apple’s vulnerability in the Diffie-Hellman code of the SSL/TLS handshake. We were wondering how this critical bug in a security function could go unnoticed for quite a long time? From this, Limes Security derived the idea to analyze the state of SSL validation through a generic, repeatable approach. We wanted to see how sensitive mobile applications react upon modified or invalid certificates and if bugs specifically in the SSL validation routines of mobile platforms could be found, frankly speaking: Are software developers doing their homework properly when it comes to SSL validation functions?

Tooling
Our approach to detect those vulnerabilites is based on the tool mitmproxy. We modified it in order to be able to generate certificates for our test-cases on-the-fly. With this approach we are able see how the X.509 validation routines are implemented using different test certificates without the need of using reverse-engineering techniques or having access to the source code. We used it to test more than 90 mobile apps on the platforms Apple iOS, Android and Windows Phone.

The following figures show the setup as well as the general workflow:

Bild2


The steps for testing are the following:

  1. Run the SSL Validation Fuzzer initially without a testcase and start the application.
    This generates all the required certificates.
  2. Iterate through and execute the different testcases.
  3. See how the app reacts upon each certificate.

Results
Even in 2014, we found banking apps that are still vulnerable to Man-in-the-Middle attacks, not doing any SSL validation checking at all. Others failed only on some of our test cases. Customers of those banks might become the victim of a man-in-the-middle-attack without noticing when using those vulnerable mobile banking apps. Limes Security also found some apps mixing HTTP and HTTPS traffic and apps where SSL Stripping attacks could easily be applied. Besides those significant issues several minor issues were also identified (E.g. User-Enumeration, …).

Using the presented approach we are able to tell if the app uses the browser component or the built in X.509 certificate validiation routines. If the latter was the case, we could check if the developer failed to implement X.509 Certificate validation, without the need of using reverse-engineering techniques or source code.

The results are presented by Thomas Brandstetter at BlackHat Europe 2014. The presentation slides are available here.