Android Photo Vault app analysis (Part 3)
Ransomware has unfortunately been gaining in popularity over the last year.
With targets such as hospitals and schools 'paying up' to get their files decrypted, ransomware has become the latest menace to both home and corporate users.
When we spotted a download page for Maktub (a new strain of ransomware), we decided take a look at just what it was like to have a machine infected. We started with a Windows 7 virtual machine in our lab, and went to the download page we had spotted…
Stage 1: The Hook
In most cases, a link to a Maktub delivery page comes in a phishing email. Here, we found it on a compromised website – where the compromised page was made to look like a download form. The page even has a box to enter a captcha code! The file to be downloaded is a suitably intriguing 'invoice' type document
After entering the verification code, we downloaded the file onto our test machine
Stage 2: The Line
We unzipped and opened the file – which, we can see from the security warning, presents itself as a .xls file (but with a .scr extension – an executable). Strange for an invoice! Here, we see that user interaction and confirmation actually is needed to open this file
We are shown a .rtf file now – even stranger! Some 'privacy policy' text is shown – designed to distract the user whilst files are encrypted in the background
Stage 3: The Sinker
After about 30 seconds, a pop-up window is shown for 'Maktub Locker'. Also notice that our files have disappeared from the desktop!
Interesting about Maktub is that it relies heavily on 'brand recognition' – presenting the user a heavily stylised 'ransom note' which they will probably recognise as being ransomware! After going to the (user personalised) link, a demand for payment will be shown, to be made in Bitcoins, usually around £300-500 per computer.
Here we see our files have been encrypted and renamed – we can't get into them or make sense of them at all!
After clicking on the personalised link, we were shown an even more heavily stylised explanation and demand for payment – with a price list. The introduction page even sounds apologetic! But don't be fooled, behind these well-designed pages is a ruthless business model, and to prove this a Bitcoin address to send the ransom is listed on the last page
Protecting against Maktub Locker
Don't get caught short on your backups!
The single most important thing to mitigate the damage done by ransomware is to have off-line backups. Multiple backups are even better. Having backups means that instead of paying a ransom, the infected system can be wiped and files then restored. Again, MAKE GOOD BACKUPS. This is the single most important thing to undo the damage done.
Do not pay the ransom
Paying a ransom does three things:
- It funds the cyber-criminals who are behind the ransomware. Not only does it make them richer, it can also help fund other kinds of more serious criminal activity, and provides an incentive to continue
- It provides more funds for the continued development of ransomware. It gets smarter and harder for the 'good guys' to detect and protect against
- It helps persuade companies that paying the ransom is a viable 'way out' of the situation. It often isn't, and there is no guarantee that files will be decrypted. And, bad news, cyber-criminals do not offer 'money-back' guarantees!
Educate your users
Here, we also saw the actions a user has to take to infect the machine with malware. We had to click through two separate warnings! Educate users about not downloading or opening suspicious files. This also applies to files by email – especially unexpected ones with attachments (commonly 'invoices', 'remittance advice', 'fines' and 'CV's. Often, users are just trying to 'get the job done' and may let this override their sense of suspicion. Make sure users know that it is okay to take a slower, more secure approach (not opening suspicious files) – even if it might mean a missed deadline!
Run system updates
Most ransomware uses well-known vulnerabilities in software to compromise systems. Keeping systems up-to-date limits the chances of ransomware even being able to run.
Get help
If you do get hit, don't be afraid to reach out to the technical community. For some well-known ransomware variants, there are free decrypting tools available to recover files without paying a ransom.
Report it!
If you get hit, report this to ActionFraud (or the NCSC if you're an organisation) as this will help them track the spread of this type of crime.
Conclusion
Again, make backups! Ideally, there should be multiple backups, including 'offline' backups which cannot be reached by a computer without being physically 'plugged in'. These mean that the ransomware cannot find and spread to the backup location.
Unfortunately ransomware is going to keep growing in popularity with the criminal world as a way of making money. However, the good news is that there are ways of preventing infection or minimising the damage done.
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.