Authenticated Remote Code Execute

[f1shh]

FILE:
/core/admin/auto-modules/forms/process.php

	if ($bigtree["form"]["hooks"]["post"]) {
		call_user_func($bigtree["form"]["hooks"]["post"],$edit_id,$item,$did_publish);
	}

We can set $bigtree["form"]["hooks"]["post"] as preg_replace and use the "\e" modifier to execute arbitrary code.

poc:

[timbuckingham]

Developer level users have complete code execution access (they can both write to the filesystem and use eval through field parsers) and they are the only ones able to access hooks. Am I misunderstanding and there's a way for regular users or admins to set hooks?

[attritionorg]

Despite that, it got assigned CVE-2018-17030 =(

[f1shh]

Developer level users have complete code execution access (they can both write to the filesystem and use eval through field parsers) and they are the only ones able to access hooks. Am I misunderstanding and there's a way for regular users or admins to set hooks?

As long as some social engineering methods are used to let developer level users set $bigtree["form"]["hooks"]["post"] to preg_replace, admin and regular users with module editing access can execute arbitrary code remotely.

As a security researcher, my goal is to investigate whether there are vulnerabilities in the system, not all vulnerabilities must be easy to apply.

If you think that what I said is unreasonable and that this is not a vulnerabilities, then you can choose to ignore it.

Thank you.

[timbuckingham]

Can you tell me more on what the social engineering angle would be there? Usually it's something like a cross site request forgery attack. If the attack is limited to a situation where you can access someone's user account through them giving you a username and password there is all kinds of damage they could do.

Thanks!

[f1shh]

Can you tell me more on what the social engineering angle would be there? Usually it's something like a cross site request forgery attack. If the attack is limited to a situation where you can access someone's user account through them giving you a username and password there is all kinds of damage they could do.

Thanks!

The attacker does not necessarily need to obtain a developer level user's account, just try to trick the developer level users into having $bigtree["form"]["hooks"]["post"] set to preg_replace. This way the attacker only needs to have an administrator account or a normal account with module edit permission. preg_replace looks less dangerous than eval, assert , so it is easier to deceive others.

[timbuckingham]

I'm not really buying that line of logic. Having another user account "trick" a developer into inserting a hook doesn't really sound like something the person who made the site would just do without a reason.

[f1shh]

I'm not really buying that line of logic. Having another user account "trick" a developer into inserting a hook doesn't really sound like something the person who made the site would just do without a reason.

I think that a vulnerability is still a vulnerability even if it is difficult to exploit. If you still think this is not a vulnerability, you can ignore it.