I found a vulnerability in Microsoft IIS when I was searching about a method to execute an ASP file when we can only upload a JPG file.
The result was too simple, but interesting! I need only a semicolon between the “.asp” and the “.jpg” to execute an ASP file. So, the answer was “myfilename.asp;,jpg”. I have written some information about this vulnerability in:
http://soroush.secproject.com/downloadable/iis-semicolon-report.pdf
I’ll try to update this PDF file if there was a need to add or change some information.
Description of this vulnerability from Secunia.com is:
Description:
Soroush Dalili has discovered a vulnerability in Microsoft Internet Information Services (IIS), which can be exploited by malicious people to potentially bypass certain security restrictions and compromise a vulnerable system.The vulnerability is caused due to the web server incorrectly executing e.g. ASP code included in a file having multiple extensions separated by “;”, only one internal extension being equal to “.asp” (e.g. “file.asp;.jpg”). This can be exploited to potentially upload and execute arbitrary ASP code via a third-party application using file extensions to restrict uploaded file types.
The vulnerability is confirmed on a fully patched Windows Server 2003 R2 SP2 running Microsoft IIS version 6. Other versions may also be affected.
There are also several websites which wrote about this weakness:
1. Secunia Advisory: Microsoft IIS ASP Multiple Extensions Security Bypass
2. Securityfocus: Microsoft IIS Malformed Local Filename Security Bypass Vulnerability
3. The Register: Microsoft IIS vuln leaves users open to remote attack
4. VUPEN Security: Microsoft IIS File Extension Processing Security Bypass Vulnerability
5. Securitytracker: Microsoft Internet Information Services (IIS) Filename Extension Parsing Flaw May Let Users Bypass Security Controls
Hello,
I read in your document :
“Finding Date: April 2008
Report Date: Dec. 2009”
Why wait so long before reporting ?
Thanks for the question.
Unfortunately, I was too busy at that time. And, I wanted to publish it after getting my MSc. degree ;)
Thank you for the answer and good work !
Hi Soroush,
This error you reported on is a non-issue. Even with the basic default configuration in place, this does not produce an executable attack. It would require a very specific set of configuration errors (where most of the defaults were changed) to create an executable attack such as,
Enabling execute on the upload folder,
Putting the uploaded files in the web tree itself,
The web application not performing any file type validation,
Disabling built in input validation,
The application not performing any input validation itself.
While it is possible to create a scenario that would be exploitable, it would take a conscious effort to do so. Admittedly, if this was a web site running on IIS 5, built in the late 1990’s you would be likely to find just such conditions, but any modern web site would be unlikely to be vulnerable to this unless the creator of the site did some very bad things intentionally. (albeit unknowingly)
If you tried this on one of your sites and it worked, you might want to re-visit basic security practices and fix up your code.
Thanks for sharing your findings.
Hello, Thanks for your comment. I think you did not understand the purpose of this vulnerability. Although this vulnerability is because of IIS, its effect is on the web applications. As I had written in the PDF file: “Many file uploaders protect the system by checking only the last section of the filename as its extension. And by using this vulnerability, an attacker can bypass this protection and upload a dangerous executable file on the server.”. It is obvious that there are many files which should be accessible by using the web URL directly, such as the images, flash files, java applets, and so on. The cost of putting these files out of the web folder directory and using a script to download them indirectly is not reasonable in most cases (Except for non-free materials).
If you do a real penetration testing against some websites, you will realize the value of this vulnerability. You can find many of these web applications which are exploitable by using this vulnerability. For example, I want to refer to the DNN (Dot Net Nuke) application vulnerability in which an attacker could upload an image, a flash, or a document file on the system; and, by mixing with this vulnerability, an attacker could get a web-shell from the system. As another example, in some cases although you can gain access to the admin panel of the website, you can only upload some images. Now, perhaps you can bypass it and upload a web-shell to read all the source codes, download some important data, and so on.
Those uploaders which checked the file’s header and source code of the file are already bypassed. And, by using this vulnerability, those checked the files’ extensions are also bypassed.
You can read the “Fast Solution/Recommendation” section in the PDF file as the possible solutions for this vulnerability. Those who performed these solutions are secured not only against this weakness, but also against the entire file uploading vulnerabilities.
Well, you’ve noticed MS final(?) statement on the issue already, did you?
MSRC Blog entry:
We’ve completed our investigation into the claims that came up over the holiday of a possible vulnerability in IIS and found that there is no vulnerability in IIS.[…]
for the scenario to work, the IIS server must already be configured to allow both “write” and “execute” privileges on the same directory. This is not the default configuration for IIS and is contrary to all of our published best practices. Quite simply, an IIS server configured in this manner is inherently vulnerable to attack
And IIS Blog entry:
The issue in question affects only IIS 6 (Windows Server 2003) and arises when you send a URL with a semi-colon in it. IIS 6 uses the path before the semi-colon to determine the script handler for it.[…]
In summary, there is a functionality issue here, but there is no security issue unless you already had a poorly configured server to begin with.
Please read: http://soroush.secproject.com/blog/2010/01/microsoft-contradiction/
Hi Soroush.
Nice finding! I’ve checked out your advisory and also comments you’ve wrote following it but there are still some shady points remaining unclear to me.
The nature of the vulnerability itself is clear and obvious, but.:
It`s main dependency is lack of MIME/type validation of affected (wep)application. While it`s spreading the wrong way by many people that simply bypassing the file extension will do the job, the case in real-world is that many web-applications out there also validate the content too (by either checking size,header,etc…) .
The other point as PhilG mentioned is that, having script execution access is the second dependency, on vulnerable target which is _usually_ considered when deploying application.
And the question: You’ve mentioned in advisory that you’ve tested some applications and 70% of them (uploaders?) seems to be vulnerable to this specific type of attack (mix of IIS bug+flawed extension checking by web-app+flawed type validation) when hosted by IIS.
If possible, I`d like to hear more accurate test results from you about your tests on the case:
1-Was it just testing uploaders, or entire web-applications being tested, which represented that result?
2-Is your estimation an educated guess based on OWASP yearly reports or it has been a personal test?
3-If it was a personal research, it would be great to know about number of tested cases.
These would help me have more clear idea about true impact of this case in real-world , not just relaying on blind estimations or hypes.
Dear Hamid,
Thanks for your comment. Please contact me via my ymsgri ID (irsdl). I do not want to discuss it here more than this (because of some personal reasons).
Microsoft were wrong. There are so many issues that could be exploited by uploading something other than executable code into an executable directory.
Something as simple as a simple HTML page with embedded javascript, if uploaded, would run from the same domain privileges as the rest of the site. Get someone to visit the URL… pop. Someone could potentially fill a partition, upload kiddie porn or warez, or upload a text file that would be included in a local file include bug, which would execute the code even if the local dir it was in was not set to be executable. An xml text file could be uploaded and used to feed urls to a botnet. Maybe you could give it an existing filename in the upload path, and overwrite it, such as overwrite the company logo with what previously was named rick-astley.jpg. Or 10000 other scenarios.
Pingback: iis semi-colon filename vulnerability | The Semicolon