Multi sql injection w Phorum

Podczas kontroli kodu źródłowego, nasz dział software security znalazł kilka błędów typu blind sql injection w oprogramowaniu Phorum3.

Phorum3 ma poważną wadę konstrukcyjną, sprawiającą iż oprogramowanie to działa w trybie register_globals=on niezależnie od ustawień w php.ini.

Winny jest plik: include/register_globals.php (includowany z commons.php), który w całości cytuję poniżej:

if (!defined("_COMMON_PHP")) return;
 if(isset($_SERVER)){
     $arrays=array(
                $_SERVER,
                $_ENV,
                $_GET,
                $_POST,
                $_COOKIE
    );
 } else {
     $arrays=array(
                $HTTP_SERVER_VARS,
                $HTTP_ENV_VARS,
                $HTTP_GET_VARS,
                $HTTP_POST_VARS,
                $HTTP_COOKIE_VARS
    );
 }

foreach($arrays as $array){
     foreach($array as $var=>$val){
        if(!isset($GLOBALS[$var])){
            $$var = $val;
        }
    }
}

Komentarz w temacie za co odpowiada ten plik wydaje się być zbędny. 

Pierwszy SQLi:

http://phorum/forum/search.php?f=1&search=test&...&globalsearch=1
&searchforums[0]=sqli

Przy tworzeniu zapytania SQL nie jest walidowana tablica $searchforums,
linijka 186, plik search.php:

http://phorum/forum/search.php?f=1&search=test&...&globalsearch=1
&searchforums[0]=sqli

search.php:

183.  if($globalsearch){
184.                  $SQL="Select id, name, table_name from $pho_main where";
185.                  if(isset($searchforums)){
186.                      $SQL.=" id in (".implode(",", $searchforums).")";
187.                  } else {
188.                      $SQL.=" (active=1 or id=$num)";
189.                  }
190.                  if(!isset($phorum_user['id'])){
191.                      $SQL.=" and security!=".SEC_ALL;
192.                  }
193.                  $q->query($DB, $SQL);
194.                  $row = $q->getrow();
195.              } else {
196.                  $row=array("id"=>$num, "name"=>$ForumName, "table_name"=>$ForumTableName);
197.              }

Drugi SQLi:

http://phorum/forum/search.php?f=1&search=test&...&fields[0]=sqli

search.php, problem jak w pierwszym SQL injection:

87.                reset($fields);
88.                unset($likeArray);
89.                while (list ($key, $val) = each ($fields)) {
90.                    $term=addslashes($term);
91.                    if(strstr($DB->type, "postgresql")){
92.                        $likeArray[]=" upper($val) $notmod"."~~ upper('%$term%') ";
93.                    } else {
94.                        $likeArray[]=" $val $notmod"."LIKE '%$term%' ";
95.                   }
96.                }

Trzeci SQLi:

http://phorum/forum/read.php?f=1&...&ids[0]=sqli

Z pliku  read.php wywolywana jest funkcja phorum_get_users()
bez walidacji parametru przekazywanego do funkcji.

Funkcja phorum_get_users() znajduje się w pliku include/userlogin.php, a interesujący fragment cytuję poniżej:

291.  function phorum_get_users($ids) {
292.    global $DB,$q,$PHORUM;
293.     // Get the user info.  I curse PG for not having Left Joins.
294.     $SQL="select id, username, email, signature from ".$PHORUM["auth_table"]." where id in (".implode(",", $ids).")";
295.     $q->query($DB, $SQL);
296.     $rec=$q->getrow();
297.     While(is_array($rec)){
298.        $users[$rec["id"]]=$rec;
299.    $rec=$q->getrow();
300.     }
301.     return $users;
302.  }

Podatności były testowane na wersji 3.4.8a phorum. Jest to wersja oficjalnie oznaczona na stronie producenta jako  niesupportowana. Vendor po zgłoszeniu przez nas błędu odmówił wypuszczenia patcha, właśnie powołując się na ww. fakt.

Z naszych doświadczeń wynika jednak, że phorum3 jest cały czas intensywnie wykorzystywane w Internecie, również w nowych projektach - informacja o znalezionych przez nas podatnościach może być więc przydatna.