ites files, to the encryption algorithms that it uses to scramble and unscramble your data.
Many, if not most, legitimate encryption tools these days are dynamically linked, meaning that they connect up with software components already on your computer, known as shared libraries on Unix, or DLLs on Windows.
For example, lots of encryption products use OpenSSL, but don’t actually build in their own copy of the OpenSSL software.
→ By sharing a central copy of a shared library amongst numerous products, you not only save disk space (they all share the same files) and memory (only one copy of the shared code needs to be loaded at a time), but also make version control and updating easier. The flipside is that a bug in a shared library typically affects lots of software at the same time, although patching the shared copy also fixes all programs that use it in one go.
Compact and self-contained
By making itself entirely self-contained, Linux/Ransm-C makes itself more dangerous: once a crook gets the malware program file onto your server, he’s not dependent on any other components you have installed, because he’s got all the software pieces he needs in one file.
If the crook only manages to run the malware in a restricted environment, for example where common system utilities are excluded and account privileges are limited (for techies, think of precautions such as chroot and setuid), it will still do as much damage as it can.
Even if the malware only manages to scramble your authentication database, or a few of your HTML web pages, that may be enough to stop you serving customers and doing business online.
To save space, Linux/Ransm-C doesn’t use the popular OpenSSL library, which is a rather large code project, but instead includes mbed TLS, formerly known as PolarSSL, an encryption library that was specifically designed to be small and easy to use. (One popular use is on embedded devices such as routers, where disk and memory space are usually tight.)
How it works
If a crook runs the “tool” like this…
$ ./ransom encrypt publickeyfile
…then it will scramble writable files on your computer, using a public key provided in a separate file for its encryption.
Scrambled files are obvious: they end up with the text string .encrypted at the end of their names.
Additionally, if the crook feeds the malware a file called readme.crypto, you will find a copy of that file under the name README_FOR_DECRYPT.txt in every directory where the malware did any damage.
That file serves as a ransom note, so the crook can use it to tell you how much you’re supposed to pay, and how.
Later on, if you manage to acquire the corresponding private key from the crook, by whatever means he has specified, you can do this…
$ ./ransom decrypt privatekeyfile
…to reverse the effects.
The details of how the crook generates the public-private key pairs, where he stores them, how he sells them, and how much he charges, is up to him.
Linux/Ransm-C just gives him the malicious mechanism he needs to do the scrambling, so he can put the squeeze on you to pay up.
What to do?
All our usual advice applies:
- Patch! To use this malware, a crook needs to sneak just two small files onto your computer: the malware program and a public key. Any remote code execution hole could be enough to lock you and your customers out of your own server.
- Backup! If you have a reliable way of restoring a ruined server, even if you lose a few recent changes, you can recover from this sort of attack without engaging with the crooks.
- Protect! Yes, a Linux anti-virus can help. On a Linux server protected by Sophos Antivirus, for example, Linux/Ransm-C would trigger an alarm as soon as the crook uploaded it – and then he wouldn’t be able to run the malware anyway, because the anti-virus would block it.
While you’re about it, make sure you pick proper passwords, to stop crooks logging in remotely without even needing to hack.
Also, consider using two-factor authentication so that a stolen or leaked password isn’t enough on its own for a crook to login.
And why not listen to our podcast, Malwa