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.
There seems to be an inverse correlation between smart and evil in human beings which is reassuring, but only mildly.
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:
Not to interfere with any internal screaming, but I think (hope?) most would agree that a secondary elephant in the room is that suppressing knowledge so as not to help the "bad guys" tends to be the worse evil.
I don't see how that applies in this case. This is just someone saying hey bad guy, here is an idea on how to perform your dastardly act "better."
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.
I believe it applies, as someone who doesn't know much about crypto AND is interested in protecting myself, this small tidbit of information moves me closer to being an aware and self-defensive computer user.
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.
This is different. He I specifically addressing what the bad guys should do. If he talked in more technical terms without spelling out what the bad guys should do, your argument would be legitimate.
> 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.
No. Encryption is done with the public key only. No knowledge of the private key is required. The private key is only used for decryption and can be delivered to the victim after payment is made.
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.
Probably obvious, but they would not want to send a private key which could be used to help other victims. If they generated a symmetric key locally and encrypted it with their provided public key, they could decrypt the symmetric key for you in exchange for payment.
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
C=aes(K, M)
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.
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
Of course smart != depth of cryptographic knowledge, but smart => acquiring said cryptographic knowledge when building a tool that deals with cryptography. If they were just teenagers, maybe you have a point.
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.
That is not how async crypto works. If you only provide the public key (as opposed to creating a keypair locally) you could print it out to the victim and it wouldn't matter, as it can only be used to encrypt.
Which is exactly my point. Ideally, you want to encrypt with a key that is different from the key that you need to decrypt, so that you can encrypt without ever having the key that is needed to decrypt in memory. This is impossible with symmetric cryptography.
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.
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.
Come back to me when you find a single infection on XP with wcry 2.0, and then go look at when your 'emergency' patch was signed (Feb 17). Have you ever heard of 'PR'?
This assumes that Kaspersky software usage is consistent across Windows versions, which seems vanishingly unlikely since most XP systems are in China or in Corp environments.
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.
- 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
How decryption should work: Get the local device's RSA private key from the attacker (EDIT: this is not the attacker's RSA private key, it's the local one), then you can decrypt the AES key for each file.
That's exactly the trick: the attacker doesn't send you their private key, they decrypt (using their private key) the other private key that the ransomware generated on your machine, which is what was used to encrypt the per-file AES keys.
To clarify, the files are encrypted with a symmetric key, which even though is "private", is not part of a public-private key pair in asymmetric crypto.
This doesn't appear to be how WannaCry works: as ridiculous as it sounds, it looks like WannaCry actually generates a private key on the infected machine. If you look in search_primes.cpp (from line 251) in the linked repo, you'll see that the tool is literally searching the memory for prime numbers that divide the public modulus.
EDIT: CiPHPerCoder appears to have figured how the key management works.
Right, I see that now. Adding an additional layer of RSA and per-file keys is an interesting twist. Generating a public/private key pair instead of a symmetric key seems to let them encrypt as many files as they want without keeping the private key in memory (which they relied on Windows to erase).
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.
Given the infrastructure and health victims that have been hit, I certainly hope that some serious people are looking into this. Given the relatively small sums of money we've seen flowing into the bitcoin addresses, if I were the perpetrator, I would not think I'd got a particularly good deal - exchanging 40k or so for interest from a number of heavy hitting actors just doesn't seem worth it.
It probably does to a pair of 16 year olds in eastern Europe.
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 infrastructure and health victims can be compromised by generic Windows hardware not even targeting them in particular & can't recover from backups, I'd argue they aren't heavy hitters. Though maybe they'll bring some in now.
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.
Instances of the worm could notice they've landed on especially-low-activity systems with open ports, and then modify their own "descendants" to contact them on that host for key-generation. (And then relay the key material to the origin host, before wiping their local copy.)
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.
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.
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.
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?
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).
It depends on how granular your clock is, too. If you seed with a number of seconds then it's pretty easy to brute-force that. If you seed with nanoseconds it'll be a lot harder.
Can you elaborate? I'm assuming the nanosecond-precision lock seeding the RNG is based on wall clock time or system uptime, so as long as the clock is actually that precise (and why not, when the base clock signal in the CPU is ticking a couple of times each nanosecond) you'll get that many digits.
my blind guess would be that they'd delete the original file, which frees up some space, and write the encrypted version in its place (which, if the encrypted version is somehow bigger, would fail, or get truncated).
It's unlikely that the malware would stop encrypting.
This is fast-published code, probably using code cut-and-pasted from elsewhere. Completely acceptable for cases like this where publishing fast is more important than esthetics.
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.
It looks like Microsoft's documentation suggests it will only work on older versions of Windows. From the README:
> 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.
Cut them some slack, this was published a day ago or so. In a case like this, fast publication is more important: both to help people, and so other people can do things like replicating stuff on other OSs while you sleep.
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.
There seems to be an inverse correlation between smart and evil in human beings which is reassuring, but only mildly.
reply