Your browser is obsolete!

The page may not load correctly.

Encrypt everything

Закодировать всё

Other issues in this category (24)
  • add to favourites
    Add to Bookmarks

Sometimes it’s better to remain silent

Read: 29737 Comments: 2 Rating: 10

Friday, July 21, 2017

As you've already learnt from our previous issues, data compromised by encryption ransomware can be recovered successfully because of virus writers' errors. For obvious reasons, we don't want to go into detail here because a thorough analysis of their mistakes would be a valuable gift for Trojan makers and would surely help them craft another, more advanced version.

Alas, some people do not adhere to this approach, and very helpful tips for malware makers appear on the Web. For example:

It turned out that the authors of NotPetya (a.k.a. Petya, Petya.A, ExPetr) made a mistake in their implementation of the Salsa20 routine. As a result, half of the encryption key bytes remained unused. Unfortunately, reducing the key length from 256 to 128 bytes doesn't give us hope that it can be cracked any time soon.

However, certain specific features in Salsa20 allow data to be recovered even without knowing the actual key.

https://habrahabr.ru/company/pt/blog/332618/

The post is very interesting. The text contains a lot of sophisticated terms, so we won't be quoting it extensively. Let's consider just a few points.

Here the author examines how malware makers use a data type which appears to be insufficient for a proper index length:

Let's take a look at the s20_crypt32() function prototype. This function is used to encrypt data.

enum s20_status_t s20_crypt32(uint8_t *key,
                            uint8_t nonce[static 8],
                            uint32_t si,
                            uint8_t *buf,
                            uint32_t buflen)

The si argument (apparently, Stream Index) is used to define the stream byte offset. Judging by the argument type, we see that it only allows for 32 bits rather than 64. This value is passed into keystream after being divided by 64; so, no more than 26 bits remain.

// Set the second-to-highest 4 bytes of n to the block number
    s20_rev_littleendian(n+8, si / 64);

The errors in the routine’s implementation allow different pieces of data to be encrypted using the same parameters:

Only 16 bits out of 26 in the block number (with offset 0x20-0x21) will affect the keystream. Therefore, the maximum gamma period will be 2^16=65536 blocks of 64 bytes or 4 megabytes.

Only 16 bits out of 26 in the block number (with offset 0x20-0x21) will affect the keystream. Therefore, the maximum gamma period will be 2^16=65536 blocks of 64 bytes or 4 megabytes.

It's a trivial logic error.

When the s20_crypt32() function is called, the number of a 512-byte sector is transmitted instead of the byte offset.

Here is how encryption parameters can be recovered:

The ransomware encrypts the first two sectors containing data of each file greater than 1024 bytes in size. As a rule, a cluster occupies more than two sectors (e.g., 8) In this case, we can find the beginning of a file that has been compromised, skip 1024 bytes, and get the subsequent 3 kilobytes that haven't been encrypted. And, if we get hold of a file that has the same 3 kilobytes at the 1024 byte offset, it is very likely that the beginning of the file will also match. And we'll get another 1024 gamma bytes.

Unfortunately the mistakes were made in the encryption module used if the ransomware manages to acquire administrative privileges and encrypt the entire hard drive using the Salsa20 routine. If the malware fails to acquire the permissions, it will use the AES cipher to encrypt only user data. And to recover information compromised using this routine, one will require an RSA private key.

#encryption_ransomware #Trojan #Trojan.Encoder

The Anti-virus Times recommends

  1. Sometimes by pointing out attackers' mistakes, one can actually do them a favour. Surely, giving out recommendations free of charge is not punishable by imprisonment, but sometimes they serve criminals so well that the authors behind the recommendations may as well be accomplices to malware makers.
  2. If data gets encrypted, it's not always “game over”.
  3. If your files have been compromised and no decryption utility exists thus far, don’t delete them. Someone may come up with a decryption routine sometime soon.

[Twitter]

Tell us what you think

To leave a comment, you need to log in under your Doctor Web site account. If you don't have an account yet, you can create one.

Comments

Comments to other issues | My comments