记录黑客技术中优秀的内容,传播黑客文化,分享黑客技术精华

发现Zoom中的多个安全漏洞

2020-08-15 09:38

在过去一年中,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的漏洞:

5.1 TLS / SSL的设计漏洞;

5.2有关Zoom Launcher的设计漏洞;

5.3 Zoom用户之间的端到端加密消息以纯文本格式存储在磁盘上;

5.4 所有本地用户均可访问的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个以上的域。

2.png

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

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

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

目标:ca01.idm.meetzoom.us

3.png

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

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

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

目标:va01.idm.meetzoom.us

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

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

无效账户如下所示:

4.png

有效账户如下所示:

5.png

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

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

攻击Kerberos

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

建立字词表

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

6.png

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

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

7.png

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

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

Zoom允许在帐户上上传个人资料图片,我一直对图像解析器很感兴趣,因为图像解析器的攻击面很宽,并且可以为不同的攻击媒介打开大门。

1.用户上传个人资料图片;

2.仅允许使用JPEG,GIF和PNG。

3.如果图像是PNG或GIF,则将其转换为JPEG。

4.如果图像为JPEG,则不会触发图像转换。

5.如果图像包含无效的图像标头,则更新配置文件API会中止该过程。

6. 检查验证的图像是通过检查魔术字节4完成的,这意味着我们无法控制文件的第一个字节。

所以我假设, Zoom将ImageMagick用作服务器端图像转换的后端。部署映像转换微服务的常见模式是,一旦微服务达到稳定状态,它们几乎不会收到所需的更新和安全控制。发生这种情况的原因是,它对业务的重要性不如基础架构中的其他功能强大。

ImageMagick的一个常见漏洞是CVE-2016–3714,这是一个远程执行代码漏洞。我使用CVE-2016–3714测试了该功能,似乎已对其进行了修补。

ImageMagick另一个较不受欢迎的漏洞是由于ImageMagick的GIF解析器上的存储空间未初始化而导致的内存泄漏漏洞。因此,可以采用“Heartbleed”方法泄漏部分内存,该漏洞就是CVE-2017-15277

原始有效载荷

8.png

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

9.png

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

$ convert -size 300x300 xc:black black.gif

正常视图如下所示:

10.png

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

1.png

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

自动化开发

要计划在Zoom上自动利用内存泄漏,需要:

· 生成新的唯一有效载荷;

· 将其上传到Zoom;

· 下载攻击的文件;

· 从Zoom攻击的损坏文件中提取数据;

· 重复并存储泄漏的内存部分。

概念验证

12.png

视频链接点这里

继续发现漏洞

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

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

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

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

有效载荷的概念证明

13.png

RCE漏洞的本地复制

14.png

缓解措施

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

Shadow IT和Zoom

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

15.png

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

16.png

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

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

适用于Linux的Zoom App

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

Linux上的Zoom TLS / SSL漏洞

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

17.png

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

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

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

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

代码如下

18.png

有关Zoom Launcher的设计漏洞

启动Zoom

[/usr/bin/zoom]是[/opt/zoom/ZoomLauncher]的符号链接,调用Zoom时会发生以下情况:

$Zoom

19.png

启动Zoom后会发现Zoom正在检查$PWD目录中是否有用于Zoom的文件,并执行该文件,否则它将导航到Zoom安装目录并执行另一个二进制文件Zoom可执行文件。如果$ PWD目录上有一个名为“zoom”的可执行文件,它将作为/ usr / bin / zoom的子进程执行。

概念验证

20.png

这破坏了应用程序白名单的所有保护,允许恶意软件作为可信任供应商(Zoom)的子进程运行,而且无论如何都是一个糟糕的设计或是安全实践。

我曾想过为什么要这样设计,但我根本没有找到很好的理由。

zoom本地数据库在Linux上安全实现的漏洞

我注意到Zoom本地数据库实现中的另一个有趣的问题,Zoom本地数据库允许Zoom存储自定义配置和用户数据。假设可以通过任何级别的权限访问用户计算机,则任何人都可以读取和提取Zoom用户数据和配置。

21.png

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

Zoom不完全是端到端加密

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

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

本文翻译自:https://mazinahmed.net/blog/hacking-zoom/如若转载,请注明原文地址:

知识来源: https://www.4hou.com/posts/yMx7

阅读:26126 | 评论:0 | 标签:漏洞

想收藏或者和大家分享这篇好文章→复制链接地址

“发现Zoom中的多个安全漏洞”共有0条留言

发表评论

姓名:

邮箱:

网址:

验证码:

ADS

标签云