If you have been following ADHAAR in the News/Social Media recently then you must have seen the posts by some prominent cyber security folks about basic security issues with Adhaar. I couldn’t resist chiming in with my two cents and pretty soon the conversation switched from the glaring security issues with Adhaar to how we could secure applications when the client could not be trusted. Sushil Kambampati had some interesting questions on this topic and we tried having a discussion on Twitter itself for a short while but since twitter is not the best medium for long winded conversations we switched to email pretty soon and the following is a summary/expansion of my conversation with him.
Special thanks to Sushil for asking the two questions listed below thereby motivating me to write this post. Please note that all the items below are my personal thoughts and I don’t claim to know everything so some of the things below might not be the best option or might require additional safeguards beside the ones I talk about.
What are the risks if the client has been modified by an attacker?
The possibilities are endless if an app has been modified and can still successfully communicate to the server backend. The attackers can tamper with it to install a backdoor on an app, re-sign it and publish the malicious version to third-party app marketplaces. They can also change the app to query the server in ways that the designer didn’t expect. e.g. query the DB for all possibly values of the Adhaar no (as an example) to identify valid values. They can also attempt to perform SQL injection attacks/other attacks on the server by sending it data that it doesn’t expect.
How can the server-code detect whether the client app has been modified?
This is a very interesting problem and there is no foolproof method to ensure that the local client hasn’t been modified. However that said we can always make it harder for the attacker to modify the app. Some ways we can detect tampering are listed below along with potential ways to bypass the checks. (I am going to talk about app side checks in addition to server side since both need to be performed to secure the app). I specifically talk about Android applications here but the same is valid for any server/client system where the client can’t necessarily be trusted (and if your client is installed on a machine you don’t control then it def can’t be trusted).
- We add code obfuscation/shrink the code using Proguard.This makes it more difficult (though certainly not impossible) to reverse engineer the code by making it harder to read a stack trace because the method names are obfuscated. Other things we can do to harden the app is to include checks to detect if the app is running in a virtual environment (emulator) and abort runs. This check should not be an easy thing to disable e.g. by setting a flag, instead the build process should add the check when building the release version or something similar while making it as hard as possible to disable. Finally we should ensure that all debug code is stripped out from the build when creating the release version. This will make it harder for the attacker.
The communication between Server & Client should be over a secure/encrypted channel (use HTTPS not HTTP), all local data should be encrypted with a unique password that is generated at runtime (1st run) using a random seed.
- We have the app send a checksum that the server verifies everytime an API call is made.
- Have the Server request for a byte string from a random location in the APP e.g. send me 100 bytes starting from byte # 2000 from the beginning of the file. This check would fail if any changes are made to the file in the section that the check queried.
- Verifying your app’s signing certificate at runtime.
- Verifying the installer
- Monitor your server side logs
This is a very basic check that is fairly simple to bypass as any competent attacker will also modify the app to send the correct checksum value even though the actual checksum value is different.
The issue is that there is a high probability that the check location requested by the server is not for the location that the attacker has modified. Also, if the attacker is sufficently motivated they can append a copy of the original App to the tampered app and then modify the check function to return the values from the original app when the server attempts to verify the integrity.
All applications in the Appstore are signed with a developers private key and the app signature will be broken if the APK is modified. By default android will not allow you to install an app where the signature doesn’t match. However you can potentially bypass it by changing the code / value you are checking against. Also, the app can still be installed manually if the phone is rooted.
Each app contains the identifier of the app which installed it. Therefore, with a very simple check you could have your app verify the installer ID. This can be an in app check and also triggered by a server API call. However with access to the code (by reverse engineering the app) this check could potentially be commented out.
This is very important, because any attempts to hack the server/bypass restrictions will leave a trace in your logs. If you have configured good log monitoring rules then this can act as an indicator of someone trying to hack your application. Then you have the option of putting countermeasures into action like blacklisting etc.
Hope this all makes sense. Please let me know if you have any further questions by posting a comment below or emailing me.
Regards,
Suramya
