I'm going to point at the elephant in the room and say that, there are probably quite a few reading this post and screaming in their mind, don't help them!!
There seems to be an inverse correlation between smart and evil in human beings which is reassuring, but only mildly.
Indeed, this isn't the first time ransomware with bad crypto has lead to a win for the good guys:
> Just ship your ransomware with the attacker's public key, generate a symmetric key K locally, encrypt the data with K, encrypt K with the public key, offer to decrypt K for a ransom.
It seems that what they're doing is generating a local Kpub/Kpriv pair, encrypting Kpriv itself and then offering to decrypt it. The files are encrypted with Kpub (approximately, see comments below for details). This has the advantage that they can encrypt all they want without knowing Kpriv, which only needs to live in memory long enough to get encrypted.
With your approach the (symmetric) key used to encrypt the files is still unprotected in memory for at least a short period of time.
I'm surprised ransomware doesn't use the TPM to protect their private keys - given that more computers have it now.
That's fair but should note that smart != depth of cryptographic knowledge. I am not saying that these are geniuses, programmers or even necessarily evil but (so far) they haven't been caught.
So if these were poor teenagers who mostly copy pasted code and built the rest on the fly then as long as (opportunity cost < ransom >
(chance of getting caught * penalty)) then it was "smart".
That's what is good and bad these days; powerful tools empower motivated people.
> There seems to be an inverse correlation between smart and evil
Hopefully you're right.
What is the fundamental difference? The pitfall that makes it possible to decrypt is that the key which is needed to decrypt is not cleared from memory. Your proposed strategy has exactly the same problem.
What would work is hardcoding a large number of public keys in the binary. Then upon paying the ransom the attacker could give the private key to the victim.
Cryptography expert usually recommend not to use the same key (here the ransomware's public key) for transport and storage. Maybe the symmetric key should not even be stored locally.
But the drawback is that with this approach the same symmetric key would be used to encrypt all files leaving it longer in memory. If 1 symmetric key is used per file it would mean that the ransomware would need to be queried for every file.
Using a locally generated asymmetric key encryption key AKEK to encrypt the files means that:
- The AKEK Pubkey can be kept in memory and the AKEK private key be sent immediately to the control center.
- A different symmetric key can be used to encrypt every file and the control center can be queried only once to retrieve the AKEK private key
On an unrelated note, I wonder if people thought about doing a DDOS on the onion service ... ?
Well the thing is, if they had alot more knowledge about this stuff, they'd probably make way more money "going straight", though I'm sure there are some exceptions to this.
Alas, in order to optimize profits you wouldn't want to use a shared key pair. The risk of course that once your private key is disclosed then you'll potentially thwart future revenue.
The more capable either avoid observation, or simply ensconce themselves within the existing economic power structure, hiding in plain sight while accruing accolades.
This is deemed "success."
The attackers seem to have a poor grasp on cryptography. The entire point of RSA is that they don't have to generate the key locally. Just ship your ransomware with the attacker's public key, generate a symmetric key K locally, encrypt the data with K, encrypt K with the public key, offer to decrypt K for a ransom.
Heh. Since this only works before a reboot and Windows 10, by design, destructively reboots with no recourse, I could imagine this ironic farce:
a) security holes lead to a ransom, b) security holes let you reverse the ransom, but c) forced reboots kill any hope you have of recovering with this kind of hack.
You've got to admit it's a little funny when an OS's security flaws prevent even targeted malware from working properly.
I don't know the exact details of how WannaCry encrypts the files, but ransomware generally works like this: when hitting a new machine, it generates a random key K1 and then encrypts all the user's files with AES (or some other symmetric key encryption) using K1 as the key. It then encrypts K1 itself using some public key Kpub embedded in the ransomware, then stores the encrypted K1 on disk. When the user pays the ransom, they receive the corresponding private key Kpriv that allows them to decrypt K1, which then lets them decrypt all their files.
I think what this tool does is read the unencrypted K1 directly from memory, which means Kpriv is no longer needed.
EDIT: One correction: the user doesn't receive Kpriv, instead they send the encrypted K1 to the ransomware owner who decrypts it and sends back K1.
I mean a technical user capable of this solution is not very likely to get hit by this in the first place. The hacker probably doesn't care if x% of people defeat the encryption.. as long as x% pay the ransom.
Exactly. I would've thought the malware would ask a C&C server to generate a key pair and then only send the public key to the malware. But I guess perhaps that required too much processing power for the server. But then again this can also distributed: let a random victim generate an RSA keypair for another victim.
In the case of ransomware, it just has to work most of the time.
If the WannaCrypt author(s) want to (partly) address this particular tool, they could, for example, just make it reboot on XP after encrypting everything.
It's hilarious that it uses public-key crypto, yet lets the client know the private key. What's even the point, then?
That's still the correct response to a potential worm, shut it down before it can do damage.
I assume disconnecting the ethernet and/or wireless is too much of a rat's nest for your average office occupants. Better to cut off the appendage to stop the spread I guess.
The sad fact is that the prevailing response to a potential worm is "shut down the computer" (hence losing the encryption keys held in memory).
Looks interesting, anyone tried these steps? Did it work for you?
This would work if time was the only thing that went into the seed for the random number generator. Relatively insecure generators do use time, but nothing serious should be using it exclusively.
Here's the remark from the Windows Crypto API on how they create the seed.
To form the seed for the random number generator, a calling
application supplies bits it might have—for instance, mouse
or keyboard timing input—that are then combined with both the
stored seed and various system data and user data such as the
process ID and thread ID, the system clock, the system time,
the system counter, memory status, free disk clusters, the
hashed user environment block. This result is used to seed
the pseudorandom number generator (PRNG).
I'm probably going to show my ignorance of RNGs here, but if we know the machine, the algorithm used, and the time the key was generated, doesnt that limit the number of possible choices? Could we check when the file was encrypted and brute force the possible keys?
"So, it seems that there are no clean and cross-platform ways under Windows to clean this memory."
Well, finally Microsofts incompetence amounts to something good.
Does anyone know what would have happened if my laptop was encrypted with wannacry and my laptop hard drive was basically full?
So if this spreads across a network, do they all share the same key? Can you use the XP key on a 10 machine?
That is nice!
It really hurts my eyes to read "dump_hex" and "normalizedEntropy" in one file.
Is there actually any viable code style guide that one can follow when writing C++ application?
It's only been tested on Windows XP? surprising they couldn't/didn't set up a 7/8/10 VM to try and replicate the results
Since WannaCry is somewhat neutered at the moment (thanks to the killswitch), and this tool stops working after a reboot, I'd say this tool is somewhat useless, with no intention to insult the man who created it. It's just the circumstances. After a week, almost all victims have rebooted their PCs or the memory has been re-written with other data.