某.NET程序文件写入漏洞挖掘分析

alyssa

免责声明
本文仅用于技术讨论与学习，利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，文章作者及本公众号团队不为此承担任何责任。

文章正文
前段时间看到公开了一个漏洞payload很奇怪，正好有空就分析了一下，也是第一次接触了.net的代码审计，一通分析下来，发现和审计java和php的思路是一样的...

前段时间看到公开了一个漏洞payload很奇怪，正好有空就分析了一下，也是第一次接触了.net的代码审计，一通分析下来，发现和审计java和php的思路是一样的...

在拿到源码后，发现这个oa是用.net编写的，基本所有的预编译的ASP.NET的Web应用程序使用的.Net程序集（通常是DLLs）都默认放在bin文件下，这一点和java写的程序中将jar都放在WEB-INF/lib中类似。.NET的DLL和Java的JAR都是用于打包和分发代码的文件格式。.NET的DLL是用于.NET Framework的动态链接库，而Java的JAR是用于Java平台的Java归档文件。

通常反编译.net的工具dnSpy, ILSpy等，但是由于ILSpy一直在维护更新，大部分人都偏向于使用这个，虽然dnSpy工具以及在2020年已经归档，但是在github通过dnspy forknly搜索到仍有非官方的爱好者对该工具进行维护，例如项目地址:dnSpy。

0x01 路由分析
首先查看Global.asax，他 是 ASP.NET 应用程序中的一个文件，它作为处理应用程序级事件和自定义应用程序行为的中心位置。通常被称为全局应用程序类。其中的Inherits中定义了定义供页继承的代码隐藏类


然后再dnSpy中搜索这个类目（最好打开全词匹配排除其他干扰项），然后在Application\_Start中定义了在应用程序启动时运行的代码


通过WebApiConfig.Register可以看到这里定义了通过api访问的路由，定义了包含控制器和方法

在 ASP.NET Web API 中，*控制器*是处理 HTTP 请求的类。控制器的公共方法称为*操作方法*或简称为*action*。当 Web API 框架收到请求时，它将请求路由到操作。


然后在WebApi.Areas.Api.Controllers命名空间中寻找到所有控制器和方法


然后在WebApi.Areas.Api.Controllers命名空间中寻找到所有控制器和方法

0x02 漏洞分析
首先查看payload

1. <p>POST /api/files/UploadFile HTTP/1.1</p><p>Host: your-ip</p><p>Accept-Encoding: gzip</p><p>User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_14\_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15</p><p>Content-Type: application/x-www-form-urlencoded</p><p>Content-Length: 1926</p><p>
   
2. </p><p>token=zxh&FileName=/../../manager/a.aspx&pathType=1&fs=[60,37,64,...]</p>

复制代码

通过路由/api/files/UploadFile锁定WebApi.Areas.Api.Controllers.filesController.UploadFile方法


在这个方法中接受四个参数，分别为token,fs,FileName,pathType。

首先会经过base.IsAuthorityCheck()进行鉴权


这里的byValue通过参数token获得，并且这里判断的内容直接被硬编码，所以直接token=zxh即可return new UserInfo();

接着返回UploadFile方法看fs

1. fs = JsonConvert.DeserializeObject<byte[]>(base.getByValue("fs"));

复制代码

JsonConvert.DeserializeObject<byte[]> 是使用 Json.NET 库（Newtonsoft.Json）中的 JsonConvert 类来将 JSON 字符串反序列化为 byte[] 数组的过程。所以这里只需要传入一个数组就可以了


因在在最后的SingleBase<fileServices>.Instance.UploadFile(fs, FileName, pathType)中

会直接将byte类型直接通过WriterTo写入，所以可以用python生成一个webshell的字节数据

1. <p>webshell = '<%now()%>'</p><p>print(str([ord(x) for x in webshell]).replace(' ', ''))</p>

复制代码

然后在看写入的路径


写入的路径是通过传入的pathType决定的，在GetFolderPathByType中定义了pathType的值对应的路径


在web.config中定义了各个值对应的路径，但是程序实在manage里，如果上传到这些目录也无法访问到


所以这里的FileName需要通过路径穿越到web目录。最后memoryStream.WriteTo(fileStream);将webshell写入


0x03 more
1、任意文件写入
在分析这个漏洞的时候，发现在这个控制器下还有四个类似上传方法


这里找到一处UploadFile2，这里获取路径的方式是通过pathType控制，但是多了两个参数startPoint和dataSize


这里会判断startPoint是否为0，如果0就直接写入文件，如果不为0，则需要被写入的文件存在，且startPoint的值必须为被写入文件的长度，然后通过append追加的方式写入，然后datasize是写入的位数，需要与写入文件的字符个数相同。


payload就不放了，能看懂的人自然能构建出来，后面的UploadBillFile2原理也是一样的，只不过是上传的路径变了，依然可以利用文件名进行目录穿梭上传到web目录下。


接着看下一处，但是这里鸡肋，因为这里的路径是通过Path.GetTempPath()获取的，也就是说只能上传到%TMP%目录下，但依然可以路径穿越到启动目录上传木马等。

2、任意文件读取

同样在files控制器中，我们发现了很多与下载相关的接口，并且都是通过硬编码进行鉴权的。


例如这个接口，获取两个参数requestFileName和pathType


pathType同样是选择不同的路径，可以用requestFileName进行路径穿越读到我们想要的文件

payload:

1. <p>POST /api/files/DownloadFile HTTP/1.1</p><p>
   
2. </p><p>token=zxh&requestFileName=../../manager/web.config&pathType=1</p>

复制代码

文章来源：https://forum.butian.net/share/2776