Welcome to Part 3 of this series on Android Photo Locker app weaknesses, and things are getting more interesting… As you’ll recall, in Part 1 we discussed the general Android app security landscape, while in Part 2 we delved into poor data storage practices. We’re now going to discuss poor implementations of encryption, alternative methods of data hiding, and the dangers of over-privileged users and apps.

Obfuscation vs Encryption:

In the previous blog we saw apps that were not encrypting the ‘locked’ images, but were just hiding the files in different folders and renaming the file extensions - these were very easy to detect and access. I have one further example of hiding which bears some consideration: another method, which I was very surprised to see being used here…

Firstly, a brief overview of computer files:

Images, documents and any other types of file are saved on a computer drive as bits and bytes of data – ones and zeroes. These have particular patterns, so the computer knows where they start and stop, what the type of file is, and lots of other information about the file. The initial patterns of information are known as the file header. Without a header, an image file is incomprehensible to the computer – it doesn’t know what to do with it.

Now we have that out of the way I can show you the next hiding technique I found in these apps. Again, this app didn’t encrypt the image file. It had moved it and renamed it like before, however when I renamed the image it still wouldn’t open. Strange. Perhaps this image was indeed encrypted as the app suggested…

Aha, no such luck! I opened the image file in a Hex Editor (a program used to look at the ones and zeroes in a different format, displaying them as the patterns the computer is looking for) and saw something truly alarming – the file data was all there, everything in its place, and unencrypted. All except for one thing: the word “obscured” had been added to the beginning!

So in the editor I deleted those letters and saved the file. It immediately opened.

In fairness to the founder of the company that makes Vaulty, he has actually responded to my disclosures, and given some explanation of the app’s actions (along with a promise to fix another weakness related to some of their security settings being stored in plaintext). Well done to them!

From my experience, one reason that developers often choose weaker security over ‘proper’ methods is that their apps may load or work faster that way. This is a common and time-honoured issue – responsiveness vs security. However, I would be interested to know how many of these developers have actually asked their customers this question directly…

Partial Encryption:

One final side-step around encrypting the image file was found in another of these apps. This time they did use encryption… but only for part of the file.

This probably relates back to the issue of the speed of accessing files – decrypting part of a file is undoubtedly quicker than decrypting an entire file. However, the portion encrypted does give us some very useful clues regarding how to decrypt it. For those of you already interested in codes and ciphers you will know that there are lots of ways to encrypt information - some more secure than others. In this case by analysing the patterns found in the file I could see that the Vault app is using a basic substitution cipher. This method is actually rather simple to break under certain circumstances. The most common methods are by using frequency analysis, or pattern analysis. However, if you already KNOW some of the data then the process gets much simpler.

And in this case we do know a lot of the data! The portion encrypted was the header of the file, which (by necessity) follows a very specific pattern. There are set title bits of text, numbers within particular ranges, and other common or normal snippets. Once we have cross-referenced the known elements with the encrypted portion the rest of it falls into place rather quickly. Indeed, it would be rather simple to script this and make a decryption tool to do this in seconds.

With the substitution code decrypted the header is restored and the image file opens up again.

The dangers of ‘Root’ access:

In the previous instalment of this series we discussed the dangers of storage of private data in the accessible portion of the Android file system. But a valid extension of that issue is the storage of data unencrypted in an area that a user may be able to access.

For many reasons a user may want to ‘root’ their device to gain additional access/permissions/customisation options. In other cases, some apps on the Play Store may (knowingly or unknowingly) contain malware, or intentionally request over-privileged access to the file system. In any of these cases an attacker - local or remote - may be able to access files in the (usually protected) /data/data directory, and extract them. Securing this area better by encrypting the private data in this location is best practice. It comes under the term ‘defence-in-depth’ – relying on multiple layers of security, so that if one fails another is there to keep your data safe.

So, while these following issues are not initially a major cause for concern, it only takes one of the noted over-privileged access reasons above to expose the data involved. 7 out of the 12 apps tested were storing the password/PIN used for accessing the app unencrypted in a preferences file in the /data/data/ directory. In addition 3 more of these had login data stored in an easily-reversible format in this location – either a hash for a limited-length PIN, or a standard pattern-unlock signature that could be looked up on a table from the internet.

Well this blog post is getting long, so I’ll finish by summing up the last weakness observed.

Login bypass:

HideItPro hadn’t done too well so far – hiding the images, rather than securing them, as well as storing unencrypted passwords in the (usually inaccessible) /data/data/ directory. However, it had another unforeseen issue - it was susceptible to an ‘Activities’ login bypass.

For the uninitiated: Android has a hidden settings option used to launch different sub-sections of any installed apps. By using the very popular Nova Launcher (or a few other apps) you can create a shortcut on the desktop to any of these app ‘Activites’. Depending on how the app is written these Activities may jump straight into the middle of a process, or may skip a crucial step - such as asking for the login password. Oh dear. Guess what launching the .Vault ‘activity’ does…

Up next…

Following all these things that have gone wrong there is one more aspect I’d like to cover – best practice. I have searched high and low and have actually found an app or two that does this task in a fairly secure way. That said, Android as a system has a lot of useful features that can be used to accomplish these tasks. So in the next blog in the series I will cover some secure ways to store your personal data.