Is there no way to bypass certificate pinning without patching apps?

Can you do anything other than patching apps’ compiled-code/cert-files (which is app-specific, requires manual analysis and patching + super-user/root) to intercept TLS traffic of apps that use certificate pinning?

The answer seems to be No, from mitmproxy’s docs:

Certificate Pinning

Some applications employ Certificate Pinning to prevent man-in-the-middle attacks. This means that mitmproxy and mitmdump’s certificates will not be accepted by these applications without modifying them. It is recommended to use the passthrough feature in order to prevent mitmproxy and mitmdump from intercepting traffic to these specific domains. If you want to intercept the pinned connections, you need to patch the application manually. For Android and (jailbroken) iOS devices, various tools exist to accomplish this.

I understand that certificate pinning is part of the trust model of these apps, at the same time as a user, I would like to sniff/intercept their traffic for analysis, locally on my device, in order to make statistics/insights on my habits and behavior, from events such as emails sent (using ProtonMail), messages sent (using Signal/WhatsApp) or any event that can be deduced from the analysis of traffic (using something similar-to/as-powerful-as mitmproxy’s Python scripting API or Scapy’s filters).

Bypassing SSL pinning Using Frida issue

I am a penetration tester, and i was doing some SSL pinning Bypass using Frida.

I have pushed all the required files, certificates , burp is intercepting traffic from the Android Studio emulator.

i have performed the steps to run frida

[Android Emulator 5554::com.*****.**** ( flagged for ethical security reasons )]-> [.] Cert Pinning Bypass/Re-Pinning [+] Loading our CA... [o] Our CA Info: CN=PortSwigger CA, OU=PortSwigger CA, O=PortSwigger, L=PortSwigger, ST=PortSwigger, C=PortSwigger [+] Creating a KeyStore for our CA... [+] Creating a TrustManager that trusts the CA in our KeyStore... [+] Our TrustManager is ready... [+] Hijacking SSLContext methods now... [-] Waiting for the app to invoke SSLContext.init()... 

And when i try to interact with the application, the application is not allowing my request through because of the missing certificate and frida is not capturing the request and bypassing the pinning knowing that i have performed all the right steps.

I am here if anyone needs to ask more question .. can you please help with the above ?

HTTP Public Key Pinning vs Certificate Transparency, which is better and why?

We are rolling out a new mobile app. Our security team recommends us to pin the public key in order to avoid MITM. iOS already has CT checks and we can enable that for the Android app as well.

The security team’s arguments for pinning are:

  1. Pinning is a more hardened solution
  2. CT is more reactive, we might have to live with a rogue certificate until it is revoked and logged in CT logs
  3. CT checks would not work in environments where corporate assets may have company PKI deployed and MITM attack is done using the company PKI

My argument for not pinning: Assume we generate a certificate and it is a 2048-bit RSA key pair. The certificate expires in 1 year, maybe 2. We go to the CA for a new certificate and the CA says “No, your key is too small, come back with a 4096 RSA key pair”. In effect, because we pinned the public key in the app, the app is bricked.

Now we release a new version of the app, but it takes typically > 1 month for the app to be adopted by all the customers. During this time, while our customers are trying to access the app at home, trying to look for offers to come and spend money in our ecosystem, they won’t be able to use the app and hence we stand to lose the customer and potential revenue.

A rogue certificate might affect 1, maybe 2 customers if someone is really being targeted to be hacked (MITM target), but the above risk is a risk to the entire customer base and for amount of time that is not directly quantifiable.

Does it really makes sense to pin? If yes, how do we mitigate the above scenario? Am I not seeing something?

Rotating TLS Certs used with Public key Pinning

I have an app which connects to an API. The API TLS certificate is about to expire and we are using Public key Pinning.

How do I rotate the certs without disabling access to our users?

When rotating certs; can I change the private key without changing the public key? I assume no as they are a key pair. Can someone confirm?

What would be the point of rotating the cert only to update the expiry date? Surely someone investing sufficient time to compromise the private key can continue to do if only the expiry date variable is changed?

I understand if it coming close to expiry I should update the cert to prevent unavailability of the service but then is it recommended to have a long expiry date on the next rotation?

When keys are rotated (say I leave the public and private key the same); is there anything mathematically or from an encryption perspective that changes if only the expiry date has changed?

Higher risk of no certificate pinning on mobile apps vs web apps?

Talking with people, it is frequently considered that having a mobile application without certificate pinning is a vulnerability. But i rarely see people mentioning it for web applications.

The question is, why is this issue only mentioned for mobile apps? Is there a higher risk derived out of this vulnerability on mobile apps?

Thinking about it, considering that the degree of difficulty is about the same for installing a rogue certificate on both pc and mobile, i would say that the vulnerability should exist in both cases, but in the case of web apps, there would be no remediation action since the hpkp which i think is the only way to achieve cert pinning is becoming obsolete.

Now none of the people i’ve talked with could give some reasonable explanations, so that’s why i wanted to see if there is indeed any good justification for the mobile cert pinning.

Is pinning global root CA almost same as not having any certificate pinning at all?

I have seen multiple mobile applications that are pinning Global Root CA’s instead of intermediate/leaf certificates. Doesn’t this expose to the same risk as not having certificate pinning at all?

Considering the classic coffee shop attack scenario where the owner of the network has a certificate issued for his domain (*.evilcoffee.com signed by DigiCert)

Now if the mobile application is trusting any certificate issued by Digicert then you can effectively MiTM? Am I missing something?

Am trying to bypass SSL pinning in an android app using a couple of tools and facing this issue?

I will tell everything form the beginning, I installed frida and objective by pip and pip3 respectively. Post that I downloaded adb from web and using adb script I connected to my genymotion android virtual device. (I checked if am really connected by gaining shell access and listing down app installed on that device)

Android version on genymotion virtual android device: 7.1.1

Command am using:

objection patchapk -s <apk_file> 

Error am getting:

No architecture specified. Determining it using `adb`... Failed to determine architecture. Is the device connected and authorized? 

Am currently on a windows machine with genymotion on vbox and Kali on VM. Am doing all this from my Kali VM, connected to genymotion virtual android device via Kali only. Can this be an issue by any means?

Please let me know if any other information is required.

Certificate Pinning for WebSockets

I have seen many implementations of certificate pinning (and public key pinning) for HTTPS connections originated from client-side apps running on web browsers and mobile devices.

I would like to know whether such certificate pinning implementations are available for websockets. In the client side (say a mobile device or web browser), can we actually implement certificate pinning / public key pinning for websockets?

If such approach is available, it would be really nice to have an explanation, ideally with links to resources/ articles/ code snippets/ libraries.