Multiple Vulnerabilities In Invision Power Board

Type securityvulns
Reporter Securityvulns
Modified 2005-05-07T00:00:00


GulfTech Security Research May 5th, 2005

Vendor : Invision Power Services


Version : All Versions Prior To 2.0.4

Risk : Multiple Vulnerabilities

Description: Invision Power Board (IPB) is a professional forum system that has been built from the ground up with speed and security in mind. It is used by a great many people all over the world. All versions of Invision Power Board are vulnerable to a serious SQL Injection vulnerability if magic_quotes_gpc is set to off. An attacker does not have to be logged in, or even have access or permission to view the forums in order to exploit this vulnerability. Users should upgrade immediately.

SQL Injection: I have discovered a serious SQL Injection issue in Invision Power Board that affects most all versions of Invision Power Board regardless of most server configurations. Also, because of the fact that UNION functionality is not needed an attacker need not worry if the victim is running an up to date version of MySQL. The vulnerability lies in the way that Invision Board handles certain types of "login methods". Let us have a look at the source of 'sources/login.php'

if ( ! $ibforums->member['id'] ) { $mid = intval($std->my_getcookie('member_id')); $pid = $std->my_getcookie('pass_hash');

If ($mid and $pid)

$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND


    if ( $member = $DB->fetch_row() )
        $ibforums->member = $member;
        $ibforums->session_id = "";
        $std->my_setcookie('session_id','0', -1 );


This particular portion of code is from the IPB 1. series, but the vulnerability seems to exists on all versions of IPB (both the 1. and 2.* series). Anyway, as we can see from the above code the variable $mid is properly forced into an integer datatype and as a result is safe to pass to the query, but what about $pid? In the above code we see that the value of $pid is returned from the my_getcookie() function within the FUNC class. Well, let us have a look at this function to see if $pid is sanitized within the function itself.

function my_getcookie($name) { global $ibforums;

if (isset($_COOKIE[$ibforums->vars['cookie_id'].$name]))
    return urldecode($_COOKIE[$ibforums->vars['cookie_id'].$name]);
    return FALSE;


In the above code we can see that not only is the data unsanitized, but the way the urldecode() function is used also lets an attacker bypass magic_quotes_gpc. Now, back to the auto_login() function where we want to concentrate on this bit of code.

$DB->query("SELECT * FROM ibf_members WHERE id=$mid AND password='$pid'");

if ( $member = $DB->fetch_row() ) { $ibforums->member = $member; $ibforums->session_id = ""; $std->my_setcookie('session_id','0', -1 ); }

This would be a very easy issue to exploit if visible data was returned to the browser, but all we will be able to see is a line in the response header that looks something like this.

Set-Cookie: session_id=0; path=/;

If we see this then we know the query returned true and produced some results. This is not that easy of an issue to exploit, but there are a number of ways to successfully take advantage of this issue. For one an attacker can select member data into an outfile and use their browser to retrieve that data, or use the MySQL "mid" function to enumerate each character of the hash one by one until the entire hash is discovered! In future versions of MySQL issues like this will be a lot easier to exploit as we will then be able to "SELECT * FROM `blah` INTO TABLE `foobar`" much like Oracle database for example. With functionality like that an attacker can then do things like dump user data into a message to himself. There is working exploit code for this issue available, but we will not be releasing it publicly. Users should upgrade as soon as possible, as this is a fairly dangerous vulnerability.

Cross Site Scripting: It is possible for an attacker to conduct Cross Site Scripting attacks in all versions of invision power board prior to the recently released 2.0.4. This vulnerability exists due to data submitted to the "highlite" parameter not being sanitized properly when displaying search results. The same issue also exists in "sources/topics.php". The only condition is that the data sent to the "highlite" parameter must be double hex encoded data in order to bypass the global sanitation methods.

Solution: Matthew Mecham addressed these issues in a VERY timely and professional manner and fixes have been available for some time now.

All users should upgrade their Invision Power Board installations as soon as possible, as these vulnerabilities make it fairly easy to grab sensitive user data including password hashes from the database.

Special Thanks: GulfTech Security Research team would like to thank Mr. Janek Vind for working with us in finding creative ways to exploit these issues. You can visit his website at :)

Related Info: The original advisory can be found at the following location

Credits: James Bercegay of the GulfTech Security Research Team