我们一般在执行应用程序漏洞评估的时候，会对漏洞的严重性进行评估，对于评级不高，不严重的那些，我们有时会先不急着修复，或是有意进行忽略。其实，这种想法非常危险，因为在某些时候，黑客可以通过多个严重性不高的漏洞，将它们联系起来，组成一个攻击。这不，近日就有黑客，通过4个NagiosXI漏洞，构造了一个远程代码执行。
这四个漏洞分别是：
CVE-2018-8734：SQL注入漏洞（还未认证）；
CVE-2018-8733：认证绕过漏洞；
CVE-2018-8735：命令注入漏洞（已认证）；
CVE-2018-8736：本地权限提升漏洞；
首先，研究人员将这四个漏洞都进行单独地隔离分析，然后再在一个应用程序中，再将这些漏洞恶意连接在一起，看看会发生什么？测试证明在NagiosXI应用程序服务器上实现一个root级别的RCE。以在NagiosXI应用程序服务器上实现根RCE。如果你想亲自测试一下的话，可以从以下地址下载含有这些漏洞的NagiosXI版本：
https://assets.nagios.com/downloads/nagiosxi/5/ovf/nagiosxi-5.4.10-64.ova
相应的漏洞利用代码，参见下列地址：
https://www.exploit-db.com/exploits/44560/
此外，Offensive Security提供的AWAE培训基本上就是一个漏洞链接方面的课程。
CVE-2018-8734：SQL注入漏洞（还未认证）
当发送未认证的<nagiosxi_host>/nagiosql/admin/helpedit.php时，程序会得到一个含有302响应代码的应答，该代码会将此操作重定向到/nagiosql/index.php。在浏览器中，对于未经认证的会话重定向回授权的Web应用程序，这可能看起来是正常行为。但研究人员通过拦截Web代理，发现此响应也包含被破坏的表单。快速浏览该表单后，他们发现如下所示的表单提交POST，它是提交给helpit.php的，其中包含一个易受攻击的selInfoKey1参数。
POST /nagiosql/admin/helpedit.php HTTP/1.1 Host: <nagiosxi_host> Content-Type: application/x-www-form-urlencoded selInfoKey1=SQLI_PAYLOAD&hidKey1=common&selInfoKey2=&hidKey2=free_variables_name&selInfoVersion=&hidVersion=&taContent=&modus=0
由于在测试时，研究人员执行的是白盒测试（是通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正）。因此他们可以检查数据库日志并准确确定注入发生的位置（有关深入研究这些类型的白盒SQLi技术，请点此详细了解）。在对数据库日志进行了一些分析之后，研究人员能够确认selInfoKey1容易受到SQLi的攻击。但是研究人员还发现，用于发出这个可注入查询的数据库用户（nagiosql）没有足够的权限执行研究人员感兴趣的许多操作，例如添加用户，转储密码哈希或枚举会话。
因此，此漏洞在单独测试的情况下只是未经认证的SQL注入！且数据库用户没有权限执行任何有趣的操作。
CVE-2018-8733：认证绕过漏洞
此漏洞的CVE描述可能是错误的，因为研究人员无法按照说明绕过此漏洞绕过身份验证。不过，研究人员发现，它与CVE-2018-8734有类似的情况，即对<nagiosxi_host> /nagiosql/admin/settings.php的GET请求返回一个带有302响应代码的表单。通过对返回的表单进行攻击，研究人员可以得到以下提交给settings.php的POST请求。
POST /nagiosql/admin/settings.php HTTP/1.1 Host: <nagiosxi_host> Content-Type: application/x-www-form-urlencoded 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。对研究人员来说重要的是能够设置数据库用户帐户。如果研究人员可以使用这种形式获得nagiosql数据库用户的更多权限，也许研究人员可以访问以前无法访问的SQLi数据库的一部分。事实证明，研究人员可以做到这一点，那就是将设备的ssh凭证默认设置为root：nagiosxi，并且这些凭证也适用于具有root权限的数据库用户。
因此，此漏洞在单独测试的情况下，研究人员只是可以更改数据库用户帐户，并且可能会破坏应用程序配置并导致DoS攻击。
CVE-2018-8735：命令注入漏洞（已认证）
这个命令注入漏洞主要是研究人员通过对应用程序的.php文件的源代码分析发现的，这对本文的研究有用，因为它影响了大量的NagiosXI版本，并以用户'nagiosxi'（而不是'apache'）运行。经过一些源代码分析和测试之后，研究人员得到以下易受攻击的POST请求，它们很容易受到通过认证的命令注入的影响。
POST /nagiosxi/backend/index.php HTTP/1.1 Host: 10.20.1.179 Content-Type: application/x-www-form-urlencoded Cookie: nagiosxi=eb8pa9098grmgummu2pnofq3f5 Content-Length: 66 cmd=submitcommand&command=1111&command_data=$(your_command_here)
这些POST请求会收到一些应答，因此，不建议在测试时，直接进行命令注入。
<?xml version="1.0" encoding="utf-8"?><result><code>0</code><message>OK</message><command_id>12</command_id></result>
但是在白盒测试中，研究人员则可以直接将文件放到/tmp目录，然后进行相应的验证：
[root@nagiosxi_host tmp]# ls -l ... -rw-r--r-- 1 nagios nagios 0 Apr 13 02:21 testing ...
因此，此漏洞在单独测试的情况下，研究人员会进行命令注入！如果该漏洞要通过认证，就需要管理员级别的授权。
CVE-2018-8736：本地特权升级漏洞
最后，我们需要寻找一些本地权限提升漏洞。一般来说，在linux环境下查找本地权限提升漏洞时，首要的就是sudoers文件，以下是Nagios / etc / sudoers文件的摘要。
... NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/html/includes/components/profile/getprofile.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/upgrade_to_latest.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/change_timezone.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/manage_services.sh * NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/reset_config_perms.sh NAGIOSXI ALL = NOPASSWD:/usr/local/nagiosxi/scripts/backup_xi.sh * ...
这正是研究人员感兴趣的，特别是如果这些文件的文件权限允许对nagiosxi用户进行写入访问，具体过程如下。
[root@nagiosxi_host ]# ls -l /usr/local/nagiosxi/scripts/ ... -rwxr-xr-x 1 nagios nagios 1664 Dec 28 2016 change_timezone.sh -rwxr-xr-x 1 nagios nagios 2303 Dec 28 2016 manage_services.sh -rwxr-xr-x 1 nagios nagios 2681 Dec 28 2016 upgrade_to_latest.sh -rwxr-xr-x 1 nagios nagios 1010 Dec 28 2016 reset_config_perms.sh -rwxr-xr-x 1 nagios nagios 5673 Dec 28 2016 backup_xi.sh ...
这就是提升一个本地权限的漏洞实例，在这个案例中， nagiosxi用户只需以root用户身份执行的所有命令放入出现在sudoers文件中的某个脚本中，然后通过无密码的sudo命令来调用该脚本。
因此，此漏洞在单独测试的情况下，该漏洞只是本地权限提升漏洞！且nagiosxi用户可以非常轻松地升级为root权限。但是，要运行这个本地权限提升漏洞，前提是攻击者就必须以nagiosxi身份执行命令。
通过4个NagiosXI漏洞，构造了一个远程代码执行
通过对以上4个NagiosXI漏洞进行单独地分析，可以发现每个漏洞在单独运行的情况下，都有很多漏洞。比如，研究人员可以修改一些未经过认证的应用程序参数，但这对于攻击应用程序来说是非常有限的。再比如研究人员有SQLi，但它无法得到nagiosxi认证数据。还有，研究人员虽有命令注入，但它需要经过认证的管理会话。即使研究人员有本地权限提升漏洞，但也需要通过命令行访问应用程序服务器。对于聪明且见多识广的黑客来说，进行优化组合是他们的特长。经过组合验证，研究人员发现将这些漏洞组合使用的话，就能得到一个无需身份认证的、具有root权限的远程命令执行漏洞！具体过程如下：
1.检查nagios的版本，上面列出的所有漏洞都适用于5.2.6到5.4之间的NagiosXI版本，这可以从<nagiosxi_host> /nagiosxi/login.php中解析的版本字符串中进行了解。
2.将数据库用户更改为root用户，使用CVE-2018-8733，研究人员可以将nagiosql数据库用户修改为root用户，授予其足够的权限来访问nagiosxi认证数据。
3.利用SQLi访问API密钥，现在数据库用户拥有足够的权限，研究人员使用CVE-2018-8734执行SQL注入，该注入将返回系统中所有唯一的API密钥。由于该API密钥是随数据库一起产生的，因此这是一个非常可靠的选项。
4.使用API密钥添加管理用户，如果你拥有适当的API密钥，则这就不是一个漏洞了，只是一个可用于添加管理用户的API。
5.登录，现在研究人员就可以伪装成系统的管理员了，就可以进行登录了。此时，研究人员已经有效地绕过了应用程序的nagiosxi部分的认证。
6.注入命令并提升权限，此时，研究人员使用CVE-2018-8735（研究人员的命令注入漏洞）来执行命令。一旦研究人员在应用服务器上获得了一个会话，研究人员就可以建立一个低权限的反向shell，然后提升权限。但是，就经过PoC测试后，由于研究人员已将所需的命令放入临时的权限提升脚本中，所以只需执行这个脚本，所有组合工作就可以完成。
cp /usr/local/nagiosxi/scripts/reset_config_perms.sh /usr/local/nagiosxi/scripts/reset_config_perms.sh.bak &&
echo "{your_command_here}" > /usr/local/nagiosxi/scripts/reset_config_perms.sh &&
sudo /usr/local/nagiosxi/scripts/reset_config_perms.sh &&
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漏洞。其中，上述代码段中的第一行和最后一行命令分别是用于备份和恢复原始脚本的。
总结
按照上述步骤，研究人员能够将4个漏洞组合为一个root级别的RCE漏洞，并且不会引起任何警告。
所以，对待漏洞，我们要有一个宏观的思维来看待，否则可能导致非常严重的后果。俗话说“千里之提毁于蚁穴”，说的就是这样的情况。
还没有评论，来说两句吧...