WannaCry in-memory key recovery for Windows XP | Hacker News Reader

WannaCry in-memory key recovery for Windows XP

github.com

317 pointsuladzislau90 comments

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:

http://blog.cassidiancybersecurity.com/post/2014/02/Bitcrypt...

http://0xec.blogspot.com/2016/04/reversing-petya-ransomware-...

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 think it's fine to publicise better attack methods, so we can figure out how to defend against the next potential version.

We should be moving to better solutions regardless, like append-only backups.

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.

The knowledge he is writing is so basic anyone must understand.

You're saying like "We should not teach programming publicly since bad guy may misuse the knowledge."

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.

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.

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.

> Encryption is done with the public key only.

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.

So, to check if I understood.

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?

Almost, the last bit should read:

>... 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

Hopefully you're right.

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.

You're right. On the other hand, asymetric encryption if a disk will be dog slow.

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 ... ?

>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.

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.

In the scenario described, you're not giving back your private key, you're returning the decrypted key the victim needs to decrypt their data.

That key won't work for other victims.

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."

You've got to admit it's a little funny when an OS's security flaws prevent even targeted malware from working properly.

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.

But Windows 10 was for the same reason largely not affected: it was patched and rebooted.

And Windows XP was not targeted at all by WannaCry.

In that case, Microsoft wouldn't have released an emergency patch for XP, three years after end of support. But they did [0].

[0]: https://blogs.technet.microsoft.com/msrc/2017/05/12/customer...

XP could be targeted theoretically, the bug is there. But the particular WannaCry variant (which Kevin Beaumont‏ looked at) didn't work under XP:

https://twitter.com/GossiTheDog/status/863339558364229634

https://twitter.com/GossiTheDog/status/863100619242053632

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'?

Windows XP systems were the primary victims of WannaCry.

That is untrue: https://twitter.com/craiu/status/865562842149392384

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 may have been thinking of 7.

> Windows 10, by design, destructively reboots with no recourse

Eh? Under what circumstance?

It sort-of-hibernates if fast startup is enabled: https://msdn.microsoft.com/en-us/library/windows/hardware/jj...

That looks on-demand to me, I'm struggling to see the relevance?

It's by default which I learned when Linux complained it couldn't mount the Windows partition at startup.

It's hilarious that it uses public-key crypto, yet lets the client know the private key. What's even the point, then?

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.

There are 4+N keys involved.

  - 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.

If someone were to pay up and receive the attacker's private key, what's to stop them from distributing it to others?

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.

The attacker probably just decrypts your locally generated key. I doubt they send along the master key.

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.

This allows computers cut off from the internet to be infected too. Juicy and the risk is minimal.

Bitcoin payment requires internet.

You don't need bitcoin payment to be infected.

If those network requests could be identified, the whole thing would be shut down by network operators.

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.

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).

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.

Looks interesting, anyone tried these steps? Did it work for you?

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).

details: https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

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.

> If you seed with nanoseconds it'll be a lot harder.

Not really. Or rather, a lot of zero is zero.

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.

Nanosecond resolution multiplies the brute force effort by 10^9, which is negligible.

"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?

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.

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!

But...

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 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.

https://google.github.io/styleguide/cppguide.html

https://www.cert.org/downloads/secure-coding/assets/sei-cert...

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

From the TFA:

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.

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.

.NET

The Twitter says that it has been adapted to work on 7.

The readme points out that CryptReleaseContext works better in 10 and thus the recovery doesn't work.

The variant for 7: https://github.com/gentilkiwi/wanakiwi

You would be welcome to also give it a shot and publish your results

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.

It's not actually neutered because there are variants without a kill switch.

Rebooting doesn't stop the ransomware.

Reply on news.ycombinator.com