Bugtraq mailing list archives

Mail File POST Vulnerability


From: Dirk Brockhausen <bro () BROCON COM>
Date: Wed, 11 Oct 2000 19:42:33 +0200

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&apos;,
                   [real_name => 'value1',
                    email => 'value2',
                    filename => 'value3',
                   ]);
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.

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!

--------

Source: fantomNews < http://www.fantomaster.com >


Current thread: