A Close Look at Ransomware at the Example of Vipasana – Part II

The Vulnerabilities of Vipasana – Why this Ransomware is Absolutely Insecure

In part one of my take of the ransomware Vipasana last week, I discussed what is new about Vipasana, compared to former types of ransomware. I described what happens once your device is infected, and figured out its encryption algorithm. It became clear that Vipasana uses its very own encryption algorithm and now, in part II, I will show you what is wrong with it. It will become perfectly clear why nobody should use such an algorithm if they wanted to use encryption to protect their sensitive data.

During my analysis, I stumbled across several severe problems with the way Vipasana encrypts files. A quick spoiler: I could not break it to the degree of releasing a decryptor for it – but I broke it down to a small remaining part of its foundation walls.

Breaking Vipasana Ransomware – What is Wrong with it?

As I said, Vipasana has so many vulnerabilities, one could never use this for serious encryption. What you read in the following lines, therefore, is kind of like a seminar in bad encryption. If you want to build good encryption you should do the opposite of what the one who built Vipasana did.

Vulnerability 1: The Filename is Merely Hidden

Not much to say here. The filename is not even really encrypted. It is just hidden in plain sight within the file.

Vulnerability 2: The Keystream Length is Limited to 30,000 Bytes

Did you study the diagram in the first part of this series carefully? In that case, you might have noticed that the keystream itself is only 30,000 bytes long. This is a fixed entity. So the question is: What happens if the file is bigger than 30,000 bytes? And the answer is…

Nothing.

Only the first 30,000 bytes are encrypted. The rest of the file stays unencrypted. Am I a bad person for being disappointed in a virus? This is just lazy. And it should be pretty obvious that if you want to encrypt sensitive data, you should definitely encrypt all of it. However, in the case of ransomware this lazy encryption probably suffices, since the only goal of the cybercriminals is to make your files unusable.

Vulnerability 3: The Keystream is Converging after 768 Bytes

Now we get to the interesting vulnerabilities. As it turns out, the keystream itself is converging after 768 byte, independent from both the state block and the block positions. That means that we know the keystream bytes from that position onwards, no matter what keys the virus choses to use.

How do we know that?

As stated earlier, the PRNG has an internal state which is used to generate the keystream. While the PRNG is running, this internal state is mutated. After every 32 bytes of generated keystream, this internal state is transformed by one of the following algorithms (the list of algorithms is cyclical, it always repeats itself):

Let’s have a closer look at the functions. updateState1() takes the state, and adds or subtracts 0x80, depending on its previous value. updateState2() adds the value of the next element in the state block to the previous one. updateState3(), however, multiplies the state’s byte by two. This is the part where it gets problematic, because one byte can only store values up to 255. If the value is larger, it is automatically truncated. (For the tech savvy folks amongst our readers: We always lose the most significant bit in this process). If we do this operation eight times, the value will have been truncated so often that it is always zero – independent from what the value was originally.

In part I we stated that a PRNG always gives out the same results if the internal state is the same. At this point this information becomes relevant. We have 3 state update functions that are each called after 32 bytes of generated keystream. We have to call updateState3() eight times. As a result, after 768 bytes of keystream, we know the keystream from there on.

Crypto experts already know that a deterministic – or even just a repeating keystream – is highly critical. In the next vulnerability, we will lever this fact to decrypt most of the file encrypted with Vipasana.

Vulnerability 4: The Global Algo Key Can be Recovered

The keystream is only one part of the puzzle. The other part is the global algo key that determines how the bytes of the keystream are combined with the bytes of the file. However, since we figured out the keystream bytes, we can now mount a so-called known-plaintext-attack to recover the algo key.

When the virus encrypts the files on your machine, it will stumble upon Windows files, as well – and encrypt them, too.

How convenient for us that those files are the same on every machine. We can easily get a copy of the unencrypted file which means that we now have a plaintext file and its encrypted counterpart.

If you look back at my example of the combination of plaintext bytes and keystream bytes, you may have realized that by now we have all the information we need, except the global algo key. The great thing is that we can resolve the equations to calculate just that value, just like a simple math problem. Since the global algo key is the same across all encrypted files on your system, we can now use the global algo key to decrypt the files, even if we do not have the unencrypted file, as well.

This vulnerability enables us to decrypt the files starting from the 769th byte onward.

Vulnerability 5: Key Stream Bytes are Ignored in Some Cases

The algo key decides how the bytes of the key stream are combined with the bytes of the plaintext file. However, for the algorithms “6”,“7”,“8” and “9”, it decides not to use the key stream at all.

In those cases, constant values are added or subtracted to or from the plaintext file. Since we can recover the global algo key, we are able to decrypt all bytes that are encrypted with the named algorithm identifiers.

As a consequence, we can decrypt about 40% of the problematic 768 bytes at the beginning, which we could not decrypt before. If I add all those values, I was able to recover >98% of the encrypted file.

Where Do we Go From Here?

The algorithm has a many insecure code sequences, which we could not directly lever to extract more of the file’s content. For example, the fact that the internal state is experiencing a constant loss of information leads to a situation just before the state is all zero, where its unknown bytes amount to only 64 bit. This is a value that can be brute-forced easily with the right equipment. Once those 64 bit are recovered, one can repeat the attack to recover the previous 64 bit, and so on, until the whole state of the PRNG is broken. This would lead to a complete recovery of the encrypted file.

Other problems might arise due to the fact that the algorithm heavily depends on using characters (with a specific bit structure) as “random” bytes. I am pretty sure that this encryption scheme can be broken – an algebraic attack, for example, could be promising. Obviously, though, our business is creating secure encryption solutions, not breaking insecure ones, so we stopped at this point.

For our tech experts
We have released the reversed PRNG and the Vipasana stream cipher algorithm on GitHub: https://github.com/secomba/vipasana_reversed

Does Boxcryptor protect you from ransomware?

The honest answer is, it might. However, this is a side effect of our document extension not being as well known as *.pdf, for example. When you do not have the Boxcryptor drive mounted, the virus will not find files with the extension *.docx, *.xlsx or similar in the Boxcryptor drive. It will only find files with the Boxcryptor extension *.bc, which is currently ignored by 95% of all known ransomware specimen – excluding those that just encrypt everything.

Of course, it could always happen that future crypto viruses include our files in their list.

How to Protect Yourself from Ransomware

There are a couple of things you can do to reduce the risk of serious data loss by ransomware:

1. Keep your malware scanner up-to-date.
Vipasana, for example, is detected by more than 75% of all scanners. But do not rely on your malware scanner too much. If you get hit by a new type of ransomware, your malware scanner might not know and ignore it. The most important factor to stay protected from ransomware is responsible behavior online.

2. Be aware of the threat and be careful with unknown and unexpected email.
Many types of ransomware are spread via infected email attachments. Follow these tips about responsible handling of email attachments and be very careful with executables from the internet, no matter how they ended up on your system.

3. Keep offline copies of your files – or back-up your files in the cloud, encrypted with Boxcryptor.
Some cloud storage providers (Dropbox, for example) keep older versions of your files, thus you can just revert the changes, in the case of ransomware, the encryption of your files:

Dropbox includes 30-day version history, in case you accidentally delete a file or want to restore a previous version.

4. If you’re infected: Keep calm.
If you can live without your files for a while, do not pay. Many ransomware samples in the past were breakable and had been broken over time. Have a look at the website malwarehunterteam – there might already be a decryptor for your virus.

The Lesson of the Exercise

Every once in a while, we hear the justified question: “If nobody can break the encryption of the ransomware, why don’t we encrypt our files in the same way?”

After reading this post, the answer should be perfectly clear: There is good encryption and there is bad encryption. Just because one cannot publish a tool that can recover the complete file does not mean that the encryption system is not broken to the core. Sure, I cannot reverse the encryption of Vipasana and hand you your Word document in the state it was before. But I can tell you 90% of what you have written in the document.

Encryption can be used for good reasons, but it can be misused by cybercriminals as well, as the prominence of ransomware this year shows. Crypto is difficult. Luckily, malware writers generally have little competence in this matter. There is a lot that one can do wrong when building a crypto solution.

Therefore, when it comes to protecting your sensitive data through encryption, you are right to rely on specialists who know what they are doing.