Page 1 of 1

[Solved] Verified SQL injection in IM1.4.0

PostPosted: Tue Jul 18, 2006 5:58 am
Author: Unregistered
Original link : http://www.attrition.org/pipermail/vim/ ... 00847.html

Ref:

BUGTRAQ:20060606 Multiple Sql injection and XSS in integramod portal
URL:http://www.securityfocus.com/archive/1/archive/1/436457/100/0/threaded

Some VDB's didn't list the SQL injection, but they listed the XSS.

notice in the Bugtraq post that the demo URL is:

http://target/index.php?STYLE_URL=%2527

which decodes to "%27" which, itself, decodes to "'"


So, we have SQL injection by double-decoding.


from includes/functions.php of a 1.4.0 download:

if ( isset($HTTP_POST_VARS[STYLE_URL]) || isset($HTTP_GET_VARS[STYLE_URL]) )
{
$style = urldecode( (isset($HTTP_POST_VARS[STYLE_URL])) ? $HTTP_POST_VARS[STYLE_URL] : $HTTP_GET_VARS[STYLE_URL] );
if ( $theme = setup_style($style) )
{

....

if ( isset($HTTP_COOKIE_VARS[$board_config['cookie_name'] . '_style']) )
{
$style = $HTTP_COOKIE_VARS[$board_config['cookie_name'] . '_style'];
if ( $theme = setup_style($style) )
{


...

function setup_style($style)
{
global $db, $board_config, $template, $images, $phpbb_root_path, $var_cache, $portal_config, $current_template_path;

// BEGIN Style Select MOD
if ( intval($style) == 0 )
{
$sql = "SELECT themes_id
FROM " . THEMES_TABLE . "
WHERE style_name = '$style'";



So... setup_style() checks if its $style argument equates to an
integer value of 0, which is the case with most arbitrary non-numeric
strings as I understand it.

But it then just feeds '$style' into a SQL query.

I would venture a guess that the "%2527" string is first decoded to
"%27" by PHP itself (this is mentioned in a comment in the online PHP
manual entry for urlencode), and then the "urldecode" call will then
translate the "%27" to a "'".


- Steve

Re: Verified SQL injection in IM1.4.0 (source inspection)

PostPosted: Tue Jul 18, 2006 9:13 am
Author: Unregistered

Re: Verified SQL injection in IM1.4.0 (source inspection)

PostPosted: Thu Jul 20, 2006 12:29 pm
Author: Teelk
We're aware of this and are working on a fix.

Re: Verified SQL injection in IM1.4.0 (source inspection)

PostPosted: Thu Jul 20, 2006 2:43 pm
Author: Unregistered
i have this idea.. wil it be ok if we can have a htaccess file and redirect STYLE_URL=%2527 to forward to http://127.0.0.1 ?

The followin codes are to prevent Santy worms (%2527 vulnerability)

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^.*$
RewriteRule ^.*%27.*$ http://127.0.0.1/ [redirect,last]
RewriteRule ^.*%25.*$ http://127.0.0.1/ [redirect,last]
RewriteRule ^.*rush=.*$ http://127.0.0.1/ [redirect,last]
RewriteRule ^.*echr.*$ http://127.0.0.1/ [redirect,last]
RewriteRule ^.*esystem.*$ http://127.0.0.1/ [redirect,last]
RewriteRule ^.*wget.*$ http://127.0.0.1/ [redirect,last]

cant we apply the same method to index.php?STYLE_URL=%2527 to redirect http://127.0.0.1/ ?

anyone familiar with htaccess please give an adivce..

Re: Verified SQL injection in IM1.4.0 (source inspection)

PostPosted: Sat Aug 26, 2006 4:48 am
Author: ihammo
Was a fix for this ever found and published?

PostPosted: Sat Aug 26, 2006 5:35 pm
Author: Dioncecht
"Unregistered";p="12044" wrote:Original link : http://www.attrition.org/pipermail/vim/ ... 00847.html

Ref:

BUGTRAQ:20060606 Multiple Sql injection and XSS in integramod portal
URL:http://www.securityfocus.com/archive/1/archive/1/436457/100/0/threaded

Some VDB's didn't list the SQL injection, but they listed the XSS.

notice in the Bugtraq post that the demo URL is:

http://target/index.php?STYLE_URL=%2527

which decodes to "%27" which, itself, decodes to "'"


So, we have SQL injection by double-decoding.


from includes/functions.php of a 1.4.0 download:

if ( isset($HTTP_POST_VARS[STYLE_URL]) || isset($HTTP_GET_VARS[STYLE_URL]) )
{
$style = urldecode( (isset($HTTP_POST_VARS[STYLE_URL])) ? $HTTP_POST_VARS[STYLE_URL] : $HTTP_GET_VARS[STYLE_URL] );
if ( $theme = setup_style($style) )
{

....

if ( isset($HTTP_COOKIE_VARS[$board_config['cookie_name'] . '_style']) )
{
$style = $HTTP_COOKIE_VARS[$board_config['cookie_name'] . '_style'];
if ( $theme = setup_style($style) )
{


...

function setup_style($style)
{
global $db, $board_config, $template, $images, $phpbb_root_path, $var_cache, $portal_config, $current_template_path;

// BEGIN Style Select MOD
if ( intval($style) == 0 )
{
$sql = "SELECT themes_id
FROM " . THEMES_TABLE . "
WHERE style_name = '$style'";



So... setup_style() checks if its $style argument equates to an
integer value of 0, which is the case with most arbitrary non-numeric
strings as I understand it.

But it then just feeds '$style' into a SQL query.

I would venture a guess that the "%2527" string is first decoded to
"%27" by PHP itself (this is mentioned in a comment in the online PHP
manual entry for urlencode), and then the "urldecode" call will then
translate the "%27" to a "'".


- Steve



um.. what?

Re: Verified SQL injection in IM1.4.0 (source inspection)

PostPosted: Sat Aug 26, 2006 6:45 pm
Author: Drop-Forged
I had to read that a few times to figure out what he was saying too.


I think he was saying that a hacker could use a URL command line that would allow them to insert something into your SQL database, by taking advantage of a security hole in the includes/function.php.

Its the line of code that allows people to choose their own template.


Somebody please correct me if Im wrong... <img>

PostPosted: Sun Aug 27, 2006 6:11 am
Author: Unregistered
actually i came to know abt this bug more then a month ago.. its a Cross-Script vulnerability it seems.. check the following link .. a friend of mine said i have that bug in my site.. and the cmd he applied also there.. but i have no idea what exactly that cmd do..

http://integramod.com/forum/viewtopic.php?t=1583

PostPosted: Wed Sep 20, 2006 12:27 pm
Author: Unregistered

PostPosted: Tue Sep 26, 2006 4:44 pm
Author: computerz
"Unregistered";p="15702" wrote:Solved!

http://integramod.com/forum/viewtopic.php?t=1944


This really doesn't solve the injection. It solves another problem which in turn takes care of the issue you reported. To stop sql injection you merely escape your syntax properly.

So instead of $SQL = "SELECT * FROM table WHERE column=$variable";

you use $SQL = "SELECT * FROM table WHERE column='".$variable."';

This way no matter what is inputted it is properly sent to the database as a variable and not as an injection.