SECUNIA ADVISORY ID: SA24224
VERIFY ADVISORY: http://secunia.com/advisories/24224/
CRITICAL: Moderately critical
IMPACT: Manipulation of data
WHERE: >From remote
SOFTWARE:
PHP-Nuke 8.x - http://secunia.com/product/13524/
PHP-Nuke 7.x - http://secunia.com/product/2385/
PHP-Nuke 6.x - http://secunia.com/product/329/
PHP-Nuke 5.x - http://secunia.com/product/689/
DESCRIPTION: Maciej "krasza" Kukla has discovered a vulnerability in PHP-Nuke, which can be exploited by malicious people to conduct SQL injection attacks.
Input passed via the "referer" HTTP header in index.php is not properly sanitised before being used in a SQL query. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code. The vulnerability is confirmed in version 7.9 and reported in version 8.0. Other versions may also be affected.
SOLUTION: Edit the source code to ensure that input is properly sanitised.
PROVIDED AND/OR DISCOVERED BY: Maciej "krasza" Kukla
Related
Re: PHP-Nuke HTTP *referer* SQL Injection Vulnerability (Score: 1) |  | To fix this, you can either go into your admin panel and set "Activate HTTP Referers?" to no, and/or do the following. In index.php, find the line of code:
Add 1 line after it so that it looks like this:
|
Re: PHP-Nuke HTTP *referer* SQL Injection Vulnerability (Score: 1) | | I am looking at the Nuke Patched version (have only looked at 7.6) and I do not believe it can be exploited. Here is the code from the patched version: if ($httpref == 1) { if (isset($_SERVER['HTTP_REFERER'])) { $referer = $_SERVER['HTTP_REFERER']; $referer = check_html($referer, "nohtml"); } if (!empty($referer) && !stripos_clone($referer, "unknown") && !stripos_clone($referer, "bookmark") && !stripos_clone($referer, $_SERVER['HTTP_HOST'])) { $result = $db->sql_query("INSERT INTO ".$prefix."_referer VALUES (NULL, '".$referer."')"); } $numrows = $db->sql_numrows($db->sql_query("SELECT * FROM ".$prefix."_referer")); if($numrows>=$httprefmax) { $result2 = $db->sql_query("DELETE FROM ".$prefix."_referer"); } } HOWEVER, IMO, initializing your variables upfront is always the right thing to do! So, I am going to add Gremmies code nonetheless to RavenNuke 2.10.00. |
| Re: PHP-Nuke HTTP *referer* SQL Injection Vulnerability (Score: 1) by Dawg on Friday, February 23, 2007 @ 09:22:53 UTC (User Info | Send a Message) | |
So this is what it should look like? if ($httpref == 1) { $referer = ''; if (isset($_SERVER['HTTP_REFERER'])) { $referer = $_SERVER['HTTP_REFERER']; $referer = check_html($referer, "nohtml"); } if (!empty($referer) && !stripos_clone($referer, "unknown") && !stripos_clone($referer, "bookmark") && !stripos_clone($referer, $_SERVER['HTTP_HOST'])) { $result = $db->sql_query("INSERT INTO ".$prefix."_referer VALUES (NULL, '".$referer."')"); } $numrows = $db->sql_numrows($db->sql_query("SELECT * FROM ".$prefix."_referer")); if($numrows>=$httprefmax) { $result2 = $db->sql_query("DELETE FROM ".$prefix."_referer"); } } |
| Re: PHP-Nuke HTTP *referer* SQL Injection Vulnerability (Score: 1) by Gremmie on Friday, February 23, 2007 @ 12:32:55 UTC (User Info | Send a Message) | |
Yes I think so. |
| Re: PHP-Nuke HTTP *referer* SQL Injection Vulnerability (Score: 1) by Gremmie on Friday, February 23, 2007 @ 12:32:31 UTC (User Info | Send a Message) | |
Montego, I believe it can be exploited even with the patches because the attacker could supply a value for $referer in the get or post arrays. As long as $_SERVER['HTTP_REFERER'] wasn't set (can this be done?), since register_globals is on, the code would use the bad one. They should have initialized $referer before use instead of conditionally assigning it. |
| Re: PHP-Nuke HTTP *referer* SQL Injection Vulnerability (Score: 1) by montego on Sunday, February 25, 2007 @ 18:21:17 UTC (User Info | Send a Message) http://montegoscripts.com | |
Actually, the more I look at this the more I wonder if the Advisory isn't "bunk". I agree with you, though, that one should ALWAYS properly initialize variables and I would suggest this fix be applied just in case (there is another instance in modules/News/categories.php possibly). In looking at the code, mySQL will not allow (in almost ALL setups) multiple INSERT, UPDATE or DELETE statements in the same query. Even the SELECT is really only being used for a numrows count, so it isn't really exposing anything? What am I missing? |
| Re: PHP-Nuke HTTP *referer* SQL Injection Vulnerability (Score: 1) by Gremmie on Sunday, February 25, 2007 @ 18:37:18 UTC (User Info | Send a Message) | |
An attacker could supply a value for $referer (say in the $_GET array by forming up an appropriate URL). Then, if and only if $_SERVER['HTTP_REFERER'] is not set (??) then the attacker's $referer would be used in the SQL query. The code should have initialized $referer = ''; and not left it open for conditional tampering. |
| Re: PHP-Nuke HTTP *referer* SQL Injection Vulnerability (Score: 1) by montego on Monday, February 26, 2007 @ 23:23:03 UTC (User Info | Send a Message) http://montegoscripts.com | |
But, my point Gremmie, is walk through the effect of doing that. What I am saying is that even if I do pass a value in the referer, what could I possibly exploit. See my previous note. If you would like to take this off-line, that is fine by me, if you are not wanting to be any more specific in public. |
![[Valid RSS]](https://www.ravenphpscripts.com/images/valid-rss.png "Validate my RSS feed"){kind=small}
