潜伏的威胁：一个简单ZIP文件如何触发Google Web Designer漏洞

Google VRP与目标选择介绍

Google漏洞奖励计划（VRP）是一个开放的漏洞赏金项目，邀请全球安全研究人员报告Google产品中的漏洞。奖励根据严重程度而异，关键发现最高可获得101,010美元，有效报告通常还会获得CVE标识符并入选Google名人堂。这鼓励研究人员探索甚至不太知名的Google应用程序以发现潜在安全问题。

其中一个目标是Google Web Designer，这是一个用于创建HTML5设计和广告的桌面应用程序。为什么选择Google Web Designer？从漏洞挖掘的角度来看，有几个原因使其具有吸引力。首先，这是一个相对小众的产品，用户较少，意味着与Google旗舰服务相比，它可能经历了较少的安全审查。尽管用户基数较小，但它功能丰富且复杂——支持自定义组件、从ZIP存档导入，并作为可安装的桌面应用程序运行。这些特性暗示了更广泛的攻击面和可能被忽视的漏洞。我怀疑这样一个复杂、很少被针对的应用程序可能隐藏着在更大、经过良好审计的产品中可能被遗漏的"低悬果实"漏洞。

虽然像Gmail和Docs这样的旗舰产品安全性很好，但像Google Web Designer这样不太知名的桌面工具往往受到较少的审查，尽管通过组件导入等功能具有广泛的攻击面。

猎人的直觉：关注ZIP导入功能

在审查Google Web Designer的过程中，一个特定的功能脱颖而出：从ZIP文件导入自定义组件的能力。这立即引起了我的注意。

我是如何发现的：漏洞利用背后的好奇心

我的起点并不花哨，只是一种直觉。我在浏览Google Web Designer时注意到了"添加自定义组件"功能。它接受用户的ZIP文件，当我看到这一点时，我的大脑立刻想到：“等等…他们真的在清理那个ZIP的内容吗？”

此时，我能感觉到一个漏洞潜伏在表面之下。我首先创建了一个包含一些无害文件的测试ZIP，只是为了观察它们被提取到哪里以及它们在GUI中的显示方式。结果发现Google Web Designer将所有内容提取到项目内的特定子文件夹中。

当我更仔细地观察提取行为时，我注意到一些有趣的事情——文件路径似乎是相对于安装位置或固定项目目录解析的。这让我想起了LFI（本地文件包含）或文件写入漏洞中常见的模式，其中由于路径处理不当而破坏了信任边界。

就在那一刻，这个想法豁然开朗。如果我制作一个文件名中包含../序列的ZIP会怎样？它会让我写入预期目录之外吗？于是我继续创建了一个新的ZIP有效载荷，文件路径指向............\Temp\evil.sh…这是一个经典的目录遍历路径。如果应用程序没有正确检查文件名，它将在预期目录之外写入该文件。

我使用相同的"添加自定义组件"流程加载了这个ZIP，然后…似乎没有什么异常。我打开了C:\。砰💣 evil.sh就在那里。那一刻我意识到这不仅仅是一个理论风险，这是Google产品中一个真实存在的、可用的Zip Slip漏洞。

为了仔细检查底层发生了什么，我使用了Process Monitor。日志清楚地显示webdesigner.exe在其自己的提取目录之外打开和写入文件。每一个动作，每一个CreateFile和WriteFile调用都证实了我刚刚看到的情况。

我使用不同的有效载荷和文件路径进行了多次测试，一致确认提取过程未能阻止路径遍历尝试。

安全专业人员非常了解"Zip Slip"漏洞，这是一类存档提取机制中的路径遍历漏洞，允许ZIP（或其他存档）中的文件写入文件系统上的任意位置。直觉是，如果Google Web Designer的导入功能没有仔细清理ZIP存档中的文件路径，它可能容易受到这个经典漏洞的影响。

https://security.snyk.io/research/zip-slip-vulnerability

我的预感是基于过去的经验和类似问题的知识。过去许多项目（跨Java、JavaScript、.NET、Go等语言）都成为包含文件名中../序列的恶意ZIP的受害者，使攻击者能够突破预期的提取目录。甚至大公司（Amazon、Apache、LinkedIn，以及是的，Google本身）过去也不得不在其软件中修补此类缺陷。

逐步：利用Zip Slip漏洞

为了验证怀疑，我设计了一个使用恶意ZIP文件的简单概念验证攻击。（或从snyk/zip-slip-vulnerability下载）

步骤如下：

制作恶意ZIP：创建一个ZIP存档（命名为zip-slip-win.zip），其中包含一个文件名具有遍历提取文件夹路径的文件。例如，ZIP可以包含一个名为../../../../../../Temp/evil.txt的条目——一个旨在最终出现在Windows上的C:\Temp\目录中的文件。存档还包括一个正常文件（例如good.txt）作为对比。这种结构确保当ZIP被简单提取时，一个evil.txt文件将被写入Windows Temp文件夹，位于应用程序的正常工作空间之外。
通过Google Web Designer导入：然后我打开Google Web Designer并导航到Components → Add custom component，选择恶意ZIP文件作为要导入的组件。在底层，应用程序继续解包ZIP内容作为导入过程的一部分。
观察结果：导入后，对文件系统的检查显示文件C:\Temp\evil.txt已被创建（内容由攻击者提供）。这在Google Web Designer界面中没有任何警告或错误。由于文件名中的../路径，应用程序盲目地将存档中的文件写入C:\Temp目录。在真实攻击场景中，这可以是攻击者选择的任何路径，而不仅仅是Temp文件夹。

Process Monitor显示异常的文件写入活动

当Google Web Designer导入此存档时，它未能剥离这些危险的路径组件，导致evil.txt在非预期位置创建。这进一步验证了ZIP条目路径没有得到适当清理。

影响：从文件写入到潜在权限提升

将任意文件写入文件系统本身就是一个严重问题，它违反了基本的安全边界。在这种情况下，攻击者可以说服用户（或内部威胁可以使用自己的访问权限）导入恶意组件ZIP。演示的直接效果是在特权位置（C:\Temp）创建了一个看似良性的evil.txt。然而，根据攻击者写入的内容和位置，影响可能更加严重：

远程代码执行：通过选择更具战略意义的文件路径和内容，攻击者可以实现代码执行。例如，将恶意脚本或可执行文件写入用户的启动文件夹将导致其在下次登录时运行，从而有效执行任意代码。或者，覆盖系统信任的配置或脚本可能会产生攻击者控制的指令执行。
权限提升：如果Google Web Designer以提升的权限运行（例如由管理员），情况将变得严峻。在这种情况下，恶意ZIP可以将文件放入系统目录（如C:\Windows\System32）或覆盖关键系统文件。这可能允许提升到SYSTEM级别或持久危害整个机器。即使没有故意提升，写入应用程序可访问的某些敏感位置（例如，修改应用程序文件或资源）可能被利用以应用程序的权限执行代码。正是出于这个原因，向Google VRP的原始报告除了任意文件写入外，还明确指出了"潜在权限提升"。
持久性和隐蔽性：任意文件写入可以促进持久性。攻击者可以植入隐蔽的后门——例如，计划任务脚本或自动加载路径中的恶意DLL——确保即使立即利用不明显，他们也能保持对系统的访问。由于该操作是通过看似合法的应用程序（Google Web Designer）并通过仅导入组件发生的，如果有效载荷精心制作，它可能不会触发防病毒防御。

总之，该漏洞允许攻击者在他们不应该的地方写入文件。这可以被利用来执行恶意软件或在受害者的机器上持久存在，所有这些都由受害者导入组件的简单行为触发。对于由Google分发的应用程序，用户可能固有地信任此类导入，使其成为一个特别阴险的漏洞。

根本原因分析：为什么路径遍历是可能的

深入根本原因，似乎Google Web Designer的组件导入功能正在使用一个不过滤危险路径条目的存档提取库。很可能，应用程序依赖一个传统的ZIP提取实用程序（调查指向Info-ZIP的unzip代码）来解包存档。

这个传统代码——虽然在许多方面都很强大——但如果配置不正确，有一个已知的目录遍历问题历史。事实上，Info-ZIP UnZip中的一个经典漏洞（CVE-2001-1268）完全允许这种情况：“攻击者通过在提取的文件名中使用..（点点）在存档提取期间覆盖任意文件。“该问题早在2001年就被披露，现代实现包括防止此类利用的保护措施。

https://nvd.nist.gov/vuln/detail/CVE-2001-1268

那么Google Web Designer ZIP导入是如何出错的呢？

可能的罪魁祸首是存档库设置的错误配置或误用。这个漏洞的核心可以追溯到Google Web Designer如何处理ZIP提取，可能使用了Info-ZIP unzip代码库。此代码包括一个名为ddotflag的全局用户选项变量，它直接控制是否应在提取期间跳过../路径组件。

默认情况下，ddotflag设置为0，意味着提取逻辑将跳过存档文件名中的任何../段。这是安全行为——当ddotflag未设置时，函数mapname()执行如下检查：

unzip60/unzip.c

unzip60/unix/unix.c

这有效地从最终提取路径中移除任何危险的父目录遍历。因此，像../../evil.txt这样的路径将被中和——..部分被跳过，文件最终出现在安全、扁平的目录中。

然而，如果设置了ddotflag（这仅在用户显式提供-:选项时发生），条件!uO.ddotflag变为false。这导致mapname()逻辑保留原始目录结构，包括任何../，允许文件被提取到目标文件夹之外。

这里重要的是，checkdir()从mapname()接收清理后的路径，不会重新验证..段。它的工作只是创建文件夹和执行存在性检查——过滤责任完全在于mapname()。

因此，如果Google Web Designer调用此ZIP提取逻辑时没有正确禁用ddotflag，或使用了缺少此过滤的修补版本，ZIP文件中的../条目可能直接导致任意文件写入。而这正是发生的事情。

这种行为已被充分记录。即使在官方的unzip源代码和注释中，也很清楚：

ddotflag – “不要跳过../路径元素（由-:启用）”

除非开发人员显式设置此标志（通常不应该），否则../路径预计会被丢弃。但如果你误用unzip库，或意外重新启用该标志，你就重新引入了一个已知的攻击面。

值得注意的是，这种错误，使用一个几十年前的库而不应用已知的安全控制，比人们可能想象的更常见。

Zip Slip漏洞作为一个整体在2018年被安全研究人员重新发现和普及，他们发现许多跨不同生态系统的项目仍然容易受到攻击。本质上，Google Web Designer由于在应用文件提取的防御性编码实践方面存在失误而成为知名漏洞的受害者。

ZIP提取中路径遍历的更广泛影响

Google Web Designer案例生动地提醒了为什么存档提取需要极其小心地处理。解压缩过程中的路径遍历问题并非特定于此应用程序，它是一个影响无数软件项目的通用问题。

问题的核心很简单：当提取用户提供的存档时，程序必须确保存档内的文件路径不会导致文件被写入预期目标目录之外。未能强制执行这一点会导致任意文件覆盖漏洞。

Zip Slip的绰号强调了这种漏洞如何轻易"滑过"防御，这不是一种新颖的利用。这是严格输入清理的失误。

开发人员有时假设存档库会处理安全性，但正如我们所看到的，如果没有明确验证，这种假设可能是错误的。关键是要么使用自动清理路径的高级API，要么在将每个文件名写入磁盘之前手动验证存档中的每个文件名。安全框架和指南近年来已更新以指出这个特定问题，鼓励使用安全提取功能或至少对文件位置进行提取后检查。

结论与要点

Google Web Designer中的这个Zip Slip漏洞具有重大影响。一旦报告，Google迅速修复了该问题，防止了在野外的潜在滥用。我因此发现获得了7,500美元的奖励，这是一笔可观的赏金，反映了Google产品中任意文件写入漏洞的严重性。

https://bughunters.google.com/reports/vrp/FJMQGy8oo

该奖励还提升了我在Google排行榜上的地位，使我当时进入VRP研究人员的前25%。更重要的是，这个案例成为了一个宝贵的组合作品，展示了技术深度和发现漏洞的系统方法。

仅一次提交，我就全球排名第411

Google VRP排行榜上的台湾顶级研究人员

很荣幸能与台湾安全社区的一些顶级头脑一起列入Google VRP排行榜。看到我的名字与我长期敬仰的研究人员并列，是一种谦卑的提醒，即使是一个报告，如果做得好，也能产生影响。

从这个案例中得出了一些关键教训：

始终实践负责任披露：我遵循了适当的渠道（Google VRP）报告问题，允许Google在攻击者可能利用之前发布修复。这种负责任的方法赢得了认可和奖励，并使用户更安全。我们鼓励所有研究人员做同样的事情，道德黑客和与供应商的合作导致更安全的生态系统。
关注"无聊"的漏洞：并非每个高影响的漏洞都是奇异的零日。有时，严重的漏洞来自代码中不太光鲜的部分的简单疏忽（如未能清理文件路径）。这些"旧"漏洞类型可能同样具有破坏性。永远不要假设大公司的软件没有基本错误，始终验证。
改进ZIP提取卫生：对于开发人员，行动呼吁很明确——以与处理原始文件上传或表单输入相同的谨慎对待文件提取。使用维护良好的库，启用其安全功能（如路径规范化），并执行自己的验证。如果你维护处理存档的遗留代码，请根据现代已知漏洞（如Zip Slip）进行审查。几行健全检查代码（或升级库）可以阻止整个类别的攻击。

最后，Google Web Designer Zip Slip漏洞提醒我们，即使可靠的软件也可能有盲点。需要一个好奇和执着的研究人员来发现一个溜过裂缝的缺陷。结果是积极的：漏洞被修补，我赢得了Google名人堂的一席之地，安全社区获得了又一个为什么我们必须保持警惕的例子。希望像这样的案例将继续鼓励研究人员和组织参与主动的安全努力——使我们的软件（和我们的用户）在未来更安全。

奖励：对于我的努力，我不仅获得了赏金，还获得了CVE分配和公开承认。这是一个当之无愧的认可，也是一个引人入胜的故事，讲述了敏锐的眼光和直觉如何导致发现"溜过Google防御的7,500美元漏洞”。为更安全的编码实践以及公司与安全研究社区之间的富有成效的合作干杯！

参考文献：Google VRP报告详情、Info-ZIP、CVE-2001–1268、Snyk和社区关于Zip Slip的文章，以及我从测试Google Web Designer中的个人发现。

所有信息共享用于教育目的，并促进所有人的更好安全。