A Man-in-the-Middle attack can come in multiple forms. This article describes these and how you can mitigate such attacks.
A Man-in-the-Middle attacks occurs when an attacker intercepts or manipulates mobile device communications between the app/device and its backend service to gain access to sensitive information. The approach provides attackers with the ability to see any communications, modify messages using the API, steal login details or certificates from encrypted traffic, intercept sensitive commercial/personal data, or even easily launch a denial of service (DDoS) attack against the service being accessed via a mobile app.
For some time now, TLS has been mandated on both Android and iOS devices, providing a mechanism for a mobile app to verify it is communicating with a legitimate backend server. TLS uses PKI (Public Key Infrastructure) and trusted Certificate Authorities to make this happen. When a communication is made from the app to the backend service, a TLS negotiation takes place during which a chain of digital certificates are presented and are verified by the mobile client to establish the legitimacy of the server. These certificates form a trust chain that ultimately needs to lead to a root Certificate Authority (CA) certificate. The trust anchor point is established via the pool of root certificates which are pre-installed (and subsequently updated) on the mobile device itself. So far, so good.
However, if an attacker has access to a mobile device on which they can run the app, they can use a MitM tool, such as mitmproxy. There are many such tools; mitmproxy is just one example. These tools create a certificate that is installed onto the end user device. Rather than being a certificate from a root CA, it is actually a self-signed certificate that the tool has itself created. The attacker installs the certificate into the trust store on the device and when the tool intercepts traffic it will, on the fly, also 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 is installed on the device. Thus the trust chain will be verified and the traffic is successfully redirected to the MitM rather than going to the real server. From there the MitM will then connect to the real server, relaying the traffic but with the proxy in the middle able to observe all the traffic. The proxy can potentially modify the traffic in flight and it can also record and potentially replay the traffic at some later point.
Another way that the trust chain can be broken is if there is a breach of a Certificate Authority or a bad issuance of a certificate. One of the challenges of the PKI architecture is that it results in a large number of root certificates that are installed on each mobile device. If there is a data breach at any one of the CAs or, more likely, a failure or circumvention in the process that’s used to prove that you are actually the owner of a domain, an attacker could be issued with a valid certificate for your domain. It only requires a breach at any one CA for this to be a threat.
Certificate Pinning, or more properly known as Public Key Pinning, adds another verification element to the standard certificate validation used by TLS. The security of TLS relies on the trust store on the device but this may be compromised, as discussed above. Therefore an additional element, not coming from the local device trust store, is required. This is the certificate pin which is delivered to the app via the app store secure channel. The pin is not normally a copy of the entire certificate but rather is typically a hash of the certificate, or some key attributes from the certificate. The app is shipped including the pin and will only connect if it sees the expected certificate. Here is a webinar recording that covers this topic extensively.
Certificate Pinning is a topic which can take a bit of time to get your head around. It is complex, both in terms of implementation and management. If you want to dig deeper into the topic you may wish to read our MitM Whitepaper. Alternatively, you may just wish to be guided by a conversation with one of our experts regarding MitM, Certificate Pinning in general, or Approov Dynamic Certificate Pinning in particular. If so, you can request a call here.