Hacker News Reader

Comment by theandrewbailey | Hacker News Reader

I would suspect that the keys would be different for each infection. But then considering this is software made by criminals, I would not expect even the most sensible or trivial of features and security precautions would be implemented.

View on HN

The ransomware developers could use public-key cryptography by generating a local session key to encrypt the victim's files, and then encrypting a copy of that key with the developers' public key. The paid ransomware service would then consist of decrypting that particular session key on request.

Perhaps the ransomware developers don't understand this or thought it was too much work, or perhaps they want to provide a better user experience by sending a unilateral unlock code rather than requiring the victim to send any data to the attacker.

Congratulations to the people behind this collaboration for making progress on helping the victims.

> The ransomware developers could use public-key cryptography by generating a local session key to encrypt the victim's files, and then encrypting a copy of that key with the developers' public key. The paid ransomware service would then consist of decrypting that particular session key on request.

The private-key to generate the session-key has to exist somewhere -- you don't want it anywhere it can be traced back to you, so it would probably be on some automated control server - which tracks the payment addresses and forwards the decryption key on bitcoin payment receipt.

My guess best is that some of the keys got recovered in the C&C Server take-downs. It would be possible to use bitmessage or another non-ip traceable method of communication to pass decryption keys and and keep the structure separate from the C&C servers.

Oh, good call. Your interpretation seems to have been confirmed by folks elsewhere in this thread.

> I would suspect that the keys would be different for each infection.

They are. CryptoLocker[1], which CoinVault is loosely based on, used per infection keys, and the warnings on the Kaspersky site make it clear they don't believe they got all the keys, which would mean there's more than a few keys.

[1] http://en.wikipedia.org/wiki/CryptoLocker

> But then considering this is software made by criminals, I would not expect even the most sensible or trivial of features and security precautions would be implemented.

I'd advise against underestimating your enemy in this global age. These aren't petty thieves akin to digital purse snatchers, working haphazardly, but the work of a few motivated individuals, likely with ties to organized crime.

In my experience, most malware creators are pretty terrible. Even in 2015 it's common for malware to communicate with C&C servers that have classic SQL injection vulnerabilities.

More specifically on the topic of ransomware, have a look at this gem [1], which uses RSA, but the key is 128 ASCII digits. Very similar to the cryptocat disaster. [2]

[1] http://blog.cassidiancybersecurity.com/post/2014/02/Bitcrypt...

[2] http://tobtu.com/decryptocat.php

There's also cryptodefense, which generated the keys locally. (See https://archive.is/1AGHG, original source doesn't load for me.)

However, the cost-benefit analysis is kind of different. Someone being able to defeat your program just means one lost sale.

Implementing this right is surprisingly hard, as the Debian SSL fiasco and the Java/Android's so called SecureRandom RNG have shown. Maybe they were using a defective RNG for the keys as well, so in total there is a very limited number of keys out there, making collisions probable?

Or possibly they seized the C&C servers and recovered all of the encryption keys stored on them?

That's exactly what happened.

https://securelist.com/blog/69595/challenging-coinvault-its-...

I assume it's a low percentage of people that would take advantage of this, so they probably don't really care. They care about the big percentages, the low hanging fruit.

Reply on news.ycombinator.com