CVE-2023-29689 / From SSTI to RCE: Unveiling Vulnerabilities in PyroCMS
Whats is Pyro?
Pyro is a content management system (CMS) that was built using the PHP programming language. It was created with the intention of being user-friendly and easy to use, allowing users to create, manage, and publish content on their websites with ease. One of the main advantages of Pyro is its modular design, which enables developers to extend its functionality using plugins and add-ons. Additionally, Pyro’s user-friendly interface allows non-technical users to manage their site without requiring extensive coding knowledge. Ultimately, PyroCMS is a versatile and powerful solution for website creation and management.
This vulnerability on version 3.9
Before anything, let’s talk about the vulnerability of SSTI — Server Side Template Injection.
SSTI, or Server-Side Template Injection, is a vulnerability that occurs in web applications when untrusted user input is used in dynamic templates to generate dynamic web pages. This can result in the execution of arbitrary code on the server, potentially leading to data theft, manipulation, or unauthorized access to sensitive information. The impact of this vulnerability is significant, as it can compromise the security and privacy of a system and its users. It is therefore crucial to thoroughly validate and sanitize user input to prevent this type of attack.
Poc:
I used the technique {{7*7}} in Twig, which returned a response of 49. Using this same approach, I was able to execute server-side commands by using the command {{[‘id’]|map(‘system’)|join}}, which returned the user’s ID. This demonstrates how the vulnerability of SSTI can be exploited to execute arbitrary code on the server. It is important to take measures to prevent SSTI attacks, such as input validation and sanitization, to ensure the security and privacy of web applications.
Continuing with my investigation, I discovered the same SSTI vulnerability in another field of the system. This time, I encountered the issue while navigating to the “Users > Roles” section. Upon editing the Admin role, I observed that the field “Description” was also susceptible to SSTI attacks.
By injecting template code into the “Description” field, I was able to execute arbitrary commands on the server and obtain sensitive information. For instance, using the payload:
{{[‘cat /etc/passwd’]|map(‘system’)|join}}
I successfully retrieved the contents of the “/etc/passwd” file.
Result of the executed command:
Even with authentication and elevated permissions, the SSTI vulnerability poses a significant risk. In an authenticated context, an attacker with malicious intent could exploit the vulnerability to escalate privileges, gain unauthorized access to sensitive information, and potentially execute arbitrary code on the server.
Furthermore, if there is a security breach resulting in leaked passwords or compromised accounts, an attacker could leverage the SSTI vulnerability to pivot within the system, making it easier for them to traverse through different components and escalate their privileges further.
Additionally, skilled Red Team operators can utilize the SSTI vulnerability as an entry point during penetration testing exercises. By exploiting this weakness, they can simulate real-world attack scenarios and assess the overall security posture of the system. This could potentially lead to the identification of additional vulnerabilities and areas for improvement in the system’s defenses.
Thanks a lot for reading my article! I hope you enjoyed it as much as I enjoyed writing it. If you learned something new or found it helpful, then my job here is done.
Anyway, it’s time for me to wrap things up and say farewell. Until next time, keep on hacking… I mean, keep on learning! Take care and stay safe out there. Cheers! 🖤 🧁
