Android Photo Vault app analysis (Part 2)

This is the second part of a security review of Android ‘Photo Locker’ apps.
In the first part we looked at an overview of the state of these types of apps, determining the most common vulnerabilities, and revealing that most of them were easy to extract images from just by having access to the device – with others being vulnerable to other attack vectors requiring more skill or access levels.

This part will look a bit more into the file structure of Android, why some photos appear in Gallery apps, and why these photo Locker apps tried hiding the photos rather than securing them properly.
And then we’ll grab some of these hidden files and show you how easy they were to extract.

Android file system

To get a good understanding of the measures taken by these and other ‘secure apps’ it is worth having an overview of the operating system file structure.
So in brief here we go: Android has two parts of the operating system – parts accessible to the apps and main processes, and parts available to the user.

The ‘system’ part contains crucial system files, as well as app data. Permissions to access parts of this are granted to apps during their installation. Although normally users cannot access most of this, a user with a ‘rooted’ device can gain access to this area. Also rogue apps can request access to more areas than they specifically need – this can lead to data theft, or devices compromised with malware.

The user-accessible parts are named /sdcard (whether the device uses an SD Card for storage or not…), and are viewable and downloadable by the logged-in user. Stock Android does not come with a file browser app, and so this may be a new structure to you, but it is where all of your photos, files downloaded from the internet, and lots of other temporary app storage resides.
This area is easily misused by apps, as it should only be used for data the apps wish to share. It should NEVER be used for passwords, or configuration files that might leak customer information.

Accessing the /sdcard area

Some apps are set up to use the /sdcard area – the Camera app for example uses /sdcard/DCIM/Camera by default, the web browsers will use /sdcard/Download for any downloaded files and screenshots are saved to sdcard/Pictures/Screenshots.
Accessing these folders can be done by downloading a file browser app (if your OEM hasn’t built one in for you). Good examples are Total Commander, ES File Explorer, ASTRO, Solid Explorer…

In a pinch you can actually access the file system via your web browser! Just type in the file:// delimiter before the location and you can view, browse and access/download any files you want…

Accessing the sdcard is simply a case of typing in: file:///sdcard

The Android Photos app is set to look at /sdcard/DCIM/Camera and monitor that for any image files, however this and other non-official gallery apps will also monitor any user-accessible folder for images and display them here. That is, unless the folder contains a file denoting that it should not be accessed for images. The file is blank, but is titled .nomedia

‘Hiding’ images

Of course Gallery apps don’t have to honour this polite request from the folder creator to not show the images in that folder, and it certainly doesn’t stop you from accessing the images in these folders with a file browser.

But that protection is precisely what the developers of those Photo Locker apps were banking on when they moved their ‘locked’ images to their own folders in the /sdcard directory and popped them in a folder with a .nomedia file.

A quick browse with a file browser or web browser to this folder for example clearly shows the ‘locked’ images as stored from the Hide Something app (com.colure.app.privacygallery):

Tapping the image file in this window opened it straight up in the browser. Not very effective.

Note: Starting a folder name or a file with a dot often makes it invisible in UNIX systems, however file browsers can choose to show them if they want, so that protection is pretty useless. And as you can see in the screenshot – the web browser shows hidden files anyway…

Renaming images

OK, so what else did these app developers try to do to avoid using proper encryption?
Well of course a user is expected to browse images using a Gallery or Photo app, right? So if these apps only open files ending in a known image file extension (like .jpg, .png, .tif etc.) then maybe the name is a way of hiding the images further?
Indeed, that is a method used by 7 of the 12 apps tested. The files were either given a new file extension, or the extension was just removed.

On top of that some apps renamed the file to a UNIX timestamp, a Base64-encoded string, a hash-value or something else. But those are just the file names of course.
The images themselves were easily accessed in a file browser: the file extension just needed to be popped back on the end, and the file opened just fine. No encryption involved.
And the web browser deals with it even better – no need to rename the file, it just opens the file when you tap on it as it can tell from the file metadata what the file type is.

As an example, here is an image hidden using HidePhoto (com.domobile.hidephoto). The file is renamed to the UNIX timestamp of when it was saved in the app, and the file extension removed. Notice the file size is exactly the same for these 2 identical files.

More data to be found

As I mentioned before some of these apps were storing other sensitive data in the user-accessible file system.
This isn’t great when you are putting personal data in an area accessible to other apps, and to people using your device of course.

But even worse if your ‘secure app’ is storing its passwords or PINs in a readable location. We’re talking the equivalent of storing a password on a sticky note next to your laptop. Not a brilliant idea…

However two of the apps tested did this by storing a preferences or settings file in a folder under /sdcard.
Here is part of the settings file for KeepSafe (com.kii.safe) stored in the accessible storage on the device. Oh, and there’s the password for the secure folder…

More coming soon

Well I hope that was informative.

The next part of this blog is coming soon, and will go a little deeper down the rabbit hole – comparing encryption to obfuscation, full encryption to partial encryption, and the dangers of leaving file data open to root-access users and apps.