每个应用都以独特但可预测的方式失败：Zoom案例研究

Zoom是软件故障多样性的有趣案例研究。Zoom团队不得不快速吸取许多教训，包括重用组件的陷阱、如何改进其SDLC和DevOps流程的安全工程，以及需要CISO领导团队。

在本文中，我将带您了解最近公开的一些问题。我将它们分类，以理解所犯的错误以及后续必要的决策。安全专业人士们纷纷对Zoom指手画脚，轮流告诉Zoom他们本可以做得更好。其中一些被发现的问题确实令人担忧，而其他一些则是安全性和可用性之间的自然权衡。在某些情况下，Zoom实际上遵循了最佳实践（如重用组件），但仍然受到了影响。

幸运的是，Zoom对这些问题的回应良好，通过良好的沟通和快速补丁。我不羡慕Zoom开发团队现在的情况，自二月底以来，他们已经发布了数十个新补丁来解决这些问题和其他问题！

本文的目的不是加入支持或反对Zoom的行列，而是利用这一情况作为镜头，理解我们如何都能改善我们的安全态势。对于每个问题，我将总结问题及其影响，然后给出Zoom如何通过更好的安全实践来缓解问题的建议。我还想补充，虽然所有这些在事后看来似乎很清楚，但我已经看到在现实世界中，这些类型的安全/功能/财务权衡有多么困难。

我将问题从最严重到最不严重排序。最严重的问题包括对最终用户的真实风险。列表底部的问题代表Zoom对风险或用户行为的误解，潜在风险较小。

不稳定的加密实践

公民实验室发现，Zoom没有重用标准加密组件，而是构建了自己的库。虽然团队确实遵循了标准（例如使用AES），但编写自定义加密库从来不是个好主意。加密可能会以非常微妙的方式失败，可能允许攻击者恢复部分或全部加密消息或元数据。此外，Zoom似乎打算使用AES-256，但实际上使用的是128位密钥。不幸的是，这种较短的密钥长度大大削弱了加密。最后，Zoom使用的是ECB模式，这可能导致数据泄漏，因为两个相同的明文块将产生相同的密文块。如果数据流有重复数据，攻击者可能能够揭示输入信息。

这确实很糟糕。在任何情况下，任何人都不应该自己编写加密。我最喜欢的指南之一是使用“无聊的加密”。无聊的加密意味着你应该使用明显安全的算法和密码套件。你在加密中使用的巧妙技巧越少，出错的地方就越少。

有很棒的加密库和许多使良好加密变得容易的库。Bouncy Castle是一个卓越的库的例子，它经过认证，并在过去20年中不断开发和改进！出于哲学原因，我一直是NaCl的粉丝（它们旨在使加密变得无聊且不易出错），但我不能完全认可它，因为它未经认证，并使用了一些我不熟悉的不常见算法，无法推荐。注意：这个问题需要时间修复，截至本文撰写时，尚未发布补丁。

糟糕的安全卫生

本周早些，Peiter Zatko（又名Mudge）写了一条Twitter线程（部分启发了本文），关于他和他同事在Linux Zoom客户端中发现的一些问题。这些问题突显了对如何保护Linux二进制文件以及如何使用开发工具启用安全默认设置的基本误解。即Mudge强调二进制文件没有使用基本的二进制利用缓解技术，如启用DEP、ASLR、堆栈金丝雀等。

这些功能使攻击者更难利用二进制漏洞，但更重要的是，它们是良好开发实践的基本要求。它们应该在每次构建时默认启用。Mudge的线程包括一些很好的指导，我不需要在这里重复，但在构建时启用这些缓解措施、启用单元测试以及创建安全和可靠的工具链是必须的。

安装程序问题

Objective-See报告了Zoom中的许多问题，但在我看来最重要的一个是在MacOS上从签名的二进制文件调用未签名的脚本。当MacOS运行任何二进制文件时，它会检查以确保二进制文件来自可信来源，这降低了在计算机上运行恶意软件的可能性。如果签名的二进制文件调用未签名的脚本，攻击者可以用恶意脚本替换该脚本，以在您的计算机上执行代码。这仅在安装时发生，这减少了利用窗口，但随着Zoom业务的快速增长，现在有很多安装正在进行！

Zoom在4.6.9版本中迅速解决了这个问题。他们没有发布代码更改，所以我无法确定他们如何修复这个问题，但任何可信代码只调用其他可信代码很重要。验证每个二进制文件和脚本的签名很重要。

泄漏电子邮件地址

Vice报道，Zoom糟糕地部署了一个公司目录功能，因此它将一些不太常见的公共电子邮件域名分组在一起，从而将电子邮件地址共享给一群不打算共享的人。

Zoom迅速解决了这个问题，但本可以通过进行适当的威胁建模在发布前缓解这个问题。在威胁建模时，将许多不同的观点带到桌面上很重要。Zoom安全团队中的某个人很可能预测到了这个问题。

凭据填充攻击

凭据填充通过使用其他系统上已披露的凭据来工作。如果您有一个从其他数据泄露中收集的凭据列表，很可能某人在其他地方有一个帐户，并且他们在该帐户上重用了密码。这是使用密码管理器（如LastPass、Dashlane或OnePassword）如此重要的最大原因之一。

我不认为这真的是Zoom的错，这是一个密码重用问题，至少部分责任在于最终用户。然而，Zoom可以利用像HIBP的API这样的服务来检查某人是否使用了泄露的密码。密码填充是一种可以影响任何服务的攻击，而不仅仅是Zoom。

自动UNC路径链接

Zoom重用了常见的Windows富文本组件，该组件自动检测链接。它检测的一种链接类型是UNC链接（以\开头的链接）。如果用户单击该链接，Windows将自动向链接的服务器发送哈希凭据。如果用户密码较弱，可能破解这些哈希。

安全行业建议重用经过充分测试的组件，而不是重新发明轮子。他们在这里这样做了，但受到了一些意外后果的影响。然而，大多数这些问题都在他们使用的组件或Windows本身中。Zoom通过禁用UNC很好地回应了这个问题。

战争拨号与“Zoom轰炸”

可以猜测Zoom会议ID并跳入别人的会议会话。这是可用性和安全性之间的经典权衡。如果我们想支持仅电话参与者，ID必须仅为数字。10位数字可能看起来足够长，但他们可能要考虑更长的代码。能够猜测有效ID的可能性随着系统上用户数量的增加而增加。我喜欢为此引入等候室，但显然密码是正确的方式。

总结

安全是一个多方面的野兽。有安全漏洞需要缓解和修复，有对安全和隐私的看法需要考虑，有滥用案例需要思考，威胁建模、测试、代码审查和扫描需要执行。

当然，有很多需要考虑，但当您发现自己成为公众焦点，在一个月内赶上十年的安全教训时，您被迫快速成长。Zoom现在正在尝试这样做，并且他们做得很好，但我们当然在此过程中揭露了他们许多隐藏的问题。任何一个这些问题单独来看都可以被最小化。

正如我在我们上一份时事通讯中写到的，这确实显示了一个主题，即Zoom像许多快速增长的公司一样，之前没有充分考虑安全。也就是说，我赞赏他们为几乎实时快速加强安全态势所做的努力。