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?

  • 1
    Looks like SSL Kill Switch 2 bypasses certificate validation altogether but you need to install that yourself on your rooted device to work. It is not something you do if you want to keep app secure. If you need that to test something using MitM attack, use some proxy tool, which creates a certificate for each site using its own CA and root CA, install that root CA on your phone and performs MitM, sending the certificate it creates. Looks like mitmproxy docs.mitmproxy.org does exactly that. That way this proxy which you control will be the only one performing mitm Aug 23 at 9:18
  • 11
    Are your users interested in breaking your encryption (as in games where cheats may be possible by MITM attacks) or both you and your users want to keep the intruders away (as in payment apps)? The possible strategy pretty much differs.
    – fraxinus
    Aug 23 at 19:21
  • 1
    "Bypass" is one word. "By Pass" means something different, and isn't applicable here. Aug 23 at 21:05
  • 1
    An app I used to work on tested for rooted devices and refused to start. I don't know how they did it - we used an external security company for all of this - and I expect that could be defeated too, but it's an acknowledgement of the problem at least. Ask the pen tester what they'd recommend to mitigate this?
    – Rup
    Aug 24 at 9:09
  • 3
    @Rup Detecting rooted devices is trivial, up until the anybody tries to hide that it's rooted. Anything that can be done to detect a rooted device (usually things like looking for a sudo binary or some such) can be hidden from one by anybody with root privileges. Root detection is right up there with DRM and obfuscation: it's impossible to do it "right", so the best you can do is slow somebody down, and create a game of cat-and-mouse as each side circumvents the other's detection/hiding in turn. It's not real security, but some people like to make things hard (for others and themselves).
    – CBHacking
    Aug 24 at 9:18

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.

  • Thanks for the detailed answer. But there are some private solutions that seem to solve this type of vulnerabilities like DexGuard for android and iXGuard for iOS. I wonder what they are doing.
    – HAK
    Aug 23 at 8:38
  • 16
    Both of those are obfuscation tools. All they do is scramble up your compiled code such that it's harder to tell what it's doing. This might also defeat attempts to hook or modify API functions, if the program doing the hooking (such as SSL Kill Switch) relies on the code being arranged a certain way. They can also include integrity self-checks, which purportedly prevent the program from being modified (unless, of course, the integrity check is itself modified out). Not using obfuscation is still not a vulnerability for all of the reasons outlined above.
    – CBHacking
    Aug 23 at 9:16

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.

  • 14
    Re-implementing security functions like this should be done carefully, if it all. There's every chance that you'll make mistakes in your implementation and leave holes in how the thing operates that wouldn't be present if you'd just used the standard implementation. Be sure to evaluate that risk against the risks that your re-implementation is attempting to avoid. Aug 23 at 9:23

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.