.Net framework DoS Vulnerability Reproduce and Analysis

This incident happened very unexpectedly. When I was trying reproducing another vulnerability, I naturally wanted to introduce a calculator to reproduce the experiment. However I forgot the file path of calc.exe, I had to open the tool everything to find it, but when I found that I had not to input all the complete word "calc.exe", everything suddenly collapsed. At first, I thought it was the occasional routine crash of Windows, but the crash appeared every time when I search "calc.exe" in everything.

First, simply record the Windows-related environment at the time, Windows 10 Pro Insider Preview version, Build.17025.rs_prerelease.171020-1626.

Then start the various Fuzz data in everything to find out why the problem exited.

Test the string "calc" and found that there was no crash;

Test the string "calc." and found that there was a crash;

Test the string "lc.exe" and find that it actually needed to be entered completely then the crash would be triggered;

In the above three testing strings, I found that every time I test, I will see the icon of calc.exe in the search box of everything. I started to suspect the problem of the icon figure. Is it that everything has an infinite loop error when rendering such icon? This kind of rendering led to the collapse of the loophole.

So I started to reproduce the problem, I typed "calc" in the search box, then use the mouse to click one of the icons and use the arrow key to pass the highlight to the exact calc.exe icon. And as I expected crash appeared again. I also recorded a small video for this test.

So, I started to find the icon of calc.exe and eventually found it in a file which had a name "Windows.old". The directory was very deep. The file path is 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。

To test whether the icon triggers the crash, I copy the exe file to the path of desktop and rename it specially. Then I use everything to test the problem, however, this time crash did not come to me, so I exclude the problem of rendering.

In the next step, I use explorer.exe to test the crash problem, using the following fuzz data.

Search from the path C:\Windows.old\WINDOWS\SoftwareDistribution\Download\, crash!

Search from the path C:\Windows.old\WINDOWS\SoftwareDistribution\Download\87e4cd6ab72e8eecadd80c62e51252d5\, crash!

Search from the path C:\Windows.old\WINDOWS\SoftwareDistribution\Download\87e4cd6ab72e8eecadd80c62e51252d5\amd64_Microsoft-Windows-Client-Features-Package~~AMD64~~10.0.17025.1000\, crash missed!

Here is the whole testing video.

From the above test, it can be found that the crash problem occurred at the position of searching in the directory and the nine of ten in the directory of /amd64_Microsoft-Windows-Client-Features-Package~~AMD64~~10.0.17025.1000/. I had a quick view in this file, there were a bunch of files in it. What needs to mention is that even every file name had a character "~".

Once refer the character “~", every researcher will come up to a specific vulnerability related to Windows, IIS shortname vulnerability. Well, its real name is IIS tilde character vulnerability rather than shortname vulnerability. Some of the POC or tools use shortname as the keyword so that no many person know the exact real name. From most of the articles on the Internet, all of them buried much efforts to research how it has impacts on leakage of file in IIS website. This IIS tilde vulnerability also has another impact of crashing .Net Framework, which has not to rise much attention of researchers.

In a paper published by Soroush Dalilide (irsdl), Microsoft IIS tilde character “~” Vulnerability/Feature – Short File/Folder Name Disclosure. The analysis of this DoS vulnerability can be seen in it.

https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf

The paper pointed that the researcher found that if the filename contained character "~1", the FS (File System) will traverse the root directory when using Filemon to monitor the active status of FS. Irsdl analyzed the 3 key points of this problem.

1. The first search has an evident visual effect because of cache;
2. If there are several illegal filenames containing character "~1" in the request, FS would start from the root directory to the deepest directory and then return from the deepest directory to the root directory. For example, when accessing the URL like http://example.com/fake~1/~1/~1/~1/~1/~1/~1/~1/~1/~1/~1.aspx, the active action of FS record shows in the following figure.
3. If filename and folder name both have the character "~1", the request will be case sensitive. It means it would search twice in upper case and lower case because of Windows platform has a feature that it cannot be sensitive to the case occasions. This feature is used to recognize the target server type.

Because of the feature, Windows does not allow there are two files each has the same name in lower case. And it may trigger case sensitive DoS, another application layer DoS. After analyzing the problem I checked out the abnormal file and found a lot of files and folders which have the key character "~" and several upper & lower letters.

TIPS

Application DoS related to case sensitive mostly happens in the URL like this, /img/ddjdsjJKLPkfdsljgeaertDjFS.jpg.

In the following paper, irsdl gave out his testing form about resource traversing in Windows based on 2008 R2, IIS 7.5, (latest patch – June 2012), and .Net framework 4.0.30319. I checked my own version of .Net framework. Exactly the same! So that the crash happened!

Due to the update halt of Filemon tool after Vista, I could only use Procmon to do the monitor of the process in FS.

Add two filter policies into Procmon.

Process Name is explorer.exe then Include;

Operation is ReadFile then Include;

The path is C:\Users\houkc\Desktop\testDirectory\ then Include；

Irsdl post a POC example on http://exploit-db.com.

Simply analyze the POC.

The main body calls the target variable, it asks users to input the deepest number of the directory and the number of requests.

Go to the definition of the function, except for the last part which checks the active status of the target server via function isServerAlive() and some other functions, the main function is testTheTarget().

POC defines a global variable tempValue and output a string whose length is about 4001 composed by several characters "A" in a loop way.

Then, a 400-length A-letter long string is processed to achieve the final purpose that converts the search URL request payload with the keyword "~" and splice with an arbitrary number in the range of 1~9(for example, "~2").

When the attack started formally, it used a similar img tag, which is often used for XSS DDoS attacks, and then the POC analyzes the accessible of the site by the time-consuming reading of the response. But why is it here called "similar img tag", because here is a use of createElement() experimental usage, a new tag custom method similar to customElement, followed by a number to determine the first few requests. Irsdl defines a time rule to determine the accessible of the website, msec <100 *requestNumber + 5000, we can also modify this time rule to judge.

Going back to the initial problem of everything tool, why does everything crash when calc.exe appears on the screen? I think this may be the reason for its own working logic. Because the function itself of searching in the disk is very resource-consuming, it may write the file resource as a class key-value relationship only to its own database, and it will only be read. To call the search function of Windows Explorer, the phenomenon of "Desktop Rendering DoS" appears.