Experts Crack Petya Ransomware, Enable Hard Drive Decryption For Free 49
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 these guys (Score:5, Insightful)
Props to the guys that cracked it and made it available!
Re: (Score:3)
Let the Cat and Mouse games begin.
Experts cracks... (Score:1)
I was hoping it would be "Experts Crack Ransomware Perps' Head Open"... but I guess I am too optimistic...
Re: (Score:2)
I think it'd be funny if we found out they actually created the ransomwear. Double points: BTC for people who pay to unlock their machines + donations for people who use this fix.
Re: (Score:1)
Yet another fanboi who neglects to mention apple has been targeted in the past as well
https://blog.malwarebytes.org/threat-analysis/2013/07/fbi-ransomware-now-targeting-apples-mac-os-x-users/
http://time.com/4249413/apple-mac-ransomware-hack/
http://securitywatch.pcmag.com/security/324170-ransomware-on-apple-s-icloud-how-the-attack-worked
Job applications? (Score:2, Funny)
What the hell kind of idiots are sending ransomware to people looking for jobs? Can't get blood from a stone...
Re:Job applications? (Score:5, Informative)
You read it wrong. These are emails posing as coming FROM job applicants, to companies looking for hires (or just random people in said company).
Re: (Score:2)
Ah. I stand corrected. That is actually far more clever and likely to work.
Re: (Score:2)
What the hell kind of idiots are sending ransomware to people looking for jobs? Can't get blood from a stone...
The ransomware is embedded in the application, and sent to companies. It's not sent to job seekers.
How did they do it? (Score:2)
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?
Re: (Score:2)
No, it doesn't store the key on the drive. That's what the GA cracks.
The key isn't stored, a yes/no is. Like MD5 (Score:5, Informative)
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.
Re: (Score:2)
Thank you. Where did you find this? I really did RTFAs and couldn't find it.
There should be many many keys that would match the hash. But I think the article said it found the "password" not the "key" so maybe that minimizes the possibilities. I suppose the code could try decrypting some bit of the MFT data to see what looks like a valid MFT, but it doesn't look like they did that.
Last link gave a hint, and it's my job (Score:5, Interesting)
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.
Always average of 1-to-1. For any decent hash ... (Score:5, Informative)
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.
Even MD5 is within 1% even distribution (Score:5, Informative)
>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.
Should be (root of x) + x (Score:3)
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.
Re: (Score:2)
Not in this case because it's the same algorithm (Score:3)
> 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
A single round encryption is EASIER w/ same method (Score:3)
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.
Re: (Score:2)
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.
Re: (Score:2)
Don't know understand why you're not getting this (Score:2)
> 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 crac
Re: (Score:2)
I see, you're still thinking generalities, don't s (Score:2)
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
These days you can't even get proper malware (Score:5, Interesting)
Refund policy? (Score:5, Funny)
Re: (Score:3)
A lot of this randomware comes in the form of javascript files. I'm sure it could be adapted to encrypt your Linux machine and, if you have /boot mounted, replace your EFI bootloader as well (MBR might be a bit tricky. It'd have to monitor/wait for when you use sudo).
I have no idea if Linux ransomware exists, but if it doesn't, it's not due to it being technically non-feasible. There are some safeguards that make it more difficult yes, but not impossible. When Mac OS started getting more popular, we started
Re: (Score:2)
The one in question asked for an Admin password. If you give a Linux system the root password (or even do a sudo) then I'm sure you can install a cryptolocker just as easily.
The interesting point on cryptolockers is you don't even need root to be effective. Encrypting the files the user owns (the real targets) doesn't require any special permissions. The only benefit you get from root level is a better chance of destroying backups.
Known-Plaintext Attack (Score:3)
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 [wikipedia.org] to extract the key. In any case, bravo!
Missing Opportunity for Slashdotters (Score:2)
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?
spam emails that masqueraded as job applications. (Score:1)
What does this mean for Salsa? (Score:3)
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!