Threema Revisited.

So the Treema bug I found a few years ago was fairly cool in my opinion, something a bit different anyway. So it was disappointing that Threema didn’t respond to me at all and then released a patched/updated Threema to the AppStore with something like “general improvements’ in the change-log.. lovely.. very general.

Well, anyway… process this for a second “All UI exploits are vulnerabilities in code; but not all vulnerabilities in code are UI exploitable.“. This should be pretty obvious… but if you forget it and find a UI bug in an iOS app, you might be passing up a 2nd vulnerability if you’re faced against lazy devs. Here’s how the same attack looks today:

So, while the UI was fixed (no more modal alerts), it was of course still possible, via Cycript, to attempt more unlock attempts than you were allowed (although in fairness, this would be effectively impossible to mitigate against) and you can even dismiss the alertView if you want (of course you can, its runtime manipulation.. you can draw dogs on the screen if you want).
Although actually… actually.. ACTUALLY.. the real problem was not the fact that you could go over your allocated unlock attempts to get at the user’s data, the crux of the problem was that Threema chose to make it so that the user’s data is not encrypted with a cryptosystem which NEEDS the passcode input. If this was the case, then while you would be able to run around all of the app’s different views as much as you like, the user’s data would not populate those views; as without a successful decryption process, the user’s data simply wouldn’t exist yet. That was the problem.
Ultimately, their fix didnt do this.. infact, using runtime manipulation you can break the app far more simply than using brute-force;
Boot up your copies of Cycript and have a guess what this line does:

Yup, its exactly as simple (and as dumb) as that.
  1. Open Threema to the passcode entry, disable it via Cycript using the above snippet, minimise and then maximise the app. BOOM. You haz access.

If you really want the Threema PIN (maybe you think your victim is super-silly and uses it at the bank).

Have a guess what you can now do 😛 (there is an easier way, but i’m not that nice).
This incredibly dumb programming was carried on for at-least another revision of Threema after the version which fixed the UI. “The most secure messaging app” ladies and gentlemen. If you want a real secure messenger, try telegram.
This should be the end of this post, but I think theres another important point about authentication on iOS which needs elaborating.. feel free to leave if you’ve had enough.
Ok, lets say for a minute that Threema did use encryption which used the passcode;
Even then you only have a key-space of 10,000 for the PINs and you can brute-force that on-device in Cycript in a few minutes. You may think that the solution would be to use keys/tokens or a very strong passWORD to replace the passcode.. but that doesn’t actually enforce the developers wishes of destroying the data after 10 incorrect attempts, it just makes it UNLIKELY that an attacker would be able to get the data after bypassing this. I hate the word unlikely.
You might then think that the only way for this to work is to wait until the future, and hope that apps on iOS devices have access to a API which pops hardware e-fuses after unsuccessful decryption attempts occurring within cryptographically-secure tamper-proof processing units, but even then some hardware boffin would find a way to replace the e-fuses (i think this happened already on the xbox360, which uses e-fuses to hardware ban consoles from Live).
The ONLY way.. the ONLY way you can enforce a “x attempts and y occurs” type logic within iOS and not be able to bypass it, is to perform the authentication remotely and have your servers delete data held remotely after witnessing the attempts itself. Which sort of flys in the face of the whole point of Threema. I guess it depends what your believe your adversaries are more likely to be able to accomplish.. compromising your device or compromising the providers of your messaging service. Pick your security model, you can only have one.