Live data from Hacker News

WannaCry in-memory key recovery for Windows XP

github.com

41–50 of 95 posts

Re: WannaCry in-memory key recovery for Windows XP

#41

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

Re: WannaCry in-memory key recovery for Windows XP

#42
post #28
post #8

Earlier quoted context omitted.

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.

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

Re: WannaCry in-memory key recovery for Windows XP

#43

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 r…

[deleted]

Re: WannaCry in-memory key recovery for Windows XP

#44
post #41

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…

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.

Re: WannaCry in-memory key recovery for Windows XP

#45
post #22

Earlier quoted context omitted.

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.

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.

Re: WannaCry in-memory key recovery for Windows XP

#46
post #22

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

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.

Re: WannaCry in-memory key recovery for Windows XP

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

Re: WannaCry in-memory key recovery for Windows XP

#48
post #44
post #41

Earlier quoted context omitted.

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…

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.

Re: WannaCry in-memory key recovery for Windows XP

#49

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, bu…

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

Re: WannaCry in-memory key recovery for Windows XP

#50
post #49

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, bu…

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 (chance of getting caught * penalty)) then it was "smart". That's what is good and bad these days; pow…

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.
Post reply on HN