5 min read

Secure Connectivity for Mobile Banking and Payment Apps: HTTPS Tunneling

Picture of Martin Rupp (guest) Martin Rupp (guest) : 26. March 2020

Mobile App Security MASC RASP
Secure Connectivity for Mobile Banking and Payment Apps: HTTPS Tunneling

In this article, we will describe what HTTPS tunneling is and how it has been used in mobile banking and payment applications. We also look at some of its vulnerabilities and remedies to the described attacks.

Why Do We Need HTTPS?

In the HTTP protocol, all information in transit is clear. This means that any interception device or spy protocol like Wireshark could fully reconstruct the TCP/IP data. Therefore, in the context of mobile banking, using HTTP is not feasible.

Generally, there are two possible remedies for this problem:

  1. Using IPSEC
  2. Using HTTPS

The following sections will focus on HTTPS.

What is HTTPS Tunneling?

HTTPS is a protocol that allows end-to-end encryption of HTTP traffic (communication between a mobile app and the server). HTTPS creates a secure “tunnel” inside where sensitive information can be exchanged. It should not be confused with IPSEC, which ciphers the data inside the IP protocol itself.

The opening of such an HTTPS secure channel presupposes the key exchange mechanism in which the symmetric keys are established on both sides of the channel.  Usually, the key exchange mechanism is based on the Diffie-Hellman key exchange (DH). 

Here are the main key exchange algorithms that are based on DH, which can be used with HTTPS:

  • DH_RSA;
  • DH_DSS;
  • DHE_RSA;
  • DHE_DSS;
  • DH_anon;
  • ECDH_ECDSA;
  • ECDH_RSA;
  • ECDHE_ECDSA;
  • ECDHE_RSA;
  • ECDH_anon.

With some of these key exchanges, the “anonymous” ones are vulnerable to man-in-the-middle attacks. Some of the variants involve using a DSA key or Elliptic Curves key that must be used for the server certificate.

Once the server certificate has been checked, a common set of algorithms has been decided between both parties, and the key exchange has been done, a handshake is performed. Then the sending and the receiving parts alternatively cipher and decipher the data.

Known Vulnerabilities of the HTTPS Protocol

Read White Paper

HTTPS tunneling can use one of the following protocols:

  • SSL 1.0;
  • SSL 2.0;
  • SSL 3.0;
  • TLS 1.0;
  • TLS 1.1;
  • TLS 1.2;
  • TLS 1.3.

Among all these protocols, only TLS 1.2 and TLS 1.3 are still considered secure. Several cipher suites used in the HTTPS protocol are considered insecure, as well.

In the following we look at several security bugs and attacks. Some of them are are active, no matter whether the client is active on a PC or on a mobile phone. The reason: The open flank is on the server - consequently it is irrelevant how the server is contacted.

If communication is done with TLS using insecure protocols where these attacks can be carried out, then the communication can be intercepted. Hence mobile apps must always check the protocol version and make sure such vulnerabilities cannot exist on the server side - by preventing the use of weak ciphers. 

Heartbleed

The Heartbleed security bug affects the most popular software library used for HTTPS, OpenSSL. OpenSSL is widely used by servers such as Apache or Nginx. Heartbleed creates a weakness by which the secret keys used for the HTTPS protocol can be compromised. This results in allowing attackers to intercept the communications secured by HTTPS.

The principle of the Heartbleed bug lies in the heartbeat packets sent by the client to the server, which is a mechanism simply used to “ping” the server to check common activity.

The bug is very simple: the server will not check the length of what it receives. This means that the server can copy an arbitrary amount of its memory into the heartbleed buffer. Therefore, the receiver is able to extract a larger quantity of private memory from the remote server. This extra-data could be anything, but it could also contain secret data, including the private keys used by the server.

Of course, OpenSSL has been fixed and upgraded to a new version. However, it is not known how many servers are still using the buggy OpenSSL version. In terms of mobile banking security, this may be a real issue.

Sweet32

Sweet32 is a birthday attack on 64-bit ciphers. Roughly, Sweet32 captures approximately one terabyte of data from an HTTPS connection that is using 64-bit block ciphers like AES, Triple-DES, or Blowfish. Then a birthday attack can be performed against the block cipher used. 

The birthday paradox is a well-known problem in probability theory. Taking a set of a few random people, the probability that two of them have the same birthday is important.

If we choose n people (n<365), the probability that two of them have the same birthday is:

Sweet32

For 10 people, the probability is already p ~88.3%.

Without going further into details, this is the main idea of a birthday attack. The fact that there is a relatively high probability of the same occurrence with “small” 64-bit cipher blocks. These are used to create collisions and thus possibly usurp identity in the HTTPS protocol. 

BEAST

BEAST is short for Browser Exploit Against SSL/TLS.

For BEAST to be possible, the following conditions must be met:

  • JavaScript injecting content within the same origin policy;
  • Network sniffing;
  • A vulnerable version of SSL using a block cipher (stream ciphers like RC4 are not vulnerable) and this includes TLS 1.0.

From this, it is possible to gain access to secure cookies, even those protected by the HTTPOnly flag by deciphering the SSL session. 

POODLE

A POODLE attack (Padding Oracle On Downgraded Legacy Encryption) is an exploit that takes advantage of the way some browsers deal with encryption. This exploit primarily targets SSL 3.0.

HTTPS to HTTP Redirection Attack

In some websites, an HTTP version coexists with an HTTPS version without an HTTPS redirection. Therefore, an attacker could create a proxy to convert requests to an HTTPS to non-HTTPS without the client necessarily noticing it. Since the traffic is then redirected as HTTP, confidential data can be intercepted.

HTTPS Man-in-the-Middle Attack

Here we demonstrate how an HTTPS Man-in-the-Middle attack can be performed in the context of mobile banking. Consider the following example of using an MTIM proxy or SSLsplit to build our Man-in-the-Middle HTTPS proxy. Once the user has accepted the proxy certificate as a root authority (and there is a wide range of techniques to lure the user into doing that), then the HTTPS traffic can be dissected through one of these man-in-the-middle proxies. 

One scenario might be:

  •  A mobile user connects to a Wi-Fi;
  • The Wi-Fi hotspot asks the user to trust the root certificate;
  • The HTTPS traffic is decrypted, intercepted in clear (passwords, keys, etc.), then re-ciphered, and sent to the bank server using an on-the-fly certificate from the proxy pretending to be the client.

This attack only works when the security is purely based on HTTPS. It will not work if the data between the client and the server are additionally ciphered by anything else. 

Some Remedies Against HTTPS attacks

Checking Certificate Fingerprints

A certificate fingerprint is simply the hash value of the DER-encoded certificate presented by the server. By taking the added step to check these values against a trusted base of such fingerprints, the client cannot be fooled by a man-in-the-middle proxy issuing an on-the-fly certificate to the legitimate server. 

Using Perfect Forward Secrecy (PFS)

PFS protects the actual session from being deciphered if their (long-term) keys are compromised in the future. This is very efficient against Man-in-the-Middle attacks such as the SSL proxy attack.

Checking the Protocols, Libraries and Cipher Suite

  • Check that the HTTPS protocol is secure (TLS 1.2 and 1.3 are secure protocols);
  • Check that a non-buggy library is used;
  • Check that non-weak cipher suites are used.

In summary 

Unfortunately, the use of HTTPS Man-in-the-Middle attacks is very common; especially with mobile banking and payment applications when rogue Wi-Fi networks are used. HTTPS tunneling, which is dedicated to protecting data must itself be protected by using a certain number of precautions to prevent such attacks.

 

Read White Paper

References and Further Reading