Slashdot Mirror
Experts Crack Petya Ransomware, Enable Hard Drive Decryption For Free
Reader itwbennett writes: Petya appeared on researchers' radar last month when criminals distributed it to companies through spam emails that masqueraded as job applications. It stood out from other file-encrypting ransomware programs because it overwrites a hard drive's master boot record (MBR), leaving infected computers unable to boot into the operating system. Now, security experts have devised a method that, while not exactly straightforward, allows users to recover data from computers infected with the ransomware without paying money to cyber criminals. Folks over at BleepingComputer have confirmed that the aforementioned technique works.
Props to the guys that cracked it and made it available!
Just cruising through this digital world at 33 1/3 rpm...
What the hell kind of idiots are sending ransomware to people looking for jobs? Can't get blood from a stone...
Why would the authors of the ransomware store the key on the drive?
The source code is out there, but I don't know what the salsa hash is or any of that. I take it that the ransomware actually has the key stored on the hard drive?
These days you can't even get proper encrypting malware, what are the chances that actual encrypting software available to public is any different?
I hope that they'll offer at least a partial refund to anyone who's paid in the last 30 days.
Avoid non-free software and anything from M$ and this or any ransomware will be a non-issue. GNU/Linux, and all free software for that matter, are secure by design while non-free software, or any M$ junk, is defective and insecure by design so only the M$ addicts will use M$ junk.
--
Friends don't help friends install M$ junk
Friends do assist M$ addicted friends in committing suicide.
If you're familiar with an MD5 hash, that's what's stored on the drive. Except it's a slightly different version than MD5.
If you're NOT familiar with MD5, I'll try to explain it a bit. The malware author wanted to handle the key being entered incorrectly, to have an error message saying "that's not the correct key". Without that error message, a typo while entering the key would result in decrypting the drive incorrectly, permanently destroying the data. So the malware needed a way to determine if the key is correct or not. To determine whether or not a key (or password) is correct without storing it, programmers use something called a hash.
Here's a really bad hash algorithm, just to demo the concept:
Where X is the key (a number):
(square root of X) = 110
So we store the hash, 110. Someone enters 9 as the key. The malware does the math:
(square root of 9) + 9 = 12
Since the hash doesn't match 110, that's the wrong key and it throws an error.
The hash function I just used is bad because based on the result, 110, you can easily figure out that the key must be 100. The malware used a better hash function, one based on something called "salsa20". However, the hash function they used wasn't very secure. You only have to try maybe a million keys before you find the right one. With CPUs that can try a million keys in just a few seconds, it's easy to find the key which matches the stored hash.
I don't have the specifications for a MBR memorized, but I suspect that by knowing what information should be at specific offsets, (or by experimenting with possible values), the person was able to perform something similar to a known-plaintext attack to extract the key. In any case, bravo!
Odd you say that mr. webmaster who runs google ads on his site and doesn't mind adblock users going to them when almostalladsblocked doesn't block those google ads by default but when apk puts out a program that does block them speeding up and protecting users and doing far more than that sold out to advertisers browser extension addon for less resources and moving parts JustAnotherOldDouchebagBitch yells and screams! Amazing hypocrisy? Yes. Prepare yourselves for a shitstorm of raving so bad from that old dildohead JustAnotherOldDouche that you'll need a forcefield to keep the spittle off you, hahahahaha! He had to downmod this last time I posted it. You judge. He's such a multiple sockpuppet karma farming weasel he did it again yesterday too contradicting himself here too https://slashdot.org/comments....
I was hoping it would be "Experts Crack Ransomware Perps' Head Open"... but I guess I am too optimistic...
I'm glad that tools like this exist. There have been a handful of ransomware viruses that have had decryption tools released. Amongst the issues I've had in the past is that it's quite difficult to tell which ransomware a particular computer has been hit with. Is there a way for end users to determine which ransomware application they've been hit with, ideally linking to known decryption tools?
You can't get much more evil than praying on people trying to find work. These are people with very little left to lose. People who are close to suicide or criminal behavior in many cases. I'm against torture in general but shit like that makes me question my stance.
If video games influenced behavior the Pac Man generation would be eating pills and running away from their problems.
I've been doing security for 20 years, so most of my explanation is based on reading between the lines. I think it was the last link in the article mentioned the crack starts with getting the "verification hash" from the disk, or similar wording. The rest is knowing what hashes are used for and how encryption an crypto malware works in general.
If the key were infinitely long, there would be infinitely many keys that match the hash. Since the key is approximately the same length as the hash, there is approximately ONE key that matches the hash. In computer forensics, you ALWAYS work on an image of the drive, never the original, so trying a wrong key won't hurt, if there happen to be two keys which match the hash. As you mentioned, you can also test whether or not a candidate key produces reasonable output.
So they made a Genetic Algorithm to efficiently crack Salsa. In this case, Salsa10 and not Salsa20, but what does that mean for the Salsa algorithm in general? I've not seen any real analysis of the greater fallout if Salsa is weaker than expected!
Fear: When you see B8 00 4C CD 21 and know what it means
My demonstration hash algorithm was intended to be:
For key X,
Hash = (square root of X) + X
As mentioned above, that's easily reversible, so it's a bad hash function. Good hash functions are much more complicated and should require at least a thousand years of CPU time to reverse.
> incredibly dumb on the part of the malware authors.
> All they really needed to do was have a known unencrypted blob that they could compare against after decrypting and completely avoid storing any hash
In this case, it's the same thing. Both are Salsa based.
In the general case, you can afford to use a stronger algorithm for a short plaintext (the hash) and a faster (weaker) algorithm for the main encryption, so using the hash is MORE secure than misusing the main encryption routine as if it were a hash.
Typically, a hash is consists of an encryption primitive repeated many times, 64 times in the case of SHA256 and MD5. So the hash should be stronger (and much slower) than a similar encryption.
Hashes still expose many more vectors of attack (i.e. rainbow tables.)and hence are not a safe way to check your key validity, not to mention a hash can still have multiple keys having the same hash so potential to destroy your data (not that the malware author cares much about destroyed data though).
Remember the suggestion was to encrypt a small, fixed-sized block.
You can create a rainbow table for encrypting a 16-byte block MORE easily than a hash rainbow of the same 16 bytes, because it's precisely the same operation, except the hash version does the operation 64 times.
If you stored a million bytes of encrypted data, that would be (probably) more difficult than 16 bytes of hash, but not harder than a million byte hash.
Remember the suggestion was to encrypt a small, fixed-sized block.
You can create a rainbow table for encrypting a 16-byte block MORE easily than a hash rainbow of the same 16 bytes, because it's precisely the same operation, except the hash version does the operation 64 times.
If you stored a million bytes of encrypted data, that would be (probably) more difficult than 16 bytes of hash, but not harder than a million byte hash.
incorrect. the fixed size block can easily be computer specific unlike the hash key, hell it doesn't even have to be fixed size, just a random chunk of data.
and at no point did I actually say small fixed sized chunk of data, that is entirely you trying your invention to try and make hashing look like a better option.
Let P be the number of possible plaintexts and J be the number of possible hashes. The average number of plaintexts which hash to a given value is therefore P / J.
We said the input is the same length as the hash. Therefore, there are always the same number of potential hashes of that lemgth as there are potential plaintexts. That is, P = J. Therefore, the average number of plaintexts per hash is P / P = 1.
When designing a hash function, it is fairly trivial to ensure that the distribution is approximately uniform, and virtually all hash functions in use have this property. Therefore, for substantially all hash values, the number of possible plaintexts is approximately equal to the average, which is 1.
The Average is 1, but the distribution of any current hashing algorithms is most definitely not even, hence any hash could have between 0 and X where X is the entire hash space, The larger X is the worse the algorithm but no algorithms that I am aware of come close to X being 1.
> The fixed size block can easily be computer specific unlike the hash key,
How can one be computer specific and the other not, while serving the same purpose ?
What you don't seem to be understanding is that the hash IS precisely what you're suggesting- it's a blob of data encrypted- 64 times. Your suggestion only works if either a) encrypting it 64 times is easier than encrypting it once, or b) you artificially limit the "hash" to be much smaller than the ciphertext.
A hash is GENERALLY easier to crack than a long ciphertext, simply because the cipher text is longer. In this instance, the complete program is a few hundred bytes. It's short because space is limited. Encrypting it fewer times isn't going to make it harder to crack.
>no algorithms that I am aware of come close to ... 1
Even distribution is a design requirement for hash functions. Any unevenness is predictably and therefore brokenness.
MD5 gives even distribution, though it is otherwise broken for many use cases. In one experiment, the experimenter hashed 10 million values, I believe, and compared the number of times each possible value appeared in the first 8 bits and the last 8 bits. The difference between the most common value and the least common was less than 1%. To my knowledge, there's no theory that MD5 isn't evenly distributed .
For SHA256, it is known that the distribution isn't perfectly even, but the variance from even distribution may well be less than 1% for SHA256 as well.
You say you understand security yet you don't understand the difference between a hash and encryption? a hash IS NOT ENCRYPTION
seriously you understand so little about hashing and encryption that you don't understand how an encrypted blob can be computer unique but a hash cannot be? A hash is algorithm specific with fixed lengths and when dealing with a key a fixed input length, hence you can precalculate known possibilities prior to a machine being infected. An encrypted blob of random data must be attacked on a case by case basis as you have no way to precalculate anything with rainbow tables. I am calling BS on you working in Security!
I THINK I'm starting to see where you're coming from. You're still thinking in general terms (hashes generally, encryption generally) rather than thinking about the exact purpose served here, you're ignoring the specific algorithm used by this malware, plus you're unfamiliar with how hashes are used with secrets - they are salted. Or you've thought of, but not articulated, some method that I haven't.
> You don't understand how an encrypted blob can be computer unique but a hash cannot be?
The second half of that sentence is "and serve the purpose". It has to be used to confirm whether the password is correct. Tell me if I'm missing something in how you're thinking this could be done with ciphertext:
1) Generate a machine-specific random bytes (the malware does this) .
2) Save the random bytes for later comparison. (It does this too).
3) generate a key (does this).
4) Encrypt the random bytes using the correct key (hash does this repeatedly) .
5) Decrypt the random bytes using the candidate key (a hash malware does the reverse, it encrypts with the candidate)
6) Check whether the decrypted bytes match the random bytes. (A hash does this, but compares th ciphertexts rather than the plaintexts).
Note especially that step 6 is impossible without step 2. Is that what you have mind?