Multiple vulnerabilities in Concrete CMS – part2 (PrivEsc/SSRF/etc)


We have previously wrote about Concrete CMS here. In that post we described how we managed to exploit a double race condition vulnerability in the file upload functionality in order to obtain remote command execution. In this blog post we will present multiple vulnerabilities in Concrete CMS that we have found at the end of last year during a pentest for one of our customers. For more info please see the “Mitigations” section regarding security tips for fixing the password poisoning issue and other tips on improving security for Concrete CMS.

Privilege escalation

Let’s start with the privilege escalation issue that we have found when we started our testing. User groups have an hierarchical structure and they inherit permissions from one another. We had a user with limited privileges “Editor”, thus we have asked ourselves what would happen if we try to move our “Editors” group under “Administrators”, would we inherit their privileges too?

First attempt to move Editors under Admin group
First attempt to move Editors under Admin group
Concrete CMS multiple vulnerabilities - Attempt failed

Attempt failed

Well damn, it looks like our attempt failed and the developer actually thought of this and he’s checking our permissions in the backend. But this is not all, we discovered another endpoint where we could try the same operation, so let’s try again and see if permission checks are consistent on all endpoints 😉

Second attempt to move Editors under Administrators Group
Second attempt to move Editors under Administrators Group
Concrete CMS multiple vulnerabilities -PrivEsc issue
Editors group now under Administrators, inheriting their privileges

Well, look at this, it seems that they forgot to implement the permission checks on this endpoint and we’ve managed to move the “Editors” group under “Administrators” using a user with very limited permissions (“Editor” role). We had to logout and login again in order to refresh our session and our permissions. And voila, we’re now an “Administrator” with access to the entire control panel 😉

Concrete CMS multiple vulnerabilities -  PrivEsc  succeeded, we're now Admin
PrivEsc succeeded, we’re now Admin


As discussed in part1, the control panel contains a SSRF by design feature. We showed how we got RCE in the previous post, however the first thing that we actually exploited was this SSRF. It was obvious that this SSRF was exploited previously and now they had some mitigations in place. The purpose of this feature is to allow editors to download a file from a remote server and save it locally.

Concrete CMS multiple vulnerabilities - SSRF by design
SSRF by design

We used a Collaborator payload from Burp Suite and we instantly got a callback:

Concrete CMS multiple vulnerabilities -SSRF Callback received
Callback received

AWS Instance metadata is blocked, oh no! Can we bypass these fixes?

Instance Metadata is not allowed
Instance Metadata is not allowed

They check for certain file extensions (.php & others) and you can’t use redirects either. What else can we do?

Redirects are not allowed/Blacklists are also used for extensions
Redirects are not allowed/Blacklists are also used for extensions

Pivoting into the LAN

We managed to bypass the extension blacklist with a well known php trick ( /info.php/test.html still requests info.php but the CMS now considers .html to be the requested extension which is whitelisted, while the server will actually execute a .php extension). After that, we were able to pivot into the local network, accessing internal web-servers.

Pivoting inside the LAN
Pivoting inside the LAN

You can use this to enumerate and fingerprint internal web applications. Here we’re reading the output of a typical phpinfo file stored on an internal webserver.

Concrete CMS multiple vulnerabilities --Pivoting into the LAN
Accessing internal web servers

Pivoting into the LAN was nice, you can chain this with various one shot GET exploits, but this was not enough for us. The wholly grail in a cloud environments is accessing the Instance Metadata server and stealing the IAM credentials. We’ve managed to achieve this using our good old friend DNS rebinding. Thanks to emil_lerner for providing this very useful service. As a tip, you might have to send 2-3 requests in order to succeed, because essentially you’re trying to win a race condition here (time of check, time of use), due to the multiple validations that the Concrete CMS team have put in place previously.

Concrete CMS multiple vulnerabilities -SSRF protection bypass with DNS rebinding
Fetching the AWS IAM role using DNS rebinding

We got the AWS IAM role the instance is using:

Concrete CMS multiple vulnerabilities -SSRF fetching AWS IAM role
AWS IAM role
Concrete CMS multiple vulnerabilities -SSRF fetching AWS IAM keys from instance metadata
AWS IAM keys from instance metadata

The moral of this story is that there’s always one more trick to try, you just have to be persistent enough.

Password reset poisoning

We wrote previously about this type of attack on Drupal and Joomla. We thought of giving it a try here as well and it looks like we were right. Poisoning the host header below:

Concrete CMS multiple vulnerabilities -password reset poisoning
Malicious request to reset password

Will result in poisoning the password reset link.

Poisoned password reset link
Poisoned password reset link

And this is how the email looks like:

Email with poisoned link
Email with poisoned link


The Concrete CMS team fixed the SSRF and PrivEsc vulnerabilities, please download versions 8.5.7/9.0.1 or later. For the password poisoning issue please set the canonical url in the Concrete CMS admin panel. For more tips on Concrete CMS security please see the following page for best practices on configuration. Once again we would like to thank their team for their support and cooperation on addressing these issues in a prompt manner.


Multple vulnerabilities in Concrete CMS Part 1