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

Authenticated Remote Code Execute #342

Closed
f1shh opened this Issue Sep 13, 2018 · 7 comments

Comments

Projects
None yet
3 participants
@f1shh

f1shh commented Sep 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@timbuckingham

timbuckingham Sep 13, 2018

Collaborator

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?

Collaborator

timbuckingham commented Sep 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@attritionorg

attritionorg Sep 14, 2018

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

attritionorg commented Sep 14, 2018

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

@f1shh

This comment has been minimized.

Show comment
Hide comment
@f1shh

f1shh Sep 14, 2018

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.

f1shh commented Sep 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@timbuckingham

timbuckingham Sep 14, 2018

Collaborator

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!

Collaborator

timbuckingham commented Sep 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@f1shh

f1shh Sep 14, 2018

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.

f1shh commented Sep 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@timbuckingham

timbuckingham Sep 14, 2018

Collaborator

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.

Collaborator

timbuckingham commented Sep 14, 2018

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

This comment has been minimized.

Show comment
Hide comment
@f1shh

f1shh Sep 14, 2018

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.

f1shh commented Sep 14, 2018

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.

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