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

2017-06-29 来源:原创 作者:腾讯电脑管家
【文章摘要】此次勒索病毒席卷乌克兰等全球多个国家,腾讯安全反病毒实验室通过分析样本的加密代码部分,发现此次勒索病毒的作者使用了与之前Petya病毒类似的代码,通过MBR中代码、数据格式、加密流程等多处的高度一致性可以判定,这次的新型Petya病毒与之前的Petya病毒有着千丝万缕的联系。

此次席卷乌克兰等全球多个国家的勒索病毒,与之前的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敲诈病毒中,此扇区结构如下:

(参考:https://securelist.com/petya-the-two-in-one-trojan/74609/)

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

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

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勒索病毒的原始作者。


电脑管家 V16

全新上线 更轻更快