Missing Certificate Validation

Thomas Jansen on Dec 14, 2017 — 6 min read

In my previous blog post, I’ve described a rather simple setup that enables an attacker to re-route a victim’s network traffic using bettercap and observing clear-text HTTP communication via mitmproxy. Today’s blog post will describe how this setup can be extended to enable eavesdropping on certain encrypted connections.

Transport Socket Layer

Let’s start off by brushing up our knowledge on the Transport Socket Layer (TLS), which puts the s in https. The TLS protocol used in HTTPS provides connection security that has three basic properties:

While data encryption ensures that someone observing the network traffic from the outside can’t make any sense of what is seen, it still allows for a so-called man-in-the-middle (MITM) attack, where the attacker secretly relays the communication between two parties who believe they are directly communicating with each other. Roughly speaking, the attacker “acts” as the server to the client and as a client to the server:

Man-in-the-middle attack on TLS connection without certificate validation

Man-in-the-middle attack on TLS connection without certificate validation

Given just encryption and integrity, the client is not able to tell if the server is really the one the data should be sent to, and the server is not able to tell if it receives the data from a valid client. Both legs (from client to the attacker and from the attacker to the server) would be private and reliable, but the attacker is still able to see all data in the clear.

Authentication

This problem of trust is solved using the third property of TLS —Authentication— primarily using Digital Certificates in conjunction with a so-called Public-Key Infrastructure (PKI). It’s rather complicated, but for the purpose of this post this will do; there is something called a certificate that is sent to the client and the client can check the validity of that certificate (and therefore the identity of the server).

There are reasons to ignore the validity of the certificate, though. Probably the most common case is using self-signed certificates to avoid the cost and organizational hassle of obtaining a valid certificate from the PKI, e.g. during development and testing. Disabling authentication for a connection can be done easily on iOS or Android, but both —Apple and Google— strongly suggest to never do this in production. So, obviously, no one ever would, right?

In The Wild

During my analysis of the Top-200 Free iOS apps a few months ago I, therefore, tested if apps do proper server certificate validation. I did not expect to find a single app, but boy was I wrong; a whopping 31 apps —15.5% of all apps I checked, or roughly 28 million combined monthly downloads1— did, in fact, ignore the validity of the server certificate.2

Again: All these apps use https, but we can still perform a MITM attack and therefore eavesdrop on the network traffic!

Attack: SHEIN

As a practical example, we will try to eavesdrop on the https traffic of the popular SHEIN shopping app. Let’s update the setup of the previous post; the bettercap configuration stays the same because it already re-routed all of the victim’s network traffic —including https— through the attacker’s device. However, we have to add another rule to iptables to redirect TLS traffic to the transparent proxy running on port 8080:

# Route all TCP traffic on port 80 to port 8080 (we did this last week already)
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080

# Route all TCP traffic on port 443 to port 8080 (this is new)
sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 8080

The victim’s https traffic is now processed by mitmproxy, which secures the connection to the client with a self-signed certificate. And while this works fine for the apps we have in mind (i.e. the ones that disable server certificate validation) it’ll fail for apps that authenticate properly — resulting in numerous client-side disconnects.

This can be solved by instructing mitmproxy to ignore all but the domains we know are vulnerable — for instance, the SHEIN app uses api-service.shein.com without proper certificate validation:3

mitmproxy --mode transparent \
          --ignore-hosts '^(?!api-service\.shein\.com)' \
          --ssl-insecure \
          --show-host

Now, running the SHEIN app on an iOS device —without having the MITM root certificate installed— will allow us to sniff the credentials, regardless of the usage of https:

Sniffing HTTPS traffic, due to the lack of certificate validation

Sniffing HTTPS traffic, due to the lack of certificate validation

To conclude: Using a similar setup as before —without special hardware, without physical access to neither the victim’s device nor the network infrastructure, and without any visual indication about an ongoing attack on the victim’s device— the attacker was able to listen into encrypted https traffic, due to a lack of certificate validation on the client.

I hope you enjoyed the post, which is the second in a series of three; the previous post was talking about sniffing of unencrypted network traffic and the third post will show how code can be injected over insecure network communication.


Update (07/12/2018): A major new version of mitmproxy has been released a while back, so I went back and updated the command line and scripts to the new syntax. I’ve also updated the screen capture and vulnerability disclosure section.


Bonus: Vulnerability Disclosure and History

SHEIN

The vulnerability is still present at the time of this writing. I reached out a total of six times and only heard back once.

DateDescription
09/12/2017Reached out to SHEIN via Twitter to learn about the disclosure process
09/15/2017SHEIN is asking for my email address — they want to reach out to me
09/22/2017CVE-2017-14710 got assigned to the vulnerability
09/22/2017Sent reminder to SHEIN
10/05/2017Sent yet another reminder, this time to service@shein.com
10/10/2017Sent final reminder to several email addresses I found via Google
07/12/2018Checked the latest version (6.2.2) and it is still vulnerable

Shpock

The described vulnerability has been fixed as of version 3.17.0 of the app.

DateDescription
09/12/2017Reached out to Shpock to learn about the disclosure process
09/12/2017Sent detailed report to support@shpock.com
09/20/2017CVE-2017-14612 got assigned to the vulnerability
10/17/2017Requested status update
10/18/2017Shpock confirms that the vulnerability has been closed

Komoot

The described vulnerability has been fixed as of version 9.3.2 of the app.

DateDescription
09/12/2017Reached out to Komoot to learn about the disclosure process
09/13/2017Sent detailed report to help@komoot.de
09/19/2017Komoot confirms that the vulnerability has been closed
09/20/2017CVE-2017-14709 got assigned to the vulnerability


  1. Download numbers are estimated using SensorTower.
  2. This does not mean that all communication of the app was ignoring the server certificate, but I saw at least some of the network traffic is vulnerable to this problem.

  3. The command line includes the --insecure flag, because mitmproxy uses an incomplete certificate bundle on some Linux distros.