Microsoft Security Bulletin MS03-028 - Important
Flaw in ISA Server Error Pages Could Allow Cross-Site Scripting Attack (816456)
Published: June 16, 2003 | Updated: July 28, 2003
Originally posted: July 16, 2003
Who should read this bulletin: System administrators running Microsoft® Internet Security and Acceleration (ISA) Server 2000
Impact of vulnerability: Allows an attacker to execute code of their choice
Maximum Severity Rating: Important
Recommendation: System administrators should install the patch at the earliest available opportunity.
End User Bulletin: An end user version of this bulletin is available at:
- Microsoft Internet Security and Acceleration (ISA) Server 2000
ISA Server contains a number of HTML-based error pages that allow the server to respond to a client requesting a Web resource with a customized error. A cross-site scripting vulnerability exists in many of these error pages that are returned by ISA Server under specific error conditions.
To exploit this flaw, an attacker would have to first be aware of a specific ISA server and its access policies or host an ISA server of their own and create specific access policies designed to exploit this vulnerability. The attacker could then craft a request to trigger a page refusal. Once the attack was crafted, the attacker would have to host a Web site containing the link, or send the link to the user in the form of an HTML e-mail. After the user previewed or opened the e-mail, the malicious site could be visited automatically without further user interaction. In the Web-based attack scenario, an attacker would have no way to force a user to visit the Web site.
- The vulnerability could only be exploited if the attacker could entice another user into visiting a Web page, or opening an HTML-based e-mail.
- The request must be one that would cause the ISA server to respond with one of several affected error pages.
- The vulnerability would not normally enable an attacker to gain any privileges on an affected ISA Server computer, breach the firewall, or compromise any cached content, unless the user is operating on the ISA server itself and is using the Web Proxy service to access the Internet.
The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them.
Vulnerability identifier: CAN-2003-0526
Microsoft tested ISA Server to assess whether it is affected by this vulnerability. Previous versions are no longer supported, and may or may not be affected by this vulnerability.
Frequently asked questions
What's the scope of the vulnerability?
This is a cross-site scripting (XSS) vulnerability that could allow an attacker to craft a request to an affected server that would cause a Web page containing script to be sent to another user. The script would execute within the user's browser as though it had come from the third-party site. This would let it run using the security settings appropriate to the third-party Web site, as well as allowing the attacker to access any data belonging to the site. The vulnerability could only be exploited if the user opened an HTML-based e-mail or clicked a specially-crafted link.
What's cross-site scripting?
Cross-site scripting (XSS) is a security vulnerability that potentially enables a malicious user to "inject" code into a user's session with a Web site. Unlike most security vulnerabilities, XSS doesn't apply to any single vendor's products - instead, it can affect any software that runs on a Web server and that doesn't follow defensive programming practices.
How does XSS work?
At a high level of detail, here's how XSS works. Suppose that Web site A offers a search feature that lets a user type a word or phrase to search for. If the user typed "banana" in as the search phrase, the site would search for the phrase and then generate a Web page saying "I'm sorry, but I can't find the word 'banana'.". It would send the Web page to the user's browser, which would then parse the page and display it. Now suppose that, instead of typing "banana" as the search phrase, the user typed something like "banana ‹SCRIPT› ‹Alert('Hello');› ‹/SCRIPT›". If the search feature were written to blindly use whatever search phrase it's provided, it would search for the entire string and create a Web page saying "I'm sorry, but I can't find the word "banana ‹SCRIPT› ‹Alert('Hello');› ‹/SCRIPT›"". However, all of the text beginning with "‹SCRIPT›" and ending with "‹/SCRIPT›" is actually program code, so when the page was processed, a dialog box that says "Hello" would appear by the user's browser. So far, this example has only shown how a user could "relay" code off a Web server and make it run on his own computer. This is not a security vulnerability. However, it's possible for a malicious Web site operator to invoke this vulnerability to run on the computer of a user who visits his site. If Web site B were operated by a malicious user who was able to entice the user into visiting it and clicking a hyperlink, Web site B could go to Web site A, fill in the search page with malicious script, and submit it on behalf of the user. The resulting page would return to the user (because the user, having clicked on the hyperlink, was ultimately the requester), and process on the user's computer.
What could the script do on the user's machine? In the security context of Web site A?
The script from Web site B (the attacker's site) would run on the user's computer as though it had come from Web site A. In practical terms, this would mean that it would run using the security settings on the user's machine that were appropriate to Web site A. The script from Web site B would be able to access cookies and any other data on the user's system that belonged to Web site A.
What is ISA Server?
ISA Server provides both an enterprise firewall and a high-performance Web cache. The firewall protects the network by regulating which resources can be accessed through the firewall, and under what conditions. The Web cache helps improve network performance by storing local copies of frequently-requested Web content. ISA Server can be installed in three modes: firewall mode, cache mode, or integrated mode.
Could an attacker use the vulnerability to take control of an ISA Server computer?
No. This is a cross-site scripting attack only. There is no capability to usurp any administrative privileges on the ISA Server.
Could an attacker use the vulnerability to breach the security of the firewall?
No. There is no capability to use this vulnerability to lower the security the firewall provides to the network. Firewall mode allows an administrator to secure network communication by configuring rules that control communication between the corporate network and the Internet. Cache mode improves network performance by storing frequently accessed Web pages on the server itself. In integrated mode, all cache and firewall features are available.
What causes the vulnerability?
The vulnerability results because some of the error pages returned by ISA Server display the requested URL in HTML text without proper encoding.
What's wrong with ISA Server error pages?
The homepage() function in many of the ISA error pages does not correctly encode the URL for displaying in HTML text. As a result, it is possible to embed a link to script on a separate Web site and cause this to be returned to the Web browser.
What would this vulnerability enable an attacker to do?
The vulnerability would allow an attacker who operated a Web site and was able to lure another user into clicking a link on it to carry out a cross-site scripting attack via another Web site that was running through ISA Server. This would enable the attacker to run script in the user's browser using the security settings of the other Web site, and to access cookies and other data belonging to it.
How could an attacker exploit this vulnerability?
To exploit this flaw, an attacker would have to first be aware of a specific ISA server and its access policies, or host an ISA server of their own and create specific access policies designed to exploit this vulnerability. The attacker could then craft a request to trigger a page refusal. Once the attack was crafted, the attacker would have to host a Web site containing the link or send the link to the user in the form of an HTML e-mail. After the user previewed or opened the e-mail, the malicious site could be visited automatically without further user interaction. In the Web-based attack scenario, an attacker would have no way to force a user to visit the Web site.
You said that the point of the attack would be for the attacker to get script running in the user's browser using the security settings of my Web site. What specific capabilities would the attacker gain by doing this?
It would vary from site to site, based on what Security zone the attacker's site and yours were placed in. If they were both in the same zone (and, by default, all Web sites reside in the Internet zone unless the user moves them), they would both be subject to exactly the same security restrictions, and the attacker would gain different abilities through the vulnerability. For instance, an attacker could affect the relationship between a user and their Web-based e-mail. If the user had put the attacker's site into a more restricted zone than yours, the attacker would gain the ability for his script to do anything on the user's computer that script from your site could do. If the user had put your site into a more restricted zone than yours, the attacker would actually lose capabilities through the attack. It's important to note, however, that regardless of the security settings, the attacker's script would always be able to access cookies and any other data on the user's system belonging to the third-party site. This is because, as far as the browser can tell, the attacker is the third-party site.
How does the patch eliminate the vulnerability?
Download locations for this patch
Additional information about this patch
This patch can be installed on systems running Microsoft ISA Server Service Pack 1 and Microsoft ISA Server with Feature Pack 1 installed.
Inclusion in future service packs:
The fix for this issue will be included in the next ISA Server service pack.
Reboot needed: No.
Patch can be uninstalled: Yes.
Superseded patches: None.
Verifying patch installation:
To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine:
To verify the updates to the error pages were done, see instructions in Knowledge base 816456.
Localized versions of this patch are available at the locations discussed in "Patch Availability".
Obtaining other security patches:
Patches for other security issues are available from the following locations:
- Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
- Patches for consumer platforms are available from the WindowsUpdate web site
- Microsoft Knowledge Base article 816456 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
- Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.
Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
- V1.0 (July 16, 2003): Bulletin Created.
- V1.1 (July 16, 2003): Clarified mitigating factor.
- V1.2 (July 28, 2003): Clarified patch verification instructions.
Built at 2014-04-18T13:49:36Z-07:00 </https:>