Can we prevent SSL Pinning Bypass by pinning key instead of certificate?

Question

I have certificate pinning implemented in my iOS and Android apps. But when apps were pen-tested, we got the report from the pentester saying SSL implementation is weak in both the apps and can be easily bypassed using an SSL by-pass tool.

For iOS it was revealed that the SSL by pass tool was the notorious SSL Kill Switch 2 app. Now as far as I have googled, the SSL Kill Switch 2 app exploits the OS level weakness to bypass the pinning check altogether.

Our team is looking into solutions to prevent or at least detect the bypassing. And one of the solutions coined was to use public key pinning instead of certificate pinning.

Now as per my understanding, since SSL Kill Switch 2 works on OS level, it doesn't matter if we pin the certificate or the public key (or public key hash). It's always gonna bypass.

So I wanted the advice of someone who has gone through this situation or has the expertise. If its worth implementing public key (or public key hash) pinning instead of the certificate pinning. Do my app stand a chance against pentest after the change?

Answer 1

Unless you specified that your software has to be secure against TLS interception even in the case of a jailbroken/rooted machine - which I hope you didn't, because that's impossible and a fool's errand to attempt - your pentester has... no idea what they're talking about and I hope you didn't pay them much for it.

SSL Kill Switch 2 isn't a weakness in your SSL implementation, and it isn't a vulnerability in general. It's a tool for - on a fully rooted device - straight-up modifying your app's use of system libraries. It in no way qualifies as an app vulnerability, for the following reasons:

• The "attacker" needs to already have control of the operating system (not even normal user control, but actually root privileges). There is no possibility of securing a user-space app against a malicious OS.
• It requires malicious action on the part of the ostensible victim of any attack (the user, whose app login tokens or whatever are supposedly at risk). Unless you're trying to keep stuff in your app secret even from the user of jailbroken phones - which, again, indicates some bad choices in your design, and a lot of wasted time in your future trying to implement unspoofable jailbreak detection and/or snake-oil code obfuscation - pinning is to protect the user; it's incoherent to think of them as the attacker of their own secrets.
• The actual attackers can't do this. On a non-jailbroken phone, apps can't modify each other (or system libraries) at all. Even on a jailbroken phone, apps are still secure against remote attacks (at least, to the extent that the OS is secured against remote code execution in general; if the user has SSH enabled with a weak password, that's a vulnerability but it isn't your vulnerability). An "SSL pinning bypass" implies that an attacker is able to get your app to make an insecure connection, and even jailbreaking doesn't do that unless the attacker's code is already executing on the device.
• There's nothing wrong with your code. It's quite reasonable to assume that your app will operate in an environment where the system TLS APIs do, in fact, create secure connections (and allow you to pin the cert or key of the server, as per their API contract). You could do something like bundle your own copy of OpenSSL and use that for the connection, instead of the system library, but you don't need to and it wouldn't really help anyhow (the "pentester" would just modify that instead).

---

Don't get me wrong, actual pentesters test on jailbroken devices specifically so they can do things like run SSL Kill Switch and disable pinning (or TLS in general). But that doesn't go in the report as a vulnerability. It's a way to find vulnerabilities - such as that your app is using hardcoded secrets, or is vulnerable to deserialization attacks, or that your server is vulnerable to an authorization bypass, or so on - but it isn't itself a vuln. Saying it is would be like saying a web app is vulnerable to XSS because the user can install an extension that injects scripts into the page. This is obvious, unavoidable, not your fault, and outright stupid to flag as an issue unless you're somehow trying to hide secrets even from the app's users.

Answer 2

You cannot prevent a determined reverse engineer from bypassing your controls. You can make it more difficult but cannot prevent it. Pinning a key won't help you in this case.

Popular SSL pinning bypass tools can easily disable popular SSL pinning methods and they usually require root access. Your app can detect and refuse to work on jailbroken/rooted devices as an additional defense. (Then one can argue that your detection method is weak and can be bypassed easily)

One way to make SSL pinning bypass harder is implementing your custom pinning code. If you do that, an attacker will have to decompile the app, understand what you did and patch it. However it usually is not worth the effort.

Answer 3

Can we prevent SSL Pinning Bypass by pinning key instead of certificate? If its worth implementing public key (or public key hash) pinning instead of the certificate pinning.

A certificate is a piece of signed information. This information contains the public key. When pinning the certificate, you automatically also pin the public key, because it's contained in the certificate. So pinning the key does not and cannot give you additional security in this regard.

However, pinning the key instead of the certificate may be useful from a operations perspective. When pinning the key, you can change certificates while keeping the same key. This may be useful if you want to change the pin less often, or if your certificate authority (CA) gets compromised and you need to switch to another CA in a hurry.