Mobile security and data privacy is a topic emphasised by a number of business owners willing to ensure their customers that their products are safe. Recently, we’ve described the tools and techniques of securing your app in Ruby on Rails. Today, let’s focus on another question:
Is it even possible to make your app 100% safe?
A lot of developers have no idea how easy is it for hackers to get the data from their applications. To feel secure, they work on the protected devices where each application is sandboxed. Also, as a lot of popular third-party libraries stores the plain text tokens in resource files of their demo apps, many developers copy this behaviour. Finally, the common practice is storing the unencrypted keys or tokens in a seemingly safe data store provided by operating system API or in the local database. Is it all enough to provide the proper security? Unfortunately, not really.
Some time ago, we’ve taken part in Mobile Security Lab organized by Niebezpiecznik which is one of the biggest security testing company in Poland. Our knowledge of mobile app security has significantly increased when we put ourselves in the attacker’s shoes. There were both Android and iOS app for which we could bypass the security or get access to some data.We had the opportunity to work with the tools used by hackers and see what they need to do to achieve their goal. Now, let’s focus on the iOS app cracking procedure.
Official development tools are very useful for regular work, but they can give a lot of information to people hunting for some data inside the app. Otool, for instance, is an application that displays information about the libraries. You can check which architecture they support or if the library is properly signed. It also gives you the information about encryption. Basically, it is not a big deal — the keys are not public so you cannot just decrypt them. But you can easily crack the app when you have access to the jailbroken device.
No, I’m not going to give you the detailed guidance on how to do that. But let’s just briefly run through the process.
Every application needs to load to the memory to be able to run on the device. Before loading, it needs to be decrypted. With access to SSH, GDB debugger and the encryption information from otool, one can easily run the app, attach the debugger and dump memory from the point where the application is loaded. Next step is to replace encrypted binary data with unencrypted ones. The last thing is to change the flag which determines app encryption. Now, you can use a class-dump application to fetch all the headers with class names, properties and public methods. The whole process is not complicated, but it obviously requires some terminal skills and technical knowledge about the memory and iOS system environment. Things get easier when you use Clutch — a tool which provides the whole process in one line.
Having that information you can attach application process to the debugger and use i.e. Cycript to make some call inside the application. And again, there are applications like Snoop-it, which simplify this procedure. You can install it on iOS device and choose the application you want to access. It created HTTP service which enables you to see app’s graphical structure, invoke methods, check the view hierarchy, hide views, etc. You can even display keychain items or see the network traffic and methods invocations with params.
At this point, you may assume that there’s no chance fully secure your app. And you are right. The mobile application will never be 100% safe. The difference between a server and mobile security is pretty huge. To be able to get data from the server, you need first to get access to it, which is the hardest part. On a mobile device, things are way simpler, because, actually, the device is in your hand. This is why the main goal of mobile device security on is to detect that someone is working on the application, delay the attacker and remove all the sensitive data. Let me point a few things you should consider to protect your app better.
-(BOOL)isDeviceJailbroken:(BOOL)jailbroken
or -(BOOL)authenticateUser:(BOOL)auth
. Fake methods may change some encryption keys, delete user data or inform the server about the attack. If you detect that someone is trying to attack your app, it is better to change app’s behaviour than to crash or exit the app. The longer the attacker keeps trying to break the app, the more data you’ll be able to secure.Keep in mind that even combining the described techniques don’t guarantee that your data are safe. They just prolong and complicate the process of attacking your app. There is no option to make the mobile app as secure as web services. When detecting the attack, clear the sensitive data and keep the attacker convinced that he’s still moving forward.