漏洞挖掘

某次渗透测试过程中，发现这个系统，看起来就老的一批

![](/media/202611/49eecb73efa643a4b1c9a6c64fabb7c22301.png)

简单看看架构，框架是thinkphp

![图片](/media/202611/f1d52f59e44140b0a0d31f75ebbb4e658145.png)

直接先打一手nday

多用两个工具试试，有可能一个工具，poc不够全，测试的也不够准

![图片](/media/202611/1a530fdf8d824e9e81eb693a3aa0c1c69444.png)

![图片](/media/202611/dfe79e935ded4a66965da00369767fd96165.png)

也可以用afrog试试

![图片](/media/202611/edfa24c3ee7a4c3fa0927b8d56823d0c3537.png)

这里我试了，没有tp的nday

回归系统本身，雪瞳这里直接0接口

![图片](/media/202611/e9387b41aaa04a7788ec0b13c22a55c04299.png)

直接抓包看看登录接口

![图片](/media/202611/7b477e8951c44a90b458e32db6ed4fae7189.png)

这里可以看到这个图形验证码，是前端校验，只要输入正确之后

后面就不会有这个图形验证码的限制，所以可以直接爆破弱口令

这个图形验证码前端检测，如果是项目上的话，本身也可以水一个低危漏洞，更神奇的是，某些src竟然也收，哈哈

![图片](/media/202611/2a6078a7688c4262bb0ef7ddf9d6af453556.png)

我这里不爆破了，直接让AI搞，其他的一些图形验证码思路可以参考这个

![图片](/media/202611/15befb3e3e554a22b10826e8124476576464.png)

然后ai开始库库发力

![图片](/media/202611/295b0682877546adade0f0245924a9852479.png)

![图片](/media/202611/5d9b1bcdf5d047a698b2fd2e9cfc395b8329.png)

![图片](/media/202611/8f8b3a9bfdc149e0bb41413bddbb8fd22596.png)

几分钟后报告出来了，我们开始复现

![图片](/media/202611/d78722b09f6e4a57b1d73d96e3e0a0757987.png)

还是复现爽，复现几个危害高的，顺便看看他是怎么打的

ai打出来一个sql注入导致的登录绕过,其实这个我是试过的，可惜不太行

![图片](/media/202611/b1301cb0c7e14fe7aa823a998f3403631496.png)

![图片](/media/202611/d2b43b562297488b809f3c1b3e739e839691.png)

ai打出来的思路是

ThinkPHP 3.2.3 中因将用户可控的 account 参数以数组形式直接传入 where() 条件，攻击者通过 account\[0\]=exp&account\[1\]=or 1=1-- - 触发框架表达式查询分支，把任意 SQL 片段原样拼接进登录查询，从而注释掉口令校验实现免密登录（可登录管理员或指定 uid 用户），并借助 Debug 模式报错回显结合 extractvalue() 等报错注入外带数据库版本、账号、库名、表名及用户明文口令，形成「未授权 → 任意用户登录 → 全库数据泄露」的完整攻击链，属于可直接入侵系统的入口级 SQL 注入漏洞。

我们简单复现

![图片](/media/202611/4bf64520b64b41aa862c19165a9bcc278982.png)

首先正常抓包，然后把请求体，替换成这个，放包

```
account[0]=exp&account[1]=or+1=1--+-&password=x
```

![图片](/media/202611/5502b367047c484b93319395940c62a67816.png)

直接以管理员的身份进入后台

![图片](/media/202611/509c68a6c7a64a5483eb1e76016e7bdf9356.png)

![图片](/media/202611/4dc63c6844fc4afd8c5fd39d536315c78286.png)

问了一下ai，为啥登录框的万能密码，不可以直接干进去

解释是

输入框里直接打字打不进去——我补测了账号框和密码框的所有字符串型 payload（admin'、admin'#、密码框 x' or '1'='1、' or 1=1-- -），全部返回"用户名或密码错误"，无 SQL 报错。原因：这个注入点要求 account 参数以数组形式提交（account\[0\]=exp），普通表单永远只会发出 account=<字符串> 这种形式，字符串路径会被转义，而表单不可能产生数组参数——所以必须改参数结构，不是改输入内容。

这个框本身也有sql注入漏洞

![图片](/media/202611/8009bd190fdd4f08b3912ed5972584a09730.png)

继续深入测试，ai又发现

站点在静态资源目录下遗留了一整套第三方 jQuery 上传组件演示程序（路径 `/Lib/uploadFile/`，组件为 CreativeDream/php-uploader 0.2，目录内 `readme.txt` 自述出处），其中处理上传的 `/Lib/uploadFile/php/upload.php` 未做任何身份校验、也未限制文件扩展名，实测在完全不带 Cookie 的情况下以 multipart 字段 `files[]` 提交一个内容为 `<?php echo "SEC_TEST_RCE_EVIDENCE_9d31"; ?>` 的 PHP 文件即可上传成功，服务端响应会回显保存路径为 `../uploads/sec_test_rce2.p.php`（保存目录 `/Lib/uploadFile/uploads/` 可通过目录列表公开访问）；随后直接请求该文件 `GET /Lib/uploadFile/uploads/sec_test_rce2.p.php`，服务端返回体为 `SEC_TEST_RCE_EVIDENCE_9d31`（而非 PHP 源码文本），证明 Apache 的 PHP 处理器在 `/Lib/uploadFile/uploads/` 目录下真实执行了上传的 PHP 代码，即攻击者在无任何账号的情况下获得服务器端任意代码执行能力，实测完成后已通过同目录的 `remove_file.php` 将测试文件删除并验证（404）。该上传点同时允许任意扩展名与任意内容，实际影响等同直接获得服务器控制权（可写入任意 webshell、读取数据库配置、横向渗透内网）。

继续复现，我这里直接搞个phpinfo,不传马子了

![图片](/media/202611/bca272b78519474cbc93377ffcf863491911.png)

拼接路径进行访问，直接getshell，写报告，跑路跑路

![图片](/media/202611/e4690927885649d09eb2e54b6e64f77d7748.png)

太高效了，其实根本，不用手动测试，简单确认一下，这个站点的价值

如果有价值，直接ai梭哈就行，ai都干了，那我？？？

SQL到登录绕过再到后台