An attacker might get administrative access to a web application. However, this does not automatically mean that the web server can be compromised. In cases where a SaaS application is made available to users, it is routine to give each user admin access to his own instance of the web application e.g. a managed hosted Wordpress site. In such scenario, the attacker who will begin accessing the application as a managed administrative user will have to figure out how to exploit the administrative interface to get a shell on the server. In some cases, it might be possible to do privilege escalation as well.
In the exercise below, the attacker has administrative access to the web application and needs to find a remote code execution attack to run arbitrary commands on the server.
Monstra CMS is a free and open source lightweight content management system written in PHP.
Monstra CMS (3.0.4) is vulnerable to a Remote Code Execution documented in CVE-2018-9037.
The following username and passwords may be used to explore the application and/or find a vulnerability which might require authenticated access:
- Username: admin
- Password: password
Level difficulty: Intermediate
Category: Webapps CVEs > Remote Code Execution
On this lab, I got a basic installation of Monstra CMS (3.0.4) which is known to be affected by multiple vulnerabilities.
The version of the application is mentioned on the admin panel login page.
After researching on the internet for this specific vulnerability and all its features, I discovered this exploit:
As stated in the exploit, I logged in with the provided lab credentials:
I accessed the file manager on the following page:
I have created and uploaded my backdoor according to the public exploit:
When I tried to execute the uploaded backdoor I encountered the following issue:
The current server does not recognize
.PHP file extension as an
.php executable file. Unfortunately, not all exploits work as expected or under multiple systems or server configurations. At this point I decided to take a look at the current theme:
As expected, the theme files can be edited and can execute custom PHP code, so I inserted my backdoor as such:
Wherever theme files are executed, an attacker can send custom payloads in order to execute local system commands. For example: