4

I am trying to mitigate SSL bypassing on a jailbroken iOS. I am unable to find any good work around as Mobile Substrate and SSL kill switch are able to bypass SSL.

I have tried two things:

  • SSL Pinning
  • Detect jailbreak and stop the application

Both can be cracked. My application handles confidential data so securing from SSL kill switch and mobile substrate is necessary.

Edit: Thanks everyone for your wonderful responses. I recently came across a security project OWASP, containing the top risks developers ignore during the developement phases. So my checklist got a whole lot bigger:

They also have a cheatsheet for iOS security testing. So taking all the security measurements are a head ache and i don't think my employer is ready for it since its a time consuming effort. So from the list I am choosing:

  • Securing data storage
  • TLS(Authorization and Authentication i.e. 2 way SSL)
  • Binary protection

Any opinion in this regard as if securing these 3 will be enough? Also the application I am working on is an e-banking application if someone is wordering.

Mohsin Khan
  • 742
  • 1
  • 4
  • 9
  • 3
    If you do that, then if your app is important enough, someone will bypass your SSL bypass mitigation. And then you'll add SSL bypass mitigation bypass mitigation. And then they'll bypass your SSL bypass mitigation bypass mitigation. And so on. *The user has full control over the device* - if they really wanted to, they could just make the device skip over your mitigation code. – user253751 Sep 15 '15 at 22:59
  • So in the end we are again at the basics of information security, We can make it hard for an attacker to break in but can not guarantee foolproof security. – Mohsin Khan Sep 16 '15 at 06:02

2 Answers2

17

I am trying to mitigate SSL bypassing on a jailbroken iOS. ... My application handles confidential data so securing from SSL kill switch and mobile substrate is necessary.

There is nothing to mitigate here. SSL is only used for transport level security, that is to protect everything between the client and the server. It is not used to protect the data on the client or data on the server itself. And even with a jailbroken device the transport is still secure, i.e. no man-in-the-middle can read the data unless the owner of the device explicitly made this possible by changing your application or installing another trusted CA.

If you send data to a device which is outside of your control you must expect that the current owner of the device will be able to read and manipulate the data. Thus you should not send any data to the device which the user should not see and you should not expect any data you get back to be harmless.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 10
    so it means I must assume that my application will be ripped apart by someone and nothing should be sent to a user that i don't want to disclose, I am thinking about it this way, thanks – Mohsin Khan Sep 15 '15 at 11:12
  • 1
    @mohsinkhan You can always look at doing some binary protection for your application to prevent people from ripping it apart. That can be extended to do multiple things, such as jailbreak detection, protect against reverse engineering, etc. – sir_k Sep 15 '15 at 12:41
  • 2
    As none of those methods are foolproof @FlorinCoada, you must still think of the client as under the user's control and implement thusly. – Neil Smithline Sep 15 '15 at 12:58
  • 1
    Steffen, either you or I have misunderstood something here. A device with SSL Kill Switch has disabled certificate validation. This specifically *does* enable man-in-the-middle attacks. The transport is *not* secure under this circumstance. Your points about sending data to a device outside your control are still valid and good advice as are these points about no tamper detection being foolproof, just not the points about the transport still being secure. – thomasrutter Sep 16 '15 at 00:53
  • 1
    @fjw: Using the kill switch is covered by "...no man-in-the-middle can read the data unless the owner of the device explicitly made this possible by changing your application ...". The main point is that the owner is in control of the device and all the data which are stored on it or pass through it and not the developer of the application. – Steffen Ullrich Sep 16 '15 at 03:00
6

Jailbreaking == Dealbreaking

If the device is jailbroken, then you have already lost. You cannot trust a jailbroken system.

You can make an effort to detect the jailbreak and then refuse to run. (This will probably help you deal with casual jailbreakers.) But none of these detection methods are foolproof. Because, well, you cannot trust a jailbroken system.

Further reading: Questions about (detecting) Jailbreaks:

Community
  • 1
StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
  • Since I will be issuing a client certificate to a user upon initial startup of the application so if I am able to detect a jailbreak at any point during the life of my application i can revoke the client certificate but that again is only possible if my jailbreak detection code is not against apple publishing rules, right? – Mohsin Khan Sep 15 '15 at 10:57
  • I don't know IOS or Apple policies very well, but that seems to be the case, yes. I don't envy you. – StackzOfZtuff Sep 15 '15 at 11:00
  • 6
    @mohsinkhan - you cannot guarantee 100% jailbreak detection so don't rely on it for your security. Make your app secure even in the face of a jailbreak. – Neil Smithline Sep 15 '15 at 12:57
  • I feel like this answer, although true, is a bit misleading. If a jailbroken device allows a user to circumvent your security, your security model was fundamentally flawed from the beginning. Systems should remain secure even if a client is compromised. – Joseph Sible-Reinstate Monica Mar 13 '17 at 19:52
  • @JosephSible: I agree. – StackzOfZtuff Mar 13 '17 at 20:11