Knowledge Archives
http://www.co-internet.net/net/articles/cloaksecurity01.txt.html

Cloaking and Security Tips #1
- MultiHTML vulnerability
- Mail File vulnerability
------------------------------------------------------
In this series of articles we will feature discussions
relating to security issues.
Obviously, the term "security" may cover a lot of
areas - here we will focus primarily on cloaking and
security.

DISCLAIMER
==========
The examples and techniques presented and discussed
here are solely intended to help you improve your web
site's security.

In no way should this information be abused to attack
other web sites or hosts!

----------

An important aspect of cloaking is the protection
of optimized HTML source code from competitors'
prying eyes.

IP delivery based cloaking is worked by determining
whether a website visitor's IP belongs to a normal
human surfer or to a search engine. Depending on
which case applies, the web server will either
present the optimized (cloaked) page or a normal
HTML page intended for human perusal.

Should a normal human visitor wish to pose as an
SE spider, he or she would have to forge their IP.
This technique is termed "IP spoofing". It requires a
great deal of tech expertise and is actually illegal
in many jurisdictions now.

IP spoofing is not our topic here.

However, there is a completely different approach
which has not been covered in connection with
cloaking until now:

The attacker causes the source code of the pertinent
file to be displayed.

Suppose a surfer enters a keyword in a search engine
and receives as top positioned site the following
URL:

< http://www.domain.com/top.htm >.

If this site is cloaking, the file "top.htm" will not
be an ordinary HTML page but, rather, a script
(program). This script governs the display of the web
site and will present the normal human visitor with
an ordinary HTML page.

If you call this URL (e.g. by clicking the link), you
will not be shown the source code; rather, your click
will execute the script posing for a normal web page.

Let us now analyze in detail some security holes
which will enable the technically sophisticated
visitor to see the source code after all.

MultiHTML vulnerability
=======================

MultiHTML by JCS Web Works < http://www.jcserv.net >
is a small Perl script intended to facilitate
administration of web pages.

For example, if you want to include a header on every
web page, you can call that header with a SSI
command. The syntax required for the MultiHTML script
would be:



This call causes the HTML code residing in the file
"header.html" to be executed.

You could also call the URL directly:

< http://domain/cgi/multihtml.pl?multi=/www/header.html >

which would display the header (i.e. the content of
"header.html").

The trick in this case is based on the fact that you
can also insert any given file name of your choice,
e.g.:

< http://domain/cgi/multihtml.pl?multi=/www/top.htm >

If the script is executed as above, you will see the
page's source code displayed.

This would allow us to learn the optimized page's
name and its exact directory location, e.g.:

/www/opt/top.html.

So a second call of:

< http://domain/cgi/multihtml.pl?multi=/www/opt/top.html >

would display the optimized HTML code of the cloaked
page.

Password protecting the directory /www/opt will do
no good because this does not apply to the
"open FILE" command in the perl script in question.

As a security measure, the script allows for
definition of specific file extensions, e.g.
"htm, html, shtml".

However, the check up of the file extension can be
neutralized by yet another trick.

This one is based on "The poisened NUL byte" and
was published by Olaf Kirch in the October 1998
Bugtraq List.

In September 1999 the problem was discussed by
rfp (rain.forest.puppy) as "Poison NULL byte" in an
article in Phrack Magazine.

Let's suppose an attacker want to open the file
"account.cgi" with the following call:

< http://domain/cgi/multihtml.pl?multi=account.cgi >

The file "account.cgi" does not have the permitted
extension "html", so access is refused.

The parsing routine will often be conducted with a
regular expression following this scheme:

if ($filename =~ /$extension/) {&do_it}

In our (simplified) example:

if ("account.cgi" =~ /html/) {&do_it}


In other words: the string "html" is not included in
the "account.cgi" string, so action "do_it" will not
be triggered.

Using the "Poison NULL byte", the call would be
effected in the following manner:

< http://domain/cgi/multihtml.pl?multi=account.cgi%00html >

The regular expression will let this file name pass
because "html" is included in the string
"account.cgi%00html"!

The file will be opened via:

open(FILE, "$filename")...

In our example:

open(FILE, "account.cgi%00html")...

This call will be transmitted by Perl to the system
routine which in turn recognizes NUL as a delimiter
and opens the file "account.cgi".

This method allows for systemwide opening of all
files holding read permissions for "others".

Therefore, it touches upon the host's overall
security if only a single user happens to install an
unsafe script like the one discussed here.

Countermeasures
==============

The script is used in combination with SSI:



You will get the same effect with:



The required file will thus be read directly without
channeling it via the MultiHTML script.

Conclusion: This script should not and need not be
implemented.

Further tips:

BugTraq
Subject: MultiHTML vulnerability
Date: Wed Sep 13 2000 21:38:34
Author: Niels Heinen < niels@safemode.org >

-----------

The example given above was discussed to demonstrate
some generic techniques employed in attacking a web
site.

It was based on a suggestion published in the
BugTrag List.

The security leak in the second example given below
was discovered in the course of our own research
work.


Mail File vulnerability
=======================

MailFile v 1.10 by Oatmeal-Studios
< http://www.oatmeal-studios.com >

This Perl script enables a site's visitor to have a
given file dispatched to a specified email address.

The visitor is required to select the file from a
given list and to enter his or her email address.

The data will then be dispatched by a POST command to
the target server.

In contrast to a GET command, a POST command will not
display the data in the referenced URL.

For example, if you search in AltaVista for the
phrase "ip blocker", the URL generated will look like
this:

< http://www.altavista.com/cgi-bin/query?q=%22ip+blocker%22 >

The query script is called with GET, which is why the
phrase is displayed in the URL and can even be
modified there.

As the MailFile script uses a POST command, the file
name is not open to manipulation on the URL level. But
this is a false security! Indeed, this script is quite
vulnerable to a fairly simple attack.

E.g. an attacker could install the entry form on his
or her own web site and modify the file name
accordingly.

To rule this out, the script will check the "Referer"
variable. For security and bandwidth economy reasons
it will only permit calls from the domain it actually
resides on. Or so it seems.

Indeed, an attacker can manipulate not only the
UserAgent data but the "Referer" variable as well.

It takes only a few lines of Perl to send the required
data (variables) to the MailFile script.

Schematic Code:

#!/usr/bin/perl

use HTTP::Request::Common;
use LWP::UserAgent;

$ua = LWP::UserAgent->new;
$res = $ua->request(POST 'http://domain/mailfile.cgi',
[name1 => value1,
name2 => value2,
]);

$html_page = $res->content();

etc.


This code can actually be used against all cgi scripts
based on the POST method.

In the case of the MailFile script discussed here, we
could even skip sending a "Referer" because the
implemented check routine will simply regard the
referrer as valid if the "Referer" variable has not been
set.

Again, this method allows for systemwide opening of
all files holding read permissions for "others" - a
major security hazard!

Conclusion: For security reasons, this script should
not be implemented.

This text may freely be republished or distributed in unmodified form provided the following resource box is included intact either at the beginning or the end of the article and a complimentary copy or notice (link) is sent to the author at the address specified below:

Ralph Tegtmeier is the co-founder and principal of fantomaster.com GmbH (Belgium), < http://fantomaster.com/ >, a company specializing in webmasters software development, industrial-strength cloaking and search engine positioning services.

He has been a web marketer since 1994 and is editor-in-chief of fantomNews, a free newsletter focusing on search engine optimization, available at: < http://fantomaster.com/fantomnews-sub.html > You can contact him at mailto:fneditor@fantomaster.com
(c) copyright 2002 by fantomaster.com
All rights reserved.
Downloaded at: < http://fantomaster.com/ >