Avoid disabling certificate pinning Android

Question

I am developing an Android application that uses Certificate Pinning (in a similar fashion such this ).

However, I've came across dynamic instrumentation libraries such as Frida , or worse yet, Objection , that can bypass this safeguard.

I understand that security must be implemented on server side, but, I'd like to keep prying eyes outside my API. Moreover I also understand that Java executables are easy to disassemble and analyze.

How can I make this process more difficult for an attacker, ie make basic commands such as objection 's

android sslpinning disable

fail and harden my app? I've seen that depending on the namings of the assets this process also crashes.

Any ideas?

Answer 1

Several harding frameworks can make it more difficult for Frida and similar tools to attach and manipulate the app process. However with enough time, motivation and/or money you can even break those frameworks.

However usually it is not the question "using a hardening framework or not" but "how many money are you willing to pay to get this little extra protection?

From my knowledge there are no free or even cheap hardening frameworks (please correct me if I am wrong and provide links to those free/cheap solutions with good protection), therefore it is just a question how much protection you want and how much you are willing to pay.

Note: Proguard and R8 are not hardening frameworks! They only just obfuscate the code a bit, but especially when it comes to certificate pinning and disabling this via Frida they do not offer any protection!

Answer 2

Possible Solution

How can I make this process more difficult for an attacker

A possible solution for your problem is to use a Mobile App Attestation solution to guarantee at run-time that your mobile app is not being MitM attacked, is not tampered, is not running in a rooted device, is not attached to a debugger and no instrumentation frameworks is present. This is achieved by running a SDK in the background that will communicate with a service running in the cloud to attest the integrity of the mobile app and the device is running on. The SDK in the mobile app doesn't make any decisions about the integrity of the app or mobile device, that is done in the cloud service, based on measurements provided by the mobile app.

So on a successful attestation of the mobile app integrity, by the cloud service, a short time lived JWT token is issued and signed with a secret that only the API server and the Mobile App Attestation service in the cloud are aware. In the case of failure on the mobile app attestation the JWT token is signed with a secret that the API server does not know.

Now the App must sent with every API call the JWT token in the headers of the request. This will allow the API server to only serve requests when it can verify the signature and expiration time in the JWT token and refuse them when it fails the verification.

Once the secret used by the Mobile App Attestation service is not known by the mobile app, is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.

So this solution works in a positive detection model without false positives, thus not blocking legit users while keeping the bad guys at bays.

Any ideas?

You can try to roll your own solution or you can look for an existing Mobile App Attestation SAAS solution, like Approov (I work here), that provides SDKs for several platforms, including iOS, Android, React Native and others. The integration will also need a small check in the API server code to verify the JWT token issued by the cloud service. This check is necessary for the API server to be able to decide what requests to serve and what ones to deny.

Summary

In the end, the solution to use in order to protect your API server and mobile app must be chosen in accordance with the value of what you are trying to protect and the legal requirements for that type of data, like the GDPR regulations in Europe.

Going the Extra Mile

You seem to be into mobile app security, does I would like to recommend you:

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.