代码审计-yxcms1.2.1(持续更新中.)
Ebounce
撰写于 2019年 09月 04 日

前记


最近有段时间没有更新博客了,之前做了一段时间的Django web开发,这篇更完之后也会更个新的系列,用Django框架快速写一篇博客.好了废话不多说,开始正题吧

CMS版本:yxcms1.2.1(老版本,也许以后还会更个1.4.6的版本然后做个比较)
PHP版本:5.4.45
<!--more-->

Part1


cookie注入
首先将相应版本的CMS安装好,然后拖到本地,进行安装,在安装界面上面,我们发现一个密钥,应该是用于各种加密操作的密钥,如果我们将这个密钥设置成为默认的yx时,可能导致一定的安全隐患,比如这里其实存在一处Cookie注入,就是利用已知密钥进行的Cookie注入.

我们首先找到加解密函数,将他们提取出来用于解构Cookie和生成Cookie,该函数位于common.function.php里面分别为:

(上面那个是加密函数)
不过我们并不需要知道是如何加密的,我们只需要知道是如何使用就可以了,然后在功能里面进行查找需要使用Cookie的地方,这个cms代码审计了一下,发现是以类作为功能点的,如下图:

首先我们需要知道Cookie是以什么参数的形式,游走在各个php文件之间的,这时候我们在index功能点处找到了Cookie的来源,这里是登陆时使用的方法,我们不难发现Cookie被设置成为了auth变量,并在此处被赋值,并且前面还将Cookie的构成展示给了我们,再观察set_cookie()和get_cookie()我们可以发现set_cookie()处使用了一次cp_decode(),而get_cookie处使用了一次cp_encode()这也就意味着密钥已知情况下,cookie是完完全全可控的.


PS:注意这里"auth"参数处实际上是$pre.$var是前缀yx_与auth的字符链接.

在已知了$auth是Cookie的情况下,我们再去查找使用的地方,发现了一处调用,这里使用了$auth变量,并且使用了model类的find()方法,再次进行查找,发现model类实际上是cpModel类的对象,使用model的find()方法,实际上就是调用了,cpModel类的find()方法,再去查找,发现这里出现了对于数据库的操作了,并且对于参数没有任何的过滤,直接就被拼接到了sql语句上面



从最开始的model()->find()我们可以发现这里传入的查询参数为id,因此sql注入点在id这里下面来构造exp

exp




由前面Cookie构成可以知道第一个数字就是id值,因此构造恶意id值为:

123'union select username,password from yx_admin#\t2\ttest\ttest\127.0.0.1


再使用cp_encode()进行加密,记得加密钥,最后在下面这个地方就可以拿到admin账号了
PS:
1.试验了很久似乎生成的cookie有一定成功率....
2.务必记得将生成yx_auth进行一次url编码

未完待续....
立个flag,每周更一篇代码审计激励一下自己233333

代码审计-yxcms1.2.1(持续更新中.)

前记


最近有段时间没有更新博客了,之前做了一段时间的Django web开发,这篇更完之后也会更个新的系列,用Django框架快速写一篇博客.好了废话不多说,开始正题吧

CMS版本:yxcms1.2.1(老版本,也许以后还会更个1.4.6的版本然后做个比较)
PHP版本:5.4.45
<!--more-->

Part1


cookie注入
首先将相应版本的CMS安装好,然后拖到本地,进行安装,在安装界面上面,我们发现一个密钥,应该是用于各种加密操作的密钥,如果我们将这个密钥设置成为默认的yx时,可能导致一定的安全隐患,比如这里其实存在一处Cookie注入,就是利用已知密钥进行的Cookie注入.

我们首先找到加解密函数,将他们提取出来用于解构Cookie和生成Cookie,该函数位于common.function.php里面分别为:

(上面那个是加密函数)
不过我们并不需要知道是如何加密的,我们只需要知道是如何使用就可以了,然后在功能里面进行查找需要使用Cookie的地方,这个cms代码审计了一下,发现是以类作为功能点的,如下图:

首先我们需要知道Cookie是以什么参数的形式,游走在各个php文件之间的,这时候我们在index功能点处找到了Cookie的来源,这里是登陆时使用的方法,我们不难发现Cookie被设置成为了auth变量,并在此处被赋值,并且前面还将Cookie的构成展示给了我们,再观察set_cookie()和get_cookie()我们可以发现set_cookie()处使用了一次cp_decode(),而get_cookie处使用了一次cp_encode()这也就意味着密钥已知情况下,cookie是完完全全可控的.


PS:注意这里"auth"参数处实际上是$pre.$var是前缀yx_与auth的字符链接.

在已知了$auth是Cookie的情况下,我们再去查找使用的地方,发现了一处调用,这里使用了$auth变量,并且使用了model类的find()方法,再次进行查找,发现model类实际上是cpModel类的对象,使用model的find()方法,实际上就是调用了,cpModel类的find()方法,再去查找,发现这里出现了对于数据库的操作了,并且对于参数没有任何的过滤,直接就被拼接到了sql语句上面



从最开始的model()->find()我们可以发现这里传入的查询参数为id,因此sql注入点在id这里下面来构造exp

exp




由前面Cookie构成可以知道第一个数字就是id值,因此构造恶意id值为:

123'union select username,password from yx_admin#\t2\ttest\ttest\127.0.0.1


再使用cp_encode()进行加密,记得加密钥,最后在下面这个地方就可以拿到admin账号了
PS:
1.试验了很久似乎生成的cookie有一定成功率....
2.务必记得将生成yx_auth进行一次url编码

未完待续....
立个flag,每周更一篇代码审计激励一下自己233333

评论区(暂无评论)

这里空空如也,快来评论吧~

我要评论