[–] userbinator link

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

reply

[–] Senderman link

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.

reply

[–] canoebuilder link

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.

reply

[–] tomokasa link

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.

reply

[–] ccvannorman link

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.

reply

[–] ezoe link

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

reply

[–] nashashmi link

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.

reply

[–] ahomescu1 link

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

reply

[–] DaiPlusPlus link

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.

reply

[–] martinko link

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.

reply

[–] DaiPlusPlus link

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

reply

[–] tcbawo link

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.

reply

[–] pmoleri link

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?

reply

[–] e12e link

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.

reply

[–] wand3r link

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.

reply

[–] murbard2 link

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.

reply

[–] kutkloon7 link

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.

reply

[–] roblabla link

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.

reply

[–] kutkloon7 link

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.

reply

[–] paulddraper link

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

reply

[–] bengalister link

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

reply

[–] brokenmachine link

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

reply

[–] nikdaheratik link

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.

reply

[–] undefined link
[deleted]

reply

[–] paupino_masano link

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.

reply

[–] brokenmachine link

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.

reply

[–] fgrimes link

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

reply

[–] murbard2 link

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.

reply

[–] avaer link

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.

reply

[–] josteink link

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

reply

[–] nthcolumn link

And Windows XP was not targeted at all by WannaCry.

reply

[–] marksomnian link

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

reply

[–] r721 link

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

reply

[–] nthcolumn link

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

reply

[–] PhasmaFelis link

Windows XP systems were the primary victims of WannaCry.

reply

[–] dpark link

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.

reply

[–] PhasmaFelis link

I may have been thinking of 7.

reply

[–] pjc50 link

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

Eh? Under what circumstance?

reply

[–] rzzzt link

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

reply

[–] pjc50 link

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

reply

[–] kaybe link

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

reply

[–] undefined link
[deleted]

reply

[–] mr_overalls link

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

reply

[–] ahomescu1 link

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.

reply

[–] CiPHPerCoder link

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.

reply

[–] uep link

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

reply

[–] equivrel link

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.

reply

[–] chinhodado link

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.

reply

[–] knome link

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

reply

[–] equivrel link

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.

reply

[–] ahomescu1 link

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

reply

[–] undefined link
[deleted]

reply

[–] soared link

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.

reply

[–] kybernetikos link

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.

reply

[–] jamiek88 link

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.

reply

[–] closeparen link

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.

reply

[–] kccqzy link

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.

reply

[–] kaoD link

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

reply

[–] paulddraper link

Bitcoin payment requires internet.

reply

[–] brokenmachine link

You don't need bitcoin payment to be infected.

reply

[–] kybernetikos link

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

reply

[–] derefr link

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.

reply

[–] gregmac link

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.

reply

[–] undefined link
[deleted]

reply

[–] TazeTSchnitzel link

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

reply

[–] Dylan16807 link

That's still the correct response to a potential worm, shut it down before it can do damage.

reply

[–] brazzledazzle link

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.

reply

[–] matchagaucho link

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

reply

[–] giis link

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

reply

[–] varenc link

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

reply

[–] mikeash link

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.

reply

[–] kaoD link

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

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

reply

[–] mikeash link

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.

reply

[–] kaoD link

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

reply

[–] dec0dedab0de link

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?

reply

[–] kutkloon7 link

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

reply

[–] chii link

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.

reply

[–] limeblack link

Does anyone know what would have happened if my laptop was encrypted with wannacry and my laptop hard drive was basically full?

reply

[–] xen2xen1 link

So if this spreads across a network, do they all share the same key? Can you use the XP key on a 10 machine?

reply

[–] gpvos link

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.

reply

[–] sergior link

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?

reply

[–] dmitrygr link

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.

reply

[–] genesee link

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.

reply

[–] dafrankenstein2 link

.NET

reply

[–] maxerickson link

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.

reply

[–] t3f link
[–] tty7 link

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

reply

[–] gpvos link

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.

reply

[–] IntelMiner link

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

reply

[–] milankragujevic link

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

reply

[–] sp332 link

Rebooting doesn't stop the ransomware.

reply

[–] campuscodi link

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.

reply