Please create an account to participate in the Slashdot moderation system


Forgot your password?
Bitcoin Security Businesses Crime Encryption Microsoft Network Operating Systems Privacy Software The Almighty Buck The Internet Windows Build Technology

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.
This discussion has been archived. No new comments can be posted.

Experts Crack Petya Ransomware, Enable Hard Drive Decryption For Free

Comments Filter:
  • by JustAnotherOldGuy ( 4145623 ) on Monday April 11, 2016 @02:58PM (#51886811)

    Props to the guys that cracked it and made it available!

    • by mrops ( 927562 )

      Let the Cat and Mouse games begin.

      • by Anonymous Coward

        I was hoping it would be "Experts Crack Ransomware Perps' Head Open"... but I guess I am too optimistic...

    • by SumDog ( 466607 )

      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.

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

    • No, it doesn't store the key on the drive. That's what the GA cracks.

    • by raymorris ( 2726007 ) on Monday April 11, 2016 @03:57PM (#51887193) Journal

      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.

      • by MobyDisk ( 75490 )

        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.

        • by raymorris ( 2726007 ) on Monday April 11, 2016 @06:14PM (#51887957) Journal

          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.

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

      • interesting and 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, once you have a hash there are all sorts of attack vectors from brute force to rainbow tables that make this far easier
        • > 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

  • by sinij ( 911942 ) on Monday April 11, 2016 @03:25PM (#51886993)
    These days you can't even get proper encrypting malware, what are the chances that actual encrypting software available to public is any different?
  • by safetyinnumbers ( 1770570 ) on Monday April 11, 2016 @03:36PM (#51887071)
    I hope that they'll offer at least a partial refund to anyone who's paid in the last 30 days.
  • by nuckfuts ( 690967 ) on Monday April 11, 2016 @04:51PM (#51887503)

    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!

  • 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.
  • by throx ( 42621 ) on Monday April 11, 2016 @06:17PM (#51887969) Homepage

    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!

Harrison's Postulate: For every action, there is an equal and opposite criticism.