WHAT IS CERTIFICATE PINNING?

Certificate pinning is the process of associating a host with their expected X.509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or ‘pinned’ to the host.

A host or service’s certificate or public key can be added to an application at development time, or it can be added upon first encountering the certificate or public key. The former – adding at development time – is preferred since preloading the certificate or public key out of band usually means the attacker cannot taint the pin. If the certificate or public key is added upon first encounter, this is known as key continuity. Key continuity can fail if the attacker has a privileged position during the first encounter.

Pinning leverages knowledge of the pre-existing relationship between the user and an organization or service to help make better security-related decisions. Because the application already has information on the server or service, it does not need to rely on generalized mechanisms meant to solve the key distribution problem. That is, it does not need to turn to DNS for name/address mappings or trusted CAs for bindings and status. No key distribution problems when there is no key distribution!

WHY SHOULD YOU ALWAYS PIN?

Mobile applications should utilise either certificate or public key pinning in order to ensure that communications are secure. This is usually implemented when the developer of the application needs to validate the remote host’s identity or when operating in a hostile environment. Since one or both of these are almost always true, it is recommended that the majority of applications implement pinning.

OWASP’s page on Certificate and Public Key Pinning[1] reads:

“You should pin anytime you want to be relatively certain of the remote host’s identity or when operating in a hostile environment. Since one or both are almost always true, you should probably pin all the time.”

– https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

WHERE TO PIN?

Leaf certificate

• Guarantees with close to 100% certainty that this is your certificate
  • even if Root CA was compromised
• If the certificate becomes invalid for some reason (either normal expiration or compromise) the app will be bricked until you can push an update out
• Allows self-signed certificates – which can be a good thing from an ease of maintenance perspective

Root certificate

• By pinning against the root certificate you are trusting the root certificate authority as well as any intermediaries they trust not to mis-issue certificates
• If CA gets compromised it’s game over
• Very important to maintain strong certificate validation
  • Pinning is not an excuse for bad certificate validation!

Intermediate certificate:

• By pinning against an intermediate certificate you are trusting that the intermediate certificate authority to not mis-issue a certificate for your server(s)
• As long as you stick to the same certificate provider then any changes to your leaf certificates will work without having to update your app

WHAT TO PIN?

Certificate

• Normally the certificate is easiest to pin
• At runtime, you retrieve the website or server’s certificate
• You compare the retrieved certificate with the certificate embedded within the application
• If the site/service rotates its certificate on a regular basis, then your application would need to be updated regularly

Public key

• More flexible
• A little trickier due to the extra steps necessary to extract the public key from a certificate
  • Its harder to work with keys since you must extract the key from the certificate – can be somewhat of a pain in Cocoa/CocoaTouch and OpenSSL.
• As with a certificate, the program checks the extracted public key with its embedded copy of the public key

Hash

• Allows you to anonymize a certificate or public key
  • this might be important if you application is concerned about leaking information during decompilation and reverse engineering
• A digested certificate fingerprint is often available as a native API for many libraries, so its convenient to use
• An organization might want to supply a reserve identity in case the primary identity is compromised

As these examples show, there are different implications that should be considered when implementing certificate pinning

How to pentest ???

1. Download and install the device on genymotion / physical device/android studio emulator

2. Install Frida and objection tools

python -m pip install Frida
python -m pip install frida-tools
python -m pip install objection 
or 
pip install Frida
pip install frida-tools
pip install objection

3. Download ADB platform-tools or Setup ADB in the distro

4. Download Frida injection script

https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/

or

https://codeshare.frida.re/@sowdust/universal-android-ssl-pinning-bypass-2/

5. Connect device to adb

//adb connect <ip of device:port>

6.Download frida server for supported android device’s arch version
7. To find out arch version of device

adb shell getprop ro.product.cpu.abi

8. Install the target application on the device.
9. Push Frida-server into the device:

//adb push <path of frida-server folder><space></data/local/tmp>

note :- make sure you extract it in your local pentest box first. 
link - https://github.com/frida/frida/releases/tag/12.4.7

Use these files as per your architecture :- 
frida-server-12.4.7-linux-x86_64.xz

frida-server-12.4.7-macos-x86_64.xz

10. Give permissions to frida-server:

adb shell chmod 777 /data/local/tmp/frida-server

11. Setup burpsuite
12. Pushing the proxy’s CA Certificate

// adb push <path to cacert.der> /data/local/tmp/cert-der.crt

13. Push fridascript.js into device:

//adb push <path to fridascript.js folder> /data/local/tmp

14. Check and run frida server in device

adb shell /data/local/tmp/frida-server &

15. List all running processes on device:

frida-ps -U

16.Locate your application’s package name
17. Hook fridascript.js into target application

//frida -U -f <your_application_package_name> -l <path_to_fridascript.js_on_your_computer> --no-paus

18. Intercept traffic in BurpSuite.

Issues Troubleshooting:

1. ADB Deamon failed to connect

If you are getting error like this:

adb devices
adb server is out of date. killing...
cannot bind 'tcp:5037'
ADB server didn't ACK
*failed to start daemon*
error:

i. Open environment System properties>>Advanced>>Environment Variables
ii. Click on the path and delete the entry of C:/Android or path where ADB tools are pointed
iii. Copy all platform tools into genymotion>>tools folder
iv. Create a new path and add a path of genymotion>>tools folder.

2. frida/ pip is not recognized as an internal or external command
i. Open environment System properties>>Advanced>>Environment Variables
ii. Create new path and add path of Python>>script folder

3. Arm translation error while installing application into device.

i. Download arm translation file from here
https://androidfilehost.com/?fid=23252070760974384

ii. Drag and drop file into device emulator or flash this file from recovery if you are using physical device
iii. Restart device and you will be able to drag and drop install target application

4. Failed to spawn: the ‘argv’ option is not supported when spawning Android apps

Check your fridascript.js path on your computer. Path maybe incorrect. You have to give the absolute path of fridascript.js file. Absolute path?

5. Started frida server but not able to list services

Disconnect and re-connect wifi in device.