Hacker News new | past | comments | ask | show | jobs | submit login
Ransomware Decryptor (kaspersky.com)
205 points by touristtam on April 23, 2015 | hide | past | favorite | 49 comments



As a Dutch person, I was confused about the Dutch police logo there (Politie is Police in Dutch). Scrolled to the bottom to find affiliation or anything... turns out it's right there in the first line.

I'm very pleasantly surprised to see our police doing something good! It's the first time I've heard the Dutch digital police actually achieving anything, and that is not exaggerated. Last time we provided an IP address involved in a hack (the IP was from the same town as the company that got hacked, so it wasn't masked), we never heard anything back, even though we know they have the CIOT database with all Dutch IP addresses mapping to names and addresses. But that was 2 years ago and there have been a lot of activities in training policemen for digital investigations.

Although it's not entirely clear what exactly their involvement was, this is nice!


That's not uncommon, unfortunately. I've off-and-on bothered to notify various entities about bad behavior for the last 15 years or so. In most cases, it goes completely ignored. Most recently, on April 2, I notified Rackspace's abuse department that they were hosting a major fraud/scam site (websitebackup.com, they send out fraudulent invoices and wait for non-tech-savvy customers to send payment) and never heard back. Rackspace is still hosting them.

It's just one of those facts of life: nobody really cares, not until they're directly affected by it somehow.


Hold on, Rackspace is not police. You have no legal right to demand that they cease to host anything and they have no legal obligation to look into anything sent to that email address. The company that got hacked and reported it to the police did: someone violated the law, we provided IP addresses and access logs to make it a clear and simple case, and then they didn't even look into it.


thaumaturgy didn't complain about his legal rights being violated nor legal obligations of others being ignored. He complained about something much more general.

> nobody really cares, not until they're directly affected by it somehow.

He explicitly marked it as such.

> It's just one of those facts of life:

He is right.


Yes, and that's not uncommon, whether police or state agency or otherwise.


Just to be crispy clear, did you report the incident to the police or to some other state agency as well? Or only to Rackspace?


Naw, that one just went to Rackspace. In the interests of clarity, I have also reported a thing here and there to local law enforcement over the years, but the experience was completely the same.


Keep in mind that this only works for people infected with CoinVault, and Kaspersky didn't get all the keys. The title is misleading here. Still, if you are infected by CoinVault or know somebody who is, this is a great thing to try.


In the manual[0] they have "Remove CoinVault" as a step to do before you check whether the Kaspersky site has the key that will decrypt your files.

People probably want to keep CoinVault around in case the key isn't known and they want to pay the ransom.

[0] https://noransom.kaspersky.com/static/convault-decrypt-manua...


Don't know about Coinvault specifically, but others give you a program along with the key if you pay.

Besides, you can always use Kaspersky's tool with a paid for key.


Key distribution is a problem even for ransomware. It looks like the decryption key is a function of the Bitcoin address to which ransom is sent. That should eliminate the need for a server controlled by the ransomware people to return keys.

What does "check payment and receive keys" really do? Does it check the Bitcoin block chain to see if payment has been made, then calculate the decryption key? Is this entirely blockchain-based?


I'm guessing that when a cyber criminal is caught they add all retrieved private keys to the police's keychain. Even a symmetrically signed key (passworded) can be brute forced or the arrested can be court compelled to decrypt the key.


AES cannot be trivially brute forced. The key phrase is also unlikely to be trivial because the convenience has no value.


I don't understand, perhaps I'm misunderstanding the situation.

GP is saying that if the [private] key is password protected, it can be brute forced. Surely if a human is able to type in the password to the private key, you can bute force that password relatively easily?


With cooperation, yes, without it, no. A password doesn't need to be too long to grow the key space to large enough all the computers in the world couldn't scratch the surface.

Of course, there are many other factors that can significantly decrease or break the security of AES.

TL;DR xkcd.com/538


bute[sic] force that password relatively easily?

"Easily" conceptually, yes, but not computationally.


They have a captured database of key/Bitcoin addresses, so when you put in the address it looks up the key.

>What does "check payment and receive keys" really do?

Presumably it asks the server whether the payment was received, and if the answer is yes, the server sends it the key.


I'm not sure, I spent five minutes thinking about it, and it's pretty easy to come up with a design that relies on no servers, accepts payment through Bitcoin and the decryption keys are only ever stored with the operator and never divulged before payment.

Maybe malware operators aren't that experienced, who knows.


I don't know about Coinvault, but other systems would generate the private key on a server and send the public key to the computer for encryption. I don't see how you could have zero servers and still send the private key upon payment, though.

There was an early version that would generate the private key locally, which was discovered by Symantec (the original blog post isn't loading, but you can see it at https://archive.is/1AGHG) For an analysis of a more recent version that fixed this see http://www.secureworks.com/cyber-threat-intelligence/threats...

A TorLocker had flaws that allowed 70% of infections to be recovered, see https://securelist.com/blog/research/69481/a-flawed-ransomwa..., although they didn't explain what flaws there were.



That link does not explain how they're managing to obtain the correct key from the server without paying money.

So they were able to dump a memory segment into a hex editor, and locate references to RijndaelManaged. So what?

In the screenshot, I still see:

  Server.GetKey().Key
So how did they convince the malicious server to cough up the token for free?


The article states they "...obtained a database from a CoinVault command & control server (containing IVs, Keys and private Bitcoin wallets)."

Reading between the lines, the police located the server, served a subpoena to the hosting company, and took possession of the server. They then turned it over to Kaspersky who created the site based on the keys on that server.

The screen dumps are just showing how they figured out the decryption routine - the private key alone doesn't do you much good if you don't know the algorithm used.


The article comments mention that you need to have the Bitcoin wallet address to use the tool to decrypt the files. Either they found some relationship between the wallet and the secret used for the encryption, or they actually compromised the servers and have a true mapping between every wallet address and the key subsequently used for that encryption.


The article says they were given the keys by the police.


The best Ransomeware Decryptor is the backup you took last night. Which reminds me ... :-)


Why assume that no-one who ever got caught by ransomware had any backups? As far as I know, the way most ransomware works is that it not only encrypts your entire drive, but also any network drives it has access to, any external drives, and so on. It's quite possible someone with a backup regiment was still affected because they left a link to their backup system open, encrypting that as well. I think most people mainly care about backups being off-site, not them being "de-linked" and unaccessible.


> I think most people mainly care about backups being off-site, not them being "de-linked" and unaccessible.

Then they don't understand backups - what's the use of backups if rm -rf / erases them as well because they're permanently mounted at /srv/backup?


Good point.

I would format any disk that has had ransomware on it before I did anything else (like plug in the usb drive with my backup). In the meantime use another PC to access the files.

However yes it is probably worth having 2 backups for this reason, just incase you get caught short.


This should remind you that a safe backup should be pulled from the backup server. Alternatively you keep an incremental backup on your server and give other computers limited privileges (they shouldn't have write access to snapshots).


Do your backups to DVD and you're guaranteed ransomeware can't touch them.


>During our joint investigation we have been able to obtain data that can help you to decrypt the files being held hostage on your PC.

Obtain data? How? :)


http://www.pcworld.com/article/2909292/files-encrypted-by-co...

>The National High Tech Crime Unit (NHTCU) of the Dutch police recently obtained a database from a CoinVault command-and-control server containing decryption keys, the Dutch police said in a news release. The information obtained from that database allowed Kaspersky to build a decryption tool.


>a CoinVault command-and-control server

So, is there anything stopping them from setting up new servers with new keys and starting the goose chase all over again?


No. In fact, this already happened before, see https://www.decryptcryptolocker.com/.

It helps some people already infected.


This originally hit the news 10 days ago: http://techwatching.com/page/there-s-finally-a-tool-to-free-...


Yeah, somehow no one on HN upvoted the stories, previously posted, about it. And, for once, I am glad I didn't do my usual search before posting. Otherwise this is a tool that wouldn't have had much exposure among the HN crowd. But this is a different topic altogether. ;)


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.


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?



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.


The title appears to have a typo: ransomEware.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: