Date: Mon, 5 Dec 2005 10:07:23 +0100
From: "Marc Ruef" <maru@...p.ch>
To: <bugtraq@...urityfocus.com>, <full-disclosure@...ts.grok.org.uk>,
	<news@...uriteam.com>, <submissions@...ketstormsecurity.org>,
	<partners@...unia.com>
Subject: [scip_Advisory] e107 v0.6 rate.php manipulation


 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

e107 v0.6 rate.php voting manipulation and forwarding vulnerability

scip AG Vulnerability Advisory (11/10/2005)
http://www.scip.ch

I. INTRODUCTION

e107 is the name of an open-source content management system (cms) that
relies on php and sql.

More Information are available at the official project web site:

     http://e107.org

II. DESCRIPTION

Marc Ruef detected two flaws in rate.php. This file is responsible for
the votes of the users to rate content (e.g. the downloads). This voting
is served by default with an option combobox in download.php for
example. If the user has already rated a content, his user id is saved
to the table e107_rate in the according rate data set.

If an user is opening a download over download.php, the php script
checks in the background if the user has already voted yet. If not, so
the user id is not remarked in the rate data set, the option combobox is
shown - If he has already voted, a place holder text string is used.
This pre-detection tries to defend against multiple votes.

If an user selected a value in the option combobox, the browser connects
to rate.php and sends the rating data to this script as an HTTP GET
query string. The first problem relies in the possibility of reply
attacks. An attacker is able to call this rate.php url again and again
(e.g. using the direct link and not relying the real user web frontend
in download.php). Thus, a manipulation of the votes may be possible.
Because in the default installation of the software the web frontend
does not show who has already voted, a deeper investigation on the
database would be nescessary.

Furthermore the same php script is vulnerable to a simple
redirection/forwarding attack. If an user is rating a content, he is
opening the php script rate.php with some data in the HTTP GET query
string variable. One of the data provided is the destination directory
after successfull rating. An attacker may be able to create a malicous
url and forward a victim to a potential dangerous content.

It is very important to remark that in the default installation always
the variable e_BASE is set before the forwarding url. In this string the
base address of the web site is saved (e.g. http://www.scip.ch). So an
attacker is just able to define the directory names, file names and HTTP
GET query string variables. A possible scenario for misuse may a social
engineering attack or cross site scripting attempt. These always rely on
the flaw in other parts of the web site.

III. EXPLOITATION

The following example url let us to vote for the content "download" with
the id "42" every time we are accessing this url. The last integer
defines the rate value (between 1 and 10).

     http://www.scip.ch/rate.php?download^42^/download.php?view.42^5

The following example url let us to vote for a content and afterwards we
are forwarded to the script /etc/passwd. All the other data is still
used for the rating procedure (e.g. saving the new value in the rate
table).

     http://www.scip.ch/rate.php?download^23^/etc/passwd^1

IV. IMPACT

Manipulation of ratings is not a real security problem for environments
using e107. But is is a real threat for the reliability and integrity of
all the ratings within e107. An attacker may be able to compromise a
rating contest by voting multiple times for not liked or very liked
content.

The possibility of the forwarding attack may gain elevated privileges
for an attacker, as long as he is possible to exploit another
vulnerability on the target web server. Due the fact just the
destination directory can be defined, no cross plattform attacks are
possible.

V. DETECTION

Slight changes on the code of the affected php code may be able to
detect and prevent the successfully attack. See VI for more technical
details.

VI. WORKAROUND

The e107 team has provided a bugfix for the new release 0.7 in the CVS.

To prevent multiple votes in earlier versions the following lines should
be added to rate.php. These check once again, if the user has already
voted or not. If this is a multiple rating attempt, a forwarding to the
web site without adding the new data to the rate table is used instead.

     require_once(e_HANDLER."rate_class.php");
     $rater = new rater;
     if(!$rater -> checkrated($qs[0], $qs[1]) == FALSE){
          header("location:".e_BASE.$qs[2]);
          exit;
     }

The workaround for a false redirection can be handled by comparing the
data for the data base and the forwarding data (e.g. if the table
download is used then the forwarding should go to download.php anyway).
If they are not the same, the forwarding should not be used. Due the
fact in e107 prior 0.7 ratings for downloads are possible only, adding
the following line in rate.php will override any other forwarding url.

     $qs[2] = e_BASE."download.php?view.".$qs[1];

Please be aware, these code lines are just suggestions and not official
patches.

VII. VENDOR RESPONSE

The e107 team was aware of the flaws for a long time. Due the fact the
risk of the successfull exploitation was very low, no further
countermeasures were implemented. But at this time at least the flaw of
the multiple ratings has been eliminated. See VI for more details.

VIII. SOURCES

scip AG Vulnerability Database (german)
http://www.scip.ch/cgi-bin/smss/showadvf.pl

computec.ch document data base (german)
http://www.computec.ch/download.php?list.26
http://www.computec.ch/download.php?list.25

IX. DISCLOSURE TIMELINE

02/08/2005 First detection of the flaw by Marc Ruef
08/23/2005 Semi-public announcement of the flaw in the computec.ch forum
by Disenchant
11/07/2005 Technical analysis of the problem and developement of
bugfixes by Marc Ruef
26/09/2005 V3 posted the "old" problem of multiple rates in the bugtrack
of e107v7[1]
12/05/2005 Public advisory by Marc Ruef with scip AG

X. CREDITS

The flaw of the rate reply attack was discovered and analyzed by Marc
Ruef and Sven Vetsch. The vulnerability of the redirection and
forwarding during rating was analyzed by Marc Ruef.

     Marc Ruef, scip AG
     maru-at-scip.ch
     http://www.scip.ch

     Sven Vetsch
     admin-at-disenchant.ch
     http://www.disenchant.ch

A1. BIBLIOGRAPHY

[1] http://e107.org/e107_plugins/bugtrack/bugtrack.php?1625.show

A2. LEGAL NOTICES

Copyright (c) 2005 by scip AG, Switzerland.

Permission is granted for the re-distribution of this alert. It may not
be edited in any way without permission of scip AG.

The information in the advisory is believed to be accurate at the time
of publishing. There are no warranties with regard to this information.
Neither the author nor the publisher accepts any liability for any
direct, indirect or consequential loss or damage from use of or reliance
on this advisory.

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
Comment: http://www.scip.ch

iQA/AwUBQ5QDURe5hzJzqVMhEQK2GACfcoePtivcmANoIRXurbGTIH9vXt0An02e
M1l0gozHFvbAWw3WoNYU+n63
=VhT/
-----END PGP SIGNATURE-----

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists