浅谈开源web程序后台的安全性

摘要：大学网站使用了名为的开源程序，青年使用一个已经公开的漏洞进入后台青年使用后台上传限制不严的缺陷上传了一个控制主机赠送我国国旗。这些程序都是国内开源程序中的佼佼者，也比较注重安全性。此时后台程序的安全性成为一个短板。

不知怎的最近甚是思念校园生活，思念食堂的炒饭。那时会去各种安全bbs上刷刷帖子，喜欢看别人写的一些关于安全技巧或经验的总结；那时BBS上很多文章标题都是：成功渗透XXX，成功拿下XXX。这里便以一篇入侵菲律宾某大学的文章引出文章的主题，我们先简要看一下过程。大学网站使用了名为joomla的开源web程序，（1）青年使用一个joomla已经公开的漏洞进入web后台（2）青年使用joomla后台上传限制不严的缺陷上传了一个webshell（3）控制主机赠送我国国旗。
       
原来入侵一台主机如此容易，管理员果断给web程序打上安全补丁。管理员的工作是结束了，作为安全从业人员再一想是不是joomla后台这里可以上传webshell是不是有问题呢，如果joomla后台不能上传webshell，是不是可以减少入侵的可能和损失。下面进入本文的主题：web后台程序的安全性。

国内很多站点都是基于开源论坛、cms搭建的，比如discuz、phpwind、dedecms等。这些程序都是国内开源web程序中的佼佼者，也比较注重安全性。平时大家关注比较多的是sql注入、xss这些可以直接窃取用户数据的漏洞。网上因为弱口令被入侵的案例数不胜数，此外用户数据泄漏事件时而发生，单纯靠密码防护的后台被突破，被社工的可能性越来越大。获取一个管理后台密码后，再结合后台程序的任意代码执行、文件包含或命令注入等漏洞得到一个shell，窃取用户资料不是什么难事。此时后台程序的安全性成为一个短板。
      
Discuz是一款流行的论坛程序，笔者这里就以它的后台程序为例简单分析一下其安全性，下面直接看一些漏洞案例（Discuz最新版本已打补丁）。

Tips：下文提到的$settingnew是discuz后台存储表单数据的变量，后台用户可控。

漏洞文件：X3sourceadmincpadmincp_setting.php

分析：

alice修改$settingnew["extcredits"]非数组

if(is_array($settingnew["extcredits"])) {
foreach($settingnew["extcredits"] as $key => $value) {

给$settingnew["initcredits"][1]传入phpinfo();,非数组绕过intval转换

$settingnew["initcredits"][$i] = intval($settingnew["initcredits"][$i]);
... 省略 ...
for($i = 1; $i <= 8; $i++) {

phpinfo();被赋值给$initformula

$initformula = str_replace("extcredits".$i, $settingnew["initcredits"][$i], $initformula);
}

phpinfo()带入eval执行

eval("$_G["setting"]["initcredits"] = round($initformula);");

       
简单介绍一下二次注入，恶意用户alice在A处传入恶意数据并被存储到数据库，在A处不直接导致安全问题；B处引用到A处存储的数据，从而触发安全问题。

漏洞文件：X3sourceadmincpadmincp_setting.php

分析：

alice上传一个图片木马假设为1.gif; alice设置$settingnew["seccodedata"]["type"]值为1.gif:xx（根据图片地址做适当目录跳转）；该值未作任何过滤存入数据库

if($settingnew["seccodedata"]["type"] == 0 || $settingnew["seccodedata"]["type"] == 2) {
  $seccoderoot = "static/image/seccode/font/en/";
} elseif($settingnew["seccodedata"]["type"] == 1) {
  $seccoderoot = "static/image/seccode/font/ch/";
}

漏洞文件：sourcemodulemiscmisc_seccode.php

$_G["setting"]["seccodedata"]["type"]值来自于数据库，即为1处传入的1.gif:xx

if(!is_numeric($_G["setting"]["seccodedata"]["type"])) {
$etype = explode(":", $_G["setting"]["seccodedata"]["type"]);
if(count($etype) > 1) {

截断得到$codefile为图片小马(也可使用././././多个路径符方法截断)

$codefile = DISCUZ_ROOT."./source/plugin/".$etype[0]."/seccode/seccode_".$etype[1].".php";
... 省略 ...
if(file_exists($codefile)) {

图片木马被include得到webshell

@include_once $codefile;

漏洞文件：X3sourceadmincpadmincp_adv.php

alice上传一个图片木马假设为1.gif; alice传入type参数值为1.gif:xx（根据图片地址做适当目录跳转）

$type = $_GET["type"];
... ...
if($type) {

得到$etype为1.gif

$etype = explode(":", $type);
if(count($etype) > 1) {

$advfile值被截断，为图片木马路径1.gif

$advfile = DISCUZ_ROOT."./source/plugin/".$etype[0]."/adv/adv_".$etype[1].".php";
$advclass = "adv_".$etype[1];
}
... 省略 ...

包含图片木马，得到webshell

if(file_exists($advfile)) {
require_once $advfile;

对比下X2.5版本的逻辑，此处漏洞完全是因为新增代码导致的。

```
$type = $_GET["type"];
$target = $_GET["target"];
$typeadd = "";
if($type) {
$advfile = libfile("adv/".$type, "class");
if(file_exists($advfile)) {
require_once $advfile;
```

漏洞文件：X3apiuc.php

分析：

config_ucenter.php内容部分截取如下：define("UC_API", "http://localhost/bbs/uc_server");

$configfile = trim(file_get_contents(DISCUZ_ROOT."./config/config_ucenter.php"));
... ...

$UC_AP外部可控，alice传入$UC_API的值为xyz");eval($_POST[cmd];得到$configfile值为define("UC_API", "xyz");eval($_POST[cmd];"); xyz后面的引号被转义。

$configfile=preg_replace("/define("UC_API",s*".*?");/i","define("UC_API","".addslashes($UC_API)."");", $configfile);

将define("UC_API", "xyz");eval($_POST[cmd];");写入配置文件

if($fp = @fopen(DISCUZ_ROOT."./config/config_ucenter.php", "w")) {
       @fwrite($fp, trim($configfile));
       @fclose($fp);
}

alice再次传入$UC_API的值为xyz，preg_replace使用的正则表达式是define("UC_API",s*".*?"); .*?"非贪婪匹配，匹配到第一个引号结束，之前的转义符被替换xyz替换为xyz，从而得到$configfile值为define("UC_API", "xyz");eval($_POST[cmd];");写入配置文件得到webshell。

这个问题早在2010年外部已经公开，官方已及时发出补丁 详情请参考：http://www.oldjun.com/blog/index.php/archives/76/

      
上面这些例子主要是笔者实践经验的一些总结，不一定全面，希望能给大家拓展一些思路；比如上述提到的二次注入，$settingnew["seccodedata"]["type"]这个变量没过滤，$settingnew的其他数组也可能没过滤，也确实存在多处类似的问题，大家可以自行去尝试一下。关于代码审计的方法主要有两个大方向：（1）危险函数向上追踪输入；（2）追踪用户输入是否进入危险函数；这里的危险函数关于危险函数主要包括代码执行相关：eval、assert，文件包含：include、require等，命令执行：system、exec等，写文件：fwrite、file_put_contents等；

代码审计的方法这里推荐两篇文章:

https://code.google.com/p/pasc2at/wiki/SimplifiedChinese
http://wenku.baidu.com/view/c85be95a3b3567ec102d8a12.html

一切输入都是有害的；

后台程序的用户输入相比前台主要增加了后台表单的数据，此外有些后台支持上传文件(如dz1.5的自定义sql)，上传文件的内容也属于输入；这些输入都属于用户范围。一定要做严格的控制和过滤。

安全意识；

其实很多漏洞的产生并不是技术问题导致的，而是我们缺乏安全意识，不重视安全而酿成的惨剧。尤其是第三个和第四个，完全不应该发生；需要对开发人员做安全宣导和基本的安全培训。

漏洞Review；

开发人员收到漏洞后要对漏洞产生的原因做总结，并Review代码中是否有类似的问题。有些时候开发人员仅仅是修补了安全人员或白帽子提供的漏洞点，另外一处代码有类似的问题没修补继续爆出漏洞，无穷无尽。这样做还会带来更大的隐患，黑客是非常乐意并擅长总结反思的，每一个补丁其实也是给黑客拓展了思路，如果修补不完全后果很严重。

开发人员修补完成后安全人员需要进行测试确认，上述的案例四就是鲜明的例子。有条件的情况下安全人员应该整理一些常见漏洞修复指引，这样也可以提高工作效率。

via freebuf