说明
该文章来源于同事lu2ker转载至此处,更多文章可参考:https://github.com/lu2ker/
文章目录
- 说明
 - 0x00 测试代码做了什么?
 - 0x01 分析调用
 - 0x02 漏洞点的发现、构造、利用
 - 0x03 总结
 
Time:9-3
影响版本:ThinkPHP=5.0.10
Payload:
/public/index.php/index/index?username[0]=not like&username[1][0]=&username[1][1]=&username[2]=) union select 1,user()--+
 
这是一篇由已知漏洞寻找利用过程的文章,跟着**参考链接学习分析,这次重点关注可控参数的处理、传递**,所以废话较多。以下是收获记录。
0x00 测试代码做了什么?
<?php
namespace app\index\controller;
class Index
{
    public function index()
    {
        $username = request()->get('username/a');
        $result = db('users')->where(['username' => $username])->select();
        var_dump($result);
    }
}
//分析时用的paylaod:/public/index.php/index/index?username[0]=1&username[1]=2
 
与上次不同,这次是先调用where方法处理$username再调用select方法进行查询,即程序构造的SQL语句应该是select * from users where 可控数据。
0x01 分析调用
①按照调用顺序先来分析一下where方法:
thinkphp/library/think/db/Query.php

937行的函数返回一个包含函数参数列表的数组,938行的函数将数组开头的单元移出数组,这里调用where的时候没有指定$op和$condition,且这两个参数默认为null,所以这两行处理完之后$param就是个空数组了。
939行调用了parseWhereExp方法且没有返回值,是直接通过$this指针调用本类方法,且这段函数最后也是返回了$this指针,所以要着重分析parseWhereExp方法,其中$field参数是可控的['username'=>$username]
跟进parseWhereExp方法,注意到其中1168行是即将要进入的分支代码。

着重看一下该分支的代码:

将$field赋值到$where,下面有段判断
    
     
      
       
        w
       
       
        h
       
       
        e
       
       
        r
       
       
        e
       
       
        是否为空的分支待会儿看,这里就是简单的给
       
       
        ‘
       
      
      
       where是否为空的分支待会儿看,这里就是简单的给`
      
     
    where是否为空的分支待会儿看,这里就是简单的给‘this->options`赋一些值。下面的一些elseif都不会进去就不用看了,来到1200行的if:

依然是简单的给$this->options加元素、赋值,这里之后where就结束了,且
    
     
      
       
        t
       
       
        h
       
       
        i
       
       
        s
       
       
        −
       
       
        >
       
       
        o
       
       
        p
       
       
        t
       
       
        i
       
       
        o
       
       
        n
       
       
        s
       
       
        中有我们可控的值,主要关注
       
       
        ‘
       
      
      
       this->options中有我们可控的值,主要关注`
      
     
    this−>options中有我们可控的值,主要关注‘this->options[‘where’][‘AND’]的值,就是最开始的 $username`。
②接下来再分析一下select方法:
因为where方法返回的是$this,再调用的select方法也是Query这个类的,来到2277行,这里将部分代码折叠起来了,因为只需要看看判断条件就知道会执行哪段代码。

看到2306行,注释是生成SQL语句,且和上次审计一样都是调用的builder的方法,有了经验这里就自然而然知道代码在Builder.php,不过这次重点关注传参,$options 源于2286行,那么先去看看parseExpress这个函数。


先看返回值能知道这个函数是对$options做了一些处理,而$options源于2701行的$this->options,再看2708行的if块,也不会进入。纵观整个函数的作用差不多就是把一些数据库的操作关键字加入到$options数组中,应该之后有可能用。此时,返回的
    
     
      
       
        o
       
       
        p
       
       
        t
       
       
        i
       
       
        o
       
       
        n
       
       
        s
       
       
        中
       
       
        ‘
       
      
      
       options中`
      
     
    options中‘options[‘where’][‘AND’]的值依然没有变化。返回继续看select方法(往上数第三个图),进入**2306行**
    
     
      
       
        t
       
       
        h
       
       
        i
       
       
        s
       
       
        −
       
       
        >
       
       
        b
       
       
        u
       
       
        i
       
       
        l
       
       
        d
       
       
        e
       
       
        r
       
       
        −
       
       
        >
       
       
        s
       
       
        e
       
       
        l
       
       
        e
       
       
        c
       
       
        t
       
       
        (
       
      
      
       this->builder->select(
      
     
    this−>builder−>select(options)`
thinkphp/library/think/db/Builder.php

因为关注的变量一直是$options['where'],遂跟进parseWhere:

225行if的条件同样不满足(在它上一行下个断点看一下当时$options的值就知道了),执行224行完就会return WHERE $whereStr。时刻关注参数,此时的$where就是$options['where'],即我们可控。进入buileWhere
来到243行,大致扫一下该函数能看到多处拼接,说明越来越接近漏洞点。



从253行初始化$whereStr开始看起,255行拆分$where,其中$key应该是AND,而$val则是$username,然后257行再次将$val拆分成$field和$value,$field应该是['username' => $username]中的'username'也就是users表的字段名,$value则就是$username即测试代码中$username = request()->get('username/a');的这个,即可控值,所以接下来重点关注$value的处理。
258和266行的判断暂时均不满足,就先直接看282的最后一个else分支,其调用了parseWhereItem,并传入了我们关心的$value,赋值给$str[],且$str在289行会拼接到$whereStr之后直接return,跟进它一探究竟。
0x02 漏洞点的发现、构造、利用
依然是thinkphp/library/think/db/Builder.php

305行用list()将$val分割,list()的作用是把数组中的值赋给一组变量,那么按照第一步中的测试payload
/public/index.php/index/index?username[0]=1&username[1]=2
 
    
     
      
       
        e
       
       
        x
       
       
        p
       
       
        的值为
       
       
        1
       
       
        ,
       
      
      
       exp的值为1,
      
     
    exp的值为1,value的值为2,先暂且往下看,308行的if肯定不会进去了,来到324行

这里需要知道一下$this->exp的值,在该文件的25行有定义
protected $exp = ['eq' => '=', 'neq' => '<>', 'gt' => '>', 'egt' => '>=', 'lt' => '<', 'elt' => '<=', 'notlike' => 'NOT LIKE', 'not like' => 'NOT LIKE', 'like' => 'LIKE', 'in' => 'IN', 'exp' => 'EXP', 'notin' => 'NOT IN', 'not in' => 'NOT IN', 'between' => 'BETWEEN', 'not between' => 'NOT BETWEEN', 'notbetween' => 'NOT BETWEEN', 'exists' => 'EXISTS', 'notexists' => 'NOT EXISTS', 'not exists' => 'NOT EXISTS', 'null' => 'NULL', 'notnull' => 'NOT NULL', 'not null' => 'NOT NULL', '> time' => '> TIME', '< time' => '< TIME', '>= time' => '>= TIME', '<= time' => '<= TIME', 'between time' => 'BETWEEN TIME', 'not between time' => 'NOT BETWEEN TIME', 'notbetween time' => 'NOT BETWEEN TIME'];
 
这样的话应该是程序允许SQL语句中可存在的逻辑关键字,类似于白名单这种。根据if块的逻辑,这里我们应该让$exp的值是在白名单中存在的,不然就直接抛出错误了。可以暂时更改一下测试paylaod,构造username[0]=白名单中的键名绕过这段代码。
/public/index.php/index/index?username[0]=eq&username[1]=2
 
再往下看:

这里is_scalar()函数不知道什么意思,查手册得知

说明此时的payload是会进入这个分支进行处理的,下断点看看最后会处理成什么样子:
 
可以看到,$value的值已经没有payload中的’2’了,意味着可控的值会被这段代码覆盖替换掉。为了保留可控值,这段代码也不能进入,所以$value不能是int、float、string、bool等类型,而只能是array、object、resource等类型,所以再次修改payload,让$value成为一个数组型变量:
/public/index.php/index/index?username[0]=eq&username[1][0]=2
 
再次下断点执行可以看到已经绕过了这段代码的处理,直接来到349行,(注意357行)。

因为之前的$exp传入的是eq也就是“=”,所以会进入350的if,依然是在它处理后的位置下断点看看会把可控值处理成什么样子,这里直接在350行处下断点。

可以看到要经过parseValue的处理后才会给$whereStr赋值,步进,return处下断点:

这里看到值还是存在的,但是再一次步进就会跳到错误处理程序,大佬的文章并没有分析这里的流程,不过我猜估计是数组的问题导致拼接时候的错误。总之这段代码也是不能进去的,再次修改paylaod:
/public/index.php/index/index?username[0]=not like&username[1][0]=2
 
(修改为not like是因为之后的357行有这个判断)

这段代码与刚刚的第一个if不同的是会把$valueforeach一下再带入parseValue,这样就不会有数组变量直接拼接的错误了,同事,注意到363行会用到
    
     
      
       
        v
       
       
        a
       
       
        l
       
       
        [
       
       
        2
       
       
        ]
       
       
        ,根据之前的分析
       
      
      
       val[2],根据之前的分析
      
     
    val[2],根据之前的分析val就是传入的
    
     
      
       
        u
       
       
        s
       
       
        e
       
       
        r
       
       
        n
       
       
        a
       
       
        m
       
       
        e
       
       
        ,所以这里
       
       
        p
       
       
        a
       
       
        y
       
       
        l
       
       
        o
       
       
        a
       
       
        d
       
       
        还得加一个参数
       
      
      
       username,所以这里payload还得加一个参数
      
     
    username,所以这里payload还得加一个参数username[2]
/public/index.php/index/index?username[0]=not like&username[1][0]=2&username[2]=1
 
然后得到$whereStr,下断点看看这里$whereStr变成什么样儿了:

可以看到’2’已经完美拼接进去。尝试闭合括号,注释掉后面多余的字符,构造payload:
/public/index.php/index/index?username[0]=not like&username[1][0]=) union select 1,user()--+&username[2]=1
 

可以看到没有过滤的直接拼接自定义SQL语句,但是放行后页面回显的却是empty,意思是查询没结果。先完整走一遍代码看看最后生成的SQL是什么样子。在thinkphp/library/think/db/Query.php的2308行下断点:

可以看到这里的单引号没有闭合导致user()没有当作函数执行,尝试加单引号闭合果不其然被转义了:
 
这样的话就得找到一种能够利用程序本身闭合单引号的办法,好好分析:

361行的
$array[] = $key . ' ' . $exp . ' ' . $this->parseValue($item, $field);
 
可以写成
$array[] = 'username not like ' . $this->parseValue($item, $field);
 
且$value有几个元素就生成几个这样的字符串。
突然发现363行的$logic=1刚才并没有被拼接到字符串中

这就比较奇怪了,好好看一看implode的用法:

看phpstorm的提示好像要求' ' . strtoupper($logic) . ' '这是个array???
不过既然第一个参数可以为数组,那就先给 a r r a y 再加一个元素,也就是再加一个 ‘ array再加一个元素,也就是再加一个` array再加一个元素,也就是再加一个‘username[1][1]`:
/public/index.php/index/index?username[0]=not like&username[1][0]=) union select 1,user()--+&username[1][1]=1&username[2]=2
 

可以看到,'2'也就是username[2]分割了array[0]和array[1],且array的元素都是会被单引号包裹起来的,所以攻击函数就不能放在array里,那么可以尝试一下,用union select 1,user()--+作为分割符 $logic,也就是将username[2]=union select 1,user()--+:
/public/index.php/index/index?username[0]=not like&username[1][0]=1&username[1][1]=2&username[2]=union select 1,user()--+
 

可以看到union select 1,user()--+没有被单引号包裹,再闭合一下括号就完美了:
/public/index.php/index/index?username[0]=not like&username[1][0]=1&username[1][1]=2&username[2]=) union select 1,user()--+
 

即(username NOT LIKE '1' ) UNION SELECT 1,USER()-- username NOT LIKE '2')
即(username NOT LIKE '1' ) UNION SELECT 1,USER()
再看一下最后生成的SQL语句:
 
SELECT * FROM users WHERE (username NOT LIKE '1' ) UNION SELECT 1,USER()-- username NOT LIKE '2') 
完美了,结束。

0x03 总结
总感觉这个过程还有好多地方疏忽掉了,依然只是由答案推过程的行为。
因为欠缺的经验还是太多,所以文中可能废话也比较多,只是为了让自己更加理清逻辑。
关于not like可用是因为这个版本的tp在过滤的时候漏掉了带空格的not like这个在文中没有详细分析,比较不完美。
感谢七月火大佬的干货文章。



















