[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20050702070858.GB23228@hardened-php.net>
Date: Sat, 2 Jul 2005 09:08:58 +0200
From: Stefan Esser <sesser@...dened-php.net>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Advisory 03/2005: Cacti Multiple SQL Injection
Vulnerabilities [FIXED]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hardened - PHP Project
www.hardened-php.net
-= Security Advisory =-
Advisory: Cacti Multiple SQL Injection Vulnerabilities
Release Date: 2005/07/01
Last Modified: 2005/07/01
Author: Stefan Esser [sesser@...dened-php.net]
Application: Cacti <= 0.8.6e
Severity: Wrongly implemented user input filters lead to
multiple SQL Injection vulnerabilities which can
lead f.e. to disclosure of the admin password hash
Risk: Critical
Vendor Status: Vendor has released an updated version
References: http://www.hardened-php.net/advisory-032005.php
Overview:
Quote from http://www.cacti.net
"Cacti is a complete network graphing solution designed to harness
the power of RRDTool's data storage and graphing functionality.
Cacti provides a fast poller, advanced graph templating, multiple
data acquisition methods, and user management features out of the
box. All of this is wrapped in an intuitive, easy to use interface
that makes sense for LAN-sized installations up to complex
networks with hundreds of devices."
Because it is usually fun to audit software which was previously
audited by experts from iDEFENSE we scanned through their reported
vulnerabilities and found that most are not properly fixed.
Details:
With the recent release of iDEFENSE's Cacti advisories version
0.8.6e of Cacti was released which according to iDEFENSE fixes
all reported flaws. But this is not true.
However the user input filters that were added to the Cacti
codebase to address the possible SQL Injections are wrongly
implemented and therefore can be tricked to let attackers
through.
To demonstrate the problem here a snipset of "graph.php"
/* ================= input validation ================= */
input_validate_input_regex(get_request_var("rra_id"), "^([0-9]+|all)$");
input_validate_input_number(get_request_var("local_graph_id"));
/* ==================================================== */
if ($_GET["rra_id"] == "all") {
$sql_where = " where id is not null";
}else{
$sql_where = " where id=" . $_GET["rra_id"];
}
On the first look this code looks safe, because it checks that
the 'rra_id' request parameter is either a number or the string
"all" before inserting it into a part of the SQL Query.
To realize that this check is however worth nothing one has to
dig deeper and look into the implementation of get_request_var()
function get_request_var($name, $default = "")
{
if (isset($_REQUEST[$name]))
{
return $_REQUEST[$name];
} else
{
return $default;
}
}
This actually means that the filter in this example is applied to
the content of $_REQUEST["rra_id"] and not to $_GET["rra_id"].
The problem with this is, that $_REQUEST is a merged version of
the $_GET, $_POST and $_COOKIE arrays and therefore array keys of
the same name will overwrite each other in $_REQUEST.
In the default configuration of PHP which is usually not changed
by anyone the merge order is GPC. This means when the request
contains both $_GET["rra_id"] and $_POST["rra_id"], only the
posted value will end up in the $_REQUEST array.
This however means, that nearly all of the implemented filters can
be bypassed by supplying the attack string through the URL and
supplying a good string through POST or through the COOKIE.
Proof of Concept:
The Hardened-PHP Project is not going to release exploits
for this vulnerabilities to the public.
Disclosure Timeline:
25. June 2005 - Contacted Cacti developers via email
29. June 2005 - Review of patch from our side
1. July 2005 - Release of updated Cacti and Public Disclosure
Recommendation:
We strongly recommend upgrading to Cacti 0.8.6f which you can get at
http://www.cacti.net/download_cacti.php
Summary for Secunia:
Because Secunia proofed several times in the past, that they have
enormous problems with reading advisories and crediting the right
parties in their advísory rip-offs, here a short summary.
This bug was not found by iDEFENSE. On the contrary it is a bug
in the input filters that were implemented because of iDEFENSE
and where nodded through by them.
GPG-Key:
http://www.hardened-php.net/hardened-php-signature-key.asc
pub 1024D/0A864AA1 2004-04-17 Hardened-PHP Signature Key
Key fingerprint = 066F A6D0 E57E 9936 9082 7E52 4439 14CC 0A86 4AA1
Copyright 2005 Stefan Esser. All rights reserved.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQFCxBb2RDkUzAqGSqERAk8iAKC8ifl5vl+GtQSw17XyyyZGHb438QCfRJGG
RwZhc/qfTE7pP8sxvE8pL4U=
=qYP/
-----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