在过去的一年里，Zoom的用户群增长迅速，从2019年初的1000万活跃用户增长到2020年年中的2亿多。Zoom的流行使其成为黑客、攻击者和安全社区的重要目标。本文的研究重点是识别Zoom中的安全漏洞。调查结果表明，几个严重的安全漏洞影响了Zoom的运营和开发基础设施、ZoomLinux应用程序以及Zoom的端到端加密实施。已识别漏洞列表(1)公开的公共Kerberos身份验证服务器；(2)ZoomProductionServer内存泄漏；(3)ZoomProductionServer上无法利用的RCE；(4)可访问的Zoom服务器IT问题上的影子；(5)ZoomAppforLinux中的漏洞：TLS/SSL中的设计漏洞；ZoomLauncher中的设计漏洞；Zoom用户之间的端到端加密消息以纯文本形式存储在磁盘上；所有本地用户均可访问Zoom本地数据库，包括私人端到端加密消息（以纯文本形式存储）和访问令牌。漏洞查找过程我于2020年4月开始了对Zoom的第一轮测试，我的目标是找到一个影响Zoom结构和用户的安全漏洞。艰苦的工作得到了回报，我发现了一个影响API的内存泄漏漏洞，该API是Zoom操作基础设施的一部分。一旦确认此漏洞，我将根据他们的安全页面zoom.us/security将其直接报告给security@zoom.us。接下来，我开始对Zoom进行进一步的安全研究，发现了影响其基础设施、ZoomLinux应用程序及其端到端加密实现的新漏洞。识别攻击面在对目标进行测试时，我的第一步是识别攻击面。以下是我在侦察阶段所做的工作，以了解正在运行的系统、公开的API、（未维护的）服务以及从对手的角度来看可能感兴趣的所有其他内容。在攻击Zoom之前，我不知道攻击面。DomainDiscovery对我来说幸运的是，我运行FullHunt.io，这是一个漏洞情报平台，可帮助攻击面发现、监控和自动化安全。有一个内部FullHuntAPI可以查询组织拥有的域。我运行了一个查询，该查询返回了13个以上的域。我将它们添加到我的FullHunt帐户以自动执行发现过程。虽然我收集了很多数据，但我没有时间测试所有的东西。公开的公共Kerberos身份验证服务器当端口扫描不同的目标时，一个目标引起了我的注意。(1)目标：ca01??.idm.meetzoom.us我注意到正在运行的Kerberos服务是可以从外部访问的，Kerberos是一种网络身份验证协议，旨在保护客户端/服务器应用程序的身份验证。目标的命名约定表明目标正在运行身份管理解决方案或PKI（公钥基础设施），当检查端口80上运行的是什么时，我发现主机正在运行FreeIPA3，这是由开发的开源身份管理解决方案红帽。另一种选择是查看Zoom对Kerberos和FreeIPA设置的实施，我还发现了另一个适用于确切设置的目标。(2)目标：va01.idm.meetzoom.us实际上，一旦我们拥有了经过身份验证的帐户，Kerberos就可以允许大规模攻击。虽然不在内部网络中，但初始Kerberos条目更加困难。HTTP接口在错误消息方面非常冗长，但是，这是FreeIPA中的默认响应。可以从[/ipa/session/login_password]API枚举用户，如下面的屏幕截图所示。无效帐户如下所示：有效帐户如下所示：但是，HTTPAPI中有一个锁定策略，可以锁定超过无效身份验证尝试次数的帐户。一旦政策被触发，我在锁定期结束后重新访问了目标。最好从HTTP接口攻击此功能，我将攻击直接转移到Kerberos服务中。攻击Kerberos我正在尝试使用运行在UDP/88上的公共Kerberos服务来枚举用户，在UDP中进行身份验证的优势之一是能够处理具有不同源IP的数据包。这有助于避免服务级别的IP黑名单，我不需要进入这部分，因为在此服务的测试中没有触发安全控制，用户枚举和用户密码暴力破解都没有被阻止。构建单词列表根据我对Zoom的背景知识，我了解到Zoom上的电子邮件和帐户配置文件架构如下：{firstName}。{lastName}@zoom.us。我们可以从Zoom.us/team页面的初始命名开始：我还使用OSINT来枚举电子邮件地址，这将用于枚举可公开访问的Kerberos服务上的有效用户帐户。生成的名称都不是Kerberos服务上的有效用户，也许这两个目标是ShadowIT目标并且它们被Zoom错误地暴露了，用户枚举给了我一个有效的用户“admin”。我还强制执行帐户密码，因为没有针对用户帐户的锁定策略，这似乎是时间跨度（意思是时间间隔）的死胡同。ZoomOperations服务器上发现内存泄漏Zoom允许在帐户上上传个人资料图片。我一直对图像解析器很感兴趣，因为它们具有广泛的攻击面并且可以为不同的攻击向量打开大门。用户上传头像；仅允许使用JPEG、GIF和PNG。如果图像是PNG或GIF，请将其转换为JPEG。如果图像是JPEG，则不会触发图像转换。如果图像包含无效的图像标头，更新配置文件API将中止该过程。检查已验证图像是通过检查魔术字节4完成的，这意味着我们无法控制文件的第一个字节。所以我假设，Zoom使用ImageMagick作为服务器端图像转换的后端。为微服务部署图像转换的一个常见模式是，一旦微服务达到稳定状态，它们就很少收到所需的更新和安全控制。发生这种情况是因为它对业务的重要性不如基础架构中的其他功能。ImageMagick中的一个常见漏洞是CVE-2016–3714，这是一个远程代码执行漏洞。我使用CVE-2016–3714测试了该功能，它似乎已被修补。ImageMagick中另一个不太常见的错误是由ImageMagick的GIF解析器上未初始化的存储空间引起的内存泄漏错误。因此，可以使用“Heartbleed”方法泄漏一些内存，即CVE-2017-15277。原始有效负载ZoomAPI攻击的结果如下所示；进一步确认，这不是ImageMagick在Zoom上实现的攻击漏洞，它是通过ImageMagick生成一个典型的黑色图片实现的，具有相同的payload规格：$convert-size300x300xc:blackblack.gif普通视图如下图：如下图，一张普通的GIF图像通过Zoom被攻击。事实证明，当提供具有相同有效载荷规格的普通GIF图像时，只要确认存在安全漏洞并且ImageMagick设置上的攻击问题部分位于Zoom中，就可以攻击该图像。自动化开发计划自动利用Zoom上的内存泄漏需要：生成一个新的唯一有效载荷；将其上传到Zoom；下载被攻击文件；从Zoom攻击的损坏文件中提取数据；复制并存储泄漏的内存部分。概念验证视频的链接在此处。继续查找漏洞经过一周的针对内存泄漏的自动化攻击，我记得TavisOrmandy正在研究GhostScriptEngine6。GhostScript是PostScript语言的解释器，也用在ImageMagick中。Tavis的研究表明，可以在GhostScript上执行远程命令。这项研究对该功能至关重要，因为如果我们可以在ImageMagick上利用GhostScript，我们就可以实现远程命令执行。我确认此漏洞存在并已于2017年7月修复。2018年8月，GhostScript和ImageMagick也针对远程命令执行漏洞进行了修补。这意味着如果在Zoom运行中出现内存泄漏，GhostScriptRCE也会出现在Zoom运行中。基于Zoom环境，我在自己的环境中复现了这个漏洞。针对RCE漏洞的有效负载本地复制缓解概念证明ZoomAPI[/p/upload]对上传的图像进行魔术字节检查，否则该漏洞可能会被充分利用。如果微服务在别处被调用，它仍然可以在那里被利用。ShadowIT和ZoomShadowIT是Zoom的公共服务模型，部分实例更新不频繁，可以公开访问。云为用户的每一个需求提供了解决方案。员工可以使用云端的应用程序高效、快速地完成工作。影子IT是未经批准或IT管理员在不知不觉中使用的应用程序。我发现了一个至少10个月没有更新的开发实例，虽然我不确定，但我认为它被Zoom的用户广泛使用。这意味着如果一个漏洞被即时修补，它可能会在这些影子IT实例上被利用，我确认这是因为Zoom在实例上留下了一个版本构建文件。下图拍摄于2020年7月4日，建造于2019年9月10日。ShadowIT目标上的Nginx状态，Nginx状态页面由于开发实例中的后端配置错误而启用，这让我可以安全地猜测该实例没有被大量使用并且与Zoom.us运行的Web应用程序无关比较，日志触发器的数量可能会更小。它显示实例上有9个活动连接，这非常适合在不触发安全警报的情况下进行测试。ZoomAppforLinux我还在ZoomAppforLinux上进行了测试。在安全研究方面，安全社区并没有将重点放在Linux的Zoom客户端上。因此，我进行了以下研究。Linux上的ZoomTLS/SSL漏洞每当使用自定义TLS/SSL证书拦截流量时，Zoom都会提示用户以下消息：Zoom中不受信任的服务器证书用户单击“仍然信任”后，证书将添加到本地缩放数据库以及证书的指纹。当下一个请求到来时，白名单证书如期被允许。问题是所有TLS/SSL证书都可以被恶意软件直接“接受”到本地Zoom数据库，而无需额外的权限。Zoom证书数据库的自定义实现不仅仅依赖于系统CA证书数据库。在正常情况下，系统CA证书数据库需要root权限才能将新的SSL/TLS证书列入白名单。我在Golang中编写了一个概念证明，用于将TLS/SSL证书指纹注入本地Zoom数据库。在用户计算机上执行此代码后，所有注入的证书都将在Zoom上无误地接受。代码如下ZoomLauncher的设计漏洞LaunchingZoom[/usr/bin/zoom]是[/opt/zoom/ZoomLauncher]的符号链接，当调用Zoom时，会发生以下情况：$Zoom启动Zoom后，你会发现Zoom正在检查$PWD目录中是否有用于Zoom的文件并执行该文件，否则它会导航到Zoom安装目录并执行另一个二进制文件，即Zoom可执行文件。如果$PWD目录下有名为“zoom”的可执行文件，它将作为/usr/bin/zoom的子进程执行。概念证明这打破了应用程序白名单的所有保护，允许恶意软件作为受信任供应商(Zoom)的子进程运行，并且无论如何都是糟糕的设计或安全实践。我一直想知道为什么要这样设计，但我根本找不到一个好的理由。Zoom在Linux上的本地数据库安全实现中的漏洞我注意到Zoom本地数据库实现中的另一个有趣的问题，它允许Zoom存储自定义配置和用户数据。假设以任何级别的权限访问用户计算机，任何人都可以读取和提取Zoom用户数据和配置。从Zoomus.db本地数据库可以看出，客户数据和关键PII细节都被混淆了，但一些重要数据仍然暴露在外。Zoom不完全是端到端加密Zoom宣布它现在支持端到端加密，并于2020年5月推出其他安全更新以保护用户。我还专门测试了ZoomChat，这是一种允许群聊的Zoom功能。它允许团队协作、共享文件，当然还可以发送消息。我注意到Zoom聊天记录以纯文本形式存储在磁盘上。将此与Linux文件权限的不良做法相结合意味着任何进程都可以无限制地访问所有Zoom聊天。点击此处查看视频。
