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:
Having this public doesn't really defend against it any way. And if someone were to perform this act, it would be easy enough to figure out what was going on.
We should be moving to better solutions regardless, like append-only backups.
Any bad guys with sufficient ambition and intelligence are going to get as far as they're going to get, and if you're afraid of talking in public because a "bad guy" might overhear you and become smarter, you really are living on the wrong side of matters.
You're saying like "We should not teach programming publicly since bad guy may misuse the knowledge."
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.
I'm surprised ransomware doesn't use the TPM to protect their private keys - given that more computers have it now.
The post said encryption is performed with a new symmetric key K, and then K is encrypted with the attacker's asymmetric public key.
Remember asymmetric encryption doesn't scale for large amounts of data - which is why systems like TLS and full-disk-encryption still use symmetric keys - the asymmetric cryptoschemes are only really used during handshaking and for the exchange of symmetric keys.
The generated key is encrypted and the user has access to it.
So, you send the encrypted key and pay the randsome to get the unecrypted private key. Is that so?
>... get The unencrypted secret symmetric (session/encryption) key
So ransomware ships with public key PubK, generates symmetric key K, encrypts user files - plaintext message M to get encrypted files, cipher text C:
K=128 random bits, generated on target system
Then the key K is encrypted with the public key PubK, yielding encrypted key, Ks. Finally K is deleted from memory/overwritten.
Ks can be decrypted by private key PrivK - known only to the author of the ransomware.
Now, the victim sends Ks and payment to the author/attacker.
The attacker decrypts Ks using PrivK, and gets K, which is sent back to the victim - who can presumably supply K to the ransomware. Ransomware then uses K to decrypt C, yielding M - the unencrypted files.
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 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.
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 ... ?
Wouldn't this, if successful, just prevent victims from paying to decrypt their files?
Sure, it would stop the attackers from getting any bitcoin, but the victims' data would still be encrypted.
That key won't work for other victims.
This is deemed "success."
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.
Eh? Under what circumstance?
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.
- The attacker's RSA private key (UNKNOWN)
- The attacker's RSA public key (KNOWN)
- The local device's RSA private key (KNOWN, but then poorly wiped)
- This is encrypted with the attacker's RSA public key
- The local device's RSA public key (KNOWN)
- A separate AES key for each file
- These are encrypted with the local device's RSA public key
EDIT: CiPHPerCoder appears to have figured how the key management works.
The problem with these tools being made and leaked is it lowers the bar of technical expertise needed to run a scheme like this.
If it still took massive knowledge and experience the likelihood is that person could earn more legitimately thus there is a smaller pool of potential attackers.
If the worm then notices that their host "goes active" (e.g. starts a login session), they could "submerge", closing the relevant ports and so forth, until the activity goes away; and their descendant instances would, while this is happening, fall back to the ancestor[N+1]th host.
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.
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).
Not really. Or rather, a lot of zero is zero.
Well, finally Microsofts incompetence amounts to something good.
It's unlikely that the malware would stop encrypting.
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?
This is not really a mistake from the ransomware authors, as they properly use the Windows Crypto API. Indeed, for what I've tested, under Windows 10, CryptReleaseContext does cleanup the memory (and so this recovery technique won't work). It can work under Windows XP because, in this version, CryptReleaseContext does not do the cleanup. Moreover, MSDN states this, for this function : "After this function is called, the released CSP handle is no longer valid. This function does not destroy key containers or key pairs.". So, it seems that there are no clean and cross-platform ways under Windows to clean this memory.
If you are lucky (that is the associated memory hasn't been reallocated and erased), these prime numbers might still be in memory.
That's what this software tries to achieve.
> Indeed, for what I've tested, under Windows 10, CryptReleaseContext does cleanup the memory (and so this recovery technique won't work). It can work under Windows XP because, in this version, CryptReleaseContext does not do the cleanup. Moreover, MSDN states this, for this function : "After this function is called, the released CSP handle is no longer valid. This function does not destroy key containers or key pairs.". So, it seems that there are no clean and cross-platform ways under Windows to clean this memory.
I'd be curious where the change happened between XP and 10.
The readme points out that CryptReleaseContext works better in 10 and thus the recovery doesn't work.