By Anders Kursar =
Certificate pinning is a client side security measure used by applications to make sure that certificate provided to the server side is the certificate that is expected. Server x509 certificates or public key are provided within the application locally which makes it possible to manipulate the certificates or keys.
Certificate pinning is perfect for mobile applications because mobile apps only have a small set of servers to connect to and they generally know what host they need to connect to. An app will connect to a server and compare the certificate that is pinned inside of the app to the certificate provided by the root server. When it is successful the app will run as normal, when it fails the app traffic will be denied and you will not be able to use the app as intended.
There are two ways to bypass certificate pinning, One way being disassembling the application to remove or change the certificate logic, the other would be to switch the embedded certificate with your own certificate.
Bypassing certificate pinning using either of these methods allows you effectively man in the middle attack apps that were once protected with HTTPS and SSL, being able to see peoples session tokens and even seeing usernames and passwords in plain text in a tool like burp suite or fiddler. In order to leverage these attacks users will have to sideload the malicious app and download them onto their device. Once they find the app online and install it on their device it will act as if nothing had been changed but communication to and from the server has been compromised.
The two ways to setup an environment to test these methods are to either emulate an android device or to use adb pull the apk from you phone or find an apk on the internet. Once you have an app you would like to test against you disassemble the app using apktool with the option -d and use option -o to assign it to a specific file. For this post I will be working with everyone’s favorite dating app Tinder.
Once the apk is disassembled the file structure is easy to sift through and the important stuff is most likely in one of the smali files.
Using grep we can search for specific terms in the directory such as “X509TrustManager, cert, pinning.” These terms will point you in the right direction and will show you which folders and what files you should be looking into.
Using grep I searched through my file “tinder.apk_disassembled” for the term “X509TrustManager” and it returned these results.
We can narrow down your search by looking for specific methods within the files. Looking for methods like “checkClientTrusted, checkServerTrusted, and getAcceptedIssuers” will show the specific functions that we are looking for to see the pinning logic.
This will provide us with the path to the files containing the methods we are looking for in the decompiled apk file. At the first and last line of all three of these methods we will add the “return-void” opcode to return void in these methods.
Once we have modified the the pinned certificate logic we need to reassemble the apk and then sign the apk with our own private key. With our apktool we use the option b to build the newly modified apk. Once the app is built we need to generate a private key.
After we build the app we need to generate a private key to sign the app with.
After the key is generated we need to use jarsigner to resign the app and then it can be pushed out to devices, distributed online for people to sideload.
After this the app needs to just be reinstalled on the device and tested against. After install the app still works as intended but is now vulnerable to man in the middle attack due to the pinned certificate being bypassed. With the secure communication no longer there we can now see things such as cookies, session tokens, usernames and passwords as if they have been sent over HTTP and sent in plain text. Mitigation for this would be to simply not sideload apps that are available on the playstore and to make sure your apps are verified and that they have not been modified in any way.