What is SSL pinning?
Mobile apps commonly use SSL to safeguard transmitted data from eavesdropping and tampering while communicating with a server. SSL application implementations trust a server with a certificate, which, in turn, is trusted by the operating system’s trust store (by default). The operating system includes a list of certificate authorities in this storage.
The developer configures SSL pinning to refuse all except one or a few predetermined certificates. The program validates the server certificate with the pinned certificate whenever it connects to a server(s). The SSL connection is made if and only if the server certificate & the pinned certificate match.
Why do we need SSL pinning?
A system library is generally responsible for setting up and managing SSL sessions. This implies that the programmer attempting to establish a connection cannot know which certificates to trust. The programmer entirely relies on the operating system’s trust store certificates.
Attackers can set up a man-in-the-middle attack against any SSL program by creating a self-signed certificate and storing it in the operating system’s trust store. Because of this, they’d be able to read and manipulate every SSL session. Adversaries could use this ability to reverse engineer the app’s protocol or extract API keys from the queries.
By fooling the end-user into installing a trusted CA through a rogue web page, attackers can also compromise SSL sessions. Alternatively, the device’s trusted root CAs can be compromised and used to produce certificates.
SSL pinning effectively protects apps from the attacks mentioned above by narrowing down the set of trustworthy certificates. It also prevents reverse engineers from installing a custom root CA to their own device’s store in order to examine the application’s functioning and communication with the server.
SSL pinning works by keeping additional information within the app to identify the server and is mainly used to prevent man-in-the-middle attacks.
What to Pin?
Either the actual server certificate or the server’s public key is pinned. We can store the exact data or a hash of it. A file hash of the certificate file or a hash of the public key string might be used. For more information, refer to this blog (Published by OWASP).
We are going to use Frida for the SSL pinning bypass.
What is Frida?
Excerpt from the Frida website:
It’s Greasemonkey for native apps, or, in more technical terms, it’s a dynamic code instrumentation toolkit. It lets you inject snippets of JavaScript or your own library into native apps on Windows, macOS, GNU/Linux, iOS, Android, and QNX. Frida also provides some simple tools built on top of the Frida API.
Because organizations are more concerned about data privacy as well as secure data transfer over the network from threats like Man-in-the-Middle (MiTM) attacks, SSL pinning bypass is a significant step that needs to be done before we even start the dynamic analysis of HTTP requests for most mobile applications nowadays.
Frida is a framework that injects scripts into native apps to modify the app’s logic in real time, making it a more dynamic approach to mobile app pen testing.
What do we need?
1) Rooted Device or Emulator
We’ll need a rooted device or emulator because we’ll inject a script into the device’s root directory. For demonstration, we’ll be utilizing Genymotion. Genymotion is simple to set up and use and can be downloaded here.
After we’ve installed Genymotion, we’ll need to set up an Android device. I’ll be using a Google Pixel XL device with the settings below.
2) Platform-tools
Platform tools for Windows can be downloaded from the following link: https://developer.android.com/studio/releases/platform-tools.
Excerpt from the official documentation:
Android SDK Platform-Tools is a component of the Android SDK. It includes tools that interface with the Android platform, primarily adb and fastboot. Although adb is required for Android app development, app developers will typically use the Studio installs.
This download is helpful if you want to use adb directly from the command line and don’t have Studio installed. Fastboot is needed to unlock your device bootloader and flash it with a new system image.
3) Frida Packages for Python
We’ll need to install a few Python packages for the Frida server.
In a terminal, type the following command:
$ pip install Frida
$ pip install objection
$ pip install frida-tools
— or —
$ python -m pip install Frida
$ python -m pip install objection
$ python -m pip install frida-tools4) Injection Script (fridascript.js)
To inject it into the target application, we’ll need to download the injection script from the link below and push it into the device.
Exploitation
Connect the device to adb
adb stands for Android Debug Bridge. It’s an official Android tool for controlling and remotely debugging Android devices.
To perform instructions on our device, we must connect it to adb. To perform this, go to Settings >> Developer options and turn on debugging mode on the device so that adb can communicate with it.
Go to the platform tools folder and enter the following command to connect the device to adb:
//adb connect <ip of device:port>
$ adb connect 192.168.54.103:5555
We can run the following command to see if our device is connected to adb:
$ adb devices
Download Frida Server
The Frida server package for our Android device must be downloaded according to the architecture version of our device. We can run the command below to find out the architecture of our device:
$ adb shell getprop ro.product.cpu.abi
In our case, the device architecture is x86.
Pushing the Proxy’s Certificate
Name the certificate cert.cer and install it on the device in the exact location of the Frida server.
// adb push <path to cer.cer> /data/local/tmp/cert-der.crt
$ adb push cer.cer /data/local/tmp/cert-der.crtFrida Server Setup
Before injecting our script, we must first run the Frida server on the device. Upload the Frida server binary file to the device. Copy the frida-server-12.4.7-android-x86file to the adb folder and rename it to frida-server.
Run the following command:
//adb push <path_of_frida_server_folder><space></data/local/tmp>
$ adb push "D:\Android Testing\platform-tools\frida-server" /data/local/tmp
Next, we’ll give the following permission to the Frida-server binary:
adb shell chmod 777 /data/local/tmp/frida-serverInjecting Script to Bypass SSL Pinning
Step 1) Push the “fridascript.js” script into device
We use the fridascript.jsscript to disable pinning on the target application. To push the fridascript.jsscript onto the device, copy it to the adb folder, and run the following command:
//adb push <path_to_fridascript.js_folder> /data/local/tmp
$ adb push "D:\Android Testing\platform-tools\fridascript.js" /data/local/tmp
Step 2) Run the following command on the device:
$ adb shell /data/local/tmp/frida-server &
This starts Frida on the device.
Step 3) Run the following command on the device:
Next, list all the devices’ running processes. We must now determine the ID of our target application. Open a new terminal and type the following command:
$ frida-ps -U
Step 4) Inject the fridascript.js script into the target application
Finally, we’ll use the following command to inject the fridascript.js script into the native application:
//frida -U -f <your_application_package_name> -l <path_to_fridascript.js_on_your_computer> --no-paus
$ frida -U -f com.twitter.android -l D:\Android Testing\platform-tools\fridascript.js --no-pausStep 5) Intercepting with Burp Suite
Burp Suite can now intercept all traffic from the target app. As long as we’re proxying traffic through Burp Suite, we’ll need to keep the Frida server running.
We have now successfully bypassed pinning. The Twitter app now trusts our MitM HTTPS proxy, allowing us to intercept and analyze the communication.
We can now study the content of each request from here or add rules to alter, mock, or completely block them.
