【技术分享】解密NotPetya/Petya：恢复MFT-安全客

预估稿费：200RMB

投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿

0x00 前言

本文中，我们将通过一些发现和工具来解密NotPetya/Petya。使用我们提供的工具，几乎所有的MFT能在数分钟内恢复。

0x01 解密MFT

毫无疑问，MFT是NTFS文件系统最重要的数据结构之一。它包含了文件系统中的文件列表，及元数据（如日期，文件大小，磁盘位置等）。没有MFT的话，任何试图恢复文件的动作都将徒劳。通过利用NotPetya/Petya中的Salsa20加密算法实现中的漏洞来解密MFT是唯一的可能。基本上，它可以是一种已知明文攻击和多次攻击的组合。注意这种攻击不意味着Salsa20可以被破坏，它只影响了具体的实现。

0x02 如何解密MFT

为了恢复MFT，首先，需要从受感染的硬盘中提取出MFT。这可以通过磁盘取证实现，通过将受感染的硬盘附加到未受感染的系统中，或者通过live CD引导受感染的计算机。

假设使用前者，如使用名为disk.dd的磁盘取证工具，通过下面的命令提取出MFT（存为文件mft.raw）:

第一个命令（mmls）返回分区表。通常，NFTFS主分区的起始扇区是63或者2048。第二个命令（icat）输出NTFS分区的MFT到文件mft.raw中。

一旦提取了加密的MFT，可以使用工具decryptPetya.py来解密它。

取决于MFT的大小和加密的记录的数量，解密时间大约在2~30分钟之间。

DecryptPetya.py的命令行选项如下：

根据提供的选项，脚本输出解密后的MFT（文件名为[mft].decrypted_strict 或者 [mft].decrypted_relaxed）。默认情况下，是relaxed解密。无论如何，它都会尝试解密输入的密文。通过使用“-strict”选项可以使得结果更加可靠。

0x03 手动分析解密后的MFT记录

很少情况下需要恢复第一个或最后几个MFT记录。可以从decryptPetya.log文件获得帮助。日志文件尽可能的输出指定密文对应的明文。下面提供了一个例子。

在默认用例中，decryptPetya.py已经填充了明文。这个例子中，0.9876的确定性的字节0x00被写入到解密后的记录中。

0x04 进一步分析MFT

一旦符合了MFT结构，可以进一步分析，例如使用类似的工具（analyzeMFT.py）,或patch到硬盘中。

0x05 技术细节

那么，Petya（也被NotPetya作者拷贝了）的作者到底犯了什么错误，导致可以解密MFT呢？

之前关于Petya和NotPetya的报告中表明了他们共享了不完善的Salsa20加密算法。代码与GitHub中找到的开源实现非常类似。尽管源代码的实现是正确的，但是Petya的作者在转换16位代码时犯了几个错误。这些错误使得Petya/NotPetya有漏洞，可以使用已知明文攻击来解密大部分MFT。

0x06 Salsa20流位置漏洞

本节描述了NotPetya/Petya中的流位置漏洞。NotPetya/Petya使用一定数量的扇区，而不是使用要加密的流数据中的字节偏移，这对这种方式的安全性有严重影响。

NotPetya/Petya使用一个修改版本的Salsa20，其是一个流对称加密算法，映射一个256位密钥、一个64位nonce以及一个64位流位置到一个512位的输出。主要的加密功能位于s20_crypt()函数中。由于position参数，这个算法可以在常量时间内在密钥流中寻找任意偏移。这个算法依赖伪随机数生成器（PRNG）来生成用于与明文异或操作的密钥流。下图是Salsa20算法的概述：

Salsa20 PRNG函数（s20_expand()），有下面4个参数：

1.一个立即数（-1nvalid s3ct-id），区别于原始算法中的立即数（expand 32-byte k）

2.一个32字节的随机生成的密钥

3.一个8字节的随机生成的nonce

4.一个8字节整数，表示流位置，但是实际上是要加密的数据的扇区号

s20_crypt()的反汇编代码如下：

正如红色标记所示，用于从磁盘中读取的扇区和s20_crypt()函数中的流偏移是同一个变量。之后扇区号用于作为PRNG函数s20_expand()的输入，如下面反汇编所示：

实际上，使用的是扇区号，而不是实际的流位置（字节），使得NotPetya/Petya能被已知明文攻击。考虑到下面参数的例子：

32字节密钥：

Nonce:

下个加密的扇区号：0x00600061

使用函数号/64来作为参数（如0x18001）调用S20_expand_key()函数。

密钥流如下：

通过下面的公式计算得到密钥流的索引：

因此，真正的XOR流起始于密钥流的索引0x21：

接下来，扇区0x00600062被加密了。因为扇区号只增加1，异或结果为：

因此，如果NotPetya/Petya加密扇区i，64字节密钥状态为FF D7 83 CF […]，对于扇区i+1的密钥状态是D7 83 CF B2 […]。这个可以用于针对NotPetya/Petya实施已知明文攻击。背后的原因是一次已知明文攻击可以提取出密钥流。用x表示明文，k表示密钥流，那么E(x) = x ⊕ k。如果x是已知的，密钥能通过再次异或恢复：E(x) ⊕ x = (x ⊕ k) ⊕ x = k。这利用了异或的特性。一旦知道了密钥流，密文的其他部分也能解密。

0x07 利用流位置漏洞

在上节中，我们看到了如果我们只要了底层明文，我们能通过异或简单的计算出原始密钥流。由于密钥流的重复性，这能用于推导出大部分密钥流。首先，需要解密MFT。它几乎是已知明文攻击的一种完美的数据结构。通常，MFT包含连续的MFT记录列表。每个MFT记录有下面的结构：

通常，每个记录是1024字节，等于2个扇区。有了上面的知识，很明显，所有的记录的密钥流字节中有重叠。下图是重叠的地方：

虽然第一个密钥流只有一些重叠，随着索引变大情况会发生变化，可以手机更多的样本。直到MFT末尾，早前的记录会消失，剩余的记录再次积累到相关少量的样本。

有两种不同的方法来利用密钥流：

1.MFT头，假设MFT头的前几个字节是常量

2.Byte histogram，可以计算指定扇区出现明文的可能性

想法是遍历MFT，模拟NotPetya/Petya实现的扇区处理。针对每个MFT记录，收集数据结构中潜在的密钥流。如果找到相同的密钥流，更新可能性。在解析MFT之后，分析数据结构，只有满足确定条件的才置为密钥流。

0x08 MFT头攻击

在大部分记录中，前8个字节是46 49 4C 45 30 00 03 00。在这种假设下，能直接推导密钥流。然而，只有明文的前8个字节恢复了，这种攻击不能解密整个MFT。而且，每个密钥流索引最多可以收集4个样本。

因此，我们进一步使用这种方式来使得可能字节的范围扩大的方法，称为byte histogram。

0x09 Byte Histogram攻击

实际上MFT记录中的大部分元素有固定的大小可以被利用。从这个事实中看，相同数据类型出现于每个记录中相同的偏移位置。为了获得指定偏移的字节的存在性，在MFT记录中每个偏移的histogram能通过从Windows安装中收集的一系列110万的记录计算得到，只选择最多10个不同值的histogram或者明显偏向某一确定值的histogram。

使用这种方法，可以从每个MFT记录中收集更多的密钥流。

0x0A 测试

在VM中的Windows XP中测试。使用NotPetya感染VM，并创建感染的快照，但是还没加密系统。提取MFT，并启动VM，使得NotPetya继续运行。在那之后，再提取加密的MFT。干净的MFT包含27984的记录。

0x0B 解密MFT

我们将两种攻击应用于加密的MFT，并比较。得到下面的结果：