[Full-disclosure] Re: plz suggest security for DLL functions
Did you try the commercial software EXE Cryptor? It should slow down anyone trying to analyze your software. http://www.strongbit.com/execryptor.asp Also, you could try integrating some custom exploits against debugging software -- here's a recent one. ** Compuware Softice (DbgMsg driver) Local Denial Of Service As stated here by many before, if someone has enough time and resources, they will get at your code. The best you can do is to frustrate them so much that the analysis consumes their time for friends, beer, wo/men, etc... -- Kristian Hermansen <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Solaris 9/10 ld.so fun
Przemyslaw Frasunek wrote: Vulnerability was confirmed by Sun: http://sunsolve.sun.com/search/document.do?assetkey=1-26-101794-1 There are still no patches available, but workaround was proposed. Here is an exploit for Schillix using venglin's mojo. -KF Schily-Root.tar Description: Binary data ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] security contact for sargento
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 2 Jul 2005, Randall M wrote: > :Does anyone have a security contact for Sargento Cheese? > > Did you find some holes in it? That would not be Gouda. RGDS GARY - --- Gary E. Miller Rellim 20340 Empire Blvd, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCxtOm8KZibdeR3qURAg6LAKCQbl9rKpaBxSEOk1HiwIauw+SH6ACdFazy kooRhmxPx7crIcmlK4U8RyY= =d4Dl -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/
RE: [Full-disclosure] security contact for sargento
:-Original Message- :From: [EMAIL PROTECTED] :[mailto:[EMAIL PROTECTED] On Behalf :Of [EMAIL PROTECTED] :Sent: Saturday, July 02, 2005 11:55 AM :To: full-disclosure@lists.grok.org.uk :Subject: [Full-disclosure] security contact for sargento : : :Does anyone have a security contact for Sargento Cheese? : Did you find some holes in it? ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] security contact for sargento
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does anyone have a security contact for Sargento Cheese? -BEGIN PGP SIGNATURE- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.4 wkYEARECAAYFAkLGxv0ACgkQLvtylUqV9TtbagCdEPwaFw8maXfI/y3KRbyd9cgE8DYA n029wnpxrCiZGWhCFPklrks+Pjcm =Cq8n -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/
RE: [Full-disclosure] plz suggest security for DLL functions
> About the best you could do to hide the "super secret sauce" (lol .. > Vladis) is put it on a secure token (eg: SmartCard) and call it from > there. While not foolproof, hardware is [generally] more > difficult to hack. > Not for someone who has more knowledge than time and above all more ego than knowledge Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] plz suggest security for DLL functions
> friends, > > We are developing a software that makes use of a COM DLL. The whole > logic lies in the dll. The User Interface is in VC++. DLL exposes > functions, application calls it and displays result. Now, we found > that anybody can copy the DLL, register it and make use of those > functions. This is a classic problem that plagues most of the software. They make good libs but don't want others to use them. Have u looked into encrypting the file itself and decrypting the required portion in the memory itself? This way nothing uncrypted in ever on the disk. So no one can actually do anything with a copied file. There are more approaches like anti debugging code like putting some your code in int 1 and int 3 so that debuggers cannot touch your code Or deliberately misaligning memory while some part of the dll so that any calling program that uses the dll has to so work around this "bug" there are quite other also like changing the PE section and so on > Please guide us in making those functions secret or encrypted so that > others cannt use our functions. But keep this in mind almost all what you do to protect your dll can be undone with enough time and resources. And someone just might! So if your DLL is heavily encrypted somewhere it would have to be decrypted and if *that* code can be debugged all the battle is lost, and believe me someone may just find a way to do that... Delivered using the Free Personal Edition of Mailtraq (www.mailtraq.com) ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: Transamericana.org
Hello list, Remember a few months ago an email about my XP workstation pinging www.transamericana.org on login? I finally got around to clean this one up. I uninstalled almost all the applications, and then proceeded to clean up the Windows registry, and finally found what the problem was. For some reason (maybe a bluethoot device that had once been installed on the computer, which was installed and removed on the same day - it was just a test for somebody I knew) had created a key on HKCU\Software\Microsoft\RAS AutoDial for that host (and a few others). When Windows was going through the login process it would ping those hosts (although, for some reason [being Windows? :)] not all of them all the time) to check if they could be reached. Deleting those keys solved the problem. Just to let all of you know what happened. This might not be news to some of you, but it could be usefull to somebody else who finds a similar problem. Why this didn't came up when I first went through the registry puzzles me. Maybe didn't dig well enough :) Thanks to all. Regards, -- Anto'nio Henrique A. Proenca de Oliveira "Although we can never go back, like an old sweet song with a strong refrain, memories remain" - (Someone) Please avoid sending me Word or PowerPoint attachments. See http://www.fsf.org/philosophy/no-word-attachments.html $Id: .signature,v 1.3 2004/07/14 08:08:10 tat Exp tat $ ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] RE: Publishing exploit code - what is it good for
I agree that in some cases, release of exploit code is unnecessary - but in other cases, it is completely essential. In an open source product - as was recently the case with the osCommerce HTTP splitting vulnerability - it is necessary for programmers to fix vulnerabilities, in cases where the organisation that produces the software does not release a patch or updated version in time. Also, open source products - especially web applications - are often modified by their users. I am responsible for maintaining several osCommerce carts that have been heavily modified to suit the needs of the companies that use them. Even if a patch or new version were released for a security problem, it would be of little help for me: to install it would require remodifying each cart. This would be a horrendous waste of time; it is far quicker simply to fix the vulnerability in each installed instance, and in cases like that, proof of concept code is essential: without it, one cannot reliably test fixes applied to the product. Finally, proof of concept code has value - in all cases - as a means of proving the existence of a vulnerability. It is the most efficient way to provide other researchers with the proof that a vulnerability is real, with the means to reproduce the problem, and with the ability to check the original researcher's approach for flaws or related vulnerabilities that may not have been discovered the first time round. Release of proof of concept code is obviously dangerous, but not *very* dangerous: it's a trade-off between the verifying the quality of research and the ability to fix problems, and the safety of the wider community. I assert that, as is often the case with this type of problem, the benefits outweigh the risks: blackhat communities will likely distribute their own exploit code anyway, and determined attackers will not be put off by the lack of proof of concept code. In other words, the lack of proof of concept *can* harm the community, and is unlikely to make much difference to evildoers. Harry Metcalfe -Original Message- From: Aviram Jenik [mailto:[EMAIL PROTECTED] Sent: 30 June 2005 13:14 To: full-disclosure@lists.grok.org.uk; bugtraq@securityfocus.com Subject: Publishing exploit code - what is it good for Hi, I recently had a discussion about the concept of full disclosure with one of the top security analysts in a well-known analyst firm. Their claim was that companies that release exploit code (like us, but this is also relevant for bugtraq, full disclosure, and several security research firms) put users at risks while those at risk gain nothing from the release of the exploit. I tried the regular 'full disclosure advocacy' bit, but the analyst remained reluctant. Their claim was that based on their own work experience, a security administrator does not have a need for the exploit code itself, and the vendor information is enough. The analyst was willing to reconsider their position if an end-user came forward and talked to them about their own benefit of public exploit codes. Quote: " If I speak to an end-user organization and they express legitimate needs for exploit code, then I'll change my opinion." Help me out here. Full disclosure is important for me, as I'm sure it is for most of the people on these two lists. If you're an end-user organization and are willing to talk to this analyst and explain your view (pro-FD, I hope), drop me a note and I'll put you in direct contact. Please note: I don't need any arguments pro or against full disclosure; all this has been discussed in the past. I also don't need you to tell me about someone else or some other project (e.g. nessus, snort) that utilizes these exploits. Tried that. Didn't work. What I need is a security administrator, CSO, IT manager or sys admin that can explain why they find public exploits are good for THEIR organizations. Maybe we can start changing public opinion with regards to full disclosure, and hopefully start with this opinion leader. TIA. -- Aviram Jenik Beyond Security http://www.BeyondSecurity.com http://www.SecuriTeam.com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Re: In-game /ignore crash in Soldier of Fortune II 1.03
Hello! In message to ; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ; <[EMAIL PROTECTED]> sent Wed, 29 Jun 2005 20:32:51 + you wrote: LA> ### LA> Luigi Auriemma LA> Application: Soldier of Fortune II LA> http://sof2.ravensoft.com LA> Versions: 1.02x and 1.03 LA> Platforms:Windows, Linux and Mac LA> Bug: bad memory access LA> Exploitation: remote, versus server (in-game) LA> Date: 29 Jun 2005 LA> Author: unknown, found in the wild and reported to me by two LA> admins LA> Advisory: Luigi Auriemma LA> e-mail: [EMAIL PROTECTED] LA> web:http://aluigi.altervista.org [...] LA> == LA> 4) Fix LA> == LA> The game is no longer supported so there is no official fix. LA> The correct way for removing the problem is patching the bug into the LA> latest SDK available for the game (1.02 + 1.03) and recompiling it. LA> The patch consists in the adding of the following instruction in LA> g_cmds.c after "ignoree = atoi( buffer );" at line 1962: LA> if(ignoree > MAX_GENTITIES) return; I'm afraid it's not enough. Unfortunatelly ignoree is declared "int" so you should test for negative values as well. Also used table is MAX_GENTITIES long, so ignoree being equal MAX_GENTITIES is invalid. Correct test should rather look like this: if ((ignoree < 0) || (ignoree >= MAX_GENTITIES)) return; -- Slawomir Piotrowski / Telsat GP Rejestracja Czasu Pracy i Kontrola Dostepu http://www.ewidencja-czasu-pracy.pl -- ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Publishing exploit code - what is it good for
I'm not too sure if this would help much but from a student standpoint I understand FAR more about how the security works by knowing how to break it, which only really works if I have source code and so full-disclosure exploits. I KNEW what a shellcode and buffer overflow were for years but I only UNDERSTOOD it after I read "Hacking: The Art of Exploitation" because it broke it down for me (excellent book BTW). Now I understand how an overflow exploit works, but don't understand how a particular one works against a particular program without the exploit code that I can go over and go "Oh, so that's how it does it." The idea is that the next generation of security pros (and the current ones I assume) need the information to be a step ahead by understanding the tricks used by the exploit, otherwise they're always playing catch-up to the latest exploit. On 6/30/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > [Because of all the broken autoresponders on bugtraq, the header From: > is a bitbucket. Use the address in the signature to reach me.] > > >> Quote: " If I speak to an end-user organization and they express > >> legitimate needs for exploit code, then I'll change my opinion." > > Well, I'm not an end-user organization, but as an end user[%], the > major benefit I see to full disclosure is that it appears to be close > to the only thing that has any real success at getting vendors to fix > bugs. (In general. There certainly are vendors that stay on top of > things without needing the prod of public exploit disclosure. But they > are notable by their rarity.) > > [%] "End user" is not the only hat I wear. It's just the one I'm > wearing here. > > /~\ The ASCII der Mouse > \ / Ribbon Campaign > X Against HTML [EMAIL PROTECTED] > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > -- "To catch a thief, think like a thief. To catch a master thief, be a master thief." ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] plz suggest security for DLL functions
> We are developing a software that makes use of a COM DLL. The whole > logic lies in the dll. The User Interface is in VC++. DLL exposes > functions, application calls it and displays result. Now, we found > that anybody can copy the DLL, register it and make use of those > functions. > > Please guide us in making those functions secret or encrypted so that > others cannt use our functions. Ironically, nobody seemed to address the fact you're using a COM DLL, not just 'some' DLL. COM has a mechanism that addresses your basic needs, although as many here pointed out, does not protect your code from the prying eyes of more sophisticated attackers. COM object activation is performed by a class factory object that resides in the COM binary. Normally, the class factory object would not be re-implemented by the designer of the COM object, as it's mostly boiler-plate code (implementing the IClassFactory interface). However, COM does support a limited version of licensing by providing a boiler-plate implementation of an alternative class factory object interface - IClassFactory2. Beside that, you can in fact write your own class factory object interface, with the slight disadvantage that the users of your COM object will then have to be aware of having to use CoGetClassObject() and use it to create object instances, instead of just calling CoCreateInstance() or using smart pointer wrappers (in VC++), etc. So if you don't need to protect your code (which resides in the COM binary, whatever you do) from sophisticated attackers, you might want to follow some licensing pattern and use the IClassFactory2 interface or implement your own. But if you want to take a more defensive approach, you could write your own class factory object interface and have it implement security measures such as those others on the list suggested. It will make the user of your object experience as little inconvenience as possible, while at the same time providing the security you need. Finally, I'd like to address the remote server issue brought up on the list - it is possible to host the COM DLL on a remote server (using a surrogate process), without resorting to implementing some sort of RPC mechanism yourself. Then, you have the option to exercise full access control to the COM object using the dcomcnfg utility or by making changes to the object code manually. -- Sasha Goldshtein ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
[Full-disclosure] Advisory 05/2005: Cacti Authentification/Addslashes Bypass Vulnerability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hardened - PHP Project
www.hardened-php.net
-= Security Advisory =-
Advisory: Cacti Authentification/Addslashes Bypass Vulnerability
Release Date: 2005/07/01
Last Modified: 2005/07/01
Author: Stefan Esser [EMAIL PROTECTED]
Application: Cacti <= 0.8.6e
Severity: A HTTP headers bypass switch can also be used
to completely bypass the authentification system
of Cacti. As admin it is possible to execute shell
commands with the permission of the webserver.
Risk: Critical
Vendor Status: Vendor has released an updated version
References: http://www.hardened-php.net/advisory-052005.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."
While looking at the source of Cacti a HTTP headers bypass switch
was discovered, that also switches off a call to session_start()
and the manual application of addslashes() in case of
magic_quotes_gpc=Off.
When register_globals is turned on* an attacker can use this
switch to disables Cacti's use of PHP's session support and
therefore supply the session variables on his own through f.e.
the URL. Additionally using the switch renders several SQL
statements vulnerable to SQL Injections attacks, when
magic_quotes_gpc is turned off, which is the recommended setting.
Logged in as an admin it is possible to issue shell commands.
(*) register_globals is turned off by default since PHP 4.2 but
is activated on most servers because of older scripts requiring it.
Details:
Within "config.php" there is code to bypass the output of
several HTTP headers for caching purposes. This is controlled
by the 'no_http_headers' switch. When register_globals is on
a potential attacker can control this f.e. through one of the
URL variables.
if ((isset($no_http_headers) ? $no_http_headers : false) != true) {
/* we don't want these pages cached */
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
...
header("Pragma: no-cache");
/* initilize php session */
session_start();
/* detect and handle get_magic_quotes */
if (!get_magic_quotes_gpc()) {
function addslashes_deep($value) {
$value = is_array($value) ? array_map('addslashes_deep',
$value) : addslashes($value);
return $value;
}
$_POST = array_map('addslashes_deep', $_POST);
$_GET = array_map('addslashes_deep', $_GET);
$_COOKIE = array_map('addslashes_deep', $_COOKIE);
}
...
}
The problem with this is, that not calling session_start() also
means, that the _SESSION superglobal is never created and
therefore it is possible to overwrite _SESSION["sess_user_id"]
or other session variables because of register_globals.
This means that any request, that comes f.e. with a
Cookie: _SESSION[sess_user_id]=1;no_http_headers=1;
will be automaticly logged in as user 1 (which is usually the
admin).
On the other hand it is quite obvious that the no_http_headers
switch will disable the automatic addslashes() on _GET, _POST
and _COOKIE which can lead f.e. to SQL Injections on the login
formular when magic_quotes_gpc is turned off, which is the
recommended setting.
Logged in as an admin the attacker can execute arbitrary
shell commands by f.e. changing the path to rrdtool in the
configuration into commands of his choice and then triggering it
by viewing a graph.
Because of this register_globals=On problem we recommendend that
the Cacti developers add a register_globals deregistration layer
to Cacti. This is usually a recommendation from us to everyone
writing PHP applications, because programmers that use the _GET,
_POST and _COOKIE superglobals are often under the wrong assumption,
that their code will only run on servers with register_globals
turned off and still do not initialise their variables properly.
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
ht
[Full-disclosure] Advisory 04/2005: Cacti Remote Command Execution Vulnerability
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hardened - PHP Project
www.hardened-php.net
-= Security Advisory =-
Advisory: Cacti Remote Command Execution Vulnerability
Release Date: 2005/07/01
Last Modified: 2005/07/01
Author: Stefan Esser [EMAIL PROTECTED]
Application: Cacti <= 0.8.6e
Severity: Wrongly implemented user input filters allows
injection of user input into executed commandline
Risk: Critical
Vendor Status: Vendor has released an updated version
References: http://www.hardened-php.net/advisory-042005.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."
Alberto Trivero posted his Remote Command Execution Exploit for
Cacti <= 0.8.6d to Bugtraq on the 22th June. Having analysed his
bug we come to the conclusion, that the malfunctioning input
filters, which were already mentioned in the previous advisory
are also responsible for this bug still being exploitable.
Details:
With the recent release of Cacti 0.8.6e a number of user input
filters were added to the codebase to prevent a number of
SQL Injection problems.
However these user input filters that made Alberto Trivero
believe, that his remote command execution vulnerability was
also fixed, are wrongly implemented and therefore can be
bypassed to execute arbitrary commands on the webserver.
To demonstrate the problem here a snipset of "graph_image.php"
/* = input validation = */
input_validate_input_number(get_request_var("graph_start"));
input_validate_input_number(get_request_var("graph_end"));
input_validate_input_number(get_request_var("graph_height"));
input_validate_input_number(get_request_var("graph_width"));
input_validate_input_number(get_request_var("local_graph_id"));
input_validate_input_number(get_request_var("rra_id"));
/* */
...
/* override: graph start time (unix time) */
if (!empty($_GET["graph_start"])) {
$graph_data_array["graph_start"] = $_GET["graph_start"];
}
...
print rrdtool_function_graph($_GET["local_graph_id"],
$_GET["rra_id"], $graph_data_array);
On the first look this code looks like it has fixed the remote
command execution vulnerability through the 'graph_*' request
parameters, because it requires them to be a number before
passing them to the rrdtool.
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["graph_start"] instead of
$_GET["graph_start"]. 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["graph_start"] and $_POST["graph_start"], only
the posted value will end up in the $_REQUEST array.
This however means, that an attacker can still inject shell
commands by supplying the injection 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.
The bug described in this advisory is an input filtering malfunction.
This is related to, but not exactly the bug Alberto Trivero found,
because when he audi
[Full-disclosure] 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 [EMAIL PROTECTED]
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] Advisory 03/2005: Cacti Multiple SQL Injection Vulnerabilities
-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 [EMAIL PROTECTED]
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 I 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
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
iD8DBQFCw7lBRDkUzAqGSqERAiBrAJ0T3FlbaBFsZ2qP8ksVNchBhW6KcgCgjVfg
oeCyHNmE0aB6tHUE1QeL7As=
=IswA
-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/
