Microsoft IIS vuln leaves users open to remote attack
Beware of the 'semicolon bug'
Agentless Backup is Not a Myth
Updated A researcher has identified a vulnerability in the most recent version of Microsoft's Internet Information Services that allows attackers to execute malicious code on machines running the popular webserver.
The bug stems from the way IIS parses file names with colons or semicolons in them, according to researcher Soroush Dalili. Many web applications are configured to reject uploads that contain executable files, such as active server pages, which often carry the extension ".asp." By appending ";.jpg" or other benign file extensions to a malicious file, attackers can bypass such filters and potentially trick a server into running the malware.
There appears to be some disagreement over the severity of the bug, which Dalili said affects all versions of IIS. While he rated it "highly critical," vulnerability tracker Secunia classified it as "less critical," which is only the second notch on its five-tier severity rating scale.
"Impact of this vulnerability is absolutely high as an attacker can bypass file extension protections by using a semicolon after an executable extension such as '.asp,' '.cer,' '.asa' and so on," Dalili wrote. "Many web applications are vulnerable against file uploading attacks because of this weakness of IIS."
In an email to El Reg, Dalili offered the following attack scenario:
"Assume a website which only accepts JPG files as the users’ avatars. And the users can upload their avatars on the server. Now an attacker tries to upload "Avatar.asp;.jpg" on the server. Web application considers this file as a JPG file. So, this file has the permission to be uploaded on the server. But when the attacker opens the uploaded file, IIS considers this file as an ASP file and tries to execute it by 'asp.dll.'
"So, the attacker can upload a web-shell on the server by using this method. Most of the uploaders only control the last part of the files as their extensions, and by using this method, their protection will be bypassed."
Secunia didn't explain how it arrived at its assessment, but it did confirm the bug on a machine running a fully patched version of Windows Server 2003 R2 SP2 with Microsoft IIS version 6.
A Microsoft spokeswoman said company researchers are investigating the report. They are not aware of attacks targeting the reported vulnerability, she said.
In the absence of any official guidance, webmasters who want to workaround the potential problem should make sure that upload directories don't have execute permissions. And web developers should ensure their applications never accept the user's input as a file name.
More from Dalili and Secunia are here (PDF) and here. ®
This article was updated to include comments from Dalili.
COMMENTS
Re "What!"
@ Destroy All Monsters
>1) Why would a webserver need to execute uploaded code? Is this a new approach to distributed >computing?
A web server would not 'want' to execute uploaded code. After the file is uploaded to the server (bypassing content filters using this hack), the malicious user would request the file via http, thus executing it.
The effect of this would depend on the permissions which the IIS process runs under. Recommendations are to run this with a low privilege account. This should prevent running services, installing malware, most administrative functions. This is probably why Secunia have given the exploit a low rating.
>2) How does IIS decide whether to execute something if the rule is to _not_ execute something >ending in .asp?
IIS executes ASP files by default (via passing the request to the ASP.dll handler), not the other way around. The general rule is to prevent users UPLOADING executable files like this via a file upload facility.
I know its clever to be down on Micro$oft, but why comment when you don't understand the issue.
This is really a non-issue
First, ASP in and of itself, as supplied by microsoft, doesn't even HAVE a file upload capability. As such, any such file upload module would have be be supplied by the web developer. If the developer doesn't sanity-check input fields even do a simple regex to strip invalid characters, then they aren't much of a developer. If they are writing files to directories where the IIS Anonymous user has execute permissions, then they aren't much of a developer. In either case, the security problem is not Microsoft's but in fact the developer's - just as most LAMP sites that are hacked are because the DEVELOPER left holes, not in the framework itself.
From what I can see from the reports (and I will be testing this week to confirm) is that the parsing mechanism that IIS uses to determine what ISAPI filters may be broken. If so, that is the extent of the bug in IIS, and it isn't a security issue but a fitness-for-purpose issue.
The fact that it has apparently had this bug for over 10 years and nobody has run across it before should tell you something about the level of brain-deadness a developer must have before it can be triggered.
Bad Coding Practice
This whole exploit relies on two extremely bad practices.
1. Upload directories have execute script / code permissions. This should never happen, as directories in which users upload files should never execute, regardless of whether the file has the appropriate extension or not.
2. The file name the user inputs is the file name on the server side. This should also never happen, as regardless of what filters you put in, it can be easy to trick a script into thinking that the file extension is one thing when it is actually another. Your server should rename any uploaded file according to some scheme or another.
Remember,
Users can't fake directory permissions, and users can't dictate what your server names the file. This is in no real way a security flaw because of Microsoft. It is a bug, but the security implications of it are due to bad practices on the end user's behalf.
IT infrastructure monitoring strategies
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
Cloud based data management
Agentless Backup is Not a Myth
