Intro
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?
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 😉
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 😉
SSRF
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.
We used a Collaborator payload from Burp Suite and we instantly got a callback:
AWS Instance metadata is blocked, oh no! Can we bypass these fixes?
They check for certain file extensions (.php & others) and you can’t use redirects either. What else can we do?
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.
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.
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.
We got the AWS IAM role the instance is using:
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:
Will result in poisoning the password reset link.
And this is how the email looks like:
Mitigations
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.
References
Multple vulnerabilities in Concrete CMS Part 1
About Post Author
