Man-in-the-Middle (MitM), or more correctly Person-in-the-Middle, is the technique of inserting yourself into API traffic to observe or manipulate requests and transactions as they pass by. In this article we’ll look at how it’s done and what you should do to prevent it, exploding a few misapprehensions on the way.
The basic concept of MitM is to convince the client and the server that they are communicating with each other, when in fact a third party is impersonating both ends of the channel. Common use cases might be an API between a web page and a server which services it, or an API between a mobile app and a server.
For bad actors MitM is ideal for researching a client-server communication channel in order to establish what attacks might be possible. Examples of potential exploits which could be researched using MitM activities are:
As should be evident by now, the ability to MitM API traffic opens up a veritable Pandora’s Box of possibilities for the bad guys. Chambers Dictionary’s definition of Pandora’s Box as “Any source of great or unexpected troubles” seems wholly appropriate in this case.
The Approov team has previously written extensively and in glorious technical detail about how MitM attacks are carried out and what can be done about it, including providing illustrative repos so readers can follow step by step.
Before introducing those articles, it would be helpful to outline standard approaches taken to protect APIs and how bad actors typically circumvent them. We will particularly focus on APIs which service mobile apps because they are undoubtedly the hardest to protect.
Since 2016 (iOS) and 2018 (Android), APIs connecting to mobile devices have been mandated to use Transport Layer Security (TLS) to implement end to end encryption of the channel. This is a welcome and necessary first step. Part of the TLS protocol requires the presentation and checking of public keys between the mobile app and the backend server or endpoint. These keys or certificates are accepted by the mobile device if signed by a recognized Certificate Authority (CA) and if that authority exists within the device's CA trust store. Any MitM tool, such as mitmproxy, will present its own key to the mobile app which will not be accepted since it is not signed by a CA which is contained in the mobile device’s trust store. For MitM to work, the attacker first has to add the required CA to the trust store - something which is difficult, but far from impossible.
Beyond TLS, certificate pinning is used to further lock down the connection. With pinning in place, the supplied key needs to be signed by a CA in the mobile device’s trust store AND it needs to match one of the set of certificates which are encoded into the app itself. For the hacker, this means that the app needs to be modified to change the stored certificate set, or the check needs to be bypassed. Again, this is challenging but can be done with the help of third party free tools.
For a deeper understanding of how all this work, a sample of blog articles on the topic from the Approov team are listed below:
Approov is a security solution to ensure APIs which service mobile apps can only be used by genuine instances of the apps associated with the APIs. To achieve this we use a patented method to check that the ‘DNA’ of the mobile app is present and unmodified.
We also make a series of checks of the runtime environment in which the mobile app is running in order to identify situations where a genuine mobile app is running in an unsafe environment. This is important for preventing MitM attacks because detecting the existence of the aforementioned third party tools required to manipulate mobile apps - and generating an invalid Approov token when the detection occurs - is the most effective way of spotting such nefarious activities.
Over and above the base capabilities of Approov in detecting MitM attacks, the solution also has a built in dynamic certificate pinning feature which will enable you to implement, monitor and manage your pinned connections with ease. You are of course able to set up your own certificate pinning and operate it alongside Approov, but if you use the Approov feature then one of the major benefits is that you can update your pins over-the-air via the Approov service. This means that if a key or certificate is compromised or needs to be rotated for any reason, you can implement the change immediately in all installed apps. There is no need to release a new mobile app version.
The Approov service over-the-air feature also allows you to update your security policies instantaneously and as frequently as necessary in the field without disturbing your app users. This could be important in a MitM context because if a new hacking tool emerges then we would add a new detection for that tool and you would want to update your security policy to ensure that detection of the new hacking tool was included as a reason to issue an invalid Approov token.
Man-in-the-Middle attacks are very important to detect and prevent because of the sheer scale and bread of exploits which can emanate from them. Don’t be fooled into thinking that obfuscation and anti-tamper on the mobile app side or rate limiting and geo blocking on the server side is sufficient. It isn’t.
Certificate pinning is a must on all APIs which service mobile apps. That already raises the security bar but it isn’t enough. The ability to detect the presence of tools and frameworks likely to be associated with unpinning is critical too, otherwise you may be blind to the interception and manipulation of your sensitive data.
Photo created by katemangostar - www.freepik.com