Petya 新型勒索病毒的加密原理分析

更多腾讯海量技术文章，请关注云加社区：https://cloud.tencent.com/developer/column

作者：serena

简介

此次席卷乌克兰等全球多个国家的勒索病毒，与之前的 Petya 病毒极为相似，二者都会修改受害者电脑的 MBR，并且在电脑重启后，展示虚假的磁盘扫描界面，同时对磁盘 MFT 进行加密操作，在加密完毕后向受害者展示敲诈信息，勒索赎金。然而，有安全厂商仍然审慎地表示，此次病毒并非 Petya 勒索软件的变种。

腾讯安全反病毒实验室对样本的加密代码部分进行了分析，着重留意了代码与原始 Petya 勒索病毒的异同。

一、文件加密逻辑

之前的 Petya 勒索病毒的加密重点在于磁盘数据，在写完恶意 MBR 之后，会使系统强制重启，直接进入 MBR 引导模式；只有在写 MBR 失败的情况下，病毒才会使用备用方案，利用 Mischa 勒索病毒加密磁盘文件。

而此次爆发的勒索病毒，会使用计划任务执行重启操作，在电脑尚未重启之前，病毒还会开启一个线程执行文件加密操作：

而在文件加密的过程中，只会对文件的前 1MB 字节进行加密，以此提升加密的速度：

二、磁盘加密逻辑

1.磁盘加密整体流程

2.修改磁盘引导扇区

勒索病毒样本在写入磁盘时，分为四个部分写入不同的扇区。

首先是恶意 MBR 代码部分，从扇区 0 开始一共写入了 19 个扇区，这部分包含伪装磁盘扫描界面、加密 MFT、显示勒索文字、接受用户输入密码并尝试解密等完整功能：

其后，病毒又写入了 0x20、0x21、0x22 三个扇区的内容：

从后往前看，三个扇区的功能分别如下：

0x22 扇区存放的是病毒一开始从磁盘中读取的原始 MBR 内容，与 0x07 进行 XOR 操作的结果：

0x21 扇区存放的是长度为 0x200 字节的 0x07 的内容：

在加密过程中，此扇区也会使用与 MFT 相同的密钥进行加密，用于在用户输入密钥之后进行解密验证：

0x20 扇区存放的是加密流程中用到的一些配置内容，比如加密密钥等。在之前的 Petya 敲诈病毒中，此扇区结构如下：

（参考：Petya: the two-in-one trojan）

而此次病毒写入内容的格式也基本一致：

所不同的只是显示的暗网地址被换成了比特币地址。

3.MBR 加载与勒索

MBR 启动后，通过 int13 AH=42 将 1 到 21 扇区的内容拷贝到内存 0x8000 处，并在随后执行。

在经过标志位（0x20 扇区中的 state）的比较，判断当前磁盘是否已经被加密，如果被加密则直接显示敲诈信息，否则则展示虚假的磁盘检查信息

随后，程序会调用 salsa20 算法对 MFT 进行对称加密，key 是 32byte 大小的 salsa_key，iv 是 8byte 大小的 salsa_iv。

病毒作者还对 salsa 算法的初始化参数做了修改，由原始算法的"expand 32-byte k"变成了如下字符串：

通过此算法，最终会把 MFT 逐个字节的进行对称加密。加密完成后，密钥会从磁盘中删除，防止加密数据被还原。

而 ec_data 被展示在敲诈界面上，作为受害者个人标识：

4.可疑的 ec_data

引起我们注意的即是这个 ec_data。在之前的 Petya 敲诈病毒中，此数据是使用密钥经过 ECDH、SHA、AES 等多次运算后得到的一个 Base58 字符串，目的是使用此数据与病毒作者手中的私钥一起可以计算出加密 MFT 使用的密钥，即前面被置空的 salsa_key 部分。

然而，在此次的敲诈病毒代码中，我们发现，病毒在生成随机数据之后，直接使用此数据生成了 Base58 字符串，并没有使用什么复杂的算法，也没有与加密密钥产生任何关联：

这就意味着，即使此次病毒作者在公布的邮箱中获取了受害者的标识，也无法将其与受害者的加密密钥对应起来。很有可能，此次病毒的始作俑者并不想帮受害者解密 MBR 部分。

结论

通过前面的分析可以看出，此次勒索病毒的作者使用了与之前 Petya 病毒类似的代码，通过 MBR 中代码、数据格式、加密流程等多处的高度一致性可以判定，这次的新型 Petya 病毒与之前的 Petya 病毒有着千丝万缕的联系。同时也可以注意到，与 Petya 病毒前几个版本不同的是，新型 Petya 病毒一方面使用了其它逻辑加密磁盘文件，另一方面并没有想要为受害者解密磁盘。我们猜测，此次勒索病毒的作者可能并非 Petya 勒索病毒的原始作者。