Updated:  Drupal 8 Post

The three biggest content management systems (CMS) are:

• WordPress which controls over 50% of the market share.
• Joomla which controls a little over 6% of the market share.
• Drupal which controls a little under 5% of the market share.
  
  

Personally, we've been hosting, developing, and managing WordPress sites for over 5 years.  Joomla is the first CMS we've used and we've been hosting, developing, and managing it for over 10 years.  But when it comes to Drupal, we have very little experience other than exploiting it and almost exclusively with Drupalgeddon in the last few years.  Aside from that, we haven't seen a need to learn yet another content management system for the purpose of using it for its intended design.  

All that being said, I've personally felt the need to become more familiar Drupal from the attack position and that leads us to this post.  Despite using a Drupalgeddon exploit to create a user account on this specific machine, let's assume the site is NOT vulnerable to Drupalgeddon but we find ourselves with an account that allows us to access the Admin UI.  Once we get in, we want to exploit the Drupal system to get a reverse shell.

First, I will walk through the Drupalgeddon exploit which allowed me to create the account because this one is a little older and less used as of late.

We discover the Drupal site:





We run Droopescan to gather information regarding this Drupal installation:

The possible versions shown above are vulnerable to Drupalgeddon and we look through searchsploit to pick our poison:






Our goal is to get an account so we choose the one highlighted above. 

We execute:






Perfect!  We think we have an account.  Let's move to the Admin login and attempt to login:






And...





We're in!

The first thing we want to do is to select Modules:






Once on the Modules page, we want to scroll down to PHP filter:






We're going to enable PHP filter which "allows embedded PHP code...":






Prior to leaving this page, we want to scroll down to hit Save configuration:






Next, we're going to select Permissions off to the right of the PHP filter module:






We've enabled the ability to use PHP but we haven't given anyone rights to use it:






We're going to give rights to Administrator:






Again, scrolling down to the bottom to hit Save Configuration:






Choosing Content from the top menu, we're going to Add Content:






We're going to create a Basic page:






Before we jump to a full-on reverse shell, let's see if we can render phpinfo:






Prior to hitting save or preview, we need to change the Text format to PHP code:






I'd gone through this exercise a couple of times and it seemed that on the first instance of selecting preview, I did not get PHP to render.  Perhaps we need to change the Text format in advance of entering PHP or maybe it's just this particular install being buggy.  Just pointing that out in case it doesn't work the first time around.  

Choosing Preview:






Excellent!  We are rendering PHP.  Now let's move to Pentest Monkey's handy reverse shell:






Once again, we want to change that Text format to PHP code:






With our handler setup, we choose Preview:






Excellent!  We have a reverse shell.

I'm still in the process of exploring the UI and perhaps there's a method similar to when I've edited the footer of a WordPress site.  While effective, it's dirty and obvious to the site owner and visitors.  This method above is akin to the recent WordPress post where I used an Insert PHP plugin.  If one were attempting to be stealthy, you could login to a site, find an old post many pages back from the current posts, and use the above technique.  There wouldn't be any sign of tampering other than that old post which might go unnoticed for quite some time.  Situations may vary and it really depends on what you're trying to accomplish.