Apache Guacamole多个漏洞分析( 三 ) _Apache

然而当我们向厂商报告这两个漏洞时，我们发现这些漏洞已经由其他研究人员报告过。即使我们只晚了几个小时，但胜利果实也必须归他人所有。
因此我们决定让其他人发表漏洞成果，在本文中不再详细介绍这些漏洞。
此时我们已经找到了5个漏洞，可以充当攻击场景中的信息泄露原语。然而我们至少还需要找到一个内存破坏漏洞，而在FreeRDP中寻找这类漏洞会比较麻烦，每次都会被代码中的检查逻辑所干扰。很多情况下，这种检查逻辑针对的都是我们报告过的漏洞，比较无奈。
现在我们的心情与Zensploitation（@zensploitation）的某篇推文非常相似：

文章插图

图8. https://twitter.com/zensploitation/status/1244598246879547393
我们毕竟走了不少路，因此绝不轻言放弃。我们决定再次研究一下guacamole-server ，这次终于有所收获。
CPR-ID-2144：内存破坏漏洞

CVE编号： CVE-2020-9498文件： protocolsrdppluginsguac-common-svcguac-common-svc.c函数： guac_rdp_common_svc_handle_open_event()

这个RDP协议会将不同的“设备”当成不同的“通道” ，每个设备一个通道。比如声音对应的是rdpsnd通道，剪贴板对应cliprdr等。作为抽象层，通道消息支持分片，最大支持的消息为4GB 。为了正确支持rdpsnd以及rdpdr（设备重定向）通道， guacamole-server的开发者添加了一个附加的抽象层，具体实现位于guac_common_svc.c文件中。该文件中对分片的处理逻辑如图9所示：

文章插图

图9. 处理传入通道分片的代码片段
从上图可知，第一个分片必须包含CHANNEL_FLAG_FIRST片段，当处理该分片时，代码会根据声明的消息总长度来分配一个流。
然而如果攻击者发送的分片不包含该标志时，会出现什么情况呢？代码似乎会将分片附加到先前的剩余流中，这看上去像是可能存在的一个“悬空指针”漏洞。现在我们只需要检查开发者在完成前一个分片消息的处理后，是否还记得将该指针置为NULL 。

文章插图

图10. 在未清除悬空指针的情况下释放已使用的流
如图10所示，在完成分片消息重组及解析后，该流会被释放。也就是说，代码没有将悬空指针设置为NULL！
恶意RDP服务器可以发送一个乱序消息片段，使用之前已被释放的wStream对象，从而变成一个UAF（释放后重用）漏洞。最重要的是， wStream对象是我们最后可能用来实现该漏洞的对象，因为如果指针字段指向所需的内存地址时，就能用来实现任意写原语。由于我们在rdpsnd通道中有个信息泄露漏洞，紧跟在恶意wStream对象被使用之后。因此经过努力后，我们可以通过精心构造的wStream对象，将原始漏洞变成更强大的任意读取利用原语。
RCE（远程代码执行）前面提到过，我们可以利用CVE-2020-9497以及CVE-2020-9498漏洞，最终实现任意读取及任意写入利用原文。利用这两个强大的原意，我们成功实现了RCE（远程代码执行）场景，当远程用户请求连接网内恶意配合的计算机（也就是我们的RDP“服务器”）时，我们就可以控制guacd进程。

文章插图

图11. 漏洞利用结果：使用被控制的guacd进程弹出计算器
但我们的旅途还未结束。guacd进程只处理单个连接，并且以较低权限运行。通常情况下，此时我们需要一个提权（PE）漏洞才能控制整个网关。在与Apache的漏洞协同分析过程中，对方也怀疑这种攻击场景是否真的可以实现：我们能否通过单个guacd进程来控制网关中所有的连接？
现在我们来寻找这个问题的答案。
“在计算领域，真正了解整个系统的人只有一个：攻击者”
——转自Halvar Flake在offensivecon 2020上的演讲。

0x05 深入分析Apache Guacamole如果深入分析前文提到的Guacamole网关，我们可以看到如下结构：