Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Web Server/CGI)  >   Sun ONE/iPlanet Web Server Vendors:   Sun
iPlanet Web Server Log Analyzer Input Filtering Flaw Lets Remote Users Conduct Cross-Site Scripting Attacks Against Administrators
SecurityTracker Alert ID:  1008208
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Nov 17 2003
Impact:   Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information
Exploit Included:  Yes  
Version(s): 6.0 Service Pack 5 and prior; 4.1 Service Pack 12 and prior
Description:   An input validation vulnerability was reported in the iPlanet Web Server in the Log Analyzer. A remote user can cause arbitrary scripting code to be executed by a target administrator when the target administrator views a log file.

In March 2003, Infohacking Research reported that a remote user can set a malicious hostname containing HTML scripting code in the domain name system (DNS) and then make an HTTP request to a target server. If the target iPlanet Web Server is configured to perform inverse hostname lookups, the user-supplied HTML scripting code may be recorded in the web server log file.

When a target administrator runs the Log Analyzer to view the affected log entry, arbitrary scripting code will be executed by the target administrator's browser. The code will originate from the Log Analyzer application and will run in the security context of that application. As a result, the code will be able to access the target administrator's cookies (including authentication cookies), if any, associated with the security zone that the application runs in, access data recently submitted by the target administrator via web form to the application, or take actions on the application acting as the target administrator.

Some demonstration exploit hostnames are provided:

<script>alert( a )&lt;/script&gt;
<script>alert( a )&lt;/script&gt;
<script>alert( a )&lt;/script&gt;

Some images showing the effects of a demonstration exploit is available at:

Impact:   A remote user can access the target administrator's cookies (including authentication cookies), if any, associated with the security zone that the iPlanet administrative interface runs in, access data recently submitted by the target administrator via web form to the application, or take actions on the application acting as the target administrator.
Solution:   No solution was available at the time of the original report.
Vendor URL: (Links to External Site)
Cause:   Input validation error
Underlying OS:  Linux (Red Hat Linux), Linux (Sun), UNIX (AIX), UNIX (HP/UX), UNIX (Solaris - SunOS), Windows (NT), Windows (2000)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Nov 17 2003 (Sun Issues Fix) Re: iPlanet Web Server Log Analyzer Input Filtering Flaw Lets Remote Users Conduct Cross-Site Scripting Attacks Against Administrators
Sun has issued a fix for the Sun ONE/iPlanet Web Server.

 Source Message Contents

Subject:  Log corruption on multiple webservers, log analyzers,...


something that could be interesting...
We have decided not to contact any vendor (many vendors are vulnerable and 
we have not enough time...sorry) and made this advisory public in this 

ILLC - Inverse Lookup Log Corruption

Corruption) that allows us to corrupt the logs generated by many web 
servers that are doing inverse address resolution. 

Impact of this technique:

-	Code execution (XSS) on boxes that are running log analyzers (web 
servers that have buit-in report analisys tools,etc.)

On some specific scenarios, we have been able to hide the entire http 
request to the log viewer.

Most of the actions were possible because of the lack of  filtering when 
parsing host names between different applications.

RFC 952: 
1.	A "name" (Net, Host, Gateway, or Domain name) is a text string up 
to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-
), and period (.). Note that periods are only allowed when they serve to 
delimit components of "domain style names". (See RFC-921, "Domain Name 
System Implementation Schedule", for background). No blank or space 
characters are permitted as part of a name. No distinction is made between 
upper and lower case. The first character must be an alpha character. The 
last character must not be a minus sign or period.... Single character 
names or nicknames are not allowed....

RFC 1034:
3.5. Preferred name syntax 
... The labels must follow the rules for ARPANET host names. They must 
start with a letter, end with a letter or digit, and have as interior 
characters only letters, digits, and hyphen. There are also some 
RFC 1123: 
2.1 Host Names and Numbers 

The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. 
One aspect of host name syntax is hereby changed: the restriction on the 
first character is relaxed to allow either a letter or a digit. Host 
software MUST support this more liberal the RFCs. Note that under BIND 8, 
you may need to add "check-names master ignore" to the zone definition 

RFC 2181: 
11. Name syntax 
Occasionally it is assumed that the Domain Name System serves only the 
purpose of mapping Internet host names to data, and mapping Internet 
addresses to host names. This is not correct, the DNS is a general (if 
somewhat limited) hierarchical database, and can store almost any kind of 
data, for almost any purpose. 
The DNS itself places only one restriction on the particular labels that 
can be used to identify resource records. That one restriction relates to 
the length of the label and the full name. The length of any one label is 
limited to between 1 and 63 octets. A full domain name is limited to 255 

Independently of what should be the legal host name syntax, it seems that 
operating systems allows host names with arbitrary characters.
server/log analyzer,etc., will be doing inverse address resolution and 
that the attacker could control in any way the responses to those inverse 
lookup requests.


Examples of attacks:

(exploited succesfully on Apache 2.0.44  on Windows/Linux, and Iplanet 6 
on Windows)
Scenario: a machine with a host name as ""  makes a request 
to an Apache server. If the server dosn`t generate any error, on the 
access log you will see an  access request from a client 
called "", what apparently seems to be a valid request from 
a client that server was unable to resolve to a host name. So the real IP 
wouldn't appear in the access log file.

access.log - - [28/Feb/2003:10:39:01 +0100] "GET / HTTP/1.1" 200 
1786 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" - - [28/Feb/2003:10:39:46 +0100] "GET /badrequest.html 
HTTP/1.1" 404 294 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)"

If the request produces some error, you will see an entry in the error log 
file were you could see the real IP, although the web server has the 
inverse lookup activated.


[Fri Feb 28 10:39:46 2003] [error] [client] File does not 
exist: C:/Archivos de programa/Apache Group/Apache2/htdocs/badrequest.html

in a complete anonymous http access for a client in a usual web surfing 
activity, that is, if there are not broken links,etc.

preview (see link below):


(Succesfully exploited on Apache 2.0.44 on Windows/Linux, on IIS 6.0 and 
Iplanet 6 on Windows)
makes an HTTP request leaves javascript code on the log.

When generating a report, with some log analyzers (that show results in 
html), the script will be executed.

*Note: in IIS 6.0 case we needed to restrict access on webserver by domain 
name in order to force inverse lookup resolution.
*Note2: in the Iplanet case we needed to simulate a FQDN client host name 
like this:
You can also set a host name were the script is only part of the entire 
string label:
so when html formatted it will appear as a valid domain name:

Some log analyzers proved to be vulnerable to "ILLC":

WebTrends (see link below):

SurfStats (see link below):

WebLogExpert (see link below):

Iplanet comes with a buil-in tool to generate html reports based on access 
and error logs. This tool is part of the administration web interface.
Moreover, Iplanet log analyzer always uses a web broser to show the 
will be always exploitable.

Iplanet Log Analyzer (HTML report, see link below):

on some characters (for example <>).

-HIDING REQUESTS (Iplanet 6 on Windows)

In the specific case of Iplanet 6, we coul realise that there`s a way to 
are visible in the access and error log files, but they would 
made requests from a box with this host name:
the access log:

format=%Ses->client.ip% - %Req->vars.auth-user% [%SYSDATE%] "%Req-
>reqpb.clf-request%" %Req->srvhdrs.clf-status% %Req->srvhdrs.content-
length% "%Req->headers.referer%" "%Req->headers.user-agent%" %Req-
>reqpb.method% %Req->reqpb.uri% %Req->reqpb.query% "%Req->reqpb.protocol%" 
%vsid% - - [28/Feb/2003:10:22:25 +0100] "GET /evilrequest.html 
HTTP/1.1" 404 292 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)" 
GET /evilrequest.html - "HTTP/1.1"

We suppose that server is processing the first part of the host name 
and the rest of the string is not recognized as valid format, so nothing 
is showed.
Combining the possibility of hiding a request and the Cross Site Scripting 
technique we could execute scripts on the machine that runs the Report 
establishing a host name like this:
(See link below):

Many more evil actions can be done... it only depends on the attacker's 

IDSs, etc. We think that probably this technique could be used in the same 
way in other scenarios.


Exploiting http headers for log corruption

Controlling inverse lookup responses is not always possible for the 
attacker. We tried to figure out another, more generic attack to corrupt 
web logs.
The first that came to us was to use faked http headers in order to 
achieve the same result: execution of scripts by log analyzers. 
There are a lot of http headers that can be used to inject code in a log 
file. We are not going to discuss all of them in this paper, but only to 
outline some generic ways to do it.
The main objective here is to choose the right header to inject code in 
web logs, but probably it will be filtered by many application firewalls 
usually is not being checked for suspicious secuence of characters, and 

An example on how to trick a log analizer to execute a script we 
the web server log. Some log analyzers reading this logs and generating 
HTML formatted reports without filtering the output, will execute the 

-Examples of vulnerables log analyzers-

WebExpert (see link below):

LoganPro (see link below):

To solve this kind of problems it would be nice a more aggressive 
filtering on DNS responses and HTTP requests on all the headers.

To finish this short analisys we would like to make some questions:

Are log analyzers thrusting too mutch on log files?

Maybe, are web servers the ones that would have to filter what they write 

Is the operating system the one that have to filter the returned values 
from DNS servers?

Are the actual legal domain name hosts allowed too mutch liberal?

Sorry for our bad english.
letting us doing this "research".

Infohacking Research 2001-2003


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2020, LLC