从补丁到漏洞分析 --记一次joomla漏洞应急

发布时间：2018-02-07 12:32:41

作者：LoRexxar'@知道创宇404实验室 
2018年1月30日，joomla更新了3.8.4版本，这次更新修复了4个安全漏洞，以及上百个bug修复。 
<a>https://www.joomla.org/announcements/release-news/5723-joomla-3-8-4-release.html</a>&nbsp; 
为了漏洞应急这几个漏洞，我花费了大量的时间分析漏洞成因、寻找漏洞触发位置、回溯逻辑，下面的文章比起漏洞分析来说，更接近我思考的思路，希望能给大家带来不一样的东西。

####背景

其中的4个安全漏洞包括 
<pre><code>- Low Priority - Core - XSS vulnerability in module chromes (affecting Joomla 3.0.0 through 3.8.3) 
- Low Priority - Core - XSS vulnerability in com_fields (affecting Joomla 3.7.0 through 3.8.3) 
- Low Priority - Core - XSS vulnerability in Uri class (affecting Joomla 1.5.0 through 3.8.3) 
- Low Priority - Core - SQLi vulnerability in Hathor postinstall message (affecting Joomla 3.7.0 through 3.8.3)</code></pre>

根据更新，我们去到github上的joomla项目，从中寻找相应的修复补丁，可以发现，4个安全漏洞的是和3.8.4的release版同时更新的。 
<a>https://github.com/joomla/joomla-cms/commit/0ec372fdc6ad5ad63082636a0942b3ea39acc7b7</a>&nbsp; 
通过补丁配合漏洞详情中的简单描述我们可以确定漏洞的一部信息，紧接着通过这部分信息来回溯漏洞成因。

####SQLi vulnerability in Hathor postinstall message

<a>https://developer.joomla.org/security-centre/722-20180104-core-sqli-vulnerability.html</a>&nbsp; 
<pre><code>Description
The lack of type casting of a variable in SQL statement leads to a SQL injection vulnerability in the Hathor postinstall message.

Affected Installs
Joomla! CMS versions 3.7.0 through 3.8.3</code></pre>

#####补丁分析

第一个漏洞说的比较明白，是说在Hathor的postinstall信息处，由于错误的类型转换导致了注入漏洞。 
我们来看看相应的补丁 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977753496cc43e737493d85ca78dc3976f0f1286e4b3cd.png"> 
符合漏洞描述的点就是这里，原来的取第一位改为了对取出信息做强制类型转换，然后拼接入sql语句。 
这里假设我们可以控制<code>$adminstyle</code>，如果我们通过传入数组的方式设置该变量为数组格式，并且第1个字符串可控，那么这里就是一个可以成立的漏洞点。 
现在我们需要找到这个功能的位置，并且回溯变量判断是否可控。

#####找到漏洞位置

hathor是joomla自带的两个后台模板之一，由于hathor更新迭代没有isis快，部分功能会缺失，所以在安装完成之后，joomla的模板为isis，我们需要手动设置该部分。 
<pre><code>Templates-&gt;styles-&gt;adminnistrator-&gt;hathor</code></pre>

<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977754e656c947b42cd4c16ff785d0cbfefd3fec6c1b32.png"> 
修改完成后回到首页，右边就是postinstallation message 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977756e9367b56bc3649ac8622e830bacee3b9dd657b4e.png">

#####回溯漏洞

回到代码中，我们需要找到<code>$adminstyle</code>这个变量进入的地方。 
<pre><code>$adminstyle = $user-&gt;getParam('admin_style', ''); </code></pre>

这里user为<code>JFactory::getUser()</code>，跟入getParam方法 
<pre><code>/libraries/src/User/User.php line 318

public function getParam($key, $default = null)
{
 return $this-&gt;_params-&gt;get($key, $default);
}</code></pre>

这里<code>$this-&gt;_params</code>来自<code>$this-&gt;_params = new Registry;</code> 
跟入Registry的get方法 
<pre><code>libraries/vendor/joomla/registry/src/Registry.php line 201

public function get($path, $default = null)
    {
        // Return default value if path is empty
        if (empty($path))
        {
            return $default;
        }

if (!strpos($path, $this-&gt;separator))
        {
            return (isset($this-&gt;data-&gt;$path) &amp;&amp; $this-&gt;data-&gt;$path !== null &amp;&amp; $this-&gt;data-&gt;$path !== '') ? $this-&gt;data-&gt;$path : $default;
        }

// Explode the registry path into an array
        $nodes = explode($this-&gt;separator, trim($path));

// Initialize the current node to be the registry root.
        $node = $this-&gt;data;
        $found = false;

// Traverse the registry to find the correct node for the result.
        foreach ($nodes as $n)
        {
            if (is_array($node) &amp;&amp; isset($node[$n]))
            {
                $node = $node[$n];
                $found = true;

continue;
            }

if (!isset($node-&gt;$n))
            {
                return $default;
            }

$node = $node-&gt;$n;
            $found = true;
        }

if (!$found || $node === null || $node === '')
        {
            return $default;
        }

return $node;
 }</code></pre>

根据这里的调用方式来看，这里会通过这里的的判断获取是否存在adminstyle，如果没有则会返回default(这里为空) 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977757cafbbd6d52063e80d0c2b34fc9f1c2c9162060fa.png"> 
接着回溯<code>$this-&gt;data</code>,data来自<code>$this-&gt;data = new \stdClass;</code> 
回溯到这里可以发现<code>$admin_style</code>的地方是从全局变量中中读取的。 
默认设置为空<code>/administrator/components/com_users/models/forms/user.xml</code> 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977759c7909f780b7737eacf1a20871259a4f18bf38866.png"> 
但我们是可以设置这个的 
后台<code>users-&gt;users-&gt;super user</code>设置，右边我们可以设置当前账户使用的后台模板，将右边修改为使用hathor型模板。 
通过抓包我们可以发现，这里显式的设置了当前账户的<code>admin_type</code>，这样如果我们通过传入数组，就可以设置<code>admin_type</code>为任意值 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/15179777624b3d6ee44bf9c699258aed75bea0ffac15dee1e6.png"> 
然后进入代码中的数据库操作
<code>/administrator/templates/hathor/postinstall/hathormessage.php function hathormessage_postinstall_condition</code> 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/15179777638670511064eb76163a6c4e7f958108aae7c04506.png"> 
访问post_install页面触发 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977764a8f9dfaf384929d6c84b9453091257afb4e7b46a.png">

####XSS vulnerability in com_fields

<a>https://developer.joomla.org/security-centre/720-20180102-core-xss-vulnerability.html</a>&nbsp; 
<pre><code>Description
Inadequate input filtering in com_fields leads to a XSS vulnerability in multiple field types, i.e. list, radio and checkbox.

Affected Installs
Joomla! CMS versions 3.7.0 through 3.8.3</code></pre>

#####补丁分析

<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977765aedb70c4631b0ef325db3095d7384507ab43e015.png"> 
漏洞详情写了很多，反而是补丁比较模糊，我们可以大胆猜测下，当插入的字段类型为list、radio、checkbox多出的部分变量没有经过转义 
首先我们需要先找到触发点 
后台<code>content-&gt;fields-&gt;new</code>，然后设置type为<code>radio</code>，在键名处加入相应的payload 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977766675b8594dafa022d883030a0ce93e6bd32522e72.png"> 
然后保存新建文章 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977768b1c48911333dc0404b5f596544ba0ef05985c308.png"> 
成功触发

#####漏洞分析

由于补丁修复的方式比较特殊，可以猜测是在某些部分调用时使用了textContent而不是nodeValue，在分析变量时以此为重点。 
漏洞的出发点<code>/administrator/components/com_fields/libraries/fieldslistplugin.php line 31</code> 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977771fcfaa489bfd76f88be8c2d527fe8dc6479ac89d2.png"> 
由于找不到该方法的调用点，所以我们从触发漏洞的点分析流程。 
编辑文章的上边栏是通过<code>administrator/components/com_content/views/article/tmp/edit.php line 99</code>载入的 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977772305895ade510e65162fb96395d51b7e5d987ceda.png"> 
这里<code>JLayoutHelper:render</code>会进入<code>/layouts/joomla/edit/params.php</code> 
然后在129行进入<code>JLayoutHelper::render('joomla.edit.fieldset', $displayData);</code> 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977774c360fe85a6e12234c4fc2c5b813bdba485bcdd62.png"> 
跟入<code>/layouts/joomla/edit/fieldset.php line 16</code>，代码在这里通过执行<code>form</code>的<code>getFieldset</code>获取了提交的自定义字段信息。 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/15179777756a430baf8e582efcc39e7a534b92f3db960390dd.png"> 
跟入<code>/libraries/src/Form/Form.php line 329 function getFieldset</code> 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977778167bea609cb9180868fadcf2c9b04b3394cad2db.png"> 
跟如1683行 <code>findFieldsByFieldset</code>函数。 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977781ba447325a9a2d9c1b11f4dd7b0322053627b2b9c.png"> 
这里调用xml来获取数据，从全局的xml变量中匹配。 
这里的全局变量中的xml中的option字段就来自于设置时的<code>$option-&gt;textContent</code>，而只有<code>list, radio and checkbox.</code>这三种是通过这里的函数做处理，其中list比较特殊，在后面的处理过程中，list类型的自定义字段会在<code>/libraries/cms/html/select.php line 742 function options</code>被二次处理，但radio不会，所以漏洞存在。 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/151797778253144eac34ca69968312700b69bb30f68d585259.png"> 
整个xss漏洞从插入到触发限制都比较大，实战价值较低。

####XSS vulnerability in Uri class

<a>https://developer.joomla.org/security-centre/721-20180103-core-xss-vulnerability.html</a>&nbsp; 
<pre><code>Description
Inadequate input filtering in the Uri class (formerly JUri) leads to a XSS vulnerability.

Affected Installs
Joomla! CMS versions 1.5.0 through 3.8.3</code></pre>

#####补丁分析

比起其他几个来说，这里的漏洞就属于特别清晰的，就是在获取系统变量时，没做相应的过滤。 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/15179777836346dc0fa6eeb32e57628d9edcec2c4cab500d1a.png"> 
前台触发方式特别简单，因为这里的<code>script_name</code>是获取基础url路径的，会拼接进所有页面的和链接有关系的地方，包括js或者css的引入。

#####漏洞利用

让我们来看看完整的代码 
<pre><code>if (strpos(php_sapi_name(), 'cgi') !== false &amp;&amp; !ini_get('cgi.fix_pathinfo') &amp;&amp; !empty($_SERVER['REQUEST_URI']))
{
 // PHP-CGI on Apache with "cgi.fix_pathinfo = 0"

// We shouldn't have user-supplied PATH_INFO in PHP_SELF in this case
    // because PHP will not work with PATH_INFO at all.
    $script_name = $_SERVER['PHP_SELF'];
}
else
{
    // Others
    $script_name = $_SERVER['SCRIPT_NAME'];
}

static::$base['path'] = rtrim(dirname($script_name), '/\\');</code></pre>

很明显只有当<code>$script_name = $_SERVER['PHP_SELF']</code>的时候，漏洞才有可能成立 
只有当php是fastcgi运行，而且cgi.fix_pathinfo = 0时才能进入这个判断，然后利用漏洞还有一个条件，就是服务端对路径的解析存在问题才行。 
<pre><code>http://127.0.0.1/index.php/{evil_code}/321321

---&gt;

http://127.0.0.1/index.php</code></pre>

当该路径能被正常解析时，<code>http://127.0.0.1/index.php/{evil_code}</code>就会被错误的设置为基础URL拼接入页面中。 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/15179777840f6490a6c4bfb0858d9442d190a3eae0d9502c4e.png"> 
一个无限制的xss就成立了

####XSS vulnerability in module chromes

<a>https://developer.joomla.org/security-centre/718-20180101-core-xss-vulnerability.html</a>&nbsp; 
<pre><code>Description
Lack of escaping in the module chromes leads to XSS vulnerabilities in the module system.

Affected Installs
Joomla! CMS versions 3.0.0 through 3.8.3</code></pre>

#####补丁分析

<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/1517977786abb545edb68e314ca82c2cb94c65d1bef8308288.png"> 
漏洞存在的点比较清楚，修复中将<code>$moduleTag</code>进行了一次转义，同样的地方有三处，但都是同一个变量导致的。 
这个触发也比较简单，当我们把前台模板设置为protostar（默认）时，访问前台就会触发这里的<code>modChrome_well</code>函数。

#####漏洞利用

让我们看看完整的代码 
<img alt="" src="http://pgicons.cn-bj.ufileos.com/img_open/15179777896dcde41cb8d3f910862d684697e1e18fe7199489.png"> 
很明显后面<code>module_tag</code>没有经过更多处理，就输出了，假设我们可控<code>module_tag</code>，那么漏洞就成立。 
问题在于怎么控制，这里的函数找不到调用的地方，能触发的地方都返回了传入的第二个值，猜测和上面的<code>get_param</code>一样，如果没有设置该变量，则返回<code>default</code>值。 
经过一番研究，并没有找到可控的设置的点，这里只能暂时放弃。

####ref

<ul>
<li>Joomla 3.8.4 <a>https://www.joomla.org/announcements/release-news/5723-joomla-3-8-4-release.html</a>&nbsp;</li>
<li>Joomla security patches <a>https://developer.joomla.org/security-centre/</a>&nbsp;</li>
</ul>

原文 / From paper.seebug.org/529/