Monday, July 18, 2016

Feedly:Understanding Java Code and Malware | Malwarebytes Unpacked. Third time (un)lucky – improved Petya is out



from Understanding Java Code and Malware | Malwarebytes Unpacked

So far we dedicated several articles to the interesting, low-level ransomware called Petya, hijacking the boot sector. You can read about it here:

Each of those versions was using Salsa20 algorithm to encrypt Master File Table and make disk inaccessible. However, due to the implementation bugs the intended algorithm was weakened – giving a chance to recover data.

Unfortunately, as always in such cases, it is just a matter of time when cybercriminals get their cryptography fixed. Petya’s authors got it right at the third attempt. The currently launched wave of this ransomware finally seems to have the proper Salsa20.

Behavioral analysis

Behavior of Petya didn’t changed – we can see exactly the same UI like in the previous green edition:green_petya

Inside

Let’s take a look at differences in the code. Using BinDiff we can spot, that not many functions have changed. However, those that were giving weak points to the previous edition are modified.

main_changes

Salsa20

First of all, let’s take a look the function s20_littleendian that was causing the major bug in the last release. Due to it’s invalid implementation, only 8 out of 16 characters of the key were meaningful and brutforcing the key was easier (working solution has been implemented by procrash). Detailed explanation of this bug you can find in the updated post about the previous Petya – under the section “New Petya, new bug”.

On the left – you can see the implementation of the buggy function (from the previous edition). On the right – current, fixed implementation:

fixed_s20

Explanation
The old implementation was truncated – it didn’t used 32 bit values as it should – only added a sign bit expansion to the 16 bit value:

static int16_t s20_littleendian(uint8_t *b)
{
  return b[0] +
         (b[1] << 8);
}

Now, authors got the proper implementation, using 32 bits. So, the last bug in Salsa20 got finally fixed, making implementation complete.

Key

In the first, Red Petya authors used 32 byte long Salsa key – that was, however, generated from the 16 byte long key, using a custom function to pre-process it and extend.

In the second – Green edition, they gave up this idea and applied the original 16 byte long key, without any modification.

This time, they changed mind and went back to the first solution of using 32 byte long key, yet with some improvements. Again we can see expand32 in the code (instead of expand16 from the previous edition):

expand32

Also, when the victim insert the key for the verification, before using it as a Salsa20 key, it is preprocessed by a new algorithm (more complex than  in case of Red Petya):

process_key

Conclusion

New edition shows that the project is reaching maturity – however, as we can read on the associated onion page – it is still a beta version and we can expect that it will keep evolving. Below – fragment of Petya’s RaaS website:

beta

We are not yet sure about the distribution method, but probability is high, that also this time it is spam with a link leading to cloud hosting. We strongly advise to be extra vigilant for the job applications coming this days – it proven to be a common cover for Petya/Mischa dropper. More information about it you can find in our previous articles about Petya.

Appendix

Petya and Mischa – Ransomware Duet (Part 1)

This was a guest post written by Hasherezade, an independent researcher and programmer with a strong interest in InfoSec. She loves going in details about malware and sharing threat information with the community. Check her out on Twitter @hasherezade and her personal blog: http://ift.tt/1R6Y8zL.

Web Analytics