干货 | .NET 文件上传多个场景绕过预编译限制获取Shell

民富

0x01 背景

在攻防演练的这个大背景下，红蓝对抗也逐渐真正的提升到对抗这个层次，这不今天由dotNet安全矩阵星球圈友们组成的微信群里有位群友问起如何突破预编译拿webshell有什么方法，预编译已经够麻烦了，这位师傅还非常有挑战的加上了不考虑跨目录的情况下怎么获取webshell，借师傅这么有挑战的命题笔者系统性的介绍预编译几种不同场景下获取shell的手段，希望本文探讨的这些可行性路径以及达成目标使用的不同方法能在实战中有所帮助。



0x02困局

.NET站点发布时提供一项预编译的能力，可以提升站点运行处理的速度以及保护知识版权，采用了这种预编译模式后站点下的每个.NET文件的内容被标记为 "这是预编译工具生成的标记文件，不应删除!"，如果此时上传一个普通的aspx木马，访问后提示 "未预编译文件，因此不能请求该文件"，如下图所示，那么这种场景下如何通过文件上传漏洞获取WebShell呢？笔者想到了以下不同场景下的几种变通的方法，在正式介绍方法前首先回顾下预编译的原理。



0x03预编译原理

.NET下的编译方式大致可以分成两种方式，分别为动态编译和预编译。动态编译因为文件以源代码的形式放置于Web容器中，所以对于首次访问编译时需要消耗大量的资源，这样会严重降低Web应用的响应速度，另外代码内容是开放的，容易被篡改导致系统不安全或崩溃，从知识产权来看也不利于保护商业秘密。以上这两点动态编译的劣势也是开发者选择预编译的两种原因，预编译模式下将编译所有的.NET文件，当然HTML、图片、css等静态资源文件不包含在内，在预编译过程中编译器将创建的程序集存储于项目根目录下的Bin文件夹，另外也会同步到一个.NET特殊的目录 %SystemRoot%\http://Microsoft.NET\Framework\version\Temporary http://ASP.NET Files 文件夹下，Bin目录下会编译生成两类为文件，一类是扩展名为.compiled，该文件包含指向与该页相应的程序集名称；另一类文件是编译后的扩展名为.dll 的程序集文件。下面笔者分几个小节分别介绍预编译发布过程和生成的结果文件
3.1 编译可选项

创建.NET MVC项目后右击选择 发布，系统提供了文件夹、FTP、IIS、云发布等多种途径，笔者选择了传统的IIS发布，发布就绪后配置Release选项，打开预编译详细配置页面，默认情况下系统勾选了 "允许更新预编译站点"，这样的好处在于可以很轻松的修改代码，方便应急维护，但不好的方面就是不安全，未能达到保护软件知识版权的目的。如果不勾选“允许更新预编译站点”，项目下的所有aspx文件的内容都将被重写为 “这是预编译工具生成的标记文件，不应删除!”，而文件本身也只是个占位符。



除了图形化界面操作预编译之外，Visual Studio还提供了命令行下的可执行程序aspnet_compiler 预编译.NET项目，具体的命令释义如下
aspnet_compiler -v /Lib -p D:\Project\VisualStudio\Pre\WebForm\test D:\test -fixednames经过编译后项目文件夹中的所有.aspx, .ashx及App_Code中的.cs文件都会被编译成DLL文件，静态资源文件将原封不动的复制到目的文件夹里。
3.2 complied文件

.NET每一次编译都会生成很多具有.compiled扩展名的保留文件，这个文件本质上是一个XML文件，命名格式如下，其中

郑自琴

楼下的接上