OpenCart 4.0.2.3 - Server-Side Template Injection

[PawaritSa]

OpenCart 4.0.2.3

During a routine security assessment, I have identified a potential security vulnerability in OpenCart 4.0.2.3 which I believe could significantly impact its integrity and the safety of its users.

Vulnerability Details
Component Affected:
https://[target]/opencart/admin/index.php?route=design/theme

Vulnerability Type:
Server-Side Template Injection

Potential Impact:
We discovered that an admin user can inject malicious template code into the theme template file, which can lead to Remote Code Execution (RCE).

Steps to Reproduce:
For a detailed step-by-step process on how to reproduce this vulnerability, please refer to the following link: https://docs.stashpad.com/document/doc-uqC6nWKamnddfa7AwkaZzvXV

I am willing to provide any additional information needed to verify or address this issue. I believe that it is in the best interest of both your organization and your users to resolve this vulnerability before it can be exploited.

Additionally, I would like to inquire about the possibility of obtaining a CVE identifier for this vulnerability once confirmed and addressed, to help in documenting and further understanding the security landscape.

I look forward to your prompt response so we can discuss the next steps towards remediation.

[pemaier]

A admin per se is a person who can harm a system - but why a admin should do this??
So this issue is obsolete in my opinion.

[mhcwebdesign]

Looks like @0xb120 has come back here, under a different name :)

This is not a security issue. I am an admin, too, for my websites, and I can easily upload malicious scripts to my sites! By why would I do that?

[PawaritSa]

I understand your perspective that an admin should not intentionally harm the system, it's important to consider the potential risks associated with this vulnerability.The issue here is not about trusted admins, but rather the potential for an attacker who gains admin credentials to exploit this vulnerability for malicious purposes, such as remote code execution (RCE). This could happen if an admin's account is compromised, or if a rogue employee with admin access decides to abuse their privileges.For example, if you hire someone to manage the content of your website and grant them admin access, this vulnerability could allow that employee to exploit your server, even if they were trusted initially. Insider threats are a real concern, and this vulnerability exposes a significant risk.Furthermore, in the event of a data breach or a compromised admin account, the impact of this vulnerability could be severe, potentially allowing attackers to take complete control of the affected system.

[OSWorX]

For example, if you hire someone to manage the content of your website and grant them admin access, this vulnerability could allow that employee to exploit your server, even if they were trusted initially.

Well said and seen a few times in the past!

The problem are not the "real" admins, the problem are "so called developers reachable only by obsure Gmail addresses".
Unfortunately users are only "users" .. and some of them - as it seems - trust anybody!

The problem finally is, if such persons manipulate the system, only a time consuming and expensive investigation can bring up such manipulations.

The current permission system is not able to avoid manipulations IF the user does not restrict the access to only needed functions.
And that's the problem in general, because if someone get the job to change the system, he must have access to several funtions which allow finally to add malicious code.

Something like a reporting tool in the background (who has done when what) would be good to have for such cases.

[mhcwebdesign]

For example, if you hire someone to manage the content of your website and grant them admin access, this vulnerability could allow that employee to exploit your server, even if they were trusted initially.

In the meantime, in the real world, nobody in their right mind would hire a content manager and give them access to the design/theme. The latter is part of a web theme design, not of site content editing. Besides, a professional would use a proper web theme anyway, not something like the Journal3 framework, or the built-in design/theme function.

OpenCart may have security issues, but this isn't one to loose your sleep over. I'd be more worried about bruteforce attackers, spambots, credit card fraudsters, etc, not this one.

[ADDCreative]

Using the Twig Sandbox for the edited templates would help. Would need to set the allowed tags, filters, etc.

$twig = new \Twig\Environment($loader, $config);

if ($code) {
	$tags = ['for', 'if', 'set'];
	$filters = ['batch', 'escape', 'format', 'length', 'round', 'url_encode'];
	$methods = [];
	$properties = [];
	$functions = ['range'];

	$policy = new \Twig\Sandbox\SecurityPolicy($tags, $filters, $methods, $properties, $functions);
	$sandbox = new \Twig\Extension\SandboxExtension($policy, true);

	$twig->addExtension($sandbox);
}

[TheCartpenter]

$filters = ['batch', 'escape', 'format', 'length', 'round', 'url_encode', 'lower', 'join'];

However, adding the suggested restrictions above may also limit the extensions.