Snake alert! This ransomware is not a game… – Naked Security

By | January 13, 2020

Source: National Cyber Security – Produced By Gregory Evans

Here’s some goodish news: the Snake ransomware seems to have made the news last week on account of its name rather than its prevalence.

Because, well, SNAKE!

Like most ransomware, Snake doesn’t touch your operating system files and programs, so your computer will still boot up, log in, and let you open your favourite apps, so that in purely technical terms you have a working system…

…but all your important data files, such as documents, spreadsheets, photos, videos, music, tax returns, business plans, accounts payable and accounts receivable, are scrambled with a randomly chosen encryption key.

Scrambled files consist of the encrypted content written back over the original data, with decryption information added at the end:

Decryption metadata plus the text EKANS (SNAKE backwards) is added at the end of encrypted files.

The original filename and directory are recorded, the decryption key is stored too, and the special tag EKANS, which is SNAKE written backwards, finishes off the encrypted file.

Note that the decryption key for each file is itself encrypted using ‘public-key encryption’, which is a special sort of encryption algorithm in which there are two keys, rather than one, so that the key used to lock data can’t be used to unlock it.

The key used for locking data is called the public key, because you can reveal it to anyone; the unlocking key is called the private key, because as long as you keep it private, you’re the only one who can later unlock the encrypted data.

Most modern ransomware uses this sort of hybrid encryption system.

The malware generates a random key to encrypt the file, using what’s called a ‘symmetric’ or ‘secret-key encryption’ algorithm where the same key both locks and unlocks; then uses a public key to lock up the random key.

To decrypt the file, you need the private key to unlock the symmetric key; then the symmetric key to unlock the file.

Why not just use public key cryptography alone to lock and unlock the file? Why the extra complexity of generating a random secret key to lock the data and then using a public key to lock the secret key? The answer is that symmetric crypto is ideally suited for scrambling large amounts of data, but public key crypto is much slower and suited only for scrambling small amounts of data at a time. Thus you use fast encryption to deal with whole files, followed by slow encryption to keep the secret key safe for the fast decryption safe.