Monday, November 23, 2015

On The "First" Linux Ransomware

Hey everyone - This is a little dated at this point, but I thought it would be interesting to talk about the first piece of Linux ransomware to make news.  Ransomware is somewhat old news on Windows, but this is the first time I have heard about it on Linux.  I suppose there is a first time for everything.  Let's discuss it.

Here is the first analysis of Linux.Encoder.1 that I came across when I heard about it almost three weeks ago. It seems to operate similarly to Windows-based ransomware.  Once it is executed on the host machine, it attempts to encrypt the contents of /home (users' home directories - similar to C:\Users on newer versions of Windows), /root (root's home directory), /var/log (where system logs are stored), and /var/www (where web pages are stored if the computer is a web server) among others.  Once encrypted, the malware holds your files ransom for money (usually some amount of BitCoin).  In theory, if you pay the money, you will get the decryption key which you can use to get your files back.  In this case, the malware must be executed with root privileges to be able to modify the files in those directories.  That means that either the attacker has to gain root somehow (such as a keylogger, exploit, or misconfiguration) or by inducing the user to execute the binary as root.  Another option is that the attacker would encrypt the files he has access to in the context of the user he is running as.  For example, the only access was the apache user, then the only affected files might be those in /var/www.

Regardless of the specific vector, it is important to be vigilant about the security of your systems.  Be careful of binaries or other tools that are of questionable origin.  As mentioned above, sometimes it is not something the user clicked or executed that was the vulnerability.  Sometimes the vulnerability is in a piece of software that is running on the machine.  With Linux.Encoder.1, it appears that the authors were leveraging targets of opportunity.  That means it is important to keep software up to date and monitor your logs.

There is a good write up on the malware here as well. It appears that the attackers discovered a vulnerability in Magneto (e-commerce software), and used crafted Google queries (google dorks) to find servers that may be vulnerable.  The attackers appeared to have exploited the vulnerability, uploaded a few files (one was likely a shell to facilitate executing commands on the box), and encrypted the files.

The encryption that this class of malware typically employs is generally strong: RSA or AES with a long key.  But as we talked about before, attacks on encryption do not need to go after the encryption algorithm itself. Entropy when generating the keys matters.  If you use a weak source of entropy (or the source of entropy is easily reverse engineered or guessed), your encryption will be trivial to decrypt.  Fortunately, that is the case here as we can see in this analysis from BitDefender.

It appears that the key is generated in the same way that Western Digital created encrypted keys on some of its hard drives as we talked about recently.  Linux.Encoder.1 uses the C function rand() seeded with a time stamp.  Apparently, the time stamp in this case is the time when the files are encrypted on disk.  This information is available very easily (just like the time stamp from the Western Digital example).  You can look at the modification time (mtime) on the encrypted files and convert that into the UNIX time stamp.

I do not think this will be the only example of ransomware for Linux, but I do think that subsequent examples will learn a lesson from Linux.Encoder.1 and generate better encryption keys.  Realisitically, they probably do not have to, though.  Ransomware plays on people's fears by touting encryption and giving the appearance that their coveted files are gone forever.  When faced with that possibility, people are likely to take whatever steps necessary to get their files back in the easiest way possible.  This is typically by paying the ransom.  The idea that there is no reason to up your game as an attacker if the less sophisticated attacks work applies here.  Why go to all the trouble of generating strong keys and storing them effectively when all you have to do is make it appear that you have done so?  If ten people do not figure out that they can get their files back without having to pay, and they pay the ransom (at roughly $300 a pop), the authors have made $3,000 without a lot of work.

The psychological analysis of malware is just as interesting as the technical analysis of it.  I believe it is important to look at things from a number of different angles in order to better understand the how and why of a situation.

Anyway, thanks for reading!  For readers in the United States, have a safe and happy Thanksgiving.

No comments:

Post a Comment