Summary
Zabbix
是企业IT网络和应用程序监视解决方案。
在对其
源代码
进行例行检查时
，我们在Zabbix UI的身份验证组件中发现了CSRF（跨站点请求伪造）漏洞。
使用此漏洞，如果未经身份验证的攻击者可以说服Zabbix管理员遵循恶意链接，则该攻击者可以接管Zabbix管理员的帐户。
即使使用默认的
SameSite=Lax
cookie保护，
此漏洞也可在所有浏览器中利用
。
该漏洞已在Zabbix版本4.0.28rc1、5.0.8rc1、5.2.4rc1和5.4.0alpha1中修复。
影响
此漏洞的影响很大。
尽管需要用户交互才能利用此漏洞，但成功利用漏洞的后果是完全接管了Zabbix管理员帐户。
对Zabbix的管理访问为攻击者提供了有关网络上其他设备的大量信息，以及在Zabbix服务器上执行任意命令的能力。
在某些配置中，攻击者还可以在Zabbix监视的主机上执行任意命令。
CVSS vector: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
在撰写本文时，Internet上有约2万个Zabbix实例，可以通过Shodan的
"html: Zabbix".
找到。
修复
至少升级到
Zabbix版本4.0.28rc1、5.0.8rc1、5.2.4rc1或5.4.0alpha1
。
背景
CSRF漏洞的工作原理如下：
-
首先，用户（受害者）登录到易受攻击的网站（目标）。
在这种情况下，“已登录”仅表示用户的浏览器已在其中存储了目标网站的有效会话cookie或基本身份验证凭据。
浏览器应用程序不一定需要打开。
-
接下来，攻击者使用社会工程学说服受害者用户跟踪指向恶意攻击者控制的网站的链接。
有多种方法可以实现此目的，例如网络钓鱼电子邮件或聊天中的链接等。
-
当受害者访问恶意网站时，来自恶意网站的
HTML/JavaScript
代码将被加载到受害者的浏览器中。
然后，此代码将API请求发送到目标网站。
源自恶意网站的请求对于受害人的浏览器来说是合法的，因此，受害人的浏览器将用户的会话cookie与请求一起发送。
-
恶意请求到达目标Web应用程序。
目标Web应用程序无法判断该请求来自恶意源。
目标Web应用程序代表攻击者执行请求的操作。
CSRF攻击通常尝试滥用与身份验证相关的操作，例如创建或修改用户或更改密码。
CSRF攻击防范
抵御CSRF攻击最常用的防御方法是使用
anti-CSRF tokens
。
这些令牌是随机生成的数据，作为请求的一部分从应用程序的前端代码发送到后端。
后端同时验证反CSRF令牌和用户的会话Cookie。
令牌可以作为HTTP标头或在请求正文中传输，但不能作为Cookie传输。
如果正确实施，此方法将击败CSRF攻击，因为攻击者很难制作包含正确的反CSRF令牌的伪造请求。
Zabbix使用
sid
在请求正文中传递
的
参数
形式的反CSRF令牌
。
例如，将Zabbix Admin用户密码更新为该值的请求
zabbix1
如下所示：
如果
sid
参数丢失或不正确，
此请求将失败
。
Same-Site
cookie属性
是另一种可以抵御CSRF攻击的措施
。
浏览器使用此设置来确定何时可以将Cookie作为跨站点请求的一部分传输到站点。
这个属性有三个值：
Strict
，
Lax
，和
None
。
-
Same-Site=Strict
：切勿在跨站点请求中发送cookie。
-
Same-Site=Lax
：仅将cookie作
为跨站点请求的一部分发送，如果它们是GET请求并影响顶层导航，即导致更改浏览器的地址栏。
单击链接被认为是顶级导航，而加载图像或脚本则不是。
GET请求通常被认为是安全的，因为它们不应该改变任何后端状态。
-
Same-Site-None
：随同发送Cookie，以应对所有跨站点请求
。
Web应用程序开发人员可以选择
Same-Site
显式
设置
属性
的值，
作为在用户进行身份验证之后将cookie发送到前端的一部分。
如果未明确设置该属性，则现代浏览器会将其默认值设置为
Lax
。
Zabbix就是这种情况-该
Same-Site
属性未设置，并且默认为
Lax
。
Zabbix CVE-2021-27927
如上所述，Zabbix使用
anti-CSRF tokens
，并且这些令牌对试图利用诸如添加和修改用户及角色之类的行为的CSRF攻击有效。
但是，我们发现有一个重要的场景，其中的
anti-CSRF tokens
未得到验证：对应用程序身份验证设置的更新。
此表单控制用于登录Zabbix的身份验证类型，该身份验证可以是“
Internal
”或“ LDAP”之一。
如果使用LDAP，还可以设置LDAP提供程序的详细信息，例如LDAP主机和端口，基本DN等。
处理此表单提交
的后端控制器类
CControllerAuthenticationUpdate
禁用了令牌验证，如下所示：
此外，同样重要的是，我们发现在Zabbix中，通过POST在请求正文中提交的任何参数都可以等效地通过GET作为URL查询参数提交。
这意味着缺少
sid
参数
的以下伪造的GET请求
可以与包含的合法POST请求一样有效
sid
。
GET /zabbix.php?form_refresh=1&action=authentication.update&db_authentication_type=0&authentication_type=1&http_auth_enabled=0&ldap_configured=1&ldap_host=10.0.229.1&ldap_port=389&ldap_base_dn=dc%3Dsmoke%2Cdc%3Dnet&ldap_search_attribute=sAMAccountName&ldap_bind_dn=cn%3DAdmin%2CCN%3DUsers%2CDC%3Dsmoke%2CDC%3Dnet&ldap_case_sensitive=1&action_passw_change=authentication.edit&ldap_test_user=Admin&ldap_test_password=Z@bb1x!&saml_auth_enabled=0&update=Update
上面的请求将身份验证方法更新为LDAP并设置各种LDAP属性。
开发
为了进行全面攻击，攻击者将执行以下操作：
首先，设置一个由攻击者控制的LDAP服务器，该服务器可通过目标Zabbix应用程序进行网络访问。
对于我们的示例，我们使用的是10.0.229.1。的Active Directory服务器。
我们还在Active Directory中为用户提供了一个名为“ Admin”的用户（与内置的Zabbix管理员用户名匹配），密码为“
Z@bb1x!
”。
然后，托管一个包含恶意HTML页面的网站。
对于我们的示例，我们有一个HTML页面，其中包含带有伪造的跨站点请求的链接。
加载页面后，链接将通过JavaScript自动单击。
