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