How to prevent bypassing of SSL certificate pinning in iOS

Nowadays, mobile apps have become the focal point in businesses such as booking, investing, food ordering, travel, shopping, banking, and more. They have become a must-have solution for small to large organizations.

However, not everything is bright, and the amount of sensitive and private information that mobile apps handle and store makes them the primary targets for people with malicious intentions. That is why security should be a priority from the start. Hacking an Android or iOS application can be relatively easy if the right measures are not taken to make it more resilient against attacks.

Here are some basic practices that should be implemented to improve mobile apps security:

•  Do not put encryption keys, access codes, or tokens in the app code:

Cyber attackers could find this data by reverse-engineering the app, all they have to do is download the app to do this, so, do not put this information in the app code.

•  Test repeatedly:

Securing a mobile app is a never-ending process. Design the code to be easy to update and patch.

Test repeatedly and fix bugs as and when they are exposed.

•  Principle of least privilege:

What is not explicitly allowed should be prohibited by default.

The principle of least privilege (PoLP), requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, etc. depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose.

• Encrypt sensitive data:

To protect the user data, use the mechanisms provided by the OS to store encrypted data. All the sensitive data collected through the mobile app should be encrypted. By encrypting data, it will impossible for cybercriminals to read them.

•  Obfuscate the code:

Bugs and vulnerabilities in code are the starting point most attackers use to break into a mobile app.

Keep the security of the code in mind from day one and harden it, making it tough to break it through.

• Beware of libraries:

Third-party libraries make our lives as developers easier, but in addition to taking into account their use licenses, we must be very careful and test the code thoroughly before using them.

• HTTPS:

Mobile apps generally communicate with a backend server, there is some sort of back and forth of data over wired or wireless communication channels.

It’s important to make data transportation as secure as possible.

Https protocol should be the standard for any communication between the mobile app and the server.

The topics mentioned above are just a set of basic measures to consider at the moment of developing a secure mobile application.

What is SSL Pinning and how does it work?

Most developers assume that using HTTPS is enough to be sure that user data transfer is fully secured and not compromised by a man-in-the-middle attack, but unfortunately is not.

A MITM occurs when an attacker places himself between the server and the client, posing as one of them. In other words, when the client connects to the server, it is actually dealing with the hacker and vice versa. Thus, even though the client “thinks” that they have established an encrypted connection to the server, they are actually “talking” to the attacker, who can view and modify the data.

One of the first things an attacker will do when reverse engineering a mobile application is to bypass the SSL/TLS protection to gain a better insight into the application’s functioning and the way it communicates with its server.

Configuration and maintenance of SSL sessions are generally delegated to a system library. This means that the application that tries to establish a connection does not determine which certificates to trust and which not. The mobile app relies entirely on the certificates that are included in the OS trust store. A researcher who generates a self-signed certificate and includes it in the operating system’s trust store can set up a man-in-the-middle attack against any app that uses SSL. This would allow him to read and manipulate every single SSL session. The attacker could use this ability to reverse engineer the protocol the app uses or to extract API keys from the requests.

Basically, SSL pinning is a technique used on the client-side to avoid MITM attacks.

The process consists of associating a host with their expected [x509 certificate](https://en.wikipedia.org/wiki/X.509) or public key. If more than one certificate or public key is accepted, the advertised identity must match one of the elements in the certificate chainset. This allows the application to trust only valid or predefined certificates or public keys.

SSL Pinning leverages knowledge of the pre-existing relationship between the client and the server to help make better security-related decisions. This technique should be used as an additional layer of security for mobile app traffic and to validate the identity of the remote host. If SSL Pinning is not implemented, the mobile application will trust the certificates installed by default in the operating system or custom certificates installed by the user allowing the proxy tools to intercept the traffic.

Implementing SSL Pinning on iOS

SSL pinning can be achieved in 3 different ways

– Certificate Pinning

– Public Key Pinning

– Hash Pinning.

Certificate SSL pinning

We store the server certificate in our application, then at runtime, we retrieve the certificate from the server and compare them. 

If they match, we can trust the server, otherwise, we can not.

However, there is a downside to pinning a certificate. Each time our server rotates it’s a certificate, we need to update our application.

Public key pinning

In this approach, we generate a key pair and put the private key on the server and the public key on the mobile app. We then verify the extracted public key against the embedded one. If it matches, we can trust the host.

By using public key pinning, we can avoid frequent application updates as the public key can remain the same for long periods.

However, there are two disadvantages to public key pinning. First, it is more difficult to work with keys as it involves the process of extracting the key from the certificate, and second, the key is static and may violate key rotation policies.

Hash pinning

In this approach, we pin the hash of the public key of the server’s certificate and compare it with the hash of the public key of the certificate received during a network request. This technique is more complex than others, but it is worth the effort. After we have the certificate, we can use the hashing algorithm that we prefer. This makes a certificate or public key anonymous.

Is it possible to bypass SSL pinning protection?

However, today adding SSL pinning is no longer enough to prevent MITM, since there are tools that allow bypass it.

Bypassing SSL pinning can be achieved in different ways:

– By avoiding the SSL pinning check or discarding the result of the check.

– By replacing the pinned data in the application, for example, the certificate asset or the hashed key.

How do I bypass SSL pinning with Frida?

Frida is a dynamic code instrumentation toolkit, which enables function hooking and allows to provide a definition to it during runtime. It works over Windows, macOS, GNU/Linux, iOS, Android, and QNX. Basically, it injects JavaScript code into a process. 

Suppose there is a function called “foo” with a specific implementation. With Frida, one can change the implementation of the “foo” function at runtime.

Furthermore, It has a vast community of users sharing their custom scripts to accomplish different kinds of tasks, from enumerating processes and attached devices, trace function calls, check memory values, kill processes, bypass SSL pinning, bypass biometrics checks, and more.

Frida isn’t the one tool someone can use to bypass SSL pinning, but the principal advantage over other tools like SSL Kill Switch 2 is that not require a rooted device to accomplish it.

So, what can we do as developers to mitigate these kinds of threats?

SSL pinning bypass mitigation

As a first step, we could use a tool to obfuscate the code, making it much more difficult for the attacker to determine which method performs the certificate validation. Obfuscation will also throw off all automated tools looking for a known method name. An obfuscator can rename methods in a different way on each application build, forcing the attacker to look up the real name in each new version.

Despite the code obfuscation, a reverse engineer with time and dedication could analyze the app control flow and at some point find the location where the certificate is verified and change it to achieve the goal he wants. So, we need to think in a different way to mitigate these types of threats. Attackers need to reverse engineer the mobile app to alter its behavior, this is the time when we can make their job harder. Implementing an anti-tamper mechanism and detecting if the app has been launched in a malicious environment it’s a better approach to deal with these kinds of attacks.

iOS Security Suite is an advanced and easy-to-use platform security library written in Swift that simplifies the implementation of anti-tampering mechanisms in iOS applications. 

Swift code is considered to be harder to manipulate dynamically than Objective-C. Since this library was written in pure Swift, the IOSSecuritySuite methods shouldn’t be exposed to Objective-C runtime, which makes it more difficult to bypass.

This library provides us an easy way to detect jailbreak, an attached debugger if the app was run in an emulator, and common reverse engineering tools running on the device. Furthermore, this library has a BSD 2 license.

With the use of this library, we can abort the app execution if some reverse engineering technique is applied, preventing an attacker from altering the normal flow of the application.

Where do we go from this? 

Since the mobile app market is growing, mobile security will continue to deliver tons of issues to deal with. 

Security is like a race between attackers and defenders, different techniques to break apps security are discovered every day and there is no silver bullet to be protected along with all threats. As developers, we should keep in mind that the data which the apps operate may be of some interest to third parties, we must be responsible and ensure that at least the basic security measures are implemented.

To conclude, adding additional protection measures in an already productive mobile app requires a significant time investment and effort. Therefore, it is worth taking care of security in the very early stages of development.