EFS 加密的一线生机－加密帐户被删的补救方法

Referer: http://blogs.itecn.net/blogs/ahpeng/archive/2006/04/20/Hack_in_EFS.aspx

引子： 看到新闻组里那么多网友"哭诉" EFS 问题，早就想写一篇 EFS 的文章。但是苦于手头资料太少，很多概念尚未圆润贯通，匆匆草就之下，这误人子弟的罪责，怕是逃不过的。

声明： 本文参考了国外一篇"牛"文，由于要掌握这篇国外文章，读者必须具备一些 NTFS 底层知识，否则难窥其堂奥。故此笔者四处网罗资料，加上穿凿附会，希望能帮助读者诸君更方便省时地领会这篇文章，舞好 EFS 这把双刃剑。文章链接如下：

<http://www.beginningtoseethelight.org/efsrecovery/index.php>

这里需要提醒用户注意：本文并非为了证明微软的 EFS 存在 " 漏洞 " ，也不是专为马大哈们准备的包治百病的 " 后悔药 " 。事实上如果没有导出 EFS 证书和私钥，那么一旦删除用户、或者重装系统， EFS 加密文件就不属于你了。

提示 本文适用于 Windows XP Professional 单机环境，并假设没有恢复代理 (DRF) 和共享访问帐户 ( 多个 DDF) 。

任务描述

如果某个用户把自己的登录帐户删除，那么其他用户将无法访问其 EFS 加密文件。更可恶的是，一旦公司里的某个用户心怀怨气，恶意加密了本属于别的用户的重要文件，将会导致严重问题。一般情况下，这些 EFS 加密文件已经被判了死刑，但是实际上只要满足以下条件的话，我们还是可以在末日来临之前打开逃生的天窗：

(1) 必须知道该被删帐户的密码。

(2) 该被删帐户的配置文件必须存在。如果使用"本地用户和组"管理单元删除帐户，则配置文件保留的机会很大，如果使用"用户帐户"控制面板删除帐户，则有一半机会保留配置文件。如果配置文件不幸被删，则只能祈祷可以借助 Easy Recovery 之类的数据恢复工具进行恢复。

可能有些朋友会觉得这两个条件比较苛刻，此处卖个关子先……

EFS 加密原理

大家知道， EFS 加密实际上综合了对称加密和不对称加密：

(1) 随机生成一个文件加密密钥 ( 叫做 FEK) ，用来加密和解密文件。

(2) 这个 FEK 会被当前帐户的公钥进行加密，加密后的 FEK 副本保存在文件 $EFS 属性的 DDF 字段里。

(3) 要想解密文件，首先必须用当前用户的私钥去解密 FEK ，然后用 FEK 去解密文件。

看到这里，似乎 EFS 的脉络已经很清晰，其实不然，这样还不足于确保 EFS 的安全性。系统还会对 EFS 添加两层保护措施：

(1) Windows 会用 64 字节的主密钥 (Master Key) 对私钥进行加密，加密后的私钥保存在以下文件夹：

%UserProfile%\Application Data\Microsoft\Crypto\RSA\ SID

提示 Windows 系统里的各种私有密钥，都用相应的主密钥进行加密。 Windows Vista 的 BitLocker 加密，也用其主密钥对 FVEK( 全卷加密密钥 ) 进行加密。

(2) 为了保护主密钥，系统会对主密钥本身进行加密 ( 使用的密钥由帐户密码派生而来 ) ，加密后的主密钥保存在以下文件夹：

%UserProfile%\Application Data\Microsoft\Protect\ SID

整个 EFS 加密的密钥架构如图 1 所示。

图 1

提示 EFS 密钥的结构部分，参考自《 Windows Internals 4th 》的第 12 章。

回到" 任务描述 "部分所述的两个条件，现在我们应该明白原因了：

(1) 必须知道该被删帐户的密码：没有帐户密码，就无法解密主密钥。因为其加密密钥是由帐户密码派生而来的。

提示 难怪 Windows XP 和 2000 不同，管理员重设帐户密码，也不能解密 EFS 文件。

(2) 该被删帐户的配置文件必须存在：加密后的私钥和主密钥 ( 还包括证书和公钥 ) ，都保存在配置文件里，所以配置文件万万不可丢失，否则就会彻底"鬼子不能进村"。重装系统后，原来的配置文件肯定被删，这时候当然不可能恢复 EFS 文件。

可能有用户会想，只需新建一个同名的用户帐户，然后把原来配置文件复制给新帐户，不就可以解密 EFS 文件了？原因在于帐户的 SID ，因为新建用户的 SID 不可能和老帐户一样，所以常规方法是不可能奏效的。我们必须另辟蹊径，让系统再造一个完全一样的 SID ！

恢复步骤

为了方便描述，这里假设被删帐户的用户名为 Admin ， Windows 安装在 C 盘。

1 ．再造 SID

注意 本方法取自"声明"部分提到的那篇文章。

首先确认被删帐户的 SID ，这里可以进入以下文件夹：

C:\Documents and Settings\ Admin \ Application Data\Microsoft\Crypto\RSA

在其下应该有一个以该被删帐户的 SID 为名的文件夹，例如是 S-1-5-21-4662660629-873921405-788003330-1004(RID 为 1004)

现在我们要设法让新建帐户同样具有 1004 的 RID ，这样就能达到目的。

在 Windows 中，下一个新建帐户所分配的 RID 是由 HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account 注册表项的 F 键值所确定的。 F 键值是二进制类型的数据，在偏移量 0048 处的四个字节，定义下一个帐户的 RID 。那么也就是说，只需要修改 0048 处的四个字节，就能达到目的 ( 让新建帐户获得 1004 的 RID) ！

确认好以后，别忘记把 Admin 帐户的配置文件转移到别的地方！

(1) 默认情况下，只有 system 帐户才有权限访问 HKEY_LOCAL_MACHINE\SAM ，这里在 CMD 命令提示符窗口，运行以下命令，以 system 帐户身份打开注册表编辑器：

psexec -i -d -s %windir%\regedit.exe

提示 可以在以下网站下载 psexec ：

<http://www.sysinternals.com/Utilities/PsExec.html>

(2) 定位到 HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account 注册表项，双击打开右侧的 F 键值。

(3) 这里要说明一下， Windows 是以十六进制、而且以反转形式保存下一个帐户的 RID 。什么意思呢？也就是说，如果是 1004 的 RID ，对应十六进制就是 03EC ，但是我们必须把它反转过来变成 EC03 ，再扩展为 4 个字节，就是 EC 03 00 00 。

所以，我们应该把 F 键值的 0048 偏移量处，把其中四个字节改为" EC 03 00 00 "，如图 2 所示。

图 2

(4) 重要： 别忘了重启计算机！

(5) 重启以后，新建一个同名帐户 Admin ，它的 SID 应该和以前是完全一样。如果不相信的话，可以借助 GetSID 或者 PsGetSID 等工具测试一下。

2 ．"破解" EFS

接下来的方法就非常简单了，用新建的 Admin 帐户身份登录系统，随便加密一个文件，然后注销，用管理员帐户登录系统，把原来保留的配置文件复制到 C:\Documents and Settings\ Admin 文件夹下。

再用 Admin 帐户登录系统，现在可以解密原来的 EFS 文件了。

疑难解答

1 ．如果已经重装系统，那怎么办？

"声明"部分提到的那篇文章里提到，如果还记得原来帐户的密码，并且配置文件没有被删除的话，还有希望。这时候可以借助 sysinternals 的 NEWSID 工具把系统的计算机 SID 重设为原来的值，再用前面描述的方法构造所需的 RID ，这样就可以获得所需的帐户 SID 。剩余步骤完全一样。

<http://www.sysinternals.com/Utilities/NewSid.html>

2 ．有用户曾经遇到这样的问题：登录系统时收到提示说密码过期，需要重设，重设密码登录后发现打开 EFS 文件。

KB890951 提到这个问题。其解释是因为在修改密码时，系统还没有加载配置文件 ( 有点语焉不详 ) ，原文如下：

This problem occurs because the user profile for the current user is not loaded correctly after you change the password.

配置文件和 EFS 有何相干？看完本文，大家应该知道， EFS 的私钥和主密钥都是保存在配置文件里的。由于配置文件没有加载，所以主密钥的加密版本没有得到更新 ( 没有跟上帐户密码的变化 ) ，导致主密钥无法正确解密，从而无法解密私钥和 FEK 。这就是问题的真正原因。

该 KB 提供了一个内部补丁，可以解决这个问题。 KB890951 的链接如下：

<http://support.microsoft.com/kb/890951>

3 ．有关公钥的问题

为了容易理解，笔者故意忽略了公钥。公钥保存也保存在帐户的配置文件里：

%UserProfile%\Application Data\Microsoft\SystemCertificates\My\Certificates

在 EFS 恢复的操作中，必须确保公钥也要复制到新帐户的配置文件里。尽管看起来公钥与 EFS 解密无关 ( 它负责加密 ) 。

原来，加密文件 $EFS 属性的 DDF 字段里除了有帐户 SID 和加密的 FEK 副本外，还有公钥的指纹信息 (Public Key Thumbprint) 和私钥 GUID 信息 ( 私钥的某种散列值 ) 。

系统在扫描加密文件 $EFS 属性中的 DDF 字段时，根据用户配置文件里的公钥中所包含的公钥指纹和私钥 GUID 信息，当然还有帐户的 SID ，来判断该帐户是否具有对应的 DDF 字段，从而判断该用户是否属于合法的 EFS 文件拥有者。

所以公钥也很重要。

当然公钥是可以"伪造"的 ( 可以伪造出所需的公钥指纹和私钥 GUID) ，以欺骗 EFS 系统，具体方法可以参考国外的那篇原稿，此处不再赘述。

加强 EFS 的安全

由于 EFS 把所有的相关密钥都保存在 Windows 分区，所以这可能给 EFS 带来一定的安全隐患。目前有一些第三方工具号称可以破解 EFS ，这些工具首先攻击 SAM 配置单元文件，尝试破解帐户密码，从而破解帐户密码→主密钥的加密密钥→主密钥→ EFS 私钥→ FEK 的 " 密钥链 " 。

为了防止攻击者窥视我们的 EFS 文件，可以借助以下三种方法：

1 ．导出删除私钥

可以用证书向导导出 EFS 加密证书和私钥，并且在 " 证书导出向导 " 对话框里选择删除私钥，如图 3 所示。

图 3

删除私钥以后，攻击者就没有办法访问 EFS 加密文件了，而我们需要访问时，只需导入先前备份的证书和私钥即可。

2 ． System Key 提供额外的保护

System Key 可以对 SAM 配置单元文件和 EFS 私钥提供额外保护。 Windows XP 的 System Key 默认保存在本地，我们可以运行 syskey 命令，强制系统将 System Key 保存在软盘里，或者用启动密码 (startup password) 来生成 System Key 。

由于 EFS" 密钥链"的根密钥 (System Key) 没有保存在本地计算机中， 所以攻击者将更加难以破解 EFS 加密。

提示 BitLocker 加密的 recovery key ，类似于 syskey 的 startup password ，都是借助启动时所输入的一串密码来生成所需的密钥。

3 ． BitLocker 提供更彻底的保护

本方法仅适用于 Windows Vista(Enterprise 和 Ultimate Edition) 。

最彻底的保护方法，首推 Windows Vista 新引入的 BitLocker 加密，这时候 Windows 分区的所有内容全部被加密 ( 包括 SAM 配置单元、 EFS 密钥 ) 。

BitLocker(TPM1.2) 加密可以看成是 Windows 启动保护器。在系统启动时， TPM 芯片会负责分析各个重要的启动组件，以判断自己是否位于原来的计算机环境。如果是的话，就依次释放 BitLocker 加密所需的密钥链，我们才能顺利地访问 Windows ，才能访问 EFS 文件。

如果攻击者企图把硬盘挂接到别的计算机上，系统就会拒绝释放密钥，整个 Windows Vista 分区处于加密状态。

如果攻击者窃取了计算机，并且窃取了 BitLocker 所需所有条件 (TPM 芯片自不必说，假设也获得密钥 U 盘 ) 。这时候系统能够顺利引导，并且成功释放 BitLocker 密钥链。但是攻击者还必须想办法知道帐户的密码， 否则无法登录系统， Windows 分区依然处于加密状态 。

EFS 额外保护的原理如图 4 所示。

图 4

4 ．题外话：为什么释放 BitLocker 密钥以后， Windows 分区依然处于加密状态？

所以尽管 BitLocker 密钥已经释放，但是 Windows 分区并没有被立即全部解密。否则每次启动，都要解密整个 Windows 分区，得花多少时间 ( 笔者的 Vista 分区完全解密，共花 3 小时 ) ！

原来 BitLocker 加密是以一个 FVE Filter Driver 来实现加密和解密，该 Filter Driver 处于文件系统驱动的下层。登录系统以后，用户需要访问文件时，文件系统会自动请求 FVE Filter Driver 进行解密，猜想应该是一次解密一个 Block ，每个 Block 可能是 512 字节 ( 和 EFS 一样 ) ，不敢确定。对于用户来说，这个过程是完全透明的，同时对性能的影响很小，几乎可以忽略不计。 EFS 加密的情况有点类似。

写在最后

这里非常敬佩国外微软技术爱好者的执着，事实上该作者还有一篇经典的文章 ( 描述 SAM 配置单元文件的二进制结构 ) ，链接如下，非常值得推荐。

很难想象，要编写这样的文章，得花费多少的人力和时间，要做多少的实验才能在 SAM 数据库逐个字节地找出其对应的含义！

本文的目的，也是为了向这些国外的作者致敬。

<http://www.beginningtoseethelight.org/ntsecurity/index.php>

posted on 2006 年 4 月 20 日 1:35 由 ahpeng <http://blogs.itecn.net/user/Profile.aspx?UserID=2131>