 |
Cloaking and Security Tips #1
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:
<!-#include virtual= "/cgi/multihtml.pl?multi=/www/header.html"->
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:
<!-#include virtual= "/cgi/multihtml.pl?multi=/www/header.html"->
You will get the same effect with:
<!-#include virtual="/www/header.html"->
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. Dirk Brockhausen is the co-founder and principal of fantomaster.com Ltd. (UK) and fantomaster.com GmbH (Belgium), a company specializing in webmasters software development, industrial-strength cloaking and search engine positioning services. He holds a doctorate in physics and has worked as an SAP consultant and software developer since 1994. He is also Technical Editor of fantomNews, a free newsletter focusing on search engine optimization, available at: < http://fantomaster.com/fantomnews-sub.html > You can contact him at mailto:fntecheditor@fantomaster.com (c) copyright 2000 by fantomaster.com
Article viewed 733 time(s). Read more: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | |
