{"id":8200,"date":"2017-06-29T09:10:48","date_gmt":"2017-06-29T17:10:48","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/06\/29\/news-1976\/"},"modified":"2017-06-29T09:10:48","modified_gmt":"2017-06-29T17:10:48","slug":"news-1976","status":"publish","type":"post","link":"https:\/\/www.palada.net\/index.php\/2017\/06\/29\/news-1976\/","title":{"rendered":"EternalPetya and the lost Salsa20 key"},"content":{"rendered":"

Credit to Author: Malwarebytes Labs| Date: Thu, 29 Jun 2017 16:39:24 +0000<\/strong><\/p>\n

We have recently been\u00a0facing a huge outbreak of the new version of Petya-like malware armed with a infector in WannaCry-style. The research is still in progress, and the full report will be published soon.<\/p>\n

In this post we will focus on some new important aspects\u00a0that the current malware has. The low level attack works in the same style as in the first Petya described here<\/a>. As before, the beginning of the disk is overwritten by the malicious Petya kernel and bootoader. When the malicious kernel is booted, it encrypts the\u00a0Master File Table<\/a>\u00a0with Salsa20 and by this way, makes the disk inaccessible.<\/p>\n

The code from Petya’s kernel didn’t change much\u00a0but the new logic implemented in the high level part (the Windows executable) caused the change in the malware’s mission. In the past, after paying the ransom, the Salsa key from\u00a0the victim was restored and with its help, the Petya kernel was able to decrypt the Master File Table<\/a>. Now, the necessary key seems to be lost for eternity. Thus, the malware appears to have only damaging intentions.<\/p>\n

Let’s have a look at\u00a0the implementation and discuss the details.<\/p>\n

How is the disk encrypted?<\/h3>\n

The low level attack, affecting the Master File Table<\/a> didn’t change since Goldeneye<\/a>. It is executed by the Petya kernel.<\/p>\n

The Salsa20 algorithm<\/a>, that was implemented incorrectly in the early versions of Petya and caused it to be cracked, has been fixed in the version 3 (read more here<\/a>). Now it looks almost the same as in Goldeneye (that was the 4-th step in the evolution) and it\u00a0 does not seem to have any bugs. Thus, once the data is encrypted. having the valid key is the only way to restore it.<\/p>\n

Comparison of the changes in the code between the current version and the Goldeneye one:<\/p>\n

\"\"<\/p>\n

Looking inside the code we can see, that the significant changes has been made only the elements responsible for displaying the screen with information, i.e.:<\/p>\n

\"\"<\/p>\n

How is the Salsa key generated?<\/h3>\n

Generating the Salsa key and the nonce, as before, is done by the PE file (in the higher level of the infector), inside the function that is preparing the stub to be written on the disk beginning:<\/p>\n

\"\"<\/p>\n

In all versions of Petya, a secure random generator was used. In the current version we can find it as well – it uses CryptGenRandom<\/em>:<\/p>\n

\"\"<\/p>\n

The generated Salsa key and nonce are stored in the dedicated sector, for further use by the kernel during encryption.<\/p>\n

Example of the stored data:<\/p>\n

\"\"<\/p>\n

The byte at the offset 0x4000 is the flag. 0 means that the disk is not encrypted yet, 1 means encrypted.<\/p>\n

From the offset 0x4001 the Salsa20 key starts. It is 32 bytes long. After that, at offset 0x4021 there is the random Salsa20 nonce.<\/p>\n

What happens with the Salsa key after the encryption?<\/h3>\n

After being read and used for the encrypting algorithm, the stored Salsa key is erased from the disk. You can see the comparison of the disk image before and after the encryption phase:<\/p>\n

\"\"<\/p>\n

As we can see, after use the key is erased.<\/p>\n

What is the relationship between the victim ID and the Salsa key?<\/h3>\n

In the previous versions of Petya, the victim ID was, in fact, the victim’s Salsa20 key, encrypted with attackers public key and converted to Base58 string. So, although the Salsa key is erased from the disk, still there was a backup – accessible only for to the attackers, who had the private key to decrypt it.<\/p>\n

Now, it is no longer true. The victim ID is generated randomly, BEFORE the random Salsa key is even made. So, in the current version, the relationship of the Salsa key and the victim ID is none. The victim ID is just ‘trash’. You can see the process of generating it on the video:<\/p>\n