KODE SNIPPETS

This series is more focused on the approaches a developer should adapt  regarding android security and less on their technicalities. In the last part, we discussed about Root Access and Persistent Data. This section will shed some light on security measures covering  Logs, System Screenshots and Backup Theft.

Logs

Logs are the most commonly used feature to inspect the application state in terms of checking the values of variables. Although this can be done using debugger and setting breakpoints, calling Log class methods is more easier way.

This may seem not very alarming at first but sometimes you are exposing sensitive data of your application to other developers. Yes, whenever a developer connects a device via ADB, the application logs will start to appear on the logcat.

This is quite common mistake among the developers that they call Log methods during development and do not remove it or apply a release filter on it while packaging the app. This may result in leaking sensitive information that the app is using like user information including emails and tokens etc which can easily result in the breach of privacy and security for both the developers and the users.

Look at this screenshot taken when a “release” version of an app was launched after installing it from the PlayStore:

To give you some hint, APKs should not exceed size of 100mb, all other data that is more than this cap, should be provided either by external download APIs or via PlayStore feature called “APK Expansion” files, which are in the format .obb. This log clearly showed the full name of the obb file along with its version and package name, and if this file had sensitive data in it, now can be accessed simply by going into “data” folder of android directory on your device.

Not just this, sometimes developers can log authentication tokens, secrets or hash keys to test and forget to remove them, if the device is connected to ADB, these can be easily seen from logs.

What to do?

• Do not log any sensitive user or app data in the logcat, if so always remember to remove it before releasing the app.
• Use a log wrapper that should automatically disable logs on release variants of the app.

 

System Screenshots

Screenshots may seem to  be a common thing for your users todo,  but sometimes  it is really important to prevent user (or system) from taking screenshot.  One use case would be credit card details screen. Your app should not allow anyone, including system to take screenshot while user is entering sensitive data.

Yet even some banking apps and payment flows in e-commerce apps allow this to happen. So yes, we know what screenshot is when user takes it with manufacturer’s defined keys, but what is system screenshot? Have a look at this image:

Whenever you goto app switcher, the system shows a preview of app that was last opened like this. This is a static image from the app that you were on. Where is this image coming from?

The system takes a screenshot whenever you press app switcher, and shows that image in the app switcher stack. This behaviour is by default, thus if you ever switched an app while entering your precious account details. It is residing in the system memory, and if the device is rooted, anyone who has access to the phone can obtain these screenshots ( I will update the post once I know the exact location).

What to do?

To sum up, this can be anything from account details to credit card info, and if the data is leaked it can cause serious implications. You can stop system (and user) from taking screenshots by just adding a filter at activity level. The FLAG_SECURE  window property will do this for you. Before calling setContentView(), you can call,

getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE,WindowManager.LayoutParams.FLAG_SECURE);

 

Backup Theft

As you should know you can take backup of the app data via adb or via settings. There is a property for allowing backup in Android Manifest’s <application> tag property as:

android:allowBackup= true  // defaults to true

So I tried something, set this property to true used adb command to create a backup using

adb backup -f yourBackupName.ab com.yourdomain.yourapp

and, I got all app data (including persistent storage). We can also verify the data by extracting this archive using Android Backup Extractor.

Now, I disabled backup,

android:allowBackup= false 

I ran backup command, and I got the backup again regardless of disabling it in the manifest. What is happening here?

My phone was connected via adb, since this property maybe useful in cases where user is unaware of things like adb or “rooted phone”, but it serves no value when the phone is rooted or device is connected using adb. So any data you have in your preferences, db or files related to that app, it will be compromised. I repeat,

Manifest’s allow backup property is not reliable in cases where attacker has physical access to your phone using adb or when the phone is rooted.

What should you do?

There is nothing you can do to stop attacker from stealing your app’s data. What you can do is to never ever save sensitive data locally. If you do save it you need to have it encrypted, so even if your app’s data (prefs, db or files)  is stolen, attacker might not be able to get any useful info out of it.

This encryption is also suggested in all persistent data storage cases regardless of backup theft, as discussed in the previous part of this series.