[NT] Web Browsers Vulnerable to the Extended HTML Form Attack

From: support@securiteam.com
Date: 02/07/02

From: support@securiteam.com
To: list@securiteam.com
Date: Thu,  7 Feb 2002 11:48:14 +0100 (CET)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Web Browsers Vulnerable to the Extended HTML Form Attack


Many web browsers such as Internet Explorer allow forms to be submitted to
non-HTTP services. Some non-HTTP services echo back the information sent,
and the web browser renders the echo as an HTML page, regardless of the
protocol behind the service. This advisory will talk about a new way to
inject HTML scripts, which makes use of the same method described in the
paper by Jochen Topf called
<http://www.securiteam.com/securitynews/5CP0D2A55I.html> "The HTML Form
Protocol Attack". This novel method of injecting Active Scripts allows a
person, who has knowledge of the services running on a network, to steal
cookies, which can possibly mean hijacking of Web Application
authentication as well as other sensitive information stored in cookies.


Vulnerable systems:
 * Internet Explorer 6 and older versions
 * Opera 6.0 and older versions

Allows stealing of cookies, penetration of internal networks, and other
evil stuff.

Vendor status:
Internet Explorer - Microsoft was informed and a patch should be out soon.
Opera - a fix is due next release.

The Original HTML form attack:
The research done by Jochen Topf shows how HTML forms can be used to
penetrate internal networks from a site outside that network, by making
use of well-known features of the HTTP protocol.

While the paper by Jochen Topf describes possibilities of sending commands
to internal servers, it does not take into account what is displayed in on
client web browser. Instead, it covers the fact that attackers may
penetrate an internal network, or servers, which make use of IP filters,
by abusing the HTML Form.

Cross Site Scripting (CSS):
A recently discovered security problem involves modifying HTML content by
inserting malicious HTML tags or script. By inserting Active Scripting, it
is possible to steal session authentication of a web application. While
this problem has been around for years, it has only been publicized in the
recent years. "Microsoft Passport Account Hijack Attack" is a paper that
describes CSS attacks by example.

Playing with error messages and replies:
The ECHO service running on port 7 is a classic example of a service that
replies to what you specify.

G:\> nc -v server 7
server [] 7 (echo) open
hi there !
hi there !

Sending "hi there" to an ECHO server, will send back a "hi there" reply.
What if we make use of an HTML Form, and point it at the echo server?
The source of the page:

<form name="form1" method="post" action="http://echo-server:7/"
  <textarea name="eostest">
<html> <script>alert()</script>
  <input type="submit" value="Submit">

The end result when the form is submitted looks something like:

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/vnd.ms-powerpoint, application/vnd.ms-excel,
application/msword, */*
Accept-Language: en-gb
Accept-Language: en-gb
Content-Type: text/plain
Content-Type: text/plain
Accept-Encoding: gzip, deflate
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
Content-Length: 45
Content-Length: 45
Connection: Keep-Alive
Connection: Keep-Alive
Cache-Control: no-cache
Cache-Control: no-cache

eostest=<html> <script>alert(document.cookie)</script>
eostest=<html> <script>alert(document.cookie)</script>

Of course everything is echoed back (RFC 862). This sometimes (tested in
Internet Explorer 5.x and 6) causes the JavaScript code to be rendered
within an html page - which is made out of the echoed replies of the

A server running a Web Application (such as Web-Mail) and an echo server
is therefore obviously vulnerable to a CSS attack, which I describe as
Extended HTML Form Attack.

Many servers will not be running the echo service, since this is only used
for testing purposes mostly. On the other hand it is very frequent that
they will have other server software such as SMTP, FTP, NNTP and POP3. All
of these services tend to echo back some information specified by the
client, depending on the implementation of the protocol by the server
developers and the settings specified by the server's administrator.

Finding vulnerable hosts - what this exploit depends on:
If we want to use this vulnerability to hijack a Web Application, the
following requirements have to be satisfied:
1. The Web Application has to make use of cookie to keep the session
2. A server that echoes back the attacker's input is on the same domain as
the target Web Application
3. The victim user is using a vulnerable browser (IE5x/6 or Opera)
4. The victim user accesses an HTML page (website or e-mail) constructed
by the attacker. An attacker with a target in mind will generally make use
of an HTML e-mail and JavaScript to force the victim user submit the form.

The below is a list of servers that were actually successful in echoing
back JavaScript commands to the web browser:

Vendor: Rhinosoft
Server: Serv-U 3.0
Commands: MKD, GET
Example Command: mkd <script>alert(document.cookie)</script>

Vendor: WU-FTPD Development Group
Server: WU-FTP
Commands: USER, MKD, GET, non-existant command + script as argument
Example Command: user <script>alert(document.cookie)</script> and ASDF

Vendor: Ipswitch, Inc.
Server: Imail 6.06
Commands: RCPT
Example Command: rcpt to: img src=javascript:alert(document.cookie)

Vendor: The ProFTPD Project.
Server: ProFTPD
Commands: USER,MKD,GET
Example Command: user <script>alert(document.cookie)</script>

Vendor: Eudora
Server: QPOP(3.1.2)
Commands: USER
Example Command: user <script>alert(document.cookie)</script>

This list is not exclusive and many other servers can be used to launch
this type of attack.

In testing done, it was noticed that some vendors prevent this and other
attacks by only allowing a certain amount of errors to be generated for
each connection. In this case, since the HTTP request by the victim
contains HTTP headers (i.e. POST /a.cgi HTTP/1.1 etc), many errors will be
generated, and the connection is terminated. This was found true on
Microsoft SMTP server (part of IIS), and some other servers.

When searching for vulnerable servers, it is probably the easiest to use
SMTP servers, since they show up in the MX records. Of course the other
alternative is port scanning - for FTP, SMTP, POP3, and NNTP.

What are the dangers?
This attack mentioned here can be exploited in various ways. Until now, we
only mentioned how an attacker can use it to gather session cookies. In
fact, this is probably the most dangerous and easily exploitable method.

However, it can also be used in conjunction with the HTML Form Attack
described by Jochen Topf to return a result to the attacker. This way the
attacker can actually know that his attack was executed by injecting
JavaScript code, which in turn sends him back the resulting page.

The solutions for this kind of attack are just as the ones mentioned in
the original document "The HTML Form Protocol Attack". While Internet
Explorer and Opera are vulnerable to this attack, Netscape and Mozilla
(without the proxy settings- i.e. direct connection) restrict access to
certain well-known ports, like 25 (SMTP), 21 (FTP), 110 (POP3) and 119
(NNTP). While this does not seem to be a server side issue but rather a
client side (web-browser) issue, servers could also limit the number of
errors for each session.


The information has been provided by <mailto:obscure@eyeonsecurity.net>


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com


The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.