[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD3Canczf0QMBQUJdP_BdbN0nFE-ZgzSwBGXyJJZ4qES=y5_cA@mail.gmail.com>
Date: Sat, 25 Apr 2015 12:04:05 +1200
From: Matthew Daley <mattd@...fuzz.com>
To: oss-security@...ts.openwall.com
Cc: cve-assign@...re.org
Subject: CVE requests / Advisory: phpMyBackupPro
I'd like to request CVE IDs for these issues in phpMyBackupPro. This
is the first such request; this message serves as an advisory as well.
Unfortunately there does not appear to be a public repository to be
able to link directly to code or fixes.
(Note: there are multiple reflected/stored XSS as well, but I didn't
have the time to enumerate and report them all.)
--- Common information
* Affected software: phpMyBackupPro
* Website: http://www.phpmybackuppro.net/
* Changelog: File doc/HISTORY.txt in the release zip file states
"03/26/2015: v.2.5: security fixes in mutli user mode, minor bug
fixes"
* Reported by: Matthew Daley
* Timeline:
2015-03-26: Private disclosure to vendor
2015-03-27: Vendor response
2015-03-31: v2.5 released
2015-04-04: Private note to vendor that some issues (#2, #3, #4 below)
remain unfixed
2015-04-25: Public disclosure
--- Issue #1: SQL injection in multi-user mode
* Affected versions: ? -> 2.4
* Fixed version: 2.5
* Bug entry: https://sourceforge.net/p/phpmybackup/bugs/35/ (still private)
* Description:
In multi-user mode, the username and password given when a user logs
in is not escaped before interpolation into the SQL query that is used
to look up users in the database. Hence, it is vulnerable to a simple
SQL injection attack.
The injection occurs at line 70 of login.php:
$res=mysql_query("select * from user where
(User='".$_POST['username']."' or User='') and
password=password('".$_POST['password']."')");
The documentation given in documentation/MULTI_USER_MODE.txt states:
> You will have to provide the MySQL root account data which are used by phpMyBackupPro to determine all available MySQL users.
Hence, it's highly likely that unauthenticated attackers are able to
enumerate all database entries and complete database configuration
information, such as user password hashes, using this vulnerability. A
tool such as sqlmap can be (and has been) used to do this.
It's also possible to exploit this vulnerability in order to log in as
any user given a victim's username. To do so, an attacker logs in with
the victim's username and the string "') OR 1=1-- " as password.
It's also possible to "log in" without a known username. To do so, an
attacker logs in with a username such as "../../../../../../../../tmp"
(which gets injected into the per-user configuration file path) and
the password string given above. This allows phpMyBackupPro to create
a multi-user config file in the /tmp directory regardless of how the
per-user configuration file path been configured.
In v2.5, this issue is fixed.
--- Issue #2: Arbitrary code execution through user configuration variables
* Affected versions: ? -> 2.5
* Fixed version: none
* Bug entry: https://sourceforge.net/p/phpmybackup/bugs/36/ (still private)
* Description:
It's possible, once logged in to phpMyBackupPro, to execute arbitrary
PHP code. This is done by injecting it into a configuration variable
using a PHP variable variable or by breaking out of the string literal
in which the variable's value is stored in the user's configuration
file.
For example, setting a user's "delete local backups after x days"
configuration variable to the following value causes the file /tmp/xyz
to be created:
${`touch /tmp/xyz`}
The value is stored unchanged in the user's configuration file
(phpMyBackupPro_conf.php) as follows:
$CONF['del_time']=htmlspecialchars_decode("${`touch /tmp/xyz`}");
As the value is not escaped before being interpolated into the
configuration file's content, the embedded PHP code (in this case, a
single backticked shell statement) will be executed when the
configuration file is include_once'd. This includes the next loading
of any phpMyBackupPro page by that user.
(Note: Upon setting the value, the message "delete local backups after
x days' is not correct!" will be displayed; however, the setting is
still written to the user's configuration file.)
In v2.5, it is no longer possible to use PHP variable variables to
gain RCE in this way. However, it is still possible to break out of
the configuration variable's value string literal and achieve RCE in
other ways (e.g. \');`touch /tmp/xyz`;// ).
--- Issue #3: Information disclosure through get_file.php functionality
* Affected versions: ? -> 2.5
* Fixed version: none
* Bug entry: https://sourceforge.net/p/phpmybackup/bugs/37/ (still private)
* Description:
It's possible, once logged in to phpMyBackupPro, to view (among other
filetypes) the content of any .php file using the functionality
provided by the get_file.php file. This includes the content of
phpMyBackupPro's own configuration files, which contain sensitive
information such as root database credentials.
For example, after logging in, a request to get_file.php can be made
to retrieve the content of definitions.php by using the following URL:
http://[host]/phpMyBackupPro/get_file.php?view=definitions.php
This will output the content of definitions.php, including the
location of the global configuration file (as the value of the
_PMBP_GLOBAL_CONF variable). Using this information, another request
can be made, this time for this global configuration file:
http://[host]/phpMyBackupPro/get_file.php?view=/[path]/global_conf.php
This will disclose the content of the global configuration file,
including root database credentials.
In v2.5, it is no longer possible to disclose the content of
phpMyBackupPro's configuration files by using get_file.php with a
direct path reference to the configuration file in question. However,
it is still possible by using indirect path references (e.g. replacing
"../../files/global_conf.php" with
"../../files/../files/global_conf.php").
--- Issue #4: Arbitrary code execution through scheduled backup scripts
* Affected versions: ? -> 2.5
* Fixed version: none
* Bug entry: https://sourceforge.net/p/phpmybackup/bugs/38/ (still private)
* Description:
It's possible, once logged in to phpMyBackupPro, to execute arbitrary
PHP code. This is done by injecting it into an automatically-generated
scheduled backup script.
Many of the user-specified parameters used when generating a scheduled
backup script are not correctly escaped before being interpolated into
the script; for example, the "period" parameter.
This can be exploited by eg. using curl:
curl -b 'PHPSESSID=[session cookie]' -d 'man_dirs=x&path=[writeable
path]/&filename=rce.php&period=;echo+"<h1>RCE</h1>"'
'http://[host]/phpMyBackupPro/scheduled.php'
This will lead scheduled.php to create a scheduled backup script named
"rce.php" in the attacker-specified writable path with the following
content:
<?php
// This script was created by phpMyBackupPro v.2.4
(http://www.phpMyBackupPro.net)
// In order to work probably, it must be saved in the directory writable/.
$_POST['man_dirs']="x";
$period=(3600*24);echo "<h1>RCE</h1>";
$security_key="d06378763f9369ceea61663c33e0e8ca";
// switch to the phpMyBackupPro v.2.4 directory
@chdir("/var/www");
@include("backup.php");
// switch back to the directory containing this script
@chdir("writable/");
?>
Note that the "period" value is interpolated into the content without
being escaped. The attacker can then execute the newly-created
"rce.php", along with the injected PHP code, by making a normal HTTP
request for the file.
This obviously requires the attacker to know a web-accessible and
web-writeable directory to pass in as the "path" parameter to
scheduled.php.
In v2.5, it is no longer possible to split the "period" PHP statement
with a semicolon. However, it is possible to still inject code using
many other methods (e.g. .print("RCE") ). There are also other
injectable parameters, e.g. dirs[]=".print("RCE2")."' .
- Matthew Daley
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
