当前位置：WooYun >> 漏洞信息

漏洞概要 关注数(24) 关注此漏洞

缺陷编号：
wooyun-2014-088907
漏洞标题：
易车网第二弹之多种姿势拿下CDN管理系统
相关厂商：
易车
漏洞作者：
plane636
提交时间：
2014-12-27 16:03
修复时间：
2015-02-10 16:04
公开时间：
2015-02-10 16:04
漏洞类型：
SQL注射漏洞
危害等级：
高
自评Rank：
20
漏洞状态：
厂商已经确认
漏洞来源：
http://www.wooyun.org，如有疑问或需要帮助请联系 [email protected]
Tags标签：
无
分享漏洞：
4人收藏 收藏
分享漏洞：
>

漏洞详情

披露状态：

2014-12-27： 细节已通知厂商并且等待厂商处理中
2014-12-29： 厂商已经确认，细节仅向厂商公开
2015-01-08： 细节向核心白帽子及相关领域专家公开
2015-01-18： 细节向普通白帽子公开
2015-01-28： 细节向实习白帽子公开
2015-02-10： 细节向公众公开

简要描述：

漏洞如此之多，让我产生了这是个蜜罐的错觉。CDN管理系统重要性不必多说。

详细说明：

上一弹发的是易车网数十台CDN节点rsync未授权访问，乍看之下rsync目录里都是一些squid日志和配置文件之类的东西，没什么能直接利用的。
但是某个日志文件里发现了如下内容：

--2014-05-13 17:30:38--  http://59.151.127.48/SystemOpsPlatform/php/Interface/receiveApplyFeedback.php
Connecting to 59.151.127.48:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Tue, 13 May 2014 09:32:30 GMT
  Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.3.10
  X-Powered-By: PHP/5.3.10
  Content-Length: 1
  Keep-Alive: timeout=5, max=100
  Connection: Keep-Alive
  Content-Type: text/html; charset=utf-8
Length: 1 [text/html]
Saving to: `/dev/null'
     0K                                                       100% 40.7K=0s
2014-05-13 17:30:39 (40.7 KB/s) - `/dev/null' saved [1/1]


先上去看看url是什么再说

1.jpg


wow，cdn的后台管理。但是现在账号密码都没有，rsync得到的信息也只有个url。先扫下端口，看看有没有突破口，可惜只开了80，只能从web端解决了。
继续翻看url，发现php目录存在能够列目录。

2.jpg


翻来翻去，都是些看不了内容的php文件，好不容易发现一处rar压缩包，打开看看。

3.jpg


里面就两个php文件

4.jpg


好吧坑爹，网站目录下就没有这两个文件。但是源码里面的内容还是引起了我的注意：

$sql_validation = "update VersionApplyValidation set Status=$validation_status,ErrorFlag=$error_flag,ErrorMessage='" . $error_msg . "'
						where GUID = '" . $guid . "' and IP = '" . $ip . "' and InstanceID = $instanceid and ConfigInfoID = $configinfoid";
				$sql_history = "update InstanceConfigHistory set Status=$history_status
								where GUID = '" . $guid . "' and InstanceID = $instanceid and ConfigInfoID = $configinfoid";


几处post的参数没有处理就拼接进sql语句中了。这样看来网站存在注入的可能性就很大了。前台只有登陆，先在登陆试试注入吧。
用户名构造如下语句：

admin' or '1' ='1'#


5.jpg


6.jpg


竟然进来了。。。这种万能密码好久没碰见过了
sqlmap也能跑出来

7.jpg


在后台测试的过程中发现一个问题

8.jpg


发现什么问题了吗？cookie里面只有用户名，没有session。。。。这是否意味着我们无需密码只要设置一下cookie就可以了呢？

9.jpg


10.jpg


2333333又成功了。
现在洞主已经对这个系统的验证机制产生深刻的怀疑了，我们去登陆界面悄悄它是怎么验证的。
翻看登陆页面的源代码，看到这段js的时候洞主惊呆了：

$(document).ready(function () {
            var username = $.cookie('cdnops_user');
            if (username != null) {
                window.location.href = "/SystemOpsPlatform/home.html";
            }
            $("#UserName").val($.cookie('cdnops_remeber_user'));
            $("#ckb_RememberMe").attr("checked", $.cookie('cdnops_remeber_ckb_status'));
            $("#UserName").focus();
        });
        function LogIn() {
            if (CheckInput()) {
                //调用PHP 进行登录验证
                var username = del_blank($('#UserName').val());
                var pwd = $.md5($('#PassWord').val());
                $.post(
                "/SystemOpsPlatform/php/login.php", { username: username, pwd: pwd, anticache: Math.floor(Math.random() * 1000) }, function (data, state) {
                    if (state == "success") {
                        if (data == "true") {
                            //写Cookie
                            var cookietime = new Date();
                            cookietime.setTime(cookietime.getTime() + (60 * 60 * 1000 * 4)); //cookie有效期4个小时
                            $.cookie('cdnops_user', username, { expires: cookietime, path: '/' });
                            if ($("#ckb_RememberMe").attr("checked") == true) {
                                $.cookie('cdnops_remeber_user', username, { expires: 7, path: '/' });
                                $.cookie('cdnops_remeber_ckb_status', true, { expires: 7, path: '/' });
                            }
                            else {
                                $.cookie('cdnops_remeber_user', null, { path: '/' });
                                $.cookie('cdnops_remeber_ckb_status', null, { path: '/' });
                            }
                            window.location.href = "/SystemOpsPlatform/home.html";
                        }
                        else {
                            $(".ErrorMsg").text(data);
                        }
                    }
                }, "text");
            }
            else {
            }
        };


竟在在客户端做的校验，这段代码的意思就是将用户名和密码发送到服务器端，如果匹配服务器将返回值“true”；若收到“true”则将用户名写入到cookie中并跳转到后台页面。这样的话我们只要将response改成true不就能登陆系统了吗。来验证下。
在fiddler命令行中输入命令bpafter 59.151.127.48 设置response断点，然后提交一个错误的用户密码，此刻我们返回的是一个错误信息。

11.jpg


改成‘true’试试.走你

13.jpg


后台君我们又见面了
此刻我又有了一个想法，既然登陆的验证是客户端做的，那么后台页面对用户的验证是不是也是在客户端呢。

14.jpg


果然在后台页面找到这样一处脚本，也验证了之前仅检测cookie用户名的说法。这样我们干掉此处js然后自己构造脚本也是可行的，不过有点多此一举就不赘述了。
验证这块已经挖掘的差不多了，还有别的姿势能进入这个系统吗，当然有！
本想通过注入获得点东西，但这个系统sqlmap跑出来是基于时间注入，获取数据老出错，数据库账号权限也有限，不从这下手了。后台有个用户管理，就在我通过列目录查看相关的文件时，点开了后台获取系统账号信息的php链接：

16.jpg


15.jpg


卧槽，全部账号和md5都出来了，也不是什么强口令，google一下都能找到。当然，这里无需登录也是能获取到的。

漏洞证明：

这么多能够利用的点，我已经无力吐槽了，好多多年没见的利用方式这次再次用上。

17.jpg


18.jpg

修复方案：

要从系统架构完全重练了。

版权声明：转载请注明来源 plane636@乌云

>

漏洞回应

厂商回应：

危害等级：高

漏洞Rank：15

确认时间：2014-12-29 11:40

厂商回复：

非常感谢提供的漏洞信息，我们会尽快进行处理

最新状态：

2014-12-30：漏洞已经修复，非常感谢给易车的帮助