.Net framework DoS的本地复现和分析
这件事其实发生得非常意外，几天前在研究Windows后缀名黑科技的时候，想要验证一下某个代码执行的小漏洞时，自然就想引入弹计算器来验证，可是我又忘了calc.exe文件的位置，只好开出神器everthing找一波，可是发现我还没输完整“calc.exe”这串字符时，我的everything突然就奔溃了。刚开始以为就是Windows的偶尔的例行奔溃，可是当我每次输入“calc.exe”时，而且是还没输完整的时候，鼠标就开始转圈圈，接着就奔溃了。
我眉头一皱，发现事情并不简单。
先简单记录一下当时的Windows相关环境，当时使用的是Windows 10 Pro Insider Preview版本，Build.17025.rs_prerelease.171020-1626。
接着开始在everythin各种Fuzz数据，以定位到底是哪个位置出了问题。
测试字符串“calc”，发现没有出现奔溃；
测试字符串"calc."，发现出现了奔溃；
测试字符串“lc.exe”，发现必须要输入完整才会引发奔溃；
在上述三个字符串测试中，我发现每次测试的时候，都一定会在everything的搜索框体中看到calc.exe的ico图标。我开始怀疑ico图标的问题，难道说是everything在渲染该图标时出现了死循环错误？这种渲染导致奔溃的漏洞上一次听说还是那个“微信15个。。。导致奔溃”的漏洞。
于是我开始去验证这个问题，我在搜索框内输入了"calc"，然后用方向键的向下键挨个列下去，果然列到了有ico图标的那一列开始奔溃。我还为这次测试录了一个小视频。
于是我开始去找这个ico图标的calc.exe文件，发现它是在Windows.old文件夹下，目录级很深，位置为C:\Windows.old\WINDOWS\SoftwareDistribution\Download\87e4cd6ab72e8eecadd80c62e51252d5\amd64_Microsoft-Windows-Client-Features-Package~~AMD64~~10.0.17025.1000\amd64_microsoft-windows-calc_31bf3856ad364e35_10.0.17025.1000_none_3584ffefbae46338\calc.exe。
为了测试是否是该图标引起的奔溃，我把该文件复制到桌面，重命名了一个唯一的文件名，用everything进行搜索测试，发现并没有出现奔溃，排除了图标渲染问题。
于是我在资源管理器中直接使用其自带的搜索功能去搜索测试，Fuzz了如下的几种测试。
C:\Windows.old\WINDOWS\SoftwareDistribution\Download\开始搜索，文件管理器奔溃；
C:\Windows.old\WINDOWS\SoftwareDistribution\Download\87e4cd6ab72e8eecadd80c62e51252d5\开始搜索，文件管理器奔溃；
C:\Windows.old\WINDOWS\SoftwareDistribution\Download\87e4cd6ab72e8eecadd80c62e51252d5\amd64_Microsoft-Windows-Client-Features-Package~~AMD64~~10.0.17025.1000\开始搜索，未发生奔溃；
针对资源管理器的搜索测试，我也录了一个小视频。
也就是说奔溃问题存在于目录级的搜索，且大概率为/amd64_Microsoft-Windows-Client-Features-Package~~AMD64~~10.0.17025.1000/这级目录存在问题。我大概看了一下这级目录下存在非常多的文件夹，且几乎每个文件夹的命名中都存在至少一个“~”。
看到“~”，自然而然就能联想到一个Windows相关的漏洞，IIS短文件名漏洞，这个漏洞有个字面意思的英文名叫IIS Shortname，一些常用工具和POC都沿用了这个英文名，所以你在Google中搜这个名字大都是搜到一些工具，但是看不到很多的research paper，其实实际上官方并不去使用这个名字，而是使用了从实际漏洞点出发的一个命名，IIS tilde character vulnerability。搜了网上的大多数文章，其实都只是详细描述了这个漏洞引起的IIS文件名泄露。大众们忽略了另一危害结果，就是引起.Net Framework的奔溃。
在Soroush Dalilide（irsdl）关于这个漏洞的一份paper（Microsoft IIS tilde character “~” Vulnerability/Feature – Short File/Folder Name Disclosure）中可以看到关于这个dos攻击的详细分析。
https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf
研究报告中指出，研究者用Filemon监视FS（File System）的活动状态时，发现，当在文件夹搜索中带上关键词“~1”时，FS会遍历其根目录。且irsdl提出了3个影响这个攻击的关键因素。
1、第一次搜索时效果会非常明显（缓存的缘故）；
2、如果在一次请求中有多个不合法的文件名命名请求且都带上了“~1”关键词的话会从第一级目录便利请求到最深的目录，然后再从最深目录回归便利到第一级目录，也不知道Windows的研发是怎么想的。例如请求http://example.com/fake~1/~1/~1/~1/~1/~1/~1/~1/~1/~1/~1.aspx这个url时，监控FS的活动为如下。
3、如果一次搜索请求中，文件名或文件夹名中同时包含大小写字母且带上了“~1”关键词时，请求会分辨用全大写和全小写遍历两次文件系统，这是由于Windows大小写不敏感的特性导致，这个特性被大家熟知用来判断Windows和Linux服务器，但很少有人去研究其搜索遍历的具体过程。
因为Windows的特性，不允许同一级目录下存在命名小写后同名属性的文件（文件或文件夹）。根据这个特性可能会引发大小写非敏感导致的DoS，是不是想到了一个类似的应用层拒绝服务供给？Web ReDoS。然后再去观察我那个出问题的文件目录，果然同一级目录下存在很多命名中带有“~”关键字符和大小写字母的文件夹。
至于如果你要问哪个模式的url最容易受到攻击，我只想反问一句，你难道没见过一长串跟乱码似的图片命名吗？就是那种大小写夹杂的自动生成的网页图片，/img/ddjdsjJKLPkfdsljgeaertDjFS.jgp。
回到主题，paper中接下去，irsdl给出了他针对资源管理器的资源遍历测试结果的一份测试表格，这份测试表格的环境是基于Windows 2008 R2, IIS 7.5
(latest patch – June 2012), and .Net framework 4.0.30319。我看了看我自己的系统的.Net framework版本，居然和irsdl的测试环境一模一样，也就是我的系统同样存在了这个漏洞。
这边由于Filemon工具在Vista之后已经停用了，所以现在只能用Procmon做进程监视分析FS的活动调用状态。
监视的时候需要添加两个Filter规则。
Process Name is explorer.exe then Include；
Operation is ReadFile then Include；
Path is C:\Users\houkc\Desktop\testDirectory\ then Include；
试一试“~1”。
而且这哥们还在exploit-db上给出了一个POC，大致界面是这个样子。
简单分析一下POC源码。
先看一下主体调用函数部分，实际就是调用JavaScript函数方法。从description也可以看出来就是调用了target，然后输入最大的目录深度和请求次数。
再看一下函数定义，除去最后校验网站服务是否处于存活状态的isServerAlive()和几个辅助方法以外，关键的方法定义也就是testTheTarget()这个关键的方法。
首先看一个全局定义，定义一个临时值tempValue，循环输出长度为4001的A字母长字符串。
然后对这4001长度的个A字母长字符串做一个处理，最终目的是转化成带有关键词“~”加上一个1-9任意数字（例如“~2”）的的搜索url请求payload。我这边直接加入了console.log()输出，更加直白。
正式开始攻击的时候，则是利用了一个类img标签，这是一个经常被用来做XSS DDoS攻击利用的标签，然后通过对reponse的耗时读取来分析网站的存活性。但是为什么这里说是“类img标签”，因为这里用了一个createElement()的实验属性用法，一个类似customElement的新标签自定义方法，跟上一个数字来判断第几次发送请求。irsdl定义了一个时间规则来判断网站存活性，msec<100*requestNumber+5000，我们也可以修改这个时间规则进行判断。
再回到最初始的现象，everything为什么会在calc.exe出现在屏幕时才会奔溃呢？我觉得这边可能是everything自身工作逻辑的缘故，由于everything本身功能就很消耗资源，它可能把文件资源作为一个类键值关系只是写入了自身的数据库，真的要去读取时才会去调用Windows资源管理器的搜索功能，所以才出现“桌面渲染DoS”的现象。