• Welcome to the world's largest Chinese hacker forum

    Welcome to the world's largest Chinese hacker forum, our forum registration is open! You can now register for technical communication with us, this is a free and open to the world of the BBS, we founded the purpose for the study of network security, please don't release business of black/grey, or on the BBS posts, to seek help hacker if violations, we will permanently frozen your IP and account, thank you for your cooperation. Hacker attack and defense cracking or network Security

    business please click here: Creation Security  From CNHACKTEAM

Zabbix客户端会话存在严重漏洞


Recommended Posts

Zabbix是一个非常流行的开源监控平台,用于收集、集中和跟踪整个基础设施的CPU负载和网络流量等指标。它与Pandora FMS和Nagios等解决方案非常相似。由于其受欢迎程度、功能以及在大多数企业网络中的特权地位,Zabbix成为了攻击者的首选目标。我们在Zabbix的客户端会话实现中发现了一个非常严重的漏洞,可能会导致整个网络的破坏。

在本文中,我们将介绍不同类型的会话存储,并讨论实现安全性的可能性。最后,我们将描述在Zabbix中发现的漏洞的技术细节,它的影响以及如何防止它。

客户端会话存储

会话都是关于跨多个HTTP请求存储状态的,并且被设计成无状态的。因此,应用程序通常给每个客户端一个唯一的标识符。他们必须在将来的请求中传输它。然后,服务器可以加载相关信息,无论是存储在内存、数据库还是本地文件系统中。这就是我们通常所说的服务器端会话存储。

这种历史方法运行良好,但是与现代web应用程序的开发和部署相比,它存在一些缺陷。比如,扩展性不好。如果后端服务分散在多个服务器上,我们如何确保一个会话可以跨服务甚至整个服务器队列使用?

因此,开发人员在客户端引入了会话存储。现在他们不必给客户机分配会话标识符,但是他们必须在每个请求中发送状态的副本。像ASP和Java这样的技术栈将这个概念包装在一种叫做“视图状态”的内容中,但是现在依靠JSON Web Token (JWT)标准已经非常普遍了。

1.png

这两种方法的目标都是在客户端安全地存储数据,但在某种程度上,后端服务仍然可以确保数据的真实性和完整性,它需要使用加密技术来提供这些保证。尽管存在错误配置的风险(弱秘密,支持破坏的加密算法)和撤销JWT的固有困难,但这基本上是一种安全的方法。

在这种用例中,加密和身份验证提供的安全保证不应该混淆。虽然加密的数据对于没有受过教育的人来说可能看起来“安全”,但是后端服务无法检测到会话数据是否已经被客户端更改。使用ECB等加密模式甚至可以让攻击者在不知道密钥的情况下做出有效的任意密文!

为了演示客户端会话代码的不安全设计和实现可能带来的风险,让我们来看看我们在Zabbix中发现的两个漏洞的技术细节。

Zabbix Web 前端漏洞

监控平台Zabbix通常部署在具有四个不同组件的基础设施上:

Zabbix代理:运行在所有被监控节点上的服务,在Zabbix服务器请求时收集信息;

Zabbix服务器:连接Zabbix代理,收集监控数据,达到配置的阈值时报警;

Zabbix代理:将单个Zabbix服务器与数百个Zabbix代理相关联可能非常昂贵,并且在某些网络拓扑中很难部署。Zabbix代理实例的目的是将整个区域的数据集中起来,并将收集到的数据上报给Zabbix主服务器;

Zabbix Web前端:Zabbix服务器的接口,通过TCP与共享数据库进行通信。系统管理员使用这个仪表板来访问收集的监控数据并配置Zabbix服务器(例如,列出主机并在Zabbix代理上运行脚本)。

2021年12月,我们分析了Zabbix Web前端的外部攻击面,以更好地了解该软件暴露于不可信网络的相关风险。这项工作导致了两个关键漏洞的发现,CVE-2022-23131和CVE-2022-23134。

这些发现都与Zabbix在客户端存储会话数据的方式有关。我们将指导您完成易受攻击的实现,讨论其影响以及如何在早期利用阶段发现它。

影响

在中发现的漏洞影响了我们研究时所有支持的Zabbix Web前端版本,包括5.4.8、5.0.18和4.0.36。它们不需要事先知道目标,可以很容易地被攻击者自动化。

我们强烈建议您将运行Zabbix Web前端的实例升级到6.0.0beta2、5.4.9、5.0.19或4.0.37,以保护您的基础架构。

在启用SAML SSO身份验证的实例中,它允许绕过身份验证并获得管理员权限。攻击者可以使用此访问权限在链接的Zabbix服务器和Zabbix代理实例上执行任意命令。CVE-2021-46088使用代码已经发布。与Zabbix代理不同,不可能配置Zabbix服务器来禁止命令的执行。

strong>Zabbix 的客户端会话存储实现

服务器端会话是 PHP 的内置功能,客户端在 cookie 中被分配了一个唯一的会话标识符,PHPSESSID 是最常见的一个,并且必须在每个请求中传输它。在服务器端,PHP 采用该值并在文件系统(/var/lib/php/sessions,有时是 /tmp/)上查找关联的会话值,以填充超全局变量 $_SESSION。客户端不能随意修改会话值,因为它们只控制会话的标识符。

Zabbix Web 前端基于 PHP 的强大功能自定义会话处理程序推出了自己的客户端存储实现。通过使用实现 SessionHandlerInterface 的类调用 session_set_save_handler(),对 $_SESSION 的所有后续访问都将由此类的方法处理。

在此示例中,目标是将任何对$_SESSION的访问映射到cookie。例如,索引$_SESSION导致调用cookiesession::read();cookie helper::get()只是一个围绕$_COOKIE的包装器:

ui/include/classes/core/CCookieSession.php

2.png

Zabbix 开发人员引入了一种方法来验证存储在 cookie 中的数据并确保它们不被篡改。此功能在 CEncryptedCookieSession 中实现:

ui/include/classes/core/CEncryptedCookieSession.php

3.png

需要注意的是,术语“sign[ature]”和“encrypted”是可以互换使用的。 CEncryptHelper::sign() 内部使用 AES ECB,容易出现可延展性,无法提供数据真实性的安全保证。使用此构造还导致了另一个安全建议,但本文不会详细介绍。

CEncryptedCookieSession::checkSign()方法只在CEncryptedCookieSession::extractSessionId()中被调用,但是从来没有在cookiesession方法中被调用(例如在访问期间在cookiesession::read())。当访问sessionid以外的字段时,会话的真实性永远不会被验证。

由于cookie完全由客户端控制,它们基本上控制了会话。这是非常罕见的,并且打破了关于存储在其中的值的可信度的大多数假设。它可能导致使用会话的应用程序的某些部分出现漏洞。

CVE-2022-23131——绕过 SAML SSO 身份验证

安全断言标记语言 (SAML) 是最常见的单点登录 (SSO) 标准之一。围绕 XML 实现,它允许身份提供者(IdP,一个能够对用户进行身份验证的实体)告诉服务提供者(SP,这里是 Zabbix)你是谁。你可以将 Zabbix Web 前端配置为允许通过 SAML 进行用户身份验证,但默认情况下不启用它,因为它需要了解身份提供者的详细信息,这是企业部署最常见的设置。

与 SAML 认证机制相关的代码可以在 index_sso.php 中找到。简而言之,它的目标是:

将用户重定向到 IdP;

用户通过身份验证后,验证传入 SAML 有效负载的格式和签名。创建一个名为 saml_data 的会话条目来记住用户的属性;

如果会话中存在名为 saml_data 的条目,则提取其值并根据 username_attribute 的值在 Zabbix 上对用户进行身份验证。

如上所述,CEncryptedCookieSession::checkSign()永远不会在这个文件中被调用,因此会话条目 saml_data[username_attribute] 的值可以完全由客户端控制:

ui/index_sso.php

4.png

漏洞利用很简单,特别是因为 Zabbix Web 前端自动配置了一个名为 Admin 的高权限用户。

一旦在仪表板上被验证为管理员,攻击者可以在任何附加的 Zabbix 服务器上执行任意命令,如果在配置中明确允许 AllowKey=system.run[*](非默认),则攻击者可以在Zabbix代理上执行任意命令。

CVE-2022-23134——重新配置实例

在 setup.php 中发现了另一个不安全使用会话的情况。此脚本通常由系统管理员在首次部署 Zabbix Web 前端时运行,以后仅允许经过身份验证的高权限用户访问。

此页面通常使用会话来跟踪设置步骤的进度,同样,CEncryptedCookieSession::checkSign()永远不会在这里被调用。使用设置为6的入口步骤创建一个会话,允许重新运行安装过程的最新步骤。

这一步对攻击者来说非常有趣,因为它的目标是创建 Zabbix Web 前端配置文件 conf/zabbix.conf.php:

ui/include/classes/setup/CSetupWizard.php

5.png

在 [1] 处,创建了一个新的 CConfigFile 对象来存储和验证新的配置值。 CSetupWizard::getConfig() 方法只是当前会话的简单包装,因此这些值完全由攻击者控制。

在 [2] 处,代码试图通过尝试连接新的数据库配置来识别它是否有效。由于此代码仅应在初始设置过程中调用,当尚未配置用户帐户和数据库设置(如加密密钥)时,控制会话的攻击者将能够通过各种检查。

因此,即使 Zabbix Web Frontend 实例已经处于工作状态,攻击者也可以覆盖现有的配置文件。通过指向他们控制的数据库,攻击者可以使用高权限帐户访问仪表板。

重要的是要理解这种访问不能用于访问网络上部署的 Zabbix Agent:Zabbix Web Frontend 和 Zabbix服务器必须使用相同的数据库才能进行通信。它仍然有可能将其与web仪表盘上的代码执行漏洞联系起来,以获得对数据库和网络的控制。

在非加固的或旧的环境中也可以使用其他的开发场景。例如,PHP的MySQL客户端实现了LOAD DATA LOCAL语句,但现在默认情况下禁用了3年。另一个原因可能是在验证数据库配置时使用完全控制的参数调用file_exists(),这是一个安全风险,因为像phar://这样的方案包装器有潜在的危险。

修复情况

Zabbix 维护人员分别解决了这两个漏洞:

SSO 身份验证流程中引入了一个额外的签名字段,以防止用户更改存储在会话中的 SAML 属性 (0395828a);

会话 cookie 的身份验证方式现在使用 HMAC 构造而不是 AES ECB (eea1f70a) 完成;

如果实例已安装且当前用户没有超级管理员角色 (20943ae3),则设置过程现在会提前退出;

他们还决定不强制执行 cookie 签名检查:这种方法的主要缺点是,如果忘记了对 CEncryptedCookieSession::checkSign() 的调用,依赖于会话的新功能可能会引入类似的漏洞。

Link to comment
Share on other sites