2 min read

Addressing HTTPS Vulnerabilities in Mobile Banking and Payment Apps

Picture of Martin Rupp (guest) Martin Rupp (guest) : 16. April 2020

Mobile App Security MASC RASP
Addressing HTTPS Vulnerabilities in Mobile Banking and Payment Apps

Here we describe some of the HTTPS vulnerabilities in the context of mobile banking and their countermeasures.

Risks with HTTPS

SSL Protocol and TLS 1.0 or 1.1

In short, HTTPS should be using TLS 1.2+. This is because other protocols that may be used for HTTPS, like the Secure Socket Layer (SSL) protocols (SSL 1.0, 2.0 and 3.0), as well as the Transport Layer Security (TLS) protocols version 1.0 and 1.1, are considered to be insecure and broken.

SSL is vulnerable to the POODLE attack.

A version of POODLE also targets TLS. Heartbleed targets the OpenSSL implementation of SSL/TLS which is by far the most popular library used for SSL and TLS. Sweet32 targets several 64-bit ciphers used in TLS as well. Finally, BEAST targets TLS 1.0 itself.

Man-in-the-Middle Attacks

Because of its structure, HTTPS is totally vulnerable to man-in-the-middle attacks. If an attacker manages to have a target user accept a ‘rogue’ certificate, then a proxy SSL server can stand in the middle and record all the HTTPS traffic in clear.

For example, if the user accepts the root certificate of a ‘spy’ server, then the traffic to the legitimate server can be redirected to the spy server by modifying the host file of the user, by rerouting, or by using a rogue DNS. The user will be presented with a valid certificate since the user previously accepted the rogue root certificate. Therefore, the connection to the web server will look perfectly normal. The HTTPS traffic can then be deciphered within the proxy SSL server, reciphered, and forwarded to the legitimate web server.

Men-in-the-middle-attacks

Countermeasures

Several countermeasures can be deployed in order to prevent the attacks on HTTPS: 

  • Creating an additional secure channel, for example, ciphering the data inside the HTTPS layer itself. This method can protect against MITM attacks as it allows to tunnel the data inside the https tunnel itself from the mobile banking or payment app to a remote server but it requires an adequate software on the server side to decipher/cipher the data as well. 
  • Checking the fingerprint of the certificate presented to the client to prevent a fake certificate to be sent by a rogue SSL proxy. Pinpointing the remote SSL certificate prevents the SSL rogue proxy scenario, that we described previously, to operate.
  • Checking the cipher suite and protocols used by the client/app to prevent the use of insecure ciphers, the SSL protocol, or TLS 1.0/1.1 protocol. The mobile banking or payment application shouldn’t be allowed to use weak ciphers, e.g the one vulnerable to “birthday attacks”, etc.
  • Additionally, a dedicated secure proxy for all the traffic between the mobile app and the outside world could be implemented to prevent a rogue HTTPS proxy to operate. All the https traffic between the mobile banking or payment application should be filtered by a proxy located inside the mobile OS itself and this proxy should make all the necessary security checks.

Concluding Words

Communications between mobile banking apps and the remote bank servers must be done inside an end-to-end secure channel. In the context of securing mobile applications, TLS is mandatory. This is to prevent “sniffing” of the sensitive data, in the event that hackers are intercepting the communication. The most convenient secure channel is the HTTPS protocol. Generally, HTTPS is considered totally secure. Unfortunately, this is not completely true - which is why additional protection measures, as described above, are needed when deploying highly sensitive and targeted financial apps.

 

Read White Paper

References and Further Reading