发现Zoom中的多个安全漏洞

在过去一年中，Zoom的用户量迅速增长，从2019年初的1000万活跃用户增长到2020年中期的2亿多。

Zoom的流行使其成为黑客，攻击者和安全社区的重要目标。本文的研究重点是识别Zoom中的安全漏洞。研究结果表明，一些严重的安全漏洞会影响Zoom的运行和开发基础架构，Zoom Linux应用程序以及Zoom的端到端加密实现。

识别出的漏洞列表

(1) 暴露的公共Kerberos身份验证服务器;

(2) Zoom Production Server上的内存泄漏;

(3) Zoom Production Server上无法利用的RCE;

(4) 可访问的Zoom服务器上的Shadow IT问题;

(5) 针对Linux的Zoom App的漏洞：

• TLS / SSL的设计漏洞;
• 有关Zoom Launcher的设计漏洞;
• Zoom用户之间的端到端加密消息以纯文本格式存储在磁盘上;
• 所有本地用户均可访问的Zoom Local Database，包括私有的端到端加密消息(以纯文本存储)和访问令牌。

漏洞的寻找过程

我于2020年4月在Zoom上开始了第一轮测试，我的目标是找到一个影响Zoom结构和用户的安全漏洞。功夫不负有心人，我确定了一个内存泄漏漏洞，该漏洞会影响属于Zoom运行基础结构的API。

确认存在此漏洞后，我会根据其安全页面zoom.us/security将其直接报告给security@zoom.us。

接下来，我开始对Zoom进行进一步的安全性研究，并发现了影响其基础架构，Zoom Linux应用及其端到端加密实施的新漏洞。

识别攻击面

在目标上进行测试时，我的第一步是攻击面识别。这是我进行侦察阶段的步骤，以了解正在运行的系统，公开的API，(未维护的)服务以及从对手的角度来看可能有趣的所有内容。

在攻击Zoom之前，我并不了解攻击面。

域发现

对我来说幸运的是，我运行了FullHunt.io，这是一个漏洞情报平台，可帮助攻击面发现，监控和自动执行安全性。有一个内部FullHunt API，可以查询组织拥有的域。我运行了一个查询，该查询返回了13个以上的域。

我将它们添加到我的FullHunt帐户中，以自动化发现过程。虽然我收集了大量的数据，但我没有时间去测试所有的东西。

暴露的公共Kerberos身份验证服务器

在对不同目标进行端口扫描时，一种目标引起了我的注意。

(1) 目标：ca01.idm.meetzoom.us

我注意到正在运行的Kerberos服务可以从外部访问，Kerberos是一种网络身份验证协议，旨在保护客户端/服务器应用程序的身份验证。

目标的命名约定表示该目标正在运行身份管理解决方案或PKI(公钥基础结构)，在检查端口80上正在运行的内容时，我发现主机正在运行FreeIPA3，这是RedHat开发的开源身份管理解决方案。

另一个选择是查看Zoom的Kerberos和FreeIPA设置的实现，我还发现另一项目标可以运行确切的设置。

(2) 目标：va01.idm.meetzoom.us

实际上，一旦我们拥有了经过身份验证的帐户，Kerberos就可以允许大规模的攻击。虽然不在内部网络内，但Kerberos的初始输入更为困难。

HTTP接口在错误消息方面非常冗长，但是，这是FreeIPA中的默认响应。可以从[/ipa/session/login_password] API枚举用户，如下面的截图所示。

无效账户如下所示：

有效账户如下所示：

但是，HTTP API中有一个锁定策略，用于锁定超过无效身份验证尝试次数的帐户。

触发该政策后，一旦锁定期超时，我便重新访问了该目标。最好是从HTTP接口攻击此功能，我直接将攻击转移到Kerberos服务中。

攻击Kerberos

我尝试枚举使用UDP/88上运行的公共Kerberos服务的用户，在UDP中进行身份验证的优点之一是能够处理具有不同源IP的数据包。这有助于在服务级别上避免IP黑名单，我不需要进入这一部分，因为在此服务的测试中没有触发任何安全控制，用户枚举和用户密码强行都没有被阻止。

建立字词表

根据我对Zoom的背景知识，我了解到Zoom上的电子邮件和帐户配置文件模式如下：{firstName}。{lastName}@zoom.us。我们可以从Zoom.us/team页面开始初始化命名：

我还使用OSINT列举了电子邮件地址，这将用于枚举可公开访问的Kerberos服务上的有效用户帐户。

所有生成的名称都不是Kerberos服务上的有效用户，也许这两个目标是Shadow IT目标，它们被Zoom错误地公开，用户枚举为我提供了一个有效用户“admin”。

我还强制使用了帐户密码，因为没有针对用户帐户的锁定策略，这似乎是timespan(表示一个时间间隔)的死胡同。

在Zoom运营服务器上发现内存泄漏

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。

原始有效载荷

Zoom API被攻击的结果如下所示;

通过进一步确认，这不是Zoom上ImageMagick实现的攻击漏洞，这是通过ImageMagick生成具有相同有效载荷规格的典型黑色图像实现的：

$convert-size300x300xc:blackblack.gif

正常视图如下所示：

如下所示，通过Zoom攻击正常GIF图像。

结果表明，当提供具有相同有效载荷规格的正常GIF图像后，只要确认存在安全漏洞并发现ImageMagick设置上存在攻击问题的部分位于Zoom时，此图像就会被攻击 。

自动化开发

要计划在Zoom上自动利用内存泄漏，需要：

• 生成新的唯一有效载荷;
• 将其上传到Zoom;
• 下载攻击的文件;
• 从Zoom攻击的损坏文件中提取数据;
• 重复并存储泄漏的内存部分。

概念验证

视频链接点这里。

继续发现漏洞

在自动执行针对内存泄漏的利用的一周之后，我记得Tavis Ormandy研究了GhostScript引擎6。 GhostScript是PostScript语言的解释器，还在ImageMagick中被使用。

Tavis的研究表明，可以在GhostScript上执行远程命令。这项研究对于这项功能至关重要，因为如果我们能够利用ImageMagick上的GhostScript，我们就可以实现远程命令执行。

我确认此漏洞存在于2017年7月被修复了。在2018年8月，GhostScript和ImageMagick也修补了远程命令执行漏洞。这意味着，如果Zoom运行中存在内存泄漏，那么GhostScript RCE也将出现在Zoom运行中。

基于Zoom的环境，我在自己的环境中复制了这个漏洞。

有效载荷的概念证明

RCE漏洞的本地复制

缓解措施

在Zoom API [/p/upload]中对上传图片的神奇字节进行检查，否则，该漏洞可能会被充分利用。如果在其他地方调用了微服务，那么它仍然可以在那里被利用。

Shadow IT和Zoom

Shadow IT是Zoom的一种公共服务模式，某些实例不经常更新，可以公开访问。云为用户的每一种需求都提供了解决方案。员工可以利用云上的应用程序高效快速的完成自己的工作。Shadow IT就是这些被使用的应用程序没有被批准或者IT管理员没有意识到其正在使用。我发现一个开发实例至少有10个月没有更新，尽管我不确定，但我认为它已被Zoom的用户广泛使用了。这意味着，如果在运行中修补了一个漏洞，则在这些Shadow IT实例上可能会利用该漏洞，我确认这一点的方式是因为Zoom在实例上留下了一个版本构建文件。

下图是在2020年7月4日拍摄的，构建时间是在2019年9月10日。

ShadowIT目标上的Nginx状态，由于开发实例中的后端配置错误，因此启用了Nginx状态页面，这使我可以有把握地猜测该实例的使用率不高，并且与Zoom.us运行型Web应用程序相比，日志触发器的数量可能更少。

它显示了该实例上的9个活动连接，非常适合测试，而不会触发安全警报。

适用于Linux的Zoom App

我还在Linux版Zoom App上进行了测试。在安全性研究方面，安全社区并未将重点放在Linux的Zoom客户端上。所以，我进行了下面的研究。

Linux上的Zoom TLS / SSL漏洞

每当使用自定义TLS / SSL证书拦截流量时，Zoom都会用以下消息提示用户：

Zoom中的不受信任的服务器证书

用户单击“仍然信任”后，该证书将随证书的指纹一起添加到本地Zoom数据库中。当出现下一个请求时，白名单证书如预期的那样被允许。

问题在于，所有TLS / SSL证书都可以被恶意软件直接“接受”到本地Zoom数据库，而无需其他权限。 Zoom证书数据库的自定义实现不仅仅依赖于系统CA证书数据库。在正常情况下，系统CA证书数据库需要root访问权限才能将新的SSL / TLS证书列入白名单。

我用Golang写了一个概念证明，将TLS / SSL证书指纹注入到本地Zoom数据库中。在用户计算机上执行此代码后，将接受所有注入的证书，而不会在Zoom上出错。

代码如下

有关Zoom Launcher的设计漏洞

启动Zoom

[/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存储自定义配置和用户数据。假设可以通过任何级别的权限访问用户计算机，则任何人都可以读取和提取Zoom用户数据和配置。

从Zoomus.db本地数据库可以看出客户数据和主要的PII详细信息被混淆处理了，但是仍然有一些重要的数据被公开。

Zoom不完全是端到端加密

Zoom宣布它现在支持端到端加密，并在20207年5月推出了其他安全更新以保护用户。为此我还专门测试了Zoom Chat，它是Zoom的一项功能，该功能允许群组聊天。 它允许团队进行协作，共享文件，当然还可以发送消息。

我注意到，Zoom的聊天记录以纯文本格式存储在磁盘上。 将此与Linux文件权限的不良做法结合在一起，就意味着任何进程都可以无限制地访问所有Zoom聊天记录。视频请点此。