office07密钥，XML中的数字签名漏洞

大家好，今天小编来为大家解答office07密钥这个问题，XML中的数字签名漏洞很多人还不知道，现在让我们一起来看看吧！

MicrosoftOffice是最广泛使用的办公文档应用程序之一。对于重要文件，如合同和发票，可以对其内容进行签名，以确保其真实性和完整性。自2019年以来，安全研究人员发现了针对PDF和ODF等其他办公标准中完整性保护的攻击。由于MicrosoftOffice文档依赖于不同的规范和处理规则，现有的攻击方法不适用于它。

这项研究对OfficeOpenXML(OOXML)签名进行了深入分析，该签名是所有MicrosoftOffice应用程序使用的Ecma/ISO标准。分析揭示了办公文档的结构和数字签名验证方式之间存在重大差异。这些差异导致规范和实施中存在严重的安全缺陷，并最终发现了五种新的攻击类别。相关漏洞的PoC：https://github.com/RUB-NDS/OOXML_Signature_Security

MicrosoftOffice是管理Word文档、演示文稿和电子表格的重要工具之一。仅Office365一项，在2021年全球拥有近3亿付费用户。从Office2007开始，默认情况下所有文档都以OfficeOpenXML文档格式存储(OOXML：https://www.ecma-international.org/publications-and-standards/standards/ecma-376/)。

OOXML文档签名：与PDF和ODF等竞争的办公格式类似，Microsoft提供了数字签名来保护其电子文档，例如Word、Excel和PowerPoint。数字签名是放置在数字信息（例如电子邮件、宏或电子文档）上的电子加密认证印记。签名确认信息源自签名者并且未被更改。这些强大的安全保障可用于保护重要的办公文档（例如合同和发票）免受篡改。OfficeOpenXML(OOXML)标准定义了如何使用XML签名的特定变体对Office文档进行数字签名。

近年来，一些研究讨论了与OOXML不同的办公文档格式，如PDF和ODF，以及其数字签名的安全性。这些工作发现了几种攻击方式，其中文档的内容可以被更改，但签名仍然显示为有效。然而，这些攻击方式不适用于OOXML文档，因为它们依赖于不同数据格式的特定结构。同样，Microsoft宏代码可以进行数字签名，但是使用了不同的数据结构来实现此目的。

链接XML的复杂容器：OOXML文档的渲染流程和签名验证流程都非常复杂。渲染过程涉及到OOXML包中的多个文件以及这些文件中的交叉引用。除了主document.xml文件外，还有一个关系文件，用于指定在渲染过程中应包含哪些其他文件。这些其他文件的命名暗示了它们的特定用途。例如，people.xml文件旨在仅存储在文档中发表评论的人员的姓名。研究还发现，此类文件还可以存储任何在打开文档后显示的可渲染内容。

签名验证流程使用复杂的XML签名标准，并对签名部分的[URI、ID]引用使用不同类型的引用。为增加复杂性，还通过向XML签名的哈希树添加另一层引用。

签名性质验证和渲染方面的复杂性会导致标准级别的漏洞，从而破坏Microsoft规定的安全目标。更准确地说，以下三种攻击类别需要在当前规范中进行修复：

1）内容注入攻击（CIA，ContentInjectionAttack）：利用标准的差异将渲染的内容放置在应该用于不同目的的文件中，例如保存元信息。

2）内容屏蔽攻击（CMA，ContentMaskingAttack）：在文档签名后操纵样式或字体信息，从而显示不同的内容。

3）遗留包装攻击（LWA，LegacyWrappingAttack）：将遗留文档（例如*.doc）的签名嵌入到OOXML文档中。

所有攻击都符合相关标准：一些明确指定的部分不受签名保护，因为它们预计是无害的。攻击证明这个假设是错误的。

除了规范缺陷之外，还在所有MicrosoftOffice应用程序中发现了两个应用缺陷。

1）通用签名伪造(USF，UniversalSignatureForgery)：利用验证逻辑中的严重缺陷，攻击者可以操纵文档的任何内容。通过使用从任何其他来源（如ODF、SAML）获得的有效XML签名令牌，可以构造任意的OOXML文件，并将其显示为有效签名。

2）恶意修复攻击(MRA，MaliciousRepairAttack)：滥用MicrosoftOffice中的修复功能来隐藏无害内容并展示恶意内容。这是唯一需要用户交互的攻击方式-目标用户会点击修复提示。

Office文档签名的安全性取决于渲染流程和签名验证流程之间的相互作用。只有经过有效签名的部分应该被渲染。研究人员首先对OOXML标准进行了研究，并系统化了文档的呈现流程和签名验证流程，这两个流程都非常复杂。例如，签名验证流程通过向XML签名使用的哈希树添加额外的引用级别，增加了签名验证的复杂性。另一方面，渲染流程有时可以识别部分签名的文档，有时则无法识别。以下是描述该标准系统化核心见解的图示。

OOXML标准分为四个部分，由EcmaInternational于2015-2021年发布第5版，并于2015-2021年发布为ISO/IEC标准29500。它依赖于开放打包约定（OPC，OpenPackagingConventions），其中多个文件被压缩在一个容器中。在本节中，将解释这些文件的含义并描述如何应用数字签名。

文档结构：每个OOXML文档都包含在一个压缩包中，其中包含多个文件。[Content_Types].xml保存了OOXML包含的文件、相应的内容类型以及它们的相对路径。_rels/.rels文件中包含的关系文件包括对主文档文件word/document.xml以及属性文件docProps/app.xml和docProps/core.xml的引用。属性文件包含有关作者、创建时间或Office版本等信息。打开文档后呈现的文档内容主要存储在word/document.xml中。word/_rels/document.xml.rels关系文件定义了包含所有其他文件的目录。因此，应用程序知道包含哪些文件以及在哪里可以找到它们。文件word/styles.xml和word/fontTable.xml指定了不同的首选项，如字符间距和字体。

渲染过程：word/document.xml文件包含了文档的显示内容，作为渲染过程的基础。在渲染过程中，可以包含OOXML包中的其他文件。为此，word/document.xml包含基于ID的引用，这些引用必须与位于word/_rels/document.xml.rels中的关系文件条目相对应。以这种方式包含的文件（例如word/styles.xml或word/fontTables.xml）因此被整合到渲染过程中，以相应地调整文本的外观。像word/fontTables.xml这样被引用的文件还可以在word/_rels/下包含它们自己的关系文件，例如引用嵌入的字体。

电子签名：前面的图示描述了OOXML文档数字签名的结构。每个签名都存储在一个XML文件中，包含六个主要区域：包信息（PackageInfo）、Office信息（OfficeInfo）、签名属性（SignatureProperties）、签名信息（SignedInfo）、签名值（SignatureValue）和密钥信息（KeyInfo）。

PackageInfo通过引用名称和路径列出了所有受保护的文件。签名始终保护document.xml文件。此外，对于在document.xml.rels中引用的每个文件，都会计算并存储整个内容的哈希值。一个重要的例外是document.xml.rels本身，因为它已部分签名。Office信息存储应用程序的首选项，例如所使用的Office和Windows版本。此外，还存储了分辨率的首选项。签名属性定义了有关签名生成的元数据，例如时间戳和所使用的证书。签名信息引用了包信息、Office信息和签名属性。对于每个区域，计算一个摘要值。最后，所有引用都经过数字签名。签名值存储了根据签名信息计算的数字签名。密钥信息是指用于对文档进行签名的密钥。该区域没有被签名，因此攻击者可以操纵它。

验证流程：签名文档的验证过程从签名值开始-应用程序使用从密钥信息中提取的公钥以加密方式验证该值的正确性。此步骤确保包信息、Office信息和签名属性的引用和相应的摘要值未被修改。其次，应用程序计算每个引用的摘要值并将其与存储的摘要值进行比较。验证成功意味着所有三个区域都没有被修改。然后，计算并比较PackageInfo中所有引用文件的哈希值。结果，应用程序验证文件未被修改。最后，验证密钥信息所持有的证书的可信度。例如，MicrosoftOffice依赖于Windows证书存储来进行基于PKI的信任验证。

用户界面层（UI）：为了反映文档的签名状态，MicrosoftOffice使用不同的UI层。在打开签名文档时，第一层UI直接显示为横幅。这里的签名状态表示为：1）valid（签名有效且证书可信）；2）可恢复（签名有效，但证书不可信）或3）invalid（签名无效）。

第二层UI反映了第一层UI的签名状态，并包含有关签名状态的详细信息。第三层UI包含有关签名者的信息，并区分完整签名性质和部分签名性质的有效签名文档。当MicrosoftOffice对文档进行部分签名时，签名状态仍然显示在UI层组合（1.a）中。

定义了攻击者的两个要求，满足其中之一就可以执行攻击。

1）可信签名文件：攻击者可以访问到一个可信签名的文档。这样的文件可能会在互联网上公开获得，例如签署的法律文件。

2）签名预言机（SigningOracle）：攻击者可以访问到签名预言机，类似于选择消息攻击。因此，攻击者可以选择（全部或部分地）对文档的内容进行签名。目标用户会信任该文件的签名。假设恶意负载必须是不可见的或者不被签名预言机执行的。因此，该文件看起来是合法的。在签名之后，攻击者会在后续的文档操纵中释放恶意负载。

1）数据操纵：攻击者的目标是操纵应用程序呈现的内容。由于签名可以保护文档的完整性，因此理想的攻击目标是更改文档的内容而不使签名状态无效。如果签名显示为有效且值得信赖，同时向目标用户呈现并显示恶意内容，则认为攻击成功。

2）目标用户行为：假设目标用户希望打开一份由可信机构签署的文档。当针对无效或不受信任的签名发出警告时，目标用户不信任该文档。此外，目标用户会排除使用不受信任的密钥签名的文档，因为这类文档在打开后会发出警告。

OOXML标准的安全问题：在第一阶段，对OOXML标准中涉及签名实现的部分进行了分析。研究者发现了一个严重的问题-OOXML标准使用的部分签名无法保护整个OOXML包。更具体地说，负责引用文件的关系文件包含未受保护的部分。签名仅保护了由唯一ID索引的单个字符串，但关系文件作为一个整体保持未签名。这使得攻击者可以在签名后添加对后续添加的文件的引用。

对于OOXML包中的各个文件（例如styles.xml），该标准定义了相应XML文件的根元素。然而，并没有禁止使用为其他文件定义的元素，例如documents.xml。因此，负责呈现内容的body元素可以在除了documents.xml之外的其他文件中定义，例如styles.xml。插入的内容无论是有符号还是无符号，都没有发生任何区别，并且无法以任何方式进行区分。

结果：OOXML中数字签名的创建和验证与完全的完整性保护安全目标至少存在冲突。

MicrosoftOffice的OOXML签名：在第二阶段，对MicrosoftOffice在实践中如何构建和签署OOXML包进行了分析，以验证MicrosoftOffice支持部分签名的概念。例如，数字签名是针对word/子目录内的所有文件以及它们在关系文件中的引用进行计算的。但是，也有一些文件不属于签名的一部分。发现描述包的内容类型[Content_Types].xml的文件是不受保护的。还有其他未受保护的属性文件，例如docProps/app.xml和docProps/core.xml，其中包含文档的创建者等信息。

结果：通过第一阶段和第二阶段的分析，可以确定出三个可能的攻击点：

3）通过后续添加的文件或引用进行操纵。

未签名文件操纵：分析了MicrosoftOffice如何对[Content_Types].xml、docProps/app.xml、docProps/core.xml以及相应关系文件中的更改做出反应。为此，更改了关系文件中的内容类型和引用。攻击者逐渐向属性文件添加新内容，这些内容应该更改OOXML的样式元素或添加要在文档中呈现的新内容。一旦属性文件中的XML根元素偏离内容类型或定义的引用，MicrosoftOffice就会认为OOXML文档已损坏。属性文件中插入的样式元素或内容实际上并未显示为具有任何攻击向量的文档内容。只能修改文档的元信息，例如创建者、最后修改者和关联的时间戳，而不会使签名无效。不过，由于这些文件不包含在签名计算中，所以这个结果是意料之中的。

结果：在此分析阶段，共创建了24个具有不同攻击向量的OOXML。已经确认当前版本的OOXML标准存在已知威胁，但尚未发现新的攻击。

签名文件操纵：OOXML包中签名文件的一个特点是待签名文件及其引用字符串不直接放在签名信息中。

在签名信息中，提供了对包信息的引用。PackageInfo中存储了多个文件的摘要值，并在签名验证时进行比较。如果缺少对包信息的引用，OOXML包的呈现内容将不受签名保护。在分析中，评估了如果引用的元素丢失，MicrosoftOffice将如何反应。为此，采用了并非由MicrosoftOffice创建的XML签名。因此签名有效，但不包含引用。此外，还分析了MicrosoftOffice如何处理使用不受信任的密钥创建的签名（密钥混淆）。还评估了关键信息中存在多个元素时的行为。该攻击的想法是，一个密钥可用于验证签名（攻击者控制的密钥/证书），另一个密钥可用于验证签名者的可信度。对于这类攻击，考虑了XML中允许的不同密钥格式以及密钥信息中的不同位置。

检查了签名的OOXML文档，以防止对XML签名的进一步已知攻击：通过简单地删除签名的相关部分（签名排除），测试了XML签名的处理是否会被验证逻辑中断，并错误地显示有效签名。还分析了诸如证书伪造之类的攻击，这些攻击依赖于对证书可信度的错误验证。因此，攻击者使用不受信任的密钥创建的文档对于目标用户来说仍然显示为受信任且有效的。另一种已知的XML签名攻击是节点分裂攻击，它会混淆XML解析器。这个想法是将注释或XML实体插入到值中，以便实现可以将其分成两部分。呈现逻辑可以显示与验证逻辑处理的内容不同的值。

结果：如果无法验证OOXML包中的文件是否确实在签名信息中被引用，则可能会创建通用的有效签名，但该签名不会对包中包含的文件提供任何完整性保护。此阶段总共生成了211个具有不同测试向量的OOXML文档。对XML签名的已知攻击已在OOXML文档上进行了调整和测试。

基于部分签名的操纵：在第五个分析阶段，研究了OOXML中部分签名的支持。首先，根据已签名的OOXML文档测试了哪些操纵是可能的。由于[Content_Types].xml文件根本未签名，并且关系文件仅部分签名，因此始终可以将更多文件添加到已签名的OOXML包中。主要挑战是强制应用程序处理和渲染注入的文件。例如，包中的单独文件也必须在打开文档后呈现的document.xml中使用。主要解决了两个问题：

1）是否存在通过打开文档呈现但未在document.xml中引用的文件；

2）攻击者是否可以从签名计算中排除document.xml引用的文件。

根据这两个问题的解决方案，发现了两种不同类别的攻击，还发现了与签名OOXML文档相关的有问题的功能。在OOXML文档中，图形可以用作外部资源。此处，文档中仅存储图形的URL，并在打开时自动重新加载。图形的自动重新加载也可以在签名文档中观察到，并且可以用于通过替换存储在URL下的图像来更改签名文档中的图形。

在第五阶段的最后一个分析步骤中，研究了MicrosoftOffice自动修复功能的属性。例如，当OOXML包包含意外的文件组合时，可以使用此功能。然而，此类攻击的局限性在于，一旦修复，文档将无法在不更改文件结构的情况下保存，从而使签名无效。因此，它们只适合一次性攻击。

结果：在此分析阶段总共出现了252个攻击向量，导致发现了针对OOXML签名的六种新颖攻击。大多数攻击利用OOXML对部分签名的支持，并表明部分签名不能保留文档的完整性。

攻击向量生成：使用MicrosoftOffice签名的简单Word文档至少有两个关系文件和一个用于描述OOXML包中不同文件的内容类型的文件。这个简单的Word文档总共包含9个不同类型和ID的参考文献。此外，[Content_Types].xml包含3个默认类型定义以及每个引用的内容类型。这三个文件中的条目有不同的可能组合，需要进行测试。如果文档使用注释、页脚、页眉和脚注进行扩展，则关系文件和[Content_Types].xml中的条目将相应扩展。如果嵌入了图形或字体，甚至会添加具有相应文档引用的新关系文件。这导致了不同分析阶段中所描述的大量测试向量，这些测试向量是根据以下初始问题通过各种排列创建的：

?声明与XML模式不匹配的XML元素；

?定义多个具有相同或不同ID的条目；

签名文件攻击的测试向量的创建也需要大量的排列来检查应用程序的漏洞。例如，为了执行XSW，应考虑使用相同或不同ID的XML元素的多种排列。对于密钥混淆，以不同顺序使用不同的X509数据元素会导致创建多个文档。虽然大多数攻击媒介都是手动创建的，但使用RSA或DSA密钥进行正确签名需要使用System.Security.Cryptography命名空间的函数对用C#编写的工具进行编程。分析阶段总共产生了430多个攻击向量，从而构建了7个攻击成功的PoC。

该攻击的目标是通过向经过可信签名的OOXML（OfficeOpenXML）文档添加任意内容并同时隐藏原始内容来操纵文档。该攻击利用了OOXML规范中的缺陷，允许添加未签名的文件并引用这些文件。

1）攻击要求：攻击者需要获得由可信实体签名的OOXML文档。

2）攻击方法：该攻击利用了关系文件document.xml.rels的部分签名性质覆盖。因此，攻击者可以将XML文件添加到已签名的OOXML包中并正确引用它们。通常情况下，这些添加的文件不会影响文档的内容，因为它们没有在document.xml文件中被引用。然而，这个规则不适用于people.xml，因为该文件是在没有事先引用的情况下处理的。因此，攻击者可以通过打开签名文档来添加和呈现任意内容，例如文本、文本框或图形。攻击者可以使用文本框或图形来覆盖原始文本，并在其上方添加任意新内容（见下图）。

3）攻击步骤：

(1)攻击者需要由可信实体有效签名的OOXML文档；

(3)在该文件中，攻击者将多个白色背景的文本框放置在原始文本上，并设置它们在文档中的位置；

(4)攻击者将people.xml文件添加到OOXML包的word子文件夹中；

(5)攻击者操纵[Content_Types].xml并添加对文件people.xml的引用。Office允许进行此操纵，因为[Content_Types].xml未签名；

(6)攻击者通过引用恶意文件people.xml来操纵document.xml.rels。这种操纵也是Office允许的，因为关系文件仅进行了部分签名。在规范中部分签名的支持下，已经签名的元素无法被篡改，但可以添加新文件而不会使签名失效；

(7)people.xml引用的图形在people.xml.rels中声明并放置在word/media文件夹中。

4）攻击影响：在打开文档后，攻击者注入的内容将显示出来，但应用的可信实体签名仍然能够成功验证。然而，攻击者可以隐藏原始内容并用任意文本覆盖它。攻击者还可以通过注入新内容来增加原始页面的计数。仅仅减少原来的页数是不可能的。

内容屏蔽的概念类似于CIA：攻击者在文档签名后包含未签名的恶意文件。与CIA相比，内容屏蔽攻击有不同的要求。

1）攻击要求：攻击者需要一个签名预言机。攻击者创建一个外观看似无害的文档，并由受信任的实体进行签名。在文档签名之后，攻击者操纵签名的文档并将其分发给目标用户。

2）攻击方法：首先，攻击者创建一个恶意文档，该文档将在之后被签名。然后，攻击者删除document.xml.rels中对fontTable.xml或style.xml的引用。由于只有document.xml.rels中引用的文件受到签名保护，攻击者可以稍后操纵所有未签名的文件。

与CIA相比（其中总是可以注入people.xml），攻击者需要在签名之前准备好恶意文档。例如，document.xml中的文本区域应该引用fontTable.xml或style.xml中定义的字体或样式。否则，攻击将不会影响相应文本区域的外观。

(1)字体注入攻击（FIA，FontInjectionAttack）：对于OOXML文档，可以嵌入字体。如果使用的字体既没有嵌入也没有在查看者的系统上可用，系统会自动选择尽可能相似的系统字体进行显示。攻击者可以利用这个功能来掩盖内容或以不同的方式显示内容。例如，攻击者可以使用字体编辑工具（如FontForge，https://fontforge.org）创建自定义字体。攻击者必须选择一个与系统上已有字体不同的名称（例如，选择"Arial1"而不是"Arial"）。

在自定义字体中，攻击者可以删除某个字母的图形表示以隐藏特定的文本段落，或者交换字母以更改特定的文本段落。通过在文档中使用多个自定义字体来针对不同的文本段落，攻击者可以创建一个文档，在嵌入和引用自定义字体的情况下，以完全不同的方式显示相同的内容。攻击者在创建文档后，删除对嵌入字体的引用，并将其传递给签名预言机。由于未引用嵌入字体，并且签名预言机未安装自定义字体，因此显示的是攻击者的无害内容。在签名之后，攻击者将对自定义字体的引用重新插入到文档中。这种插入会掩盖内容或以不同的方式呈现内容。

(2)Style注入攻击（SIA，StyleInjectionAttack）。类似于FIA，攻击者使用签名预言机对自己创建的Word文档进行签名，而不引用styles.xml文件。攻击者可以将对styles.xml的引用添加回关系文件中，而不会破坏签名。通过操纵styles.xml，各个元素的外观可能会有所不同，从而隐藏或覆盖单个文本段落。

4）攻击影响：通过向body元素添加内容，以及通过styles.xml注入新内容，攻击者可以操纵文档。与CIA相比，这种攻击的影响相对较小，因为攻击者需要为每个被操纵的文档提供签名预言机。

遗留包装攻击（LWA）的目标是利用旧的二进制文件格式（例如.doc）的Word文档的签名特性，通过向目标用户显示有效签名的方式来掩盖攻击者控制的内容。目标用户在打开签名文档（.docx）时会看到受信任实体的有效签名。

1）攻击要求：该攻击需要签名预言机，这意味着攻击者需要创建一个恶意但看似无害的文档，并由可信实体进行签名。

2）攻击方法：此攻击将旧的文档格式与现代的基于XML的签名相结合。旧的文档使用复合文件二进制格式作为容器格式。当支持基于XML的签名的MicrosoftOffice版本对旧文档进行签名时，它会在旧文档中创建一个名为"_xmlsignatures"的新文件夹。该文件夹包含一个以随机数字作为文件名的文件，该签名文件与现代OOXML格式使用的"sig1.xml"文件相同。旧文档的签名包括"1Table"、"[0x01]CompObj"、"Data"和"WordDocument"。

在"CompObj"之前的字节是一个值为1的字节。Word要求OOXML文档中的所有文件都具有在"[Content_Types].xml"中指定的内容类型，否则，它会认为文档已损坏并提示修复文档。大多数不可打印的ASCII字符（包括0x01）不能直接使用。攻击者可以通过使用十六进制编辑器来自定义旧文档，以解决此限制。通过将0x01字节替换为可打印字符，例如A，攻击者可以保持文档的结构完整。

3）攻击步骤：

(1)攻击者创建一个遗留文档(.doc)，其中包含签名预言机同意的内容；

(2)攻击者将CompObj之前值为0x01的字节转换为可打印字节（本例中为A）；

(4)攻击者创建一个新的.docx文档并任意选择内容；

(5)攻击者将1Table、ACompObj、Data和WordDocument注入到.docx包的根目录中；

(6)攻击者在[Content_Types].xml中将内容类型设置为application/octet-stream；

(7)攻击者将签名的.doc文档中的_xmlsignatures复制到.docx包中；

(8)攻击者将_xmlsignatures中的签名文件（文件名由随机数组成）重命名为sig1.xml；

(9)攻击者为sig1.xml创建_xmlsignatures/origin.sigs和_xmlsignatures/_rels文件；

(10)攻击者在[Content_Types].xml中添加_xmlsignatures/origin.sigs和_xmlsignatures/sig1.xml的内容类型；

(11)攻击者在_rels/.rels中添加数字签名关系。

4）攻击影响：该攻击利用了与OOXML文档结构不同的旧文档（.doc）。当旧文档使用较新版本的MicrosoftOffice进行签名时，会创建与OOXML文档的XML签名兼容的XML签名。通过获取旧文档上的OOXML签名，可以将旧文档和签名插入到任何OOXML文档中，从而获得普遍有效的签名。当目标用户打开被操纵的文档时，该文档会向目标用户显示受信任实体的有效签名，同时允许攻击者任意选择内容。

通用签名伪造(USF)的目标是创建具有任意内容的签名OOXML文档。一旦目标用户打开文档，应用程序就会显示属于受信任实体的有效签名。

1）攻击要求：攻击者假设拥有可信实体的有效XML签名。攻击者可以从使用XML签名的其他应用程序中提取适当的XML签名，例如签名的OpenDocument格式（ODF）文档或SAML身份验证令牌。这与其他攻击有所不同。攻击者既不需要可信签名的文档，也不需要签名预言机。他们只需要来自目标用户信任的任何其他来源的XML签名。

2）攻击方法：攻击者创建一个自签名的OOXML文档，其中包含任意内容。然而，攻击者没有引用签名属性、包和Office信息，而是粘贴有效的XML签名以及从与OOXML不同的数据格式（例如SAML）中提取的签名内容。加密签名验证处理不引用包信息的签名信息。因此，攻击者可以修改所有摘要值以与修改后的内容相匹配。

3）攻击步骤：(1)攻击者创建具有任意内容的自签名OOXML文档。自签名过程仅用于让应用程序自动在PackageInfo中创建正确的引用和哈希值；

(2)攻击者从OOXML包中提取签名文件；

(3)攻击者用可信实体的有效XML签名替换签名信息、签名值和密钥信息。例如，来自已签名的ODF文档。如果新的SignedInfo元素包含对XML签名中的内部对象的引用，则也必须包含这些对象；

(4)攻击者将如此处理的签名文件添加回OOXML包中。

4）攻击影响：如果目标用户打开攻击者操纵的OOXML文档，Office应用程序将根据存储在PackageInfo中的摘要值进行验证。由于这些哈希值与攻击者创建的内容匹配，验证成功。由于签名信息来自受信任实体的有效XML签名，因此签名验证也成功。因此，应用程序向目标用户呈现文档上的有效签名。密钥信息中包含的证书的受信任实体显示为签名者。

这些攻击滥用了MicrosoftOffice的修复功能，以欺骗可信实体的签名并在攻击者控制的内容上自动创建临时文档。

1）攻击要求：攻击者需要由可信实体签名的OOXML文档。

2）攻击方法：这种攻击利用了仅在签名时存在的关系文件进行签名的事实。因此，攻击者可以在保留签名的同时添加更多关系。这允许攻击者创建一个文档，其中包含已签名但未渲染的文件。

3）重复文档攻击（DDA，DuplicateDocumentAttack）：在此攻击中，攻击者从可信实体处获取一个具有有效签名的OOXML文档。然后，攻击者准备一个新的OOXML文档，该文档应该被显示出来。攻击者重新命名新文档中的所有文件，以避免与默认名称冲突。最后，攻击者将新创建的OOXML包的文件添加到签名文档中，并在[Content_Types].xml中插入相应的引用。攻击者还添加了一个与新目标document.xml相关的新关系。这是允许的，因为关系文件只是部分签名的。攻击者从攻击者的文档中复制document.xml.rels文件并将其重命名，以使其与重新命名的document.xml的名称相匹配。

4）恶意类型攻击（ETA，EvilTypeAttack）：攻击者使用签名的Excel或PowerPoint文档将Word包的内容注入其中。利用MicrosoftOffice的自动修复功能，目标用户可以看到Word包的内容，同时签名是在原始Excel或PowerPoint文档上计算的，因此仍然有效。

为了执行此攻击，攻击者从受信任实体获取一个有效签名的Excel或PowerPoint文档。然后，攻击者创建一个内容可自由定义的Word文档。接下来，攻击者将Word相关文件复制到签名的Excel或PowerPoint文档中。攻击者将Word相关文件的内容类型复制到签名文档的[Content_Types].xml中。攻击者将Word包文件的引用插入到签名的Excel或PowerPoint文档的关系文件中。最后，攻击者将文件扩展名更改为.docx。

当目标用户打开被操纵的文档时，MicrosoftOffice会提示修复该文件。通过自动修复过程，MicrosoftOffice创建一个新的临时文档。由于文档中包含重复的文件结构，修复过程会发生。修复过程结束后，应用程序仅显示攻击者选择的内容。然而，签名验证是基于原始文档的内容进行的。因此，受信任实体的有效签名将显示给目标用户。

测试环境：测试环境分为基于Windows10和Ubuntu22.04.1的虚拟机（VM），以及基于macOSMonterey的硬件环境，共计三个系统环境。签名预言机依赖于安装了MicrosoftOffice2019的虚拟机，该虚拟机配置了私钥和公共证书。攻击者的系统部署在一个虚拟机中，该虚拟机安装了MicrosoftOffice2019版，并且无权访问签名者的私钥。目标用户的系统由不同的虚拟机组成，每个虚拟机都安装了经过验证的MicrosoftOffice或OnlyOfficeDesktop的顶级版本，并且信任签名系统的公共证书。此外，受害系统还依赖于macOS等硬件环境。MicrosoftOffice和OnlyOfficeDesktop的验证版本都得到了评估。

对于MicrosoftOffice，评估了针对仍处于产品生命周期中的所有版本的攻击，包括Windows版本的2013、2016、2019、2021、365，以及适用于macOS的MicrosoftOffice2019、2021、365。对于OnlyOfficeDesktop，评估了7.1版本在Windows、macOS和Linux上的攻击情况，下表总结了结果。

针对MicrosoftOffice的安全研究发现了针对PDF和ODF等其他办公标准中完整性保护的攻击方法并不适用于OfficeOpenXML（OOXML）签名。研究者测试了针对Windows和macOS上不同MicrosoftOffice版本的攻击，以及针对Windows、macOS和Linux上的OnlyOfficeDesktop的攻击，所有经过测试的Office版本都存在漏洞。安全研究人员正在努力改进和加强MicrosoftOffice的安全性来应对这些新的攻击方式。

翻译自：https://www.usenix.org/conference/usenixsecurity23/presentation/rohlmann

关于office07密钥的内容到此结束，希望对大家有所帮助。