Concrete5 <= Remote Code Execution Vulnerability & Exploitation


I decided to work on Concrete5. I chose concrete5 because I discovered few Reflected XSS vulnerability 2 years ago. At the following part, we will describe issue that cause remote code execution, lets start.

PreCode analysis

Concrete5 has been developed with PHP & MySQL power. So If you want to follow instructions step by step. You should install PHP, MySQL and Apache.

Also, As I did, you need to fetch latest version of concrete5 from github.

And final step is IDE.  I have been using PhpStorm. It’s awesome IDE for developers also hacker. We can easily track functions and classes. Of course you can choose what ever you want.

Discovering Phase

Before go further, you need to understand structure of application that you analysis. So I had a look for a while in order to understand that. But I knew where should I focus.

Most application have installation module. Basically application takes form request from person, than validate them all, than finished installation process. In this application cycle, it should write some variables into the configuration files. Like username and password of database management system. here, we have a chance to inject our payload’s codes into the configuration file.

Following POST request’s data captured from browser while i was trying to understand installation process.

Those are our parameters. Now Let’s look source code of installation module. As you can see at up side, function name is configuration.

Lines 4 – 9 : Input validation for SITE, uEmail, DB_DATABASE, DB_SERVER. There is now way to bypass uEmail validation.

Lines 37 – 76 : It creates configuration files and writes variables into the file.

First of all, if you try to cheat on string there is no way in order to by pass addslashes() function. So we cant inject payloads into the configuration file via DB_USERNAME, DB_PASSWORD, DB_DATABASE. Please look closer on lines 38 – 46 .

Secondarily, we cant inject too via  uEmail, uPassword and SITE. Please look closer on lines 62 – 69.

Finally, SAMPLE_CONTENT looks suitable to our duty which located at line 66. But it validates by line 29. If it fails, it returns error and stop execution before creation of configuration file.

Now, let’s look lines 47 – 51.

There is one more user supplied variables which name is SITE_CONFIG. But remember HTTP Post request of installation process. It wasn’t in request! So we can add it manually.

This codes checks SITE_CONFIG is array or not. If so, add them into the $configuration variables which is content of configuration php file. Also there is no addslashes() function! Yummy.

Some how, developers thought that “If we remove input fields from form body. This part will automatically skip.Because SITE_CONFIG wont exists. So leave these codes alone at there. Maybe we will use them later.”


As you understand, I kindly want to remind that this vulnerability DONT work  if concrete5 has already been installed.

Frameworks usually sanitize POST and GET variables on system wide. Deliver command to application via POST or GET is can cause exploitation fails. Also POST, GET and most common HTTP Headers like COOKIE are can be under investigation by Web Application Firewalls. In my opinion, best way is custom HTTP Header Parameter.

In order to return True on line 47. I defined SITE_CONFIG as an array and put PHP payload into that variables.

When I send that request to the Concrete5 It will start installation process immediately.


Installation proccess finished. Now, Lets see content of configuration file which is located at config/site.php .


concrete5_exec Metasploit Module

Also I wrote metasploit modules in order to exploit that vulnerability.

Here is the screenshot of the modules.

concrete5 metasploit

You can get exploit codes from here.


In conclusion

This vulnerability only work if concrete5 has already been installed.

Don’t forget remove useless codes from application.