How Certificate Pinning Helps Thwart Mobile MitM Attacks

Editor's note: This post was originally published in November 2021 in Cyber Defense Magazine.

The massive deployment of mobile apps is presenting new attack surfaces to bad actors and the API channel between the apps and backend services is one of the 5 defined attack surfaces in the ecosystem. In this article we will explore the challenges of defending this channel and outline some practical steps you can take to put immediate protection in place.

Mobile app usage has been increasing year on year and that seems unlikely to change. As shown in the chart below, direct revenue derived from mobile apps is also showing impressive growth. Most consumer facing enterprises now have a mobile app since it is the preferred touchpoint for their customers and even if those apps don’t generate revenue directly for the company, trust in the mobile app platform is vital for brand reputation.

(Image source: Statista)

Attacking the API channel between mobile apps and their backend servers through Man-in-the-Middle (MitM) attacks are a growing threat for mobile users. The ability to intercept and manipulate communications between mobile devices and servers is an issue that has been known for some time and, backed by the explosive growth in mobile app usage, it has become commonplace. In spite of this, many enterprises are not clear on effective and efficient ways to combat these attacks.

In the following sections, we'll look at how certificate pinning can help thwart mobile MitM attacks, as well as the pros and cons involved with static versus dynamic pinning, and what else you could do to protect your organization's data and revenue from these types of exploits.

Man-in-the-Middle Attacks - A Brief Explainer

Man-in-the-middle attacks are when an attacker intercepts or manipulates mobile device communications to gain access to sensitive information. The bottom line is that they give attackers the ability to see any communications, modify messages using the channel, steal login details or certificates from encrypted traffic, intercept sensitive commercial/personal data, or even launch a denial of service attack against the service being accessed via a mobile app with ease.

(Image source: Approov)

You might be wondering about the fact that API traffic is normally encrypted using TLS (Transport Level Security). You are right and in TLS there's a whole protocol around ensuring that the mobile app thinks it's talking to a legitimate backend server. However a MitM can insert themselves into the channel such that the mobile app ends up talking to the MitM actor over an encrypted channel thinking that it's actually the backend server. Thus the MitM can see all the traffic, potentially modify the traffic, and then transmit that on, again over an encrypted channel back to the backend service. Let’s look at how TLS is supposed to work and how it can be manipulated.

When a communication is made from the app to the backend service, there is a certificate that is on your server that's part of an overall trust chain that proves the legitimacy of that particular server and that it actually belongs to the person you say it belongs to. This uses public key infrastructure (PKI) and during the negotiation a number of different certificates are presented and are checked by the client to prove that they are correct and this follows a trust chain that ultimately needs to lead to a root certificate authority. The anchor point in terms of trust is the fact that there are a number of certificates which are essentially pre-installed and updated on the mobile device itself from certificate authorities and you only accept the traffic if you have a chain of trust leading there.

Now, there are a couple of ways that this trust chain can be subverted. One way is to use a MitM tool, of which there are many, such as mitmproxy. In such cases you’ll be analyzing traffic from a mobile app and you're also controlling the device. Tools such as mitmproxy create a certificate that is installed onto the end user device. Rather than being a certificate from a root certificate authority, it is actually a self-signed certificate that the tool has made up. You install it into the trust store on the device and then when the tool intercepts traffic, on the fly it will create leaf certificates for the particular domains that you are visiting, which have a chain of trust back to the self-signed certificate authority that you have put on the device. Thus, everything will check out on the trust side and the traffic is redirected to the MitM rather than actually going to the server. From there the MitM will then connect to the real server, allowing the traffic to continue but actually there's this proxy in the middle that's seeing all the traffic. You can replay the traffic and you can now modify the traffic if you want.

(Image source: Approov)

The other way that you can break the trust is if there has been a breach of a certificate authority or a bad issuance of a certificate. One of the weaknesses of the PKI architecture is the fact that there are a large number of root certificate authorities that are installed on the device and if there's a breach in any of those then that could lead to a situation in which a certificate for a domain that you're connecting to you could have an attacker certificate incorrectly issued.  

So the trust is only as strong as the weakest link.

The Benefits of Certificate Pinning

Certificate pinning helps mobile app developers protect mobile apps from the MitM attacks described above. However, despite its usefulness, it isn't widely used.

Certificate pinning allows mobile applications to restrict communication only to servers with a valid certificate matching the expected value (pin). The connection is terminated immediately if communication is attempted with any server that doesn't match this "expected" value.

(Image source: Approov)

In the past, certificate pinning has been challenging to implement and highly reliant on the networking stack in use. DataTheorem's TrustKit, as always, has been a fantastic tool for putting it into action. However, Google and Apple have recently enhanced their platforms to simplify the process, removing any dependency on the network stack.

Since Android 7, Google has supported pinning. Developers simply define pins in the file's particular XML syntax. Apple has lately followed suit and added NSPinnedDomains support with iOS 14. Developers may add Pins by entering them in the Info.plist file for the app in the correct format.

There's now some solid platform support, but the configuration part is tricky, especially if you're not familiar with PKI and certificate management. The majority of the setup is based on issuing numerous complex OpenSSL commands and managing certificate files in various formats.

If you want to get started with understanding and implementing certificate pinning, this free Pinning Generator Tool makes it simple to generate and maintain pinning configurations for mobile apps, ensuring that they are kept up to date on Android and iOS.

Static Pinning Risks

Unfortunately, certificate pinning isn't quite the panacea for preventing MiTM attacks, particular for mobile. There are certain risks where a certificate pin is set statically as described above. For example, when you hardcode the pins into an app before releasing it, there are a few things to consider:

• If somebody with malicious intent gains access to one of your private keys that have been used in production, they could then use this key on any other server linked to your mobile application and have complete control over all communications from users' devices, without them knowing anything was amiss;
• If you make changes (for instance, by changing encryption algorithms), old versions of the code using static pinning will break;
• If there is a problem with the pins in your mobile app and you release an updated app, users will remain vulnerable until they get around to updating it.

A good example of a situation where static pinning was disastrous is the 2016 Barclays Bank UK incident. The bank's mobile application had been pinning an obsolete intermediate certificate in the mobile application - making transaction authentication impossible. Hundreds of thousands of consumer payment transactions were affected due to the outage, which prevented many small and medium-sized enterprises from conducting important transactions. As a result, many companies had to close their doors at 8:30 am on 25th November 2016 (Black Friday) and for the rest of the festive period leading to immense financial losses. In addition, it had a significant negative impact on Barclays' reputation and its business customers.

The Need for an Alternative Pinning Approach

What mobile app developers need is a way to pin certificates that don't require static pins. Instead, mobile applications should have access to dynamic or live pinned certificates from an online service so they can be updated automatically on the fly - without having users download and install updates for their apps every time there's a change in security infrastructure.

Essentially, this approach allows mobile application developers to stay one step ahead of hackers by keeping up with changes in certificate authorities' keys over time while minimizing downtime due to misconfiguration, avoiding any potential reputational damage among consumers that could lead them away from using your business' mobile offering altogether.

This would allow developers and DevOps teams to avoid further incidents like Barclays' and improve customer experience over mobile. Certificate pinning must be implemented for all APIs that service mobile apps in industries which handle commercially or personally sensitive data. Trust is a major factor in mobile security, and app developers need to do everything they can to protect their customers from cyber-attacks while also maintaining trust among their users that the mobile application has been designed with privacy and data protection as top priorities.