此漏洞来自dz公司的ucenter,这个ucenter,应该是在数据库备份操作时候,没有做csrf防御可导致dz被文件操作,脱裤等等,开始分析:
下来我们分析代码:
uc_server\control\admin\db.php:(85-ll6行):
这里的意思就是,当你发送一个get请求之后,然后php内部通过fopen完成剩下的所有动作,漏洞产生在哪里呢:
看到这两句了没有,举个例子吧:
我们提交的http请求如果是:
http://site.com/index.php?a=1&b=2
那么当我们b传递进来的时候重新二次构造url,如果我们的b=xxxx%26backupfilename%3Daaaa
这里时候等于在内部通过fopen发送get请求时候后面多添加了一个参数交个backupfilename=aaaa
看到这个解释,就恍然大悟了吧,肯定后面有怎么设置backupfilename,本来这里是不会被用户更改的,这样已设置,我们备份的文件名字可控了,直接可以拿到,在看代码:
uc_server\api\dbbak.php:(255-334):
我们主要看着一句:
刚才我们举例子了,按照这个逻辑走那么我们就会绕过去,不会在这里创建一个6个字符的随机数文件名
这里为了举例子,我们摘出来其中一部分sql备份:
url:http://192.168.10.70/discuz_x3.2_sc_utf8https://wooyun-img.oss-cn-beijing.aliyuncs.com/upload/uc_server/admin.php?m=db&a=operate&t=export&appid=0&backupdir=xxxx%26backupfilename%3Daaaa
按照程序的逻辑,这句话的意思就是在xxxx目录底下备份一个aaaa-1.sql
我们访问一下:
我们去这个目录看看是否已经生成备份文件:
有了这个我们害怕什么,很简单的一个get csrf,这时候我们在论坛发送一个img
<img src=http://192.168.10.70/discuz_x3.2_sc_utf8https://wooyun-img.oss-cn-beijing.aliyuncs.com/upload/uc_server/admin.php?m=db&a=operate&t=export&appid=0&backupdir=xxxx%26backupfilename%3Daaaa>
一切都搞定......关于这里怎么利用,方法太多了
下来我们看第二个漏洞目录穿越:
这里的backupdir 居然没有做任何限制,所以我们可以再操作系统内部随意创建文件夹
并且把备份的文件给写入进去,想想都可怕,如果dz的数据库非常强大,我这里只要一个死循环,分分钟让硬盘爆满:
url:http://192.168.10.70/discuz_x3.2_sc_utf8https://wooyun-img.oss-cn-beijing.aliyuncs.com/upload/uc_server/admin.php?m=db&a=operate&t=export&appid=0&backupdir=../../../../../../../../../../../../../../../../../xxxx
这时候我们去根目录看看:
有人说gpc开着那么我们就没有办法阶段这一句代码:
说的一点都没有错,因为我们这个$get['backupfilename']是完全可控的,如果我们发送%00这里会被gpc转义为\0不会被截短,但是在linux底下就不一样了,每个文件达到一定长度时候它自然就被截断了,举个例子:
在Linux环境下测试,你会发现'.php'被截断了.这时候我们就可以写一个php文件了,不做演示了,主要漏洞点演示完毕
下来我们再看一个文件删除的地方:
这里的逻辑就是删除某个目录底下的以sql后缀的文件,然后删除改文件夹,当然了这个文件夹如果是空的,那么我也就直接删除,非空是删不掉的
由于$sqlpath 路径完全可控,所以导致,可以再某一个盘符底下任意穿越删除sql文件,不管你是其他备份的还是这里自己生成的一概删掉
反正有了这个fopen的参数污染bug,那么应该还有好多地方存在问题,这里就不一一说了
再付最后一张图:
这些 我想就不用分析了吧,都是嵌入应用.........
ok