Android Ransomware Dissected by University Student

Remember when we told you about the first ransomware for Android? No? Oh ok so let’s give you a quick background. Not that long ago some enterprising person came up with a way to use the locking portion of Find my iPhone to lock a number of iPhones in Australia. This started a number of rumors about the spread of this new threat to the iPhone including one that claimed iCloud had been hacked. In the end the number of locked phones was much smaller than reported and the users were able to get their phones back without paying out the relatively small ransom.

Shortly after this a bit of Malware hit the Android ecosystem in Eastern Europe. This new bit of code was overblown by some in the media as a massive threat to all Android based phones and was even compared to CryptoLocker. Part of the comparison was accurate simply because the malware does encrypt certain files and demands a ransom for the keys to decrypt those files. Where it is unlike CryptoLocker is that the code was (and is) still very immature. Security researchers even went so far as to say it looked more like a proof of concept than any real threat.

The code ended up being simple enough that one Student at the University of Sussex, Simon Bell, feel that he can pull the decryption keys right out of the code itself. This would allow people to get their files back without paying the ransom at all. He has already published on article on how the malware works and plans a follow on with an app that will allow affected users to bypass the app and recover their data.

He feels that the decryption keys are not stored on the C&C servers yet due to the immaturity of the code. The decryption password is the same as the one used to encrypt the files. This means by calling the same decrypt() function listed in the class AESCrypt with the encrypt() function. This made it fairly simple to recover the files.
decryptRemember, this is not a fully blown application. It is something that looks to be a very localized test. Future versions will more likely not have the encryption/decryption password listed openly in the code. Instead it is likely to receive the encryption password string from C&C servers after the infection. The app is also likely to be much more resistant to examination with obfuscated code structure and also potential payloads which impact the ability to dynamically test the app.

That is, if the developers of this simple app keep going or if someone else takes up the flag and runs with it. Right now there are no reported instances of this (or any other ransomware) in the Play Store, but sadly, this could be the beginnings.

For the coders out there you can read both of Bell’s blogs posts: here and here.

Tell us what you think

No comments

Leave your comment

In reply to Some User