Mobile apps commonly use SSL to safeguard transmitted data from eavesdropping and tampering while communicating with a server. SSL implementations in apps trust a server that has 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.
A system library is normally in charge of setting up and managing SSL sessions. This implies that the programmer attempting to establish a connection has no way of knowing which certificates to trust. The programmer is completely reliant on the certificates in the operating system’s trust store.
Attackers can set up a man-in-the-middle attack against any program that uses SSL by creating a self-signed certificate and storing it in the operating system’s trust store. They’d be able to read and manipulate every SSL session as a result of this. 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 then utilized to produce certificates.
The use of SSL pinning effectively protects apps from the aforementioned attacks 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.
Either the real server certificate or the server’s public key is pinned. We have the option of storing 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 SSL pinning bypass.
Excerpt from the Frida website:
It’s Greasemonkey for native apps, or, put 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 you with 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 major 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 logic of the app in real-time, making it a more dynamic approach to mobile app pen testing.
We’ll need a rooted device or emulator because we’ll be injecting 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.
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 for 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 normally just use the copy Studio installs. This download is useful if you want to use adb directly from the command-line and don’t have Studio installed. (If you do have Studio installed, you might want to just use the copy it installed because Studio will automatically update it.) fastboot is needed if you want to unlock your device bootloader and flash it with a new system image.
For Frida server, we’ll need to install a few python packages. 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-tools
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.
adbstands 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 optionsand 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
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.
Name the certificate cer.cerand install it on the device in the same location as the frida-server.
// adb push <path to cer.cer> /data/local/tmp/cert-der.crt
$ adb push cer.cer /data/local/tmp/cert-der.crt
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-server
5) Injecting Script to Bypass SSL Pinning
Step 1) Push the “fridascript.js” script into device
We are using 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 running processes of devices. 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-paus
Step 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 of those requests from here, or add rules to alter, mock, or completely block them.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.
“Join us on our journey of growth and development by signing up for our comprehensive courses.“
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2024 Redfox Cyber Security Inc. All rights reserved.
